From ttmrichter at gmail.com Wed Dec 1 06:45:34 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Wed, 1 Dec 2010 13:45:34 +0800 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> <20101130150418.GB11084@topoi.pooq.com> Message-ID: On 1 December 2010 01:18, Jay K wrote: > In the case of templates leading to some meta programming, it was an > accident. > But in the case of operator overloading it seems just goodness. > I am badly conflicted in the case of operator overloading. In its favour we have: - more succinct code that clearly states intent (when overloaded properly) - opportunities to optimize calculations (like your example with intermediate forms for matrix manipulations) Countering that favour, however, we have: - idiots redefining operators in ways that are emphatically *not* proper in terms of semantics (operator<< and operator>> being obvious cases, but also operator+ for concatenation and some of the ... utterly painful uses for operator,) - the inability to define *new* operators (which leads to the first problem of idiots redefining the semantics of operators) - unexpected costs to operations making the eyeballing of execution complexity (time-wise and memory-wise) literally impossible - painful interaction with templates that makes a perfect storm of eye-damaging syntax -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 1 07:49:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Dec 2010 06:49:36 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, , , <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, <20101130150418.GB11084@topoi.pooq.com>, , Message-ID: opportunities to optimize calculations (like your example with intermediate forms for matrix manipulations) Just to be clear, that power is not easily created, and would not be do-able in the constrained form I suggested, where it is always, e.g. T +(T,T) > not proper in terms of semantics (operator<< and operator>> being obvious cases) This would not be allowed in my constrained proposal. > but also operator+ for concatenation This is very reasonable. > utterly painful uses for operator,) I'm surprised that is overloadable, but indeed it appears it is. I don't think I have *ever* seen anyone overload it, and I have seen a lot. > the inability to define new operators (which leads to the first problem of idiots redefining the semantics of operators) Stroupstroup rejected this as too complex. (See the Design&Evolution book). I don't see people pine for this often and I suspect he did the right thing. It creates a layering problem I believe in the typical structure. The lexical analysis would have to get information from higher layers. > unexpected costs to operations making the eyeballing of execution complexity (time-wise and memory-wise) literally impossible This is already the case. As I said. So let's say that every single function call is shown. It is hard to know which functions have which cost. There are also hidden function calls e.g. for "try" and every pointer derereference (right?) Please consider floating point. Historically floating point was "soft float". Sometimes these days it still us. Yet we still have operators for floating point. Why? Because it is just so convenient and idiomatic. Why stop there? A primary design point of C++ is to give user defined types all the powers of built in types. No longer does it require a compiler change to introduce a type with the "power" of int. And so on. > painful interaction with templates that makes a perfect storm of eye-damaging syntax Huh? Specifically? The one vague reason I don't fully understand is: C doesn't have it. Does C represent a good example of a sort of minimalism? Maybe. It isn't clear to me the value of C. It has been *very* widely abandoned in favor of C++. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Wed Dec 1 08:55:49 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 30 Nov 2010 23:55:49 -0800 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, , , <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, <20101130150418.GB11084@topoi.pooq.com>, , Message-ID: <20101201075549.426511A208F@async.async.caltech.edu> I think if you want overloaded operators, you code in Scheme or your own invented language and write a little compiler/translator (to C or Modula-3, for example), for the particular expressions you want to convert. You can have whatever crazy syntax and features you want if you do it that way, and it doesn't gum up everyone else's day... Mika P.S. People were listing things they liked about Modula-3 a few days ago. I'm surprised no one mentioned my favorite properties: -- no possibility of breaking existing code by adding new symbols to an interface, no matter how public -- no possibility of breaking existing code by adding new methods to an object type, no matter how widely exported or how widely used or "subclassed" about how many other programming languages can you say that? (Note also that these features are on a quite different level from Jay's list...) Jay K writes: >--_25139682-7cce-49b1-ae17-6a4dff3488ee_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > >opportunities to optimize calculations (like your example with intermediate= > forms for matrix manipulations) >Just to be clear=2C that power is not easily created=2C and would not be do= >-able in the constrained form I suggested=2C where it is always=2C e.g. T += >(T=2CT) > > > not proper in terms of semantics (operator<< and operator>> being obvio= >us cases) > >This would not be allowed in my constrained proposal. > >> but also operator+ for concatenation > >This is very reasonable. > > > utterly painful uses for operator=2C) > > >I'm surprised that is overloadable=2C but indeed it appears it is. I don't = >think I have *ever* seen anyone overload it=2C and I have seen a lot. > > > > > the inability to define new operators (which leads to the first problem = >of idiots redefining the semantics of operators) > > >Stroupstroup rejected this as too complex. (See the Design&Evolution book). >I don't see people pine for this often and I suspect he did the right thing= >. >It creates a layering problem I believe in the typical structure. >The lexical analysis would have to get information from higher layers. > > > > unexpected costs to operations making the eyeballing of execution comple= >xity (time-wise and memory-wise) literally impossible > > >This is already the case. As I said. So let's say that every single functio= >n call is shown. It is hard to know which functions have which cost. >There are also hidden function calls e.g. for "try" and every pointer derer= >eference (right?) > > >Please consider floating point. Historically floating point was "soft float= >". Sometimes these days it still us. Yet we still have operators for floati= >ng point. >Why? Because it is just so convenient and idiomatic. Why stop there? > > >A primary design point of C++ is to give user defined types all the powers = >of built in types. >No longer does it require a compiler change to introduce a type with the "p= >ower" of int. And so on. > > > >> painful interaction with templates that makes a perfect storm of eye-dama= >ging syntax >Huh? Specifically? > >The one vague reason I don't fully understand is: C doesn't have it. >Does C represent a good example of a sort of minimalism? Maybe. >It isn't clear to me the value of C. It has been *very* widely abandoned in= > favor of C++. > > - Jay > = > >--_25139682-7cce-49b1-ae17-6a4dff3488ee_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >
  • opportunities to optimize calculations (like your example with = >intermediate forms for matrix manipulations)

Just to be clear= >=2C that power is not easily created=2C and would not be do-able in the con= >strained form I suggested=2C where it is always=2C e.g. T +(T=2CT)

<= >div class=3D"ecxgmail_quote"> =3B>=3B =3B not =3Bprope= >r in terms of semantics (e=3D"'courier new'=2C monospace">operator<=3B<=3B and e=3D"" class=3D"ecxApple-style-span" face=3D"'courier new'=2C monospace">op= >erator>=3B>=3B being obvious cases)

This would not be all= >owed in my constrained proposal.

>=3B but also ass=3D"ecxApple-style-span" face=3D"'courier new'=2C monospace">operator+font> for concatenation

This is very reasonable.

 =3B>= >=3B utterly painful uses for face=3D"'courier new'=2C monospace">operator=2C)


I'm sur= >prised that is overloadable=2C but indeed it appears it is. I don't think I= > have *ever* seen anyone overload it=2C and I have seen a lot.
>

 =3B>=3B the inability to define new =3Boperators = >(which leads to the first problem of idiots redefining the semantics of ope= >rators)


Stroupstroup rejected this as too complex. (See the Desi= >gn&=3BEvolution book).
I don't see people pine for this often and I s= >uspect he did the right thing.
It creates a layering problem I believe i= >n the typical structure.
The lexical analysis would have to get informat= >ion from higher layers.


 =3B>=3B unexpected costs to opera= >tions making the eyeballing of execution complexity (time-wise and memory-w= >ise) literally impossible


This is already the case. As I said. S= >o let's say that every single function call is shown. It is hard to know wh= >ich functions have which cost.
There are also hidden function calls e.g.= > for "try" and every pointer derereference (right?)


Please consi= >der floating point. Historically floating point was "soft float". Sometimes= > these days it still us. Yet we still have operators for floating point.>Why? Because it is just so convenient and idiomatic. Why stop there?
r>
A primary design point of C++ is to give user defined types all the p= >owers of built in types.
No longer does it require a compiler change to = >introduce a type with the "power" of int. And so on.


>>=3B painful interaction with templates that makes a perfect storm of eye= >-damaging syntax
Huh? Specifically?

The one vague reason I = >don't fully understand is: C doesn't have it.
Does C represent a good ex= >ample of a sort of minimalism? Maybe.
It isn't clear to me the value of = >C. It has been *very* widely abandoned in favor of C++.

 =3B- Ja= >y
>= > >--_25139682-7cce-49b1-ae17-6a4dff3488ee_-- From dragisha at m3w.org Wed Dec 1 09:18:55 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 1 Dec 2010 09:18:55 +0100 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, , , <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, <20101130150418.GB11084@topoi.pooq.com>, , Message-ID: <4C27C8EE-5A26-456A-A0D7-EC176113CCB5@m3w.org> Look for Modula-2 R10 and how they spec'd it. On Dec 1, 2010, at 7:49 AM, Jay K wrote: > A primary design point of C++ is to give user defined types all the powers of built in types. > No longer does it require a compiler change to introduce a type with the "power" of int. And so on. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed Dec 1 17:00:10 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 01 Dec 2010 10:00:10 -0600 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: , , <4CF42AEE.3000807@lcwb.coop>, , <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> Message-ID: <4CF6710A.4010907@lcwb.coop> Jay K wrote: >> generics are good, but not as good as C++ templates On the contrary, Modula-3 generics are overall, *far* superior to C++ templates, which are a language complexity nightmare, about as bad as user-defined overloading. Modula-3 generics are vastly simpler, yet more flexible. (Modula-3 generics do achieve this at the cost of a small inconvenience.) Here is a comparison I wrote some time ago of the generic/template facilities of Ada, C++, and Modula-3: ----------------------------------------------------------------------- Some comparisons of generics/templates in Ada, C++, and Modula-3 C++'s template facility is *vastly* more complicated than Modula-3's. C++(2003) has a 58-page chapter on templates, more that the entire Modula-3 reference. Additionally, C++ has a lot of additional material on templates woven throughout the rest of the language. Modula-3 devotes 2 pages to its generics and defines them with a translation to equivalent, generic-free code, so that they need not be mentioned elsewhere. Ada's generics are a bit less complicated than C++'s, but not a whole lot. Here are some of the sources of the gratuitous complexity: Confused identifier resolution Probably the worst source of C++'s template complexity derives from interaction with the identifier resolution rules it inherits from C. They were already cobbled-up in C and got worse in C++. In a single scope, the same identifier can be declared with different meanings, most importantly, two different ways of naming types (typedef names, class names), neither of which is sufficient by itself, and ordinary identifiers (variables and functions). The rules for deciding what an identifier reference actually means are highly dependent on the context of the reference. Moreover, the very syntax depends on the surrounding declarations. The template facility makes this immeasurably worse, because, in a template, the needed context is not there. So this is fixed by new and different syntactic and semantic rules for making the distinction. In contexts where the syntax does not determine whether a type or ordinary meaning is needed, the presence or absence of 'typename' (or a class key) makes the needed distinction. But there are several contexts where the syntax does imply that a type is needed, and these are full of inconsistency. In some, 'typename' is required, in others, it is optional, and in yet others, it is not allowed. So a programmer cannot just establish a habit of always doing it a certain way. None of this conveys any useful function to the language. In Modula-3 and Ada, all identifiers in a scope are really in the same scope, and both the syntax and rules for looking up identifiers are independent of the referencing context. A drastic simplification. Many kinds of template/generic units Another source is the ability to have several kinds of template units (functions, classes, member functions, member templates, etc.) and template parameters. Moreover, these are not necessarily tied to separate compilation units. Like C++, Ada also allows several kinds of units, not necessarily separately compiled, to be generic, instantiated, and in the case of procedures, generic parameters. In Modula-3, only interfaces and modules can be generic, and only interfaces can be generic parameters. But since an interface or module can contain any declarable entity, the result is every bit as flexible, probably even more so. Yet this greatly simplifies generics. It does come at a price of minor inconvenience by requiring more very small, separately compiled interfaces and modules as instantiations and more small interfaces as generic actuals. As an aside, the ability to create instantiations using the build system is only an added convenience, not mandated by the language. You can always write Modula-3 code for all instantiations and generic actuals, with no more burden added to the build system or its use by than ordinary, non-generic interfaces and modules. The Quake commands we have in the implementations of Modula-3 merely generate common cases of these almost trivial compilation units, as a quicker alternative. All instantiations are anonymous Yet another source of complexity in C++ is the lack of named instantiations. Everywhere you want to refer to an instantiation, you have to repeat is full structural definition, complete with repeats of the template actuals. This makes some code awfully pedantic. It gets worse when there are nested instantiations. And, of course, it complicates the language itself. Aside from language complexity, this also creates a very difficult problem for an implementation, because it must locate and combine all the structurally-equivalent instantiations, even from separate compilations. This the worst source of very highly mangled linker names. In both Ada and Modula-3, you always declare a name for an instantiation, attached to its definition, providing the generic actuals exactly once here. Then you use the name (a single identifier) everywhere else. If you don't want multiple copies of structurally-equivalent instantiations to be compiled, you just take care to code it this way, as is the case in virtually all other constructs in all languages. The implementation doesn't need to find the duplicates. Static checkability of template/generic units One source of complexity in Ada's generics is Ada's policy that a generic can be fully statically checked in the absence of any instantiation. The instantiations have some semantic rules that must still be applied, but they don't involve anything but the normal kinds of interface properties of the generic unit. An instantiation cannot cause internal semantic errors to pop up inside the generic. (In Ada 83, there was one language bug in this property. It was fixed in the next version, Ada 99.) This is a very nice property. Unfortunately, it complicates the language greatly. On the one hand, there has to be an elaborate set of rules about what kinds of generic parameters are allowed at all and how different generic parameters of a single generic unit can be interrelated. The programmer then has to specify these relationships. Inevitably, while this system of rules is complicated, it is also incomplete. C++ and Modula-3 postpone semantic checking until instantiation time, which removes these limitations, at the cost that an instantiation could mysteriously fail to compile if the actuals don't have the right properties. The compile errors will likely be deep inside the body of the generic--where the instantiator would ideally not need to venture. Modula-3 at least informally encourages the writers of generics to write comments spelling out the necessary properties of the generic actuals. AFAIK, C++ does not. This postponement sacrifices a very nice property for static checking. In Modula-3, the sacrifice buys a lot of simplicity and some increased flexibility. C++ gives the worst of both worlds, as the same static checking is lost, with no simplicity benefit. Interaction with overloading Both C++ and Ada allow user-defined overloading of both operators and procedure/function identifiers. This creates massive language complexity in many ways. A template/generic facility provides more things to interact with overloading, heaping on more complexity. ----------------------------------------------------------------------- From ttmrichter at gmail.com Thu Dec 2 07:36:05 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Thu, 2 Dec 2010 14:36:05 +0800 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> <20101130150418.GB11084@topoi.pooq.com> Message-ID: On 1 December 2010 14:49, Jay K wrote: > > *not* proper in terms of semantics (operator<< and operator>> being > obvious cases) > > This would not be allowed in my constrained proposal. > How would you stop it? How would you enforce a rule that says "<<" means that you are somehow shifting something to the left, even if the representation isn't a binary integer? How would you enforce a rule that says "+" must add, not concatenate, subtract, multiply or reset the computer? > > but also operator+ for concatenation > > This is very reasonable. > No, it is not. The semantics of concatenation are hugely different from the semantics of addition. Consider 3+4 vs. 4+3. Now consider "three"+"four" vs. "four"+"three". If you want to do concatenation, have an operator for concatenation. (++, say, as a random example.) Do not overload addition with an operation that isn't even vaguely analogous. > > utterly painful uses for operator,) > > I'm surprised that is overloadable, but indeed it appears it is. I don't > think I have *ever* seen anyone overload it, and I have seen a lot. > I would tell you how I used it, but I'm utterly ashamed of that portion of my life. ;) (It was in a type-safe SQL query builder.) > > the inability to define *new* operators (which leads to the first > problem of idiots redefining the semantics of operators) > > Stroupstroup rejected this as too complex. (See the Design&Evolution book). > Stroustrup is, not to put too fine a point on this, a gibbering lunatic. He rejected defining new operators as "too complex" -- yet created a language that to this day is nigh-impossible to implement according to specification (a situation that will be made even worse with the never-arriving C++1x). In the meantime languages far simpler than C++ (syntactically, at least) have had the ability to define new operators at will for ages. Haskell, for example, as a top of my head instance. Prolog too, if memory serves. Personally, I'd much rather try to implement a parser for Haskell or Prolog or languages in that vein than I would a C++ parser. > I don't see people pine for this often and I suspect he did the right > thing. > People don't pine for it often because people don't pine for capabilities they don't know exist. Most people don't pine for hygenic macro systems either -- until they use them in languages that provide that kind of capability. People didn't pine for RTTI in C++ either ... until it became available in some compilers and other compilers seemed far more constrained. People didn't pine for automated memory management ... until Java came along and made it mainstream. People didn't pine for multi-threading ... until everybody and their dog supported it. Hell, people didn't pine, by and large, for *operator overloading *until C++ made it mainstream! What people pine for vs. what people need or at least can truly use are such radically disjoint sets that I often use what people pine for as a hint for what to *avoid*. > It creates a layering problem I believe in the typical structure. > The lexical analysis would have to get information from higher layers. > Or you could go the Haskell route. Any token that consists of purely "special symbols" is an operator that can be used directly as an operator. To use it as a regular function you need to wrap it in parens. This means I can define, say, a "UFO operator" like <=+=+=+=> (made deliberately gonzo for fun) and use it as-is--e.g.: Expr1 <=+=+=+=> Expr2--or as a two-parameter function call--(<=+=+=+=>) Expr1 Expr2. Further you can go more down the Haskell route and make any function usable as an operator: myFunc Expr1 Expr2 is equally usable as Expr1 `myFunc` Expr2. Can you see how lexical analysis can trivially identify your operator definitions and usage here? > > unexpected costs to operations making the eyeballing of execution > complexity (time-wise and memory-wise) literally impossible > > This is already the case. As I said. So let's say that every single > function call is shown. It is hard to know which functions have which cost. > There are also hidden function calls e.g. for "try" and every pointer > derereference (right?) > Operator overloading can multiply these by orders of magnitude and have the added problem of being, in effect, "COME FROM" statements. I mean they're not as bad in this regard as, say, Aspect-Oriented Programming, but they're still pretty nasty. The fact that features X and Y have hidden costs is not really a good argument for adding feature Z that has all those hidden costs and an order of magnitude more all concealed in such a way that it is almost impossible to keep track of where things are really going. > Please consider floating point. Historically floating point was "soft > float". Sometimes these days it still us. Yet we still have operators for > floating point. > Why? Because it is just so convenient and idiomatic. Why stop there? > Because at some point the costs outweigh the benefits. Operator overloading is at just that cusp point for me to be torn. It has some major benefits, but it has major costs and right now I actually lean slightly in the direction of thinking the costs outweigh the benefits. (A few years ago I leaned slightly in the other direction, mind, so it, as a feature is not something I'm going to reject a language for.) > A primary design point of C++ is to give user defined types all the powers > of built in types. > No longer does it require a compiler change to introduce a type with the > "power" of int. And so on. > Instead it allows you to introduce a type that looks like an int but has such wildly varying semantics that it will confuse the ever living daylights out of people using it. Like using "+" for concatenation. > > painful interaction with templates that makes a perfect storm of > eye-damaging syntax > > Huh? Specifically? > My C++ days are a decade behind me so I no longer have any source that illustrates this. I just recall that any time we had a templated class with overloaded operators that it turned into an asinine stew of unreadable code. > The one vague reason I don't fully understand is: C doesn't have it. > Does C represent a good example of a sort of minimalism? Maybe. > It isn't clear to me the value of C. It has been *very* widely abandoned in > favor of C++. > What is the FFI lingua franca again? C or C++? (Hint: one of those two languages has syntax to make it compatible with the other, but not vice versa.) -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 2 07:53:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 2 Dec 2010 06:53:37 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, , , <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, <20101130150418.GB11084@topoi.pooq.com>, , , , Message-ID: > What is the FFI lingua franca again? C or C++? C is fairly lingua franca, but how do I *efficiently* *portably* implement exception handling? NT, Tru64, VMS all extend C slightly to allow it. I don't believe C on any other system does. C also doesn't offer "good idioms" for operator overloading. Easy enough for a target language, but as we are discussing here, not for a source language. + for String really is ok. Java, C++, C#. I realize it has completely different meaning than for integers, but even float vs. int are quite different in what + means. You know, big + small float == big. At this point, probably millions of programmers are comfortable with + being concat. At least in statically typed systems, where 3 and "3" are clearly different. > Any token that consists of purely "special symbols" is an operator that > can be used directly as an operator This changes the meaning of existing code in both C/C++ and Modula-3. e.g.: a:=+b; a:=-b; a:=--b; a:=---b; Maybe this can be resolved though. Still, I think there is plenty value in overloading existing operators. As well, one might just go ahead and define new rules for "unused" characters, if we have any. e.g. tilde, percent? > What people pine for vs. what people need or at least can truly use are > such radically disjoint sets that I often use what people pine for as a > hint for what to avoid. True. > How would you enforce a rule that says "<<" means that you are somehow > shifting something to the left My proposal was, like, that + is always T +(T,T). Similar for *, -, DIV. For << I think it'd always be T <<(T, integer). := would also be, like, := (T designator?, T) Granted, the semantic could still be arbitrary. But you wouldn't be able to define the family: <<(stream, integer) <<(stream, text) <<(stream, float) so that'd probably stop you from <<(stream, integer) meaning to print an integer. This limited form of operator overloading supports many scenarios. It does not however support the Blitz++ construct that optimizes all temporaries out of matrix/vector math. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Dec 2 08:59:35 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 2 Dec 2010 08:59:35 +0100 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, , , <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, <20101130150418.GB11084@topoi.pooq.com>, , , , Message-ID: <0E7D490B-41B9-4B90-B689-A280B2B2E0C8@m3w.org> Then obviously you are hitting blind alley there. Go other route. For example, LLVM route. On Dec 2, 2010, at 7:53 AM, Jay K wrote: > > What is the FFI lingua franca again? C or C++? > > > C is fairly lingua franca, but how do I *efficiently* *portably* > implement exception handling? NT, Tru64, VMS all extend C slightly > to allow it. I don't believe C on any other system does. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 2 10:17:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 2 Dec 2010 09:17:32 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: <0E7D490B-41B9-4B90-B689-A280B2B2E0C8@m3w.org> References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, , , , , , <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, , <20101130150418.GB11084@topoi.pooq.com>, , , , , , , , , , <0E7D490B-41B9-4B90-B689-A280B2B2E0C8@m3w.org> Message-ID: The gcc intermediate form does support exception handling. Efficient exception handling doesn't motivate gcc to llvm switch. As well, generating C++ is a good option for this reason. At least on non-NT/Tru64/VMS systems. As well, since this is multiple axes, an initial C backend could generate code like we do today -- pthread_getspecific/setjmp. Switching to LLVM is a big task. - Jay From: dragisha at m3w.org Date: Thu, 2 Dec 2010 08:59:35 +0100 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Enumeration or subrange value out of range Then obviously you are hitting blind alley there. Go other route. For example, LLVM route. On Dec 2, 2010, at 7:53 AM, Jay K wrote:> What is the FFI lingua franca again? C or C++? C is fairly lingua franca, but how do I *efficiently* *portably* implement exception handling? NT, Tru64, VMS all extend C slightly to allow it. I don't believe C on any other system does. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Dec 2 10:29:24 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 2 Dec 2010 10:29:24 +0100 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, , , , , , <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, , <20101130150418.GB11084@topoi.pooq.com>, , , , , , , , , , <0E7D490B-41B9-4B90-B689-A280B2B2E0C8@m3w.org> Message-ID: On Dec 2, 2010, at 10:17 AM, Jay K wrote: > The gcc intermediate form does support exception handling. > Efficient exception handling doesn't motivate gcc to llvm switch. > As well, generating C++ is a good option for this reason. > At least on non-NT/Tru64/VMS systems. > As well, since this is multiple axes, an initial C backend could generate code > like we do today -- pthread_getspecific/setjmp. > > Switching to LLVM is a big task. As big as making C++ backend? I don't see it as a switch. Just as another backend. And yes, I know it's easier from audience. It is your call, but anything C, C++, GCC is pain long term. We will probably all reap benefits of that C backend, as good intermediate solution if nothing else, but sooner we settle on LLVM, and forget GCC's wriggling backend, better. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 2 10:41:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 2 Dec 2010 09:41:13 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, ,,, ,,, ,,<16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, ,,<20101130150418.GB11084@topoi.pooq.com>, ,,, ,,, ,,, , , , , , , <0E7D490B-41B9-4B90-B689-A280B2B2E0C8@m3w.org>, , Message-ID: A C/C++ backend is definitely easier than anything else. It requires no learning of the target form! I know C and C++ very well, very little of C++ is relevant, mainly exception handling (*), and surely there is far more familiarity in the world of C and C++ than LLVM or gcc trees. * -- other parts of C++ might be interesting, such as putting module initializers in statics with constructors. This feature of C++ doesn't work well, but this would possibly help e.g. LoadLibrary/dlopen(mod3.dll) run the module initializers. Though here again, there is a way to do in C for NT and probably C in general, with platform-specific code. - Jay From: dragisha at m3w.org Date: Thu, 2 Dec 2010 10:29:24 +0100 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Enumeration or subrange value out of range On Dec 2, 2010, at 10:17 AM, Jay K wrote:The gcc intermediate form does support exception handling. Efficient exception handling doesn't motivate gcc to llvm switch. As well, generating C++ is a good option for this reason. At least on non-NT/Tru64/VMS systems. As well, since this is multiple axes, an initial C backend could generate code like we do today -- pthread_getspecific/setjmp. Switching to LLVM is a big task. As big as making C++ backend? I don't see it as a switch. Just as another backend. And yes, I know it's easier from audience. It is your call, but anything C, C++, GCC is pain long term. We will probably all reap benefits of that C backend, as good intermediate solution if nothing else, but sooner we settle on LLVM, and forget GCC's wriggling backend, better. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ttmrichter at gmail.com Thu Dec 2 13:51:08 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Thu, 2 Dec 2010 20:51:08 +0800 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> <20101130150418.GB11084@topoi.pooq.com> Message-ID: On 2 December 2010 14:53, Jay K wrote: > + for String really is ok. > We will have to agree to disagree here. I really cannot stand having addition and concatenation using the same operator. It bugs me at a very profound level, even more than using left- and right-shift operators for output and input. > At this point, probably millions of programmers are comfortable > with + being concat. At least in statically typed systems, > where 3 and "3" are clearly different. > At this point millions of programmers are comfortable programming without a clean separation between interface and implementation. I still prefer the Modula series of languages and would not want them to change into an abortion like C++. > > Any token that consists of purely "special symbols" is an operator that > > can be used directly as an operator > > This changes the meaning of existing code in both C/C++ and Modula-3. > > e.g.: > a:=+b; > a:=-b; > a:=--b; > a:=---b; > I wasn't actually suggesting that we directly use Haskell's system. I was just pointing out that it's trivial to allow operators to be defined by the programmer without having the lexer communicating outside of the lexing process. It's a matter of language design. Were I to retrofit a "define new operator" mechanism into an established language like Modula-3, I'd probably insist that user-added operators be wrapped in something like backquotes. So a hypothetical concatenation operator might become `++`. Basically user-defined operators would have to have some way to uniquely identify themselves as such to the lexer in the absence of a language built from scratch to support them. > Still, I think there is plenty value in overloading existing operators. > There can be, yes. It's just that I've seen more abuse of operator overloading than I have good uses. This makes me nervous of having them, even though they *really are* damned convenient when used correctly. -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Dec 2 15:12:56 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 2 Dec 2010 09:12:56 -0500 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> <20101130150418.GB11084@topoi.pooq.com> Message-ID: <20101202141256.GA17591@topoi.pooq.com> On Thu, Dec 02, 2010 at 02:36:05PM +0800, Michael Richter wrote: > On 1 December 2010 14:49, Jay K wrote: > > No, it is not. The semantics of concatenation are hugely different from the > semantics of addition. Consider 3+4 vs. 4+3. > Now consider "three"+"four" > vs. "four"+"three". If you want to do concatenation, have an operator for > concatenation. (++, say, as a random example.) Do not overload addition > with an operation that isn't even vaguely analogous. The semantics of matrix multiplication are hugely different from those of integer multiplication. Consider A*B vs B*A. By this this doesn't mean that we necessarily need a different operator symbol. For string concatenation, there's even a homomorphism (length) mapping it to natural number addition. Just like determinant for matrices. > > > > > utterly painful uses for operator,) > > > > > > I'm surprised that is overloadable, but indeed it appears it is. I don't > > think I have *ever* seen anyone overload it, and I have seen a lot. > > > > I would tell you how I used it, but I'm utterly ashamed of that portion of > my life. ;) (It was in a type-safe SQL query builder.) That sounds as if you were defining . to be a reasonable approximation to SQL's . That sounds like a reasonable thing to do -- except if any of its uses would have to be disambiguated with C++'s hopelessly complicated disambiguation rules. > > Operator overloading can multiply these by orders of magnitude and have the > added problem of being, in effect, "COME FROM" statements. Those were fun. Good thing no one took hem seriously. > My C++ days are a decade behind me so I no longer have any source that > illustrates this. I just recall that any time we had a templated class with > overloaded operators that it turned into an asinine stew of unreadable code. > > > > The one vague reason I don't fully understand is: C doesn't have it. > > Does C represent a good example of a sort of minimalism? Maybe. > > It isn't clear to me the value of C. It has been *very* widely abandoned in > > favor of C++. I use the subset of C++ that's more or less equivalent to C. It gives me slightly better type-checking, but that's the main benefit. Very rarely I use single inheritance. If I do anything that involves a lot of that, I prefer Modula 3. > > What is the FFI lingua franca again? C or C++? (Hint: one of those two > languages has syntax to make it compatible with the other, but not vice > versa.) C has interfacing specs that are more or less consistent from machine to machine. C++ doesn't seem to. > > -- > "Perhaps people don't believe this, but throughout all of the discussions of > entering China our focus has really been what's best for the Chinese people. > It's not been about our revenue or profit or whatnot." > --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. More demonstrating how difficult some ethical decisions, even with the best of intentions. - hendrik From hendrik at topoi.pooq.com Thu Dec 2 15:22:03 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 2 Dec 2010 09:22:03 -0500 Subject: [M3devel] Code generation (was: Enumeration or subrange value out of range) In-Reply-To: References: <0E7D490B-41B9-4B90-B689-A280B2B2E0C8@m3w.org> Message-ID: <20101202142203.GB17591@topoi.pooq.com> On Thu, Dec 02, 2010 at 09:17:32AM +0000, Jay K wrote: > > The gcc intermediate form does support exception handling. > Efficient exception handling doesn't motivate gcc to llvm switch. > As well, generating C++ is a good option for this reason. > At least on non-NT/Tru64/VMS systems. > As well, since this is multiple axes, an initial C backend could generate code > like we do today -- pthread_getspecific/setjmp. > > Switching to LLVM is a big task. > > - Jay We seem to have switched from language design to Modula 3 implementatin decisions. Are either LLVN or gcc-intermediate as well-documented as C--, C, or C++? Too bad C-- seems to be somewhat lacking in implementatins of multiple kinds of hardware. It's otherwise excellent. -- hendrik From ttmrichter at gmail.com Thu Dec 2 15:36:59 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Thu, 2 Dec 2010 22:36:59 +0800 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: <20101202141256.GA17591@topoi.pooq.com> References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> <20101130150418.GB11084@topoi.pooq.com> <20101202141256.GA17591@topoi.pooq.com> Message-ID: On 2 December 2010 22:12, Hendrik Boom wrote: > > The semantics of concatenation are hugely different from the > > semantics of addition. Consider 3+4 vs. 4+3. > > Now consider "three"+"four" > > vs. "four"+"three". If you want to do concatenation, have an operator > for > > concatenation. (++, say, as a random example.) Do not overload addition > > with an operation that isn't even vaguely analogous. > > The semantics of matrix multiplication are hugely different from those > of integer multiplication. Consider A*B vs B*A. > This is why, if memory serves, there's two different "multiplication" operations and operators for matrices? > > > I'm surprised that is overloadable, but indeed it appears it is. I > don't > > > think I have *ever* seen anyone overload it, and I have seen a lot. > > > I would tell you how I used it, but I'm utterly ashamed of that portion > of > > my life. ;) (It was in a type-safe SQL query builder.) > > That sounds as if you were defining . to be a reasonable approximation > to SQL's . That sounds like a reasonable thing to do -- except if any of > its uses would have to be disambiguated with C++'s hopelessly > complicated disambiguation rules. > Yeah, that was a problem. It also required some utterly retarded constructs like function calls that had double-parentheses because the comma is used differently in argument lists than in expressions and so forth. The final product was marginally better to use than the traditional format string-style SQL statement builders, but only marginally so and at a huge expense in implementation comprehension (and thus testing and debugging). > > Operator overloading can multiply these by orders of magnitude and have > the > > added problem of being, in effect, "COME FROM" statements. > > Those were fun. Good thing no one took hem seriously. > Sure they did. It's called "Aspect-Oriented Programming". ;) > I use the subset of C++ that's more or less equivalent to C. It gives > me slightly better type-checking, but that's the main benefit. > I think this plus limited use of inheritance is the majority use of C++. > > What is the FFI lingua franca again? C or C++? (Hint: one of those two > > languages has syntax to make it compatible with the other, but not vice > > versa.) > > C has interfacing specs that are more or less consistent from machine to > machine. > > C++ doesn't seem to. > C++ doesn't even have interfacing specs that are consistent and compatible from compiler to compiler. Or, often, compiler version to compiler version in the same family. > > "Perhaps people don't believe this, but throughout all of the discussions > of > entering China our focus has really been what's best for the Chinese > people. > It's not been about our revenue or profit or whatnot." > --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. More demonstrating how difficult some ethical decisions, even with the best of intentions. This presumes you actually believe what Brin says. I don't. I think revenue and profit was their only concern in moving into China and a lack thereof on both fronts was their motive to leave. -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 2 15:48:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 2 Dec 2010 14:48:35 +0000 Subject: [M3devel] Code generation (was: Enumeration or subrange value out of range) In-Reply-To: <20101202142203.GB17591@topoi.pooq.com> References: <0E7D490B-41B9-4B90-B689-A280B2B2E0C8@m3w.org>, , <20101202142203.GB17591@topoi.pooq.com> Message-ID: > Are either LLVN or gcc-intermediate as well-documented as C--, C, or > C++? > Too bad C-- seems to be somewhat lacking in implementatins of multiple > kinds of hardware. It's otherwise excellent. gcc-intermediate isn't necessarily poorly documented or changes much, but C and C++ are clearly the better documented forms. Just go to a bookstore. And even if they weren't better documented, there is much broader experience with them, by me and the wider world. It's a numbers thing. I have written thousands of lines of C and C++ and overall millions or billions have been written. Most of mine have been compiled by one line of compilers, but not all, and, in reality, I don't believe a backend would use the language(s) very intensely. The main reason I advocate C++ as a target vs. C is for portable efficient exception handling. (As well, Visual C++ I think is closer to the standard in terms of lack of extensions than gcc; I have also compiled some code with its /Za switch that disables extensions.) I should point out that nested functions will probably pose a small problem. Using "this" in C++ might help some, esp. to get the extra parameter efficiently passed on 32bit x86. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Dec 2 19:08:41 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 2 Dec 2010 13:08:41 -0500 Subject: [M3devel] Code generation (was: Enumeration or subrange value out of range) In-Reply-To: References: <20101202142203.GB17591@topoi.pooq.com> Message-ID: <20101202180841.GA2541@topoi.pooq.com> On Thu, Dec 02, 2010 at 02:48:35PM +0000, Jay K wrote: > > > Are either LLVN or gcc-intermediate as well-documented as C--, C, or > > C++? > > Too bad C-- seems to be somewhat lacking in implementatins of multiple > > kinds of hardware. It's otherwise excellent. > > > gcc-intermediate isn't necessarily poorly documented or changes much, > but C and C++ are clearly the better documented forms. > Just go to a bookstore. > > > And even if they weren't better documented, there is much broader > experience with them, by me and the wider world. > > > It's a numbers thing. I have written thousands of lines of C and C++ > and overall millions or billions have been written. > > > Most of mine have been compiled by one line of compilers, but not all, > and, in reality, I don't believe a backend would use the language(s) > very intensely. The main reason I advocate C++ as a target vs. C > is for portable efficient exception handling. > (As well, Visual C++ I think is closer to the standard in terms > of lack of extensions than gcc; I have also compiled some code > with its /Za switch that disables extensions.) > > > I should point out that nested functions will probably pose a small problem. > Using "this" in C++ might help some, esp. to get the extra parameter efficiently > passed on 32bit x86. I've used "this" trick for environments in a language in which almost every source line resulted in multiple functions, each with its own environment. I ended up with a huge number of classes and enormous link times. I'm not at all sure that the many classes were the cause of the link times. That was about 20 years ago. -- hendrik From mika at async.async.caltech.edu Thu Dec 2 20:29:19 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Thu, 02 Dec 2010 11:29:19 -0800 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: <20101202141256.GA17591@topoi.pooq.com> References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> <20101130150418.GB11084@topoi.pooq.com> <20101202141256.GA17591@topoi.pooq.com> Message-ID: <20101202192919.AFAE01A209B@async.async.caltech.edu> Hendrik Boom writes: >On Thu, Dec 02, 2010 at 02:36:05PM +0800, Michael Richter wrote: >> On 1 December 2010 14:49, Jay K wrote: >> >> No, it is not. The semantics of concatenation are hugely different from the >> semantics of addition. Consider 3+4 vs. 4+3. >> Now consider "three"+"four" >> vs. "four"+"three". If you want to do concatenation, have an operator for >> concatenation. (++, say, as a random example.) Do not overload addition >> with an operation that isn't even vaguely analogous. > >The semantics of matrix multiplication are hugely different from those >of integer multiplication. Consider A*B vs B*A. Ummm... integer multiplication is a special case of matrix multiplication.... Mika From jay.krell at cornell.edu Tue Dec 7 23:45:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 7 Dec 2010 22:45:36 +0000 Subject: [M3devel] ongoing hardware clearance -- anyone want a working Alpha, Sparcs? Message-ID: ongoing hardware clearance.. The hardware clearance is ongoing. In particular, with mixed feelings, my only HPPA/HP-UX/Linux machine is gone. On the other hand, last night I installed Linux/alpha and it can soon be in Hudson (albeit with a 9GB hard drive, which has proven challenging on Linux/sparc). This is the first I've had an Alpha locally up and running. I'm torn: keep the machine, running Linux Linux has the advantage of having Java across all architectures, so easily put into Hudson keep the machine, try NetBSD, OpenBSD, FreeBSD (6.4), VMS, Tru64. *BSD generally lack Java except on x86/AMD64. VMS would be nice to get working. It was on the machine originally. Tru64 probably redundant with Mika's machine, which we should try to get into Hudson. Get rid of the machine. I have 2 other Alphas, physically smaller, don't know yet if they work. Fourth Alpha already gone, not sure it worked. Machine is like: alphaev5 266MHz ? 256MB ? 9GB CD-ROM drive noticably slow but working ok no video out -- using serial console -- a fun rare little exercise :) (the other hand is easily implemented as Windows XP laptop running Hyperterm, using a USB to serial device, they run about $20; someday I might try a dedicated serial terminal device) Linux/sparc might be on the chopping block soon too. Someone to host that would be nice. Shipping outside the US is generally too expensive. The current Hudson node has no takers on ebay yet. http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=120657135772 I do have some other Sparcs I haven't used yet, might try them, or might get rid of them. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Dec 11 13:09:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 11 Dec 2010 12:09:48 +0000 Subject: [M3devel] Linux/Alpha working, uploaded archives Message-ID: Alpha/Linux works, builds itself, Juno comes up. There are builds here: http://modula3.elegosoft.com/cm3/uploaded-archives/ built on Debian 5.0. Debian 6.0 drops support for Alpha. It was easy as usual: setup the machine workaround one small gcc bug get the jmpbuf size, and the ucontext field My intention is to: not keep the machine up and running, not in Hudson go through and get OpenBSD, FreeBSD, NetBSD, VMS to work, however: so far I haven't been able to boot OpenBSD, NetBSD on my DS10L, FreeBSD doesn't see the hard drive, Linux works fine, and the I seem to have toasted the machine I was using so: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=120659104744 If anyone knows how to fix that, please let me know, thanks. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sat Dec 11 23:19:02 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 11 Dec 2010 14:19:02 -0800 Subject: [M3devel] cm3 on snow leopard? Message-ID: <20101211221902.B71F81A207C@async.async.caltech.edu> Hello m3devel, I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook Air, but it seems I have the wrong assembler? I had to force dpkg to override the architecture on install (it was expecting i386, I think, and my machine identified itself as being "i386-darwin"?) Here are some details... [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version Critical Mass Modula-3 version 5.8.6 last updated: 2010-04-11 compiled: 2010-07-14 21:27:23 configuration: /usr/local/cm3/bin/cm3.cfg host: I386_DARWIN target: I386_DARWIN compiling an empty Main.m3 yields: [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands --- building in ../I386_DARWIN --- cd ../I386_DARWIN rm .M3SHIP rm .M3OVERRIDES inhale prog.mx inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a new source -> compiling Main.m3 m3front ../src/Main.m3 -w1 /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno-reorde r-blocks Main.mc -o Main.ms echo "rep movsl" | as -o /dev/null 2> /dev/null as Main.ms -o Main.mo Main.ms:15:suffix or operands invalid for `push' assemble => 1 assembler failed assembling: Main.ms rm Main.mo exhale prog.mx rm prog.manifest compilation failed => not building program "prog" Fatal Error: package build failed [HAL:~/test/src] mika% uname -a Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 [HAL:~/test/src] mika% as -v Apple Inc version cctools-782~33, GNU assembler version 1.38 I have XCode installed. [HAL:~/test/src] mika% gcc -v Using built-in specs. Target: i686-apple-darwin10 Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Apple Inc. build 5664) [HAL:~/test/src] mika% which gcc /usr/bin/gcc I must be doing something very obviously wrong (obviously to someone on this list, right??) Mika From jay.krell at cornell.edu Sun Dec 12 01:59:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 12 Dec 2010 00:59:18 +0000 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: <20101211221902.B71F81A207C@async.async.caltech.edu> References: <20101211221902.B71F81A207C@async.async.caltech.edu> Message-ID: I admit I'm still using Leopard. - Jay > To: m3devel at elegosoft.com > Date: Sat, 11 Dec 2010 14:19:02 -0800 > From: mika at async.caltech.edu > Subject: [M3devel] cm3 on snow leopard? > > Hello m3devel, > > I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook > Air, but it seems I have the wrong assembler? > > I had to force dpkg to override the architecture on install (it was expecting > i386, I think, and my machine identified itself as being "i386-darwin"?) > > Here are some details... > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-14 21:27:23 > configuration: /usr/local/cm3/bin/cm3.cfg > host: I386_DARWIN > target: I386_DARWIN > > compiling an empty Main.m3 yields: > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands > --- building in ../I386_DARWIN --- > > cd ../I386_DARWIN > rm .M3SHIP > rm .M3OVERRIDES > inhale prog.mx > inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a > inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a > > new source -> compiling Main.m3 > m3front ../src/Main.m3 -w1 > /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno-reorde > r-blocks Main.mc -o Main.ms > echo "rep movsl" | as -o /dev/null 2> /dev/null > as Main.ms -o Main.mo > Main.ms:15:suffix or operands invalid for `push' > assemble => 1 > assembler failed assembling: Main.ms > rm Main.mo > exhale prog.mx > rm prog.manifest > > compilation failed => not building program "prog" > Fatal Error: package build failed > > [HAL:~/test/src] mika% uname -a > Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 > [HAL:~/test/src] mika% as -v > Apple Inc version cctools-782~33, GNU assembler version 1.38 > > > I have XCode installed. > > [HAL:~/test/src] mika% gcc -v > Using built-in specs. > Target: i686-apple-darwin10 > Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 > Thread model: posix > gcc version 4.2.1 (Apple Inc. build 5664) > [HAL:~/test/src] mika% which gcc > /usr/bin/gcc > > > I must be doing something very obviously wrong (obviously to someone on this list, right??) > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 12 06:26:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 12 Dec 2010 05:26:37 +0000 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: References: <20101211221902.B71F81A207C@async.async.caltech.edu>, Message-ID: I'm rudely (but helpfully) ignoring your details and giving some of mine. I though what is supposed to happen, specifically on Darwin, is the assembly code is supposed to indicate an architecture. jbook2:m3core jay$ CM3_TARGET=I386_DARWIN M3CONFIG=/cm3/bin/config/I386_DARWIN cm3 -keep ^C jbook2:m3core jay$ CM3_TARGET=AMD64_DARWIN M3CONFIG=/cm3/bin/config/AMD64_DARWIN cm3 -keep ^C head */RTHooks.ms but no. But then this: jbook2:m3core jay$ CM3_TARGET=AMD64_DARWIN M3CONFIG=/cm3/bin/config/AMD64_DARWIN cm3 -keep -commands --- building in AMD64_DARWIN --- .. /usr/libexec/gcc/darwin/x86_64/as RTAllocator.ms -o RTAllocator.mo CM3_TARGET=I386_DARWIN M3CONFIG=/cm3/bin/config/I386_DARWIN cm3 -keep -commands ... /usr/libexec/gcc/darwin/i386/as Ctypes.is -o Ctypes.io i386 vs. x86_64. Darwin.common: proc configure_assembler() is if defined("SYSTEM_ASM") return end SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" if not FileExists(SYSTEM_ASM) SYSTEM_ASM = "as" end end jbook2:m3core jay$ grep DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-install/* /dev2/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN:DarwinArch = "x86_64" /dev2/cm3/m3-sys/cminstall/src/config-no-install/ARM_DARWIN:DarwinArch = "armv6" % ? /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: local arch = " -arch " & DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: arch = " -arch_only " & DarwinArch & " " /dev2/cm3/m3-sys/cminstall/src/config-no-install/I386_DARWIN:DarwinArch = "i386" /dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC64_DARWIN:DarwinArch = "ppc64" /dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC_DARWIN:DarwinArch = "ppc" ? cm3 -commands? find /usr/lib | grep /as$ find /usr/libexec | grep /as$ Maybe the path changed? Has a version? or is there is only i686-apple-darwin9, powerpc-apple-darwin9? I should look into getting the architecture into the assembly code though and just running "as", esp. on newer hosts. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; m3devel at elegosoft.com Date: Sun, 12 Dec 2010 00:59:18 +0000 Subject: Re: [M3devel] cm3 on snow leopard? I admit I'm still using Leopard. - Jay > To: m3devel at elegosoft.com > Date: Sat, 11 Dec 2010 14:19:02 -0800 > From: mika at async.caltech.edu > Subject: [M3devel] cm3 on snow leopard? > > Hello m3devel, > > I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook > Air, but it seems I have the wrong assembler? > > I had to force dpkg to override the architecture on install (it was expecting > i386, I think, and my machine identified itself as being "i386-darwin"?) > > Here are some details... > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-14 21:27:23 > configuration: /usr/local/cm3/bin/cm3.cfg > host: I386_DARWIN > target: I386_DARWIN > > compiling an empty Main.m3 yields: > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands > --- building in ../I386_DARWIN --- > > cd ../I386_DARWIN > rm .M3SHIP > rm .M3OVERRIDES > inhale prog.mx > inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a > inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a > > new source -> compiling Main.m3 > m3front ../src/Main.m3 -w1 > /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno-reorde > r-blocks Main.mc -o Main.ms > echo "rep movsl" | as -o /dev/null 2> /dev/null > as Main.ms -o Main.mo > Main.ms:15:suffix or operands invalid for `push' > assemble => 1 > assembler failed assembling: Main.ms > rm Main.mo > exhale prog.mx > rm prog.manifest > > compilation failed => not building program "prog" > Fatal Error: package build failed > > [HAL:~/test/src] mika% uname -a > Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 > [HAL:~/test/src] mika% as -v > Apple Inc version cctools-782~33, GNU assembler version 1.38 > > > I have XCode installed. > > [HAL:~/test/src] mika% gcc -v > Using built-in specs. > Target: i686-apple-darwin10 > Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 > Thread model: posix > gcc version 4.2.1 (Apple Inc. build 5664) > [HAL:~/test/src] mika% which gcc > /usr/bin/gcc > > > I must be doing something very obviously wrong (obviously to someone on this list, right??) > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 12 06:36:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 12 Dec 2010 05:36:02 +0000 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: References: <20101211221902.B71F81A207C@async.async.caltech.edu>, , , Message-ID: Please experiment a bit with this and let me know. Notice how I only get .machine for ppc. jbook2:~ jay$ cat 1.c void F1() {} jbook2:~ jay$ gcc -arch ppc64 -c 1.c -S && grep machine 1.s .machine ppc64 jbook2:~ jay$ gcc -arch ppc -c 1.c -S && grep machine 1.s .machine ppc7400 jbook2:~ jay$ gcc -arch i386 -c 1.c -S && grep machine 1.s jbook2:~ jay$ gcc -arch x86_64 -c 1.c -S && grep machine 1.s Oh, here: gcc-4.2 -arch ppc64 -c 1.c -v gcc-4.2 -arch x86_64 -c 1.c -v /usr/libexec/gcc/i686-apple-darwin9/4.2.1/as -arch x86_64 -force_cpusubtype_ALL -o 1.o /var/folders/QG/Q Ok, I think we should use the C compiler on Darwin to assemble. It costs an extra fork/exec. This is probably a reasonable idea on all systems, and cheap enough except on Cygwin. I'll try to get around to this fairly soon. It'll require per-target. More generally we *might* be able to extract enough from the gcc driver in m3-sys/m3cc and use it. I might might might might pursue that. Might. In particular, we could build both cm3cg and gcc driver (renamed -- m3gcc?) and trigger gcc to run both cm3cg (m3cgc1) and as. This seems very very reasonable. gcc driver (renamed) merely has to know that .is/.ms map to cm3cg or m3cgc1. This is a good idea. But more work. Thanks, - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; m3devel at elegosoft.com Date: Sun, 12 Dec 2010 05:26:37 +0000 Subject: Re: [M3devel] cm3 on snow leopard? I'm rudely (but helpfully) ignoring your details and giving some of mine. I though what is supposed to happen, specifically on Darwin, is the assembly code is supposed to indicate an architecture. jbook2:m3core jay$ CM3_TARGET=I386_DARWIN M3CONFIG=/cm3/bin/config/I386_DARWIN cm3 -keep ^C jbook2:m3core jay$ CM3_TARGET=AMD64_DARWIN M3CONFIG=/cm3/bin/config/AMD64_DARWIN cm3 -keep ^C head */RTHooks.ms but no. But then this: jbook2:m3core jay$ CM3_TARGET=AMD64_DARWIN M3CONFIG=/cm3/bin/config/AMD64_DARWIN cm3 -keep -commands --- building in AMD64_DARWIN --- .. /usr/libexec/gcc/darwin/x86_64/as RTAllocator.ms -o RTAllocator.mo CM3_TARGET=I386_DARWIN M3CONFIG=/cm3/bin/config/I386_DARWIN cm3 -keep -commands ... /usr/libexec/gcc/darwin/i386/as Ctypes.is -o Ctypes.io i386 vs. x86_64. Darwin.common: proc configure_assembler() is if defined("SYSTEM_ASM") return end SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" if not FileExists(SYSTEM_ASM) SYSTEM_ASM = "as" end end jbook2:m3core jay$ grep DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-install/* /dev2/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN:DarwinArch = "x86_64" /dev2/cm3/m3-sys/cminstall/src/config-no-install/ARM_DARWIN:DarwinArch = "armv6" % ? /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: local arch = " -arch " & DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: arch = " -arch_only " & DarwinArch & " " /dev2/cm3/m3-sys/cminstall/src/config-no-install/I386_DARWIN:DarwinArch = "i386" /dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC64_DARWIN:DarwinArch = "ppc64" /dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC_DARWIN:DarwinArch = "ppc" ? cm3 -commands? find /usr/lib | grep /as$ find /usr/libexec | grep /as$ Maybe the path changed? Has a version? or is there is only i686-apple-darwin9, powerpc-apple-darwin9? I should look into getting the architecture into the assembly code though and just running "as", esp. on newer hosts. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; m3devel at elegosoft.com Date: Sun, 12 Dec 2010 00:59:18 +0000 Subject: Re: [M3devel] cm3 on snow leopard? I admit I'm still using Leopard. - Jay > To: m3devel at elegosoft.com > Date: Sat, 11 Dec 2010 14:19:02 -0800 > From: mika at async.caltech.edu > Subject: [M3devel] cm3 on snow leopard? > > Hello m3devel, > > I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook > Air, but it seems I have the wrong assembler? > > I had to force dpkg to override the architecture on install (it was expecting > i386, I think, and my machine identified itself as being "i386-darwin"?) > > Here are some details... > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-14 21:27:23 > configuration: /usr/local/cm3/bin/cm3.cfg > host: I386_DARWIN > target: I386_DARWIN > > compiling an empty Main.m3 yields: > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands > --- building in ../I386_DARWIN --- > > cd ../I386_DARWIN > rm .M3SHIP > rm .M3OVERRIDES > inhale prog.mx > inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a > inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a > > new source -> compiling Main.m3 > m3front ../src/Main.m3 -w1 > /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno-reorde > r-blocks Main.mc -o Main.ms > echo "rep movsl" | as -o /dev/null 2> /dev/null > as Main.ms -o Main.mo > Main.ms:15:suffix or operands invalid for `push' > assemble => 1 > assembler failed assembling: Main.ms > rm Main.mo > exhale prog.mx > rm prog.manifest > > compilation failed => not building program "prog" > Fatal Error: package build failed > > [HAL:~/test/src] mika% uname -a > Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 > [HAL:~/test/src] mika% as -v > Apple Inc version cctools-782~33, GNU assembler version 1.38 > > > I have XCode installed. > > [HAL:~/test/src] mika% gcc -v > Using built-in specs. > Target: i686-apple-darwin10 > Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 > Thread model: posix > gcc version 4.2.1 (Apple Inc. build 5664) > [HAL:~/test/src] mika% which gcc > /usr/bin/gcc > > > I must be doing something very obviously wrong (obviously to someone on this list, right??) > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 12 06:49:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 12 Dec 2010 05:49:29 +0000 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: References: <20101211221902.B71F81A207C@async.async.caltech.edu>, , , Message-ID: I'm more sympathetic to using the already installed C compiler to drive the assembler, than to build the current gcc driver. You can see on Darwin we already probe around fairly aggressively for a C compiler that can be told the target: Darwin.common: proc configure_c_compiler() is if defined("SYSTEM_CC") return end % % older compiler doesn't like -m32 or -arch % % gcc -c -m32 -x c /dev/null % cc1: error: invalid option ?m32? % % fPIC is not usually needed here. % It is the default for Apple gcc and left % here in case user is using a self-built FSF gcc. % SYSTEM_CC = "gcc -gstabs+ -fPIC" local m = " -m" & {"32BITS":"32","64BITS":"64"}{WORD_SIZE} local arch = " -arch " & DarwinArch if not equal(try_exec("@" & SYSTEM_CC & m & " -c -x c /dev/null -o /dev/null 2>&1 | fgrep \"cc1: error: invalid option \\\`32'\" >/dev/null"), 0) SYSTEM_CC = SYSTEM_CC & m end if not equal(try_exec("@" & SYSTEM_CC & arch & " -c -x c /dev/null -o /dev/null 2>&1 | fgrep \"cc1: error: unrecognized command line option \\\\\"-arch\\\\\"\" >/dev/null"), 0) SYSTEM_CC = SYSTEM_CC & arch end %write("SYSTEM_CC is " & SYSTEM_CC) end Most likely if we merely set SYSTEM_ASM = SYSTEM_CC & "-x assembler" it'll work well. Maybe only in this else case: proc configure_assembler() is if defined("SYSTEM_ASM") return end SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" if not FileExists(SYSTEM_ASM) SYSTEM_ASM = "as" <<== here end end All this is addressed by autoconf and/or a C-generating backend..... - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; m3devel at elegosoft.com Date: Sun, 12 Dec 2010 05:26:37 +0000 Subject: Re: [M3devel] cm3 on snow leopard? I'm rudely (but helpfully) ignoring your details and giving some of mine. I though what is supposed to happen, specifically on Darwin, is the assembly code is supposed to indicate an architecture. jbook2:m3core jay$ CM3_TARGET=I386_DARWIN M3CONFIG=/cm3/bin/config/I386_DARWIN cm3 -keep ^C jbook2:m3core jay$ CM3_TARGET=AMD64_DARWIN M3CONFIG=/cm3/bin/config/AMD64_DARWIN cm3 -keep ^C head */RTHooks.ms but no. But then this: jbook2:m3core jay$ CM3_TARGET=AMD64_DARWIN M3CONFIG=/cm3/bin/config/AMD64_DARWIN cm3 -keep -commands --- building in AMD64_DARWIN --- .. /usr/libexec/gcc/darwin/x86_64/as RTAllocator.ms -o RTAllocator.mo CM3_TARGET=I386_DARWIN M3CONFIG=/cm3/bin/config/I386_DARWIN cm3 -keep -commands ... /usr/libexec/gcc/darwin/i386/as Ctypes.is -o Ctypes.io i386 vs. x86_64. Darwin.common: proc configure_assembler() is if defined("SYSTEM_ASM") return end SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" if not FileExists(SYSTEM_ASM) SYSTEM_ASM = "as" end end jbook2:m3core jay$ grep DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-install/* /dev2/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN:DarwinArch = "x86_64" /dev2/cm3/m3-sys/cminstall/src/config-no-install/ARM_DARWIN:DarwinArch = "armv6" % ? /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: local arch = " -arch " & DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: arch = " -arch_only " & DarwinArch & " " /dev2/cm3/m3-sys/cminstall/src/config-no-install/I386_DARWIN:DarwinArch = "i386" /dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC64_DARWIN:DarwinArch = "ppc64" /dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC_DARWIN:DarwinArch = "ppc" ? cm3 -commands? find /usr/lib | grep /as$ find /usr/libexec | grep /as$ Maybe the path changed? Has a version? or is there is only i686-apple-darwin9, powerpc-apple-darwin9? I should look into getting the architecture into the assembly code though and just running "as", esp. on newer hosts. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; m3devel at elegosoft.com Date: Sun, 12 Dec 2010 00:59:18 +0000 Subject: Re: [M3devel] cm3 on snow leopard? I admit I'm still using Leopard. - Jay > To: m3devel at elegosoft.com > Date: Sat, 11 Dec 2010 14:19:02 -0800 > From: mika at async.caltech.edu > Subject: [M3devel] cm3 on snow leopard? > > Hello m3devel, > > I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook > Air, but it seems I have the wrong assembler? > > I had to force dpkg to override the architecture on install (it was expecting > i386, I think, and my machine identified itself as being "i386-darwin"?) > > Here are some details... > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-14 21:27:23 > configuration: /usr/local/cm3/bin/cm3.cfg > host: I386_DARWIN > target: I386_DARWIN > > compiling an empty Main.m3 yields: > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands > --- building in ../I386_DARWIN --- > > cd ../I386_DARWIN > rm .M3SHIP > rm .M3OVERRIDES > inhale prog.mx > inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a > inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a > > new source -> compiling Main.m3 > m3front ../src/Main.m3 -w1 > /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno-reorde > r-blocks Main.mc -o Main.ms > echo "rep movsl" | as -o /dev/null 2> /dev/null > as Main.ms -o Main.mo > Main.ms:15:suffix or operands invalid for `push' > assemble => 1 > assembler failed assembling: Main.ms > rm Main.mo > exhale prog.mx > rm prog.manifest > > compilation failed => not building program "prog" > Fatal Error: package build failed > > [HAL:~/test/src] mika% uname -a > Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 > [HAL:~/test/src] mika% as -v > Apple Inc version cctools-782~33, GNU assembler version 1.38 > > > I have XCode installed. > > [HAL:~/test/src] mika% gcc -v > Using built-in specs. > Target: i686-apple-darwin10 > Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 > Thread model: posix > gcc version 4.2.1 (Apple Inc. build 5664) > [HAL:~/test/src] mika% which gcc > /usr/bin/gcc > > > I must be doing something very obviously wrong (obviously to someone on this list, right??) > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 12 07:01:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 12 Dec 2010 06:01:21 +0000 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: References: <20101211221902.B71F81A207C@async.async.caltech.edu>, , , , , , Message-ID: Please try my updated Darwin.common. IsX86 = equal(TARGET, "I386_DARWIN") or equal(TARGET, "AMD64_DARWIN") proc configure_assembler() is if defined("SYSTEM_ASM") return end SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" if not FileExists(SYSTEM_ASM) if IsX86 configure_c_compiler () SYSTEM_ASM = SYSTEM_CC_ASM & " -c -x assembler" else SYSTEM_ASM = "as" end end %SYSTEM_ASM = SYSTEM_CC_ASM & " -v -c -x assembler" end proc configure_c_compiler() is if defined("SYSTEM_CC") return end % % older compiler doesn't like -m32 or -arch % % gcc -c -m32 -x c /dev/null % cc1: error: invalid option ?m32? % % fPIC is not usually needed here. % It is the default for Apple gcc and left % here in case user is using a self-built FSF gcc. % SYSTEM_CC = "gcc -gstabs+ -fPIC" SYSTEM_CC_ASM = "gcc -fPIC" local m = " -m" & {"32BITS":"32","64BITS":"64"}{WORD_SIZE} local arch = " -arch " & DarwinArch if not equal(try_exec("@" & SYSTEM_CC & m & " -c -x c /dev/null -o /dev/null 2>&1 | fgrep \"cc1: error: invalid option \\\`32'\" >/dev/null"), 0) SYSTEM_CC = SYSTEM_CC & m SYSTEM_CC_ASM = SYSTEM_CC_ASM & m end if not equal(try_exec("@" & SYSTEM_CC & arch & " -c -x c /dev/null -o /dev/null 2>&1 | fgrep \"cc1: error: unrecognized command line option \\\\\"-arch\\\\\"\" >/dev/null"), 0) SYSTEM_CC = SYSTEM_CC & arch SYSTEM_CC_ASM = SYSTEM_CC_ASM & arch end %write("SYSTEM_CC is " & SYSTEM_CC) end - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; m3devel at elegosoft.com Date: Sun, 12 Dec 2010 05:49:29 +0000 Subject: Re: [M3devel] cm3 on snow leopard? I'm more sympathetic to using the already installed C compiler to drive the assembler, than to build the current gcc driver. You can see on Darwin we already probe around fairly aggressively for a C compiler that can be told the target: Darwin.common: proc configure_c_compiler() is if defined("SYSTEM_CC") return end % % older compiler doesn't like -m32 or -arch % % gcc -c -m32 -x c /dev/null % cc1: error: invalid option ?m32? % % fPIC is not usually needed here. % It is the default for Apple gcc and left % here in case user is using a self-built FSF gcc. % SYSTEM_CC = "gcc -gstabs+ -fPIC" local m = " -m" & {"32BITS":"32","64BITS":"64"}{WORD_SIZE} local arch = " -arch " & DarwinArch if not equal(try_exec("@" & SYSTEM_CC & m & " -c -x c /dev/null -o /dev/null 2>&1 | fgrep \"cc1: error: invalid option \\\`32'\" >/dev/null"), 0) SYSTEM_CC = SYSTEM_CC & m end if not equal(try_exec("@" & SYSTEM_CC & arch & " -c -x c /dev/null -o /dev/null 2>&1 | fgrep \"cc1: error: unrecognized command line option \\\\\"-arch\\\\\"\" >/dev/null"), 0) SYSTEM_CC = SYSTEM_CC & arch end %write("SYSTEM_CC is " & SYSTEM_CC) end Most likely if we merely set SYSTEM_ASM = SYSTEM_CC & "-x assembler" it'll work well. Maybe only in this else case: proc configure_assembler() is if defined("SYSTEM_ASM") return end SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" if not FileExists(SYSTEM_ASM) SYSTEM_ASM = "as" <<== here end end All this is addressed by autoconf and/or a C-generating backend..... - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; m3devel at elegosoft.com Date: Sun, 12 Dec 2010 05:26:37 +0000 Subject: Re: [M3devel] cm3 on snow leopard? I'm rudely (but helpfully) ignoring your details and giving some of mine. I though what is supposed to happen, specifically on Darwin, is the assembly code is supposed to indicate an architecture. jbook2:m3core jay$ CM3_TARGET=I386_DARWIN M3CONFIG=/cm3/bin/config/I386_DARWIN cm3 -keep ^C jbook2:m3core jay$ CM3_TARGET=AMD64_DARWIN M3CONFIG=/cm3/bin/config/AMD64_DARWIN cm3 -keep ^C head */RTHooks.ms but no. But then this: jbook2:m3core jay$ CM3_TARGET=AMD64_DARWIN M3CONFIG=/cm3/bin/config/AMD64_DARWIN cm3 -keep -commands --- building in AMD64_DARWIN --- .. /usr/libexec/gcc/darwin/x86_64/as RTAllocator.ms -o RTAllocator.mo CM3_TARGET=I386_DARWIN M3CONFIG=/cm3/bin/config/I386_DARWIN cm3 -keep -commands ... /usr/libexec/gcc/darwin/i386/as Ctypes.is -o Ctypes.io i386 vs. x86_64. Darwin.common: proc configure_assembler() is if defined("SYSTEM_ASM") return end SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" if not FileExists(SYSTEM_ASM) SYSTEM_ASM = "as" end end jbook2:m3core jay$ grep DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-install/* /dev2/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN:DarwinArch = "x86_64" /dev2/cm3/m3-sys/cminstall/src/config-no-install/ARM_DARWIN:DarwinArch = "armv6" % ? /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: local arch = " -arch " & DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: arch = " -arch_only " & DarwinArch & " " /dev2/cm3/m3-sys/cminstall/src/config-no-install/I386_DARWIN:DarwinArch = "i386" /dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC64_DARWIN:DarwinArch = "ppc64" /dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC_DARWIN:DarwinArch = "ppc" ? cm3 -commands? find /usr/lib | grep /as$ find /usr/libexec | grep /as$ Maybe the path changed? Has a version? or is there is only i686-apple-darwin9, powerpc-apple-darwin9? I should look into getting the architecture into the assembly code though and just running "as", esp. on newer hosts. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; m3devel at elegosoft.com Date: Sun, 12 Dec 2010 00:59:18 +0000 Subject: Re: [M3devel] cm3 on snow leopard? I admit I'm still using Leopard. - Jay > To: m3devel at elegosoft.com > Date: Sat, 11 Dec 2010 14:19:02 -0800 > From: mika at async.caltech.edu > Subject: [M3devel] cm3 on snow leopard? > > Hello m3devel, > > I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook > Air, but it seems I have the wrong assembler? > > I had to force dpkg to override the architecture on install (it was expecting > i386, I think, and my machine identified itself as being "i386-darwin"?) > > Here are some details... > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-14 21:27:23 > configuration: /usr/local/cm3/bin/cm3.cfg > host: I386_DARWIN > target: I386_DARWIN > > compiling an empty Main.m3 yields: > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands > --- building in ../I386_DARWIN --- > > cd ../I386_DARWIN > rm .M3SHIP > rm .M3OVERRIDES > inhale prog.mx > inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a > inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a > > new source -> compiling Main.m3 > m3front ../src/Main.m3 -w1 > /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno-reorde > r-blocks Main.mc -o Main.ms > echo "rep movsl" | as -o /dev/null 2> /dev/null > as Main.ms -o Main.mo > Main.ms:15:suffix or operands invalid for `push' > assemble => 1 > assembler failed assembling: Main.ms > rm Main.mo > exhale prog.mx > rm prog.manifest > > compilation failed => not building program "prog" > Fatal Error: package build failed > > [HAL:~/test/src] mika% uname -a > Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 > [HAL:~/test/src] mika% as -v > Apple Inc version cctools-782~33, GNU assembler version 1.38 > > > I have XCode installed. > > [HAL:~/test/src] mika% gcc -v > Using built-in specs. > Target: i686-apple-darwin10 > Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 > Thread model: posix > gcc version 4.2.1 (Apple Inc. build 5664) > [HAL:~/test/src] mika% which gcc > /usr/bin/gcc > > > I must be doing something very obviously wrong (obviously to someone on this list, right??) > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Dec 12 10:35:35 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 12 Dec 2010 01:35:35 -0800 Subject: [M3devel] cm3 on snow leopard? Message-ID: <20101212093535.155ED1A207C@async.async.caltech.edu> Thanks, Jay. I wasn't able to use your Darwin.config (remember, I'm installing from the release .deb)---there seem to have been too many changes to these files for me to be able to sort it all out. However, I figured out how to do a "quick and dirty" from your email. This fixed it for me: if not defined("SYSTEM_ASM") SYSTEM_ASM="/usr/libexec/gcc/darwin/i386/as" end Now to check on all the other problems. Mika Jay K writes: >--_1377ed26-bb42-4722-b430-c9bf3b1b287d_ >Content-Type: text/plain; charset="Windows-1252" >Content-Transfer-Encoding: quoted-printable > > >I'm more sympathetic to using the already installed C compiler >to drive the assembler=2C than to build the current gcc driver. > > >You can see on Darwin we already probe around fairly aggressively >for a C compiler that can be told the target: > >Darwin.common: > > >proc configure_c_compiler() is > > if defined("SYSTEM_CC") > return > end > > % > % older compiler doesn't like -m32 or -arch > % > % gcc -c -m32 -x c /dev/null > % cc1: error: invalid option =91m32=92 > % > % fPIC is not usually needed here. > % It is the default for Apple gcc and left > % here in case user is using a self-built FSF gcc. > % > > SYSTEM_CC =3D "gcc -gstabs+ -fPIC" > local m =3D " -m" & {"32BITS":"32"=2C"64BITS":"64"}{WORD_SIZE} > local arch =3D " -arch " & DarwinArch > if not equal(try_exec("@" & SYSTEM_CC & m & " -c -x c /dev/null -o /dev/n= >ull 2>&1 | fgrep \"cc1: error: invalid option \\\`32'\" >/dev/null")=2C 0) > SYSTEM_CC =3D SYSTEM_CC & m > end > if not equal(try_exec("@" & SYSTEM_CC & arch & " -c -x c /dev/null -o /de= >v/null 2>&1 | fgrep \"cc1: error: unrecognized command line option \\\\\"-a= >rch\\\\\"\" >/dev/null")=2C 0) > SYSTEM_CC =3D SYSTEM_CC & arch > end > %write("SYSTEM_CC is " & SYSTEM_CC) >end > ... From jay.krell at cornell.edu Sun Dec 12 10:51:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 12 Dec 2010 09:51:06 +0000 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: References: <20101211221902.B71F81A207C@async.async.caltech.edu>, , , , , , , <20101212093436.813921A207A@async.async.caltech.edu>, Message-ID: oh, oops, I didn't realize release was so far behind, duh. :) It reads, AMD64_DARWIN: SYSTEM_ASM = "/usr/libexec/gcc/darwin/x86_64/as" if not FileExists(SYSTEM_ASM) SYSTEM_ASM = "as" end I386_DARWIN: proc configure_assembler() is if defined("SYSTEM_ASM") return end local a = try_exec("@echo \"rep movsl\" | as -o /dev/null 2> /dev/null") % write("a is " & a & CR) if equal(a, 0) SYSTEM_ASM = "as" % write(SYSTEM_ASM & " works" & CR) return end % write("as does not work" & CR) if FileExists("/cctools-698.1/usr/bin/as") SYSTEM_ASM = "/cctools-698.1/usr/bin/as" % write("using " & SYSTEM_ASM & ", which is presumed to work" & CR) return end error("as does not work (does not recognize \"rep movsl\"), please upgrade to " & "cctools-698.1 or newer and install to /cctools-698.1") % % another good option is probably to put an assembler next to cm3cg % end I have since changed m3cc to work with the older assembler. :) (The gcc folks might have also, but I did so differently.) - Jay > To: jay.krell at cornell.edu > CC: m3devel at async.caltech.edu > Subject: Re: [M3devel] cm3 on snow leopard? > Date: Sun, 12 Dec 2010 01:34:36 -0800 > From: mika at async.caltech.edu > > Thanks, Jay. > > I wasn't able to use your Darwin.config (remember, I'm installing > from the release .deb)---there seem to have been too many changes to > these files for me to be able to sort it all out. However, I figured > out how to do a "quick and dirty" from your email. > > This fixed it for me: > > if not defined("SYSTEM_ASM") > SYSTEM_ASM="/usr/libexec/gcc/darwin/i386/as" > end > > Now to check on all the other problems. > > Mika > > Jay K writes: > >--_1377ed26-bb42-4722-b430-c9bf3b1b287d_ > >Content-Type: text/plain; charset="Windows-1252" > >Content-Transfer-Encoding: quoted-printable > > > > > >I'm more sympathetic to using the already installed C compiler > >to drive the assembler=2C than to build the current gcc driver. > > > > > >You can see on Darwin we already probe around fairly aggressively > >for a C compiler that can be told the target: > > > >Darwin.common: > > > > > >proc configure_c_compiler() is > > > > if defined("SYSTEM_CC") > > return > > end > > > > % > > % older compiler doesn't like -m32 or -arch > > % > > % gcc -c -m32 -x c /dev/null > > % cc1: error: invalid option =91m32=92 > > % > > % fPIC is not usually needed here. > > % It is the default for Apple gcc and left > > % here in case user is using a self-built FSF gcc. > > % > > > > SYSTEM_CC =3D "gcc -gstabs+ -fPIC" > > local m =3D " -m" & {"32BITS":"32"=2C"64BITS":"64"}{WORD_SIZE} > > local arch =3D " -arch " & DarwinArch > > if not equal(try_exec("@" & SYSTEM_CC & m & " -c -x c /dev/null -o /dev/n= > >ull 2>&1 | fgrep \"cc1: error: invalid option \\\`32'\" >/dev/null")=2C 0) > > SYSTEM_CC =3D SYSTEM_CC & m > > end > > if not equal(try_exec("@" & SYSTEM_CC & arch & " -c -x c /dev/null -o /de= > >v/null 2>&1 | fgrep \"cc1: error: unrecognized command line option \\\\\"-a= > >rch\\\\\"\" >/dev/null")=2C 0) > > SYSTEM_CC =3D SYSTEM_CC & arch > > end > > %write("SYSTEM_CC is " & SYSTEM_CC) > >end > > > > > >Most likely if we merely set SYSTEM_ASM =3D SYSTEM_CC & "-x assembler" > >it'll work well. > >Maybe only in this else case: > > > > > >proc configure_assembler() is > > if defined("SYSTEM_ASM") > > return > > end > > SYSTEM_ASM =3D "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" > > if not FileExists(SYSTEM_ASM) > > SYSTEM_ASM =3D "as" <<=3D=3D here > > end > >end > > > > > >All this is addressed by autoconf and/or a C-generating backend..... > > > > > > - Jay > > > > > > > > > > > > > >From: jay.krell at cornell.edu > >To: mika at async.caltech.edu=3B m3devel at elegosoft.com > >Date: Sun=2C 12 Dec 2010 05:26:37 +0000 > >Subject: Re: [M3devel] cm3 on snow leopard? > > > > > > > > > > > > > > > > > >I'm rudely (but helpfully) ignoring your details and giving some of mine. > > > >I though what is supposed to happen=2C specifically on Darwin=2C is the ass= > >embly code is supposed to indicate an architecture. > > > >jbook2:m3core jay$ CM3_TARGET=3DI386_DARWIN M3CONFIG=3D/cm3/bin/config/I386= > >_DARWIN cm3 -keep > >^C > > > >jbook2:m3core jay$ CM3_TARGET=3DAMD64_DARWIN M3CONFIG=3D/cm3/bin/config/AMD= > >64_DARWIN cm3 -keep > >^C > > > >head */RTHooks.ms > > > >but no. > > > >But then this: > > > >jbook2:m3core jay$ CM3_TARGET=3DAMD64_DARWIN M3CONFIG=3D/cm3/bin/config/AMD= > >64_DARWIN cm3 -keep -commands > >--- building in AMD64_DARWIN --- > > > >.. > >/usr/libexec/gcc/darwin/x86_64/as RTAllocator.ms -o RTAllocator.mo > > > >CM3_TARGET=3DI386_DARWIN M3CONFIG=3D/cm3/bin/config/I386_DARWIN cm3 -keep -= > >commands > > > >... > >/usr/libexec/gcc/darwin/i386/as Ctypes.is -o Ctypes.io > > > >i386 vs. x86_64. > > > >Darwin.common: > >proc configure_assembler() is > > if defined("SYSTEM_ASM") > > return > > end > > SYSTEM_ASM =3D "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" > > if not FileExists(SYSTEM_ASM) > > SYSTEM_ASM =3D "as" > > end > >end > > > > > >jbook2:m3core jay$ grep DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no= > >-install/* > >/dev2/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN:DarwinArch = > >=3D "x86_64" > >/dev2/cm3/m3-sys/cminstall/src/config-no-install/ARM_DARWIN:DarwinArch =3D = > >"armv6" % ? > >/dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: SYSTEM_ASM= > > =3D "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" > >/dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: local arch= > > =3D " -arch " & DarwinArch > >/dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: arch = > >=3D " -arch_only " & DarwinArch & " " > >/dev2/cm3/m3-sys/cminstall/src/config-no-install/I386_DARWIN:DarwinArch =3D= > > "i386" > >/dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC64_DARWIN:DarwinArch = > >=3D "ppc64" > >/dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC_DARWIN:DarwinArch =3D = > >"ppc" > > > >? > >cm3 -commands? > > > >find /usr/lib | grep /as$ > >find /usr/libexec | grep /as$ > > > > > >Maybe the path changed? Has a version? or is there is only i686-apple-darwi= > >n9=2C powerpc-apple-darwin9? > > > >I should look into getting the architecture into the assembly code though a= > >nd just running "as"=2C esp. on newer hosts. > > > > - Jay > > > > > >From: jay.krell at cornell.edu > >To: mika at async.caltech.edu=3B m3devel at elegosoft.com > >Date: Sun=2C 12 Dec 2010 00:59:18 +0000 > >Subject: Re: [M3devel] cm3 on snow leopard? > > > > > > > > > > > > > > > > > >I admit I'm still using Leopard. > > > > - Jay > > > > > > > >> To: m3devel at elegosoft.com > >> Date: Sat=2C 11 Dec 2010 14:19:02 -0800 > >> From: mika at async.caltech.edu > >> Subject: [M3devel] cm3 on snow leopard? > >>=20 > >> Hello m3devel=2C > >>=20 > >> I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook > >> Air=2C but it seems I have the wrong assembler? > >>=20 > >> I had to force dpkg to override the architecture on install (it was expec= > >ting > >> i386=2C I think=2C and my machine identified itself as being "i386-darwin= > >"?) > >>=20 > >> Here are some details... > >>=20 > >> [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version > >> Critical Mass Modula-3 version 5.8.6 > >> last updated: 2010-04-11 > >> compiled: 2010-07-14 21:27:23 > >> configuration: /usr/local/cm3/bin/cm3.cfg > >> host: I386_DARWIN > >> target: I386_DARWIN > >>=20 > >> compiling an empty Main.m3 yields: > >>=20 > >> [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands > >> --- building in ../I386_DARWIN --- > >>=20 > >> cd ../I386_DARWIN > >> rm .M3SHIP > >> rm .M3OVERRIDES > >> inhale prog.mx > >> inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a > >> inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a > >>=20 > >> new source -> compiling Main.m3 > >> m3front ../src/Main.m3 -w1 > >> /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno= > >-reorde > >> r-blocks Main.mc -o Main.ms > >> echo "rep movsl" | as -o /dev/null 2> /dev/null > >> as Main.ms -o Main.mo > >> Main.ms:15:suffix or operands invalid for `push' > >> assemble =3D> 1 > >> assembler failed assembling: Main.ms > >> rm Main.mo > >> exhale prog.mx > >> rm prog.manifest > >>=20 > >> compilation failed =3D> not building program "prog" > >> Fatal Error: package build failed > >>=20 > >> [HAL:~/test/src] mika% uname -a > >> Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39= > > PDT 2010=3B root:xnu-1504.9.17~1/RELEASE_I386 i386 > >> [HAL:~/test/src] mika% as -v > >> Apple Inc version cctools-782~33=2C GNU assembler version 1.38 > >>=20 > >>=20 > >> I have XCode installed. > >>=20 > >> [HAL:~/test/src] mika% gcc -v > >> Using built-in specs. > >> Target: i686-apple-darwin10 > >> Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checkin= > >g --enable-werror --prefix=3D/usr --mandir=3D/share/man --enable-languages= > >=3Dc=2Cobjc=2Cc++=2Cobj-c++ --program-transform-name=3D/^[cg][^.-]*$/s/$/-4= > >.2/ --with-slibdir=3D/usr/lib --build=3Di686-apple-darwin10 --program-prefi= > >x=3Di686-apple-darwin10- --host=3Dx86_64-apple-darwin10 --target=3Di686-app= > >le-darwin10 --with-gxx-include-dir=3D/include/c++/4.2.1 > >> Thread model: posix > >> gcc version 4.2.1 (Apple Inc. build 5664) > >> [HAL:~/test/src] mika% which gcc > >> /usr/bin/gcc > >>=20 > >>=20 > >> I must be doing something very obviously wrong (obviously to someone on t= > >his list=2C right??) > >>=20 > >> Mika > > = > > > >--_1377ed26-bb42-4722-b430-c9bf3b1b287d_ > >Content-Type: text/html; charset="Windows-1252" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >I'm more sympathetic to using the already installed C compiler
to drive = > >the assembler=2C than to build the current gcc driver.


You can s= > >ee on Darwin we already probe around fairly aggressively
for a C compile= > >r that can be told the target:

Darwin.common:


proc config= > >ure_c_compiler() is

 =3B if defined("SYSTEM_CC")
 =3B&nbs= > >p=3B =3B return
 =3B end

 =3B %
 =3B % older c= > >ompiler doesn't like -m32 or -arch
 =3B %
 =3B % gcc -c -m32 = > >-x c /dev/null
 =3B % cc1: error: invalid option =91m32=92
 = > >=3B %
 =3B % fPIC is not usually needed here.
 =3B % It is th= > >e default for Apple gcc and left
 =3B % here in case user is using a= > > self-built FSF gcc.
 =3B %

 =3B SYSTEM_CC =3D "gcc -gsta= > >bs+ -fPIC"
 =3B local m =3D " -m" &=3B {"32BITS":"32"=2C"64BITS":= > >"64"}{WORD_SIZE}
 =3B local arch =3D " -arch " &=3B DarwinArch >> =3B if not equal(try_exec("@" &=3B SYSTEM_CC &=3B m &=3B " -= > >c -x c /dev/null -o /dev/null 2>=3B&=3B1 | fgrep \"cc1: error: invalid= > > option \\\`32'\" >=3B/dev/null")=2C 0)
 =3B =3B =3B SYSTE= > >M_CC =3D SYSTEM_CC &=3B m
 =3B end
 =3B if not equal(try_e= > >xec("@" &=3B SYSTEM_CC &=3B arch &=3B " -c -x c /dev/null -o /dev/= > >null 2>=3B&=3B1 | fgrep \"cc1: error: unrecognized command line option= > > \\\\\"-arch\\\\\"\" >=3B/dev/null")=2C 0)
 =3B =3B =3B SY= > >STEM_CC =3D SYSTEM_CC &=3B arch
 =3B end
 =3B %write("SYST= > >EM_CC is " &=3B SYSTEM_CC)
end


Most likely if we merely se= > >t SYSTEM_ASM =3D SYSTEM_CC &=3B "-x assembler"
it'll work well.
Ma= > >ybe only in this else case:


proc configure_assembler() is
&nb= > >sp=3B if defined("SYSTEM_ASM")
 =3B =3B =3B return
 = > >=3B end
 =3B SYSTEM_ASM =3D "/usr/libexec/gcc/darwin/" &=3B Darwi= > >nArch &=3B "/as"
 =3B if not FileExists(SYSTEM_ASM)
 =3B&n= > >bsp=3B =3B =3B =3B SYSTEM_ASM =3D "as" <=3B<=3B=3D=3D here<= > >br> =3B end
end


All this is addressed by autoconf and/or = > >a C-generating backend.....


 =3B- Jay




>>
From: jay.krell at cornell.edu
To: mika at async.= > >caltech.edu=3B m3devel at elegosoft.com
Date: Sun=2C 12 Dec 2010 05:26:37 += > >0000
Subject: Re: [M3devel] cm3 on snow leopard?

> > > > >"> > > > > > > > > > >I'm rudely (but helpfully) ignoring your details and giving some of mine. >r>
I though what is supposed to happen=2C specifically on Darwin=2C is t= > >he assembly code is supposed to indicate an architecture.

jbook2:m3c= > >ore jay$ CM3_TARGET=3DI386_DARWIN M3CONFIG=3D/cm3/bin/config/I386_DARWIN cm= > >3 -keep
^C

jbook2:m3core jay$ CM3_TARGET=3DAMD64_DARWIN M3CONFIG= > >=3D/cm3/bin/config/AMD64_DARWIN cm3 -keep
^C

head */RTHooks.ms >>
but no.

But then this:

jbook2:m3core jay$ CM3_TARGET=3DA= > >MD64_DARWIN M3CONFIG=3D/cm3/bin/config/AMD64_DARWIN cm3 -keep -commands
= > >--- building in AMD64_DARWIN ---

..
/usr/libexec/gcc/darwin/x86_6= > >4/as RTAllocator.ms -o RTAllocator.mo

CM3_TARGET=3DI386_DARWIN M3CON= > >FIG=3D/cm3/bin/config/I386_DARWIN cm3 -keep -commands

...
/usr/li= > >bexec/gcc/darwin/i386/as Ctypes.is -o Ctypes.io

i386 vs. x86_64.
= > >
Darwin.common:
proc configure_assembler() is
 =3B if defined(= > >"SYSTEM_ASM")
 =3B =3B =3B return
 =3B end
 = > >=3B SYSTEM_ASM =3D "/usr/libexec/gcc/darwin/" &=3B DarwinArch &=3B "/= > >as"
 =3B if not FileExists(SYSTEM_ASM)
 =3B =3B =3B&n= > >bsp=3B =3B SYSTEM_ASM =3D "as"
 =3B end
end


jbook2= > >:m3core jay$ grep DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-insta= > >ll/*
/dev2/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN:Darwi= > >nArch =3D "x86_64"
/dev2/cm3/m3-sys/cminstall/src/config-no-install/ARM_= > >DARWIN:DarwinArch =3D "armv6" % ?
/dev2/cm3/m3-sys/cminstall/src/config-= > >no-install/Darwin.common: =3B SYSTEM_ASM =3D "/usr/libexec/gcc/darwin/"= > > &=3B DarwinArch &=3B "/as"
/dev2/cm3/m3-sys/cminstall/src/config-= > >no-install/Darwin.common: =3B local arch =3D " -arch " &=3B DarwinAr= > >ch
/dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: = > >=3B =3B =3B =3B =3B arch =3D " -arch_only " &=3B DarwinA= > >rch &=3B " "
/dev2/cm3/m3-sys/cminstall/src/config-no-install/I386_DA= > >RWIN:DarwinArch =3D "i386"
/dev2/cm3/m3-sys/cminstall/src/config-no-inst= > >all/PPC64_DARWIN:DarwinArch =3D "ppc64"
/dev2/cm3/m3-sys/cminstall/src/c= > >onfig-no-install/PPC_DARWIN:DarwinArch =3D "ppc"

?
cm3 -commands?= > >

find /usr/lib | grep /as$
find /usr/libexec | grep /as$
> >
Maybe the path changed? Has a version? or is there is only i686-apple-d= > >arwin9=2C powerpc-apple-darwin9?

I should look into getting the arch= > >itecture into the assembly code though and just running "as"=2C esp. on new= > >er hosts.

 =3B- Jay


From: = > >jay.krell at cornell.edu
To: mika at async.caltech.edu=3B m3devel at elegosoft.co= > >m
Date: Sun=2C 12 Dec 2010 00:59:18 +0000
Subject: Re: [M3devel] cm3 = > >on snow leopard?

> > > > > > > > > > > > > >I admit I'm still using Leopard.

 =3B- Jay



>=3B= > > To: m3devel at elegosoft.com
>=3B Date: Sat=2C 11 Dec 2010 14:19:02 -080= > >0
>=3B From: mika at async.caltech.edu
>=3B Subject: [M3devel] cm3 o= > >n snow leopard?
>=3B
>=3B Hello m3devel=2C
>=3B
>=3B = > >I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook >r>>=3B Air=2C but it seems I have the wrong assembler?
>=3B
>= > >=3B I had to force dpkg to override the architecture on install (it was exp= > >ecting
>=3B i386=2C I think=2C and my machine identified itself as bei= > >ng "i386-darwin"?)
>=3B
>=3B Here are some details...
>=3B = > >
>=3B [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version
>=3B= > > Critical Mass Modula-3 version 5.8.6
>=3B last updated: 2010-04-11<= > >br>>=3B compiled: 2010-07-14 21:27:23
>=3B configuration: /usr/l= > >ocal/cm3/bin/cm3.cfg
>=3B host: I386_DARWIN
>=3B target: I386= > >_DARWIN
>=3B
>=3B compiling an empty Main.m3 yields:
>=3B <= > >br>>=3B [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands
= > >>=3B --- building in ../I386_DARWIN ---
>=3B
>=3B cd ../I386_D= > >ARWIN
>=3B rm .M3SHIP
>=3B rm .M3OVERRIDES
>=3B inhale prog.= > >mx
>=3B inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a
&g= > >t=3B inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a
>=3B
>= > >=3B new source ->=3B compiling Main.m3
>=3B m3front ../src/Main.m3 -= > >w1
>=3B /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 = > >-quiet -fno-reorde
>=3B r-blocks Main.mc -o Main.ms
>=3B echo "re= > >p movsl" | as -o /dev/null 2>=3B /dev/null
>=3B as Main.ms -o Main.m= > >o
>=3B Main.ms:15:suffix or operands invalid for `push'
>=3B as= > >semble =3D>=3B 1
>=3B assembler failed assembling: Main.ms
>=3B= > > rm Main.mo
>=3B exhale prog.mx
>=3B rm prog.manifest
>=3B <= > >br>>=3B compilation failed =3D>=3B not building program "prog"
>= > >=3B Fatal Error: package build failed
>=3B
>=3B [HAL:~/test/src]= > > mika% uname -a
>=3B Darwin HAL.local 10.5.0 Darwin Kernel Version 10.= > >5.0: Fri Nov 5 23:20:39 PDT 2010=3B root:xnu-1504.9.17~1/RELEASE_I386 i386= > >
>=3B [HAL:~/test/src] mika% as -v
>=3B Apple Inc version cctools= > >-782~33=2C GNU assembler version 1.38
>=3B
>=3B
>=3B I hav= > >e XCode installed.
>=3B
>=3B [HAL:~/test/src] mika% gcc -v
&g= > >t=3B Using built-in specs.
>=3B Target: i686-apple-darwin10
>=3B = > >Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking = > >--enable-werror --prefix=3D/usr --mandir=3D/share/man --enable-languages=3D= > >c=2Cobjc=2Cc++=2Cobj-c++ --program-transform-name=3D/^[cg][^.-]*$/s/$/-4.2/= > > --with-slibdir=3D/usr/lib --build=3Di686-apple-darwin10 --program-prefix= > >=3Di686-apple-darwin10- --host=3Dx86_64-apple-darwin10 --target=3Di686-appl= > >e-darwin10 --with-gxx-include-dir=3D/include/c++/4.2.1
>=3B Thread mod= > >el: posix
>=3B gcc version 4.2.1 (Apple Inc. build 5664)
>=3B [HA= > >L:~/test/src] mika% which gcc
>=3B /usr/bin/gcc
>=3B
>=3B <= > >br>>=3B I must be doing something very obviously wrong (obviously to some= > >one on this list=2C right??)
>=3B
>=3B Mika
> > = > > > >= > > > >--_1377ed26-bb42-4722-b430-c9bf3b1b287d_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Dec 12 21:14:58 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 12 Dec 2010 12:14:58 -0800 Subject: [M3devel] compiler problems on Snow Leopard Message-ID: <20101212201458.BEFA41A2079@async.async.caltech.edu> Hi everyone, Well I was able to get past all my linking issues (mostly questions of dynamic vs. static linking and how to do it, which seems to change from version to version...) But now I did hit a real problem. "../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** unaligned store type=6 s/o/a=32/0/32 "../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** unaligned load_indirect type=6 s/a=32/32 Here is the code, but it's not likely to be of much help... PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.T RAISES { Scheme.E } = BEGIN VAR res : SchemePair.T:=NIL; BEGIN res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),ToScheme_Atom_T(x.type)),res); res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modificationTime"),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),ToScheme_VAL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) RETURN res END END ToScheme_File_Status; ... PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0, LONGINT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = BEGIN RETURN ToScheme_LONGINT(x) (* line 981 *) END ToScheme_VAL0LONGINT__VAL16778080LONGINT; for reference, ToScheme_LONGINT is: PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISES { Scheme.E } = BEGIN WITH ref = NEW(REF LONGINT) DO ref^ := x; RETURN SchemeModula3Types.ToScheme_LONGINT(ref) END END ToScheme_LONGINT; Mika From hosking at cs.purdue.edu Sun Dec 12 21:19:15 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Dec 2010 15:19:15 -0500 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: <20101211221902.B71F81A207C@async.async.caltech.edu> References: <20101211221902.B71F81A207C@async.async.caltech.edu> Message-ID: My config file has: SYSTEM_ASM="as" ... return try_exec ("@" & SYSTEM_ASM, "-arch", "i386", "-q", source, "-o", object Works fine for me on Snow Leopard. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 11, 2010, at 5:19 PM, Mika Nystrom wrote: > Hello m3devel, > > I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook > Air, but it seems I have the wrong assembler? > > I had to force dpkg to override the architecture on install (it was expecting > i386, I think, and my machine identified itself as being "i386-darwin"?) > > Here are some details... > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-14 21:27:23 > configuration: /usr/local/cm3/bin/cm3.cfg > host: I386_DARWIN > target: I386_DARWIN > > compiling an empty Main.m3 yields: > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands > --- building in ../I386_DARWIN --- > > cd ../I386_DARWIN > rm .M3SHIP > rm .M3OVERRIDES > inhale prog.mx > inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a > inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a > > new source -> compiling Main.m3 > m3front ../src/Main.m3 -w1 > /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno-reorde > r-blocks Main.mc -o Main.ms > echo "rep movsl" | as -o /dev/null 2> /dev/null > as Main.ms -o Main.mo > Main.ms:15:suffix or operands invalid for `push' > assemble => 1 > assembler failed assembling: Main.ms > rm Main.mo > exhale prog.mx > rm prog.manifest > > compilation failed => not building program "prog" > Fatal Error: package build failed > > [HAL:~/test/src] mika% uname -a > Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 > [HAL:~/test/src] mika% as -v > Apple Inc version cctools-782~33, GNU assembler version 1.38 > > > I have XCode installed. > > [HAL:~/test/src] mika% gcc -v > Using built-in specs. > Target: i686-apple-darwin10 > Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 > Thread model: posix > gcc version 4.2.1 (Apple Inc. build 5664) > [HAL:~/test/src] mika% which gcc > /usr/bin/gcc > > > I must be doing something very obviously wrong (obviously to someone on this list, right??) > > Mika From hosking at cs.purdue.edu Sun Dec 12 21:20:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Dec 2010 15:20:20 -0500 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: <20101212093535.155ED1A207C@async.async.caltech.edu> References: <20101212093535.155ED1A207C@async.async.caltech.edu> Message-ID: <6545A943-6879-4B23-B3C4-17E5BDEB83C4@cs.purdue.edu> PS My "as" shows version: Apple Inc version cctools-782~37, GNU assembler version 1.38 Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 12, 2010, at 4:35 AM, Mika Nystrom wrote: > Thanks, Jay. > > I wasn't able to use your Darwin.config (remember, I'm installing > from the release .deb)---there seem to have been too many changes to > these files for me to be able to sort it all out. However, I figured > out how to do a "quick and dirty" from your email. > > This fixed it for me: > > if not defined("SYSTEM_ASM") > SYSTEM_ASM="/usr/libexec/gcc/darwin/i386/as" > end > > Now to check on all the other problems. > > Mika > > Jay K writes: >> --_1377ed26-bb42-4722-b430-c9bf3b1b287d_ >> Content-Type: text/plain; charset="Windows-1252" >> Content-Transfer-Encoding: quoted-printable >> >> >> I'm more sympathetic to using the already installed C compiler >> to drive the assembler=2C than to build the current gcc driver. >> >> >> You can see on Darwin we already probe around fairly aggressively >> for a C compiler that can be told the target: >> >> Darwin.common: >> >> >> proc configure_c_compiler() is >> >> if defined("SYSTEM_CC") >> return >> end >> >> % >> % older compiler doesn't like -m32 or -arch >> % >> % gcc -c -m32 -x c /dev/null >> % cc1: error: invalid option =91m32=92 >> % >> % fPIC is not usually needed here. >> % It is the default for Apple gcc and left >> % here in case user is using a self-built FSF gcc. >> % >> >> SYSTEM_CC =3D "gcc -gstabs+ -fPIC" >> local m =3D " -m" & {"32BITS":"32"=2C"64BITS":"64"}{WORD_SIZE} >> local arch =3D " -arch " & DarwinArch >> if not equal(try_exec("@" & SYSTEM_CC & m & " -c -x c /dev/null -o /dev/n= >> ull 2>&1 | fgrep \"cc1: error: invalid option \\\`32'\" >/dev/null")=2C 0) >> SYSTEM_CC =3D SYSTEM_CC & m >> end >> if not equal(try_exec("@" & SYSTEM_CC & arch & " -c -x c /dev/null -o /de= >> v/null 2>&1 | fgrep \"cc1: error: unrecognized command line option \\\\\"-a= >> rch\\\\\"\" >/dev/null")=2C 0) >> SYSTEM_CC =3D SYSTEM_CC & arch >> end >> %write("SYSTEM_CC is " & SYSTEM_CC) >> end >> > ... From hosking at cs.purdue.edu Sun Dec 12 21:25:13 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Dec 2010 15:25:13 -0500 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <20101212201458.BEFA41A2079@async.async.caltech.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu> Message-ID: <8A823CE8-A4A2-4280-8558-39D494F87160@cs.purdue.edu> That's an alignment problem alright. Perhaps the alignment information for VAL is wrong? Or for LONGINT? Jay, any ideas? On Dec 12, 2010, at 3:14 PM, Mika Nystrom wrote: > Hi everyone, > > Well I was able to get past all my linking issues (mostly questions > of dynamic vs. static linking and how to do it, which seems to change from > version to version...) > > But now I did hit a real problem. > > "../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** unaligned store type=6 s/o/a=32/0/32 > "../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** unaligned load_indirect type=6 s/a=32/32 > > Here is the code, but it's not likely to be of much help... > > PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.T RAISES { Scheme.E } = > BEGIN > VAR res : SchemePair.T:=NIL; BEGIN > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),ToScheme_Atom_T(x.type)),res); > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modificationTime"),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),ToScheme_VAL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) > RETURN res > END > END ToScheme_File_Status; > > > ... > > PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0, LONGINT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = > BEGIN > RETURN ToScheme_LONGINT(x) (* line 981 *) > END ToScheme_VAL0LONGINT__VAL16778080LONGINT; > > > for reference, ToScheme_LONGINT is: > > PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISES { Scheme.E } = > BEGIN > WITH ref = NEW(REF LONGINT) DO > ref^ := x; > RETURN SchemeModula3Types.ToScheme_LONGINT(ref) > END > END ToScheme_LONGINT; > > Mika From hosking at cs.purdue.edu Sun Dec 12 21:26:06 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Dec 2010 15:26:06 -0500 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <20101212201458.BEFA41A2079@async.async.caltech.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu> Message-ID: <8E56EB70-2DF9-40F8-8842-0D782A46EC7B@cs.purdue.edu> Mika, Did this LONGINT code work previously? I'm trying to figure out when the problem was introduced. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 12, 2010, at 3:14 PM, Mika Nystrom wrote: > Hi everyone, > > Well I was able to get past all my linking issues (mostly questions > of dynamic vs. static linking and how to do it, which seems to change from > version to version...) > > But now I did hit a real problem. > > "../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** unaligned store type=6 s/o/a=32/0/32 > "../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** unaligned load_indirect type=6 s/a=32/32 > > Here is the code, but it's not likely to be of much help... > > PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.T RAISES { Scheme.E } = > BEGIN > VAR res : SchemePair.T:=NIL; BEGIN > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),ToScheme_Atom_T(x.type)),res); > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modificationTime"),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),ToScheme_VAL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) > RETURN res > END > END ToScheme_File_Status; > > > ... > > PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0, LONGINT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = > BEGIN > RETURN ToScheme_LONGINT(x) (* line 981 *) > END ToScheme_VAL0LONGINT__VAL16778080LONGINT; > > > for reference, ToScheme_LONGINT is: > > PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISES { Scheme.E } = > BEGIN > WITH ref = NEW(REF LONGINT) DO > ref^ := x; > RETURN SchemeModula3Types.ToScheme_LONGINT(ref) > END > END ToScheme_LONGINT; > > Mika From mika at async.caltech.edu Sun Dec 12 21:49:02 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 12 Dec 2010 12:49:02 -0800 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <8E56EB70-2DF9-40F8-8842-0D782A46EC7B@cs.purdue.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu> <8E56EB70-2DF9-40F8-8842-0D782A46EC7B@cs.purdue.edu> Message-ID: <20101212204902.D68291A2079@async.async.caltech.edu> Tony, It's been a long, long time since I last compiled anything on I386_DARWIN, so I'm not sure. It did/does work on AMD64_LINUX and _FREEBSD, as far as I know. Mika Tony Hosking writes: >Mika, > >Did this LONGINT code work previously? I'm trying to figure out when = >the problem was introduced. > >Antony Hosking | Associate Professor | Computer Science | Purdue = >University >305 N. University Street | West Lafayette | IN 47907 | USA >Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > >On Dec 12, 2010, at 3:14 PM, Mika Nystrom wrote: > >> Hi everyone, >>=20 >> Well I was able to get past all my linking issues (mostly questions >> of dynamic vs. static linking and how to do it, which seems to change = >from >> version to version...) >>=20 >> But now I did hit a real problem. >>=20 >> "../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** = >unaligned store type=3D6 s/o/a=3D32/0/32 >> "../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** = >unaligned load_indirect type=3D6 s/a=3D32/32 >>=20 >> Here is the code, but it's not likely to be of much help... >>=20 >> PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : = >SchemeObject.T RAISES { Scheme.E } =3D >> BEGIN >> VAR res : SchemePair.T:=3DNIL; BEGIN >> res :=3D = >SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),ToScheme_A= >tom_T(x.type)),res); >> res :=3D = >SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modificationTime"= >),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); >> res :=3D = >SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),ToScheme_V= >AL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) >> RETURN res >> END >> END ToScheme_File_Status; >>=20 >>=20 >> ... >>=20 >> PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ = >VAL(0, LONGINT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { = >Scheme.E } =3D >> BEGIN >> RETURN ToScheme_LONGINT(x) (* line 981 *) >> END ToScheme_VAL0LONGINT__VAL16778080LONGINT; >>=20 >>=20 >> for reference, ToScheme_LONGINT is: >>=20 >> PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T = >RAISES { Scheme.E } =3D >> BEGIN >> WITH ref =3D NEW(REF LONGINT) DO >> ref^ :=3D x; >> RETURN SchemeModula3Types.ToScheme_LONGINT(ref) >> END >> END ToScheme_LONGINT; >>=20 >> Mika From jay.krell at cornell.edu Mon Dec 13 09:23:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Dec 2010 08:23:31 +0000 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: References: <20101211221902.B71F81A207C@async.async.caltech.edu>, Message-ID: Do all Darwin/x86 assemblers accept -arch flag? I don't know. e.g. 10.4? I might bring such a system back online.... Do all Darwin assemblers accept -arch? I doubt it. - Jay > From: hosking at cs.purdue.edu > Date: Sun, 12 Dec 2010 15:19:15 -0500 > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] cm3 on snow leopard? > > My config file has: > > SYSTEM_ASM="as" > ... > return try_exec ("@" & SYSTEM_ASM, "-arch", "i386", "-q", source, "-o", object > > Works fine for me on Snow Leopard. > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On Dec 11, 2010, at 5:19 PM, Mika Nystrom wrote: > > > Hello m3devel, > > > > I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook > > Air, but it seems I have the wrong assembler? > > > > I had to force dpkg to override the architecture on install (it was expecting > > i386, I think, and my machine identified itself as being "i386-darwin"?) > > > > Here are some details... > > > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version > > Critical Mass Modula-3 version 5.8.6 > > last updated: 2010-04-11 > > compiled: 2010-07-14 21:27:23 > > configuration: /usr/local/cm3/bin/cm3.cfg > > host: I386_DARWIN > > target: I386_DARWIN > > > > compiling an empty Main.m3 yields: > > > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands > > --- building in ../I386_DARWIN --- > > > > cd ../I386_DARWIN > > rm .M3SHIP > > rm .M3OVERRIDES > > inhale prog.mx > > inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a > > inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a > > > > new source -> compiling Main.m3 > > m3front ../src/Main.m3 -w1 > > /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno-reorde > > r-blocks Main.mc -o Main.ms > > echo "rep movsl" | as -o /dev/null 2> /dev/null > > as Main.ms -o Main.mo > > Main.ms:15:suffix or operands invalid for `push' > > assemble => 1 > > assembler failed assembling: Main.ms > > rm Main.mo > > exhale prog.mx > > rm prog.manifest > > > > compilation failed => not building program "prog" > > Fatal Error: package build failed > > > > [HAL:~/test/src] mika% uname -a > > Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 > > [HAL:~/test/src] mika% as -v > > Apple Inc version cctools-782~33, GNU assembler version 1.38 > > > > > > I have XCode installed. > > > > [HAL:~/test/src] mika% gcc -v > > Using built-in specs. > > Target: i686-apple-darwin10 > > Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 > > Thread model: posix > > gcc version 4.2.1 (Apple Inc. build 5664) > > [HAL:~/test/src] mika% which gcc > > /usr/bin/gcc > > > > > > I must be doing something very obviously wrong (obviously to someone on this list, right??) > > > > Mika > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 13 09:49:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Dec 2010 08:49:21 +0000 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <8A823CE8-A4A2-4280-8558-39D494F87160@cs.purdue.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, <8A823CE8-A4A2-4280-8558-39D494F87160@cs.purdue.edu> Message-ID: Head looks much better than release here. I'm not "just" saying that. release has stuff like m3front/src/misc/CG.m3: ELSIF (t = Target.Word.cg_type) OR (t = Target.Integer.cg_type) THEN ... ELSE Err("unaligned..." where head has: ELSIF (t = Target.Word.cg_type) OR (t = Target.Integer.cg_type) OR (t = Target.Long.cg_type) OR (t = Target.Longint.cg_type) THEN ... ELSE Err("unaligned..." several instances. Please try head. - Jay > From: hosking at cs.purdue.edu > Date: Sun, 12 Dec 2010 15:25:13 -0500 > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] compiler problems on Snow Leopard > > That's an alignment problem alright. Perhaps the alignment information for VAL is wrong? Or for LONGINT? Jay, any ideas? > > On Dec 12, 2010, at 3:14 PM, Mika Nystrom wrote: > > > Hi everyone, > > > > Well I was able to get past all my linking issues (mostly questions > > of dynamic vs. static linking and how to do it, which seems to change from > > version to version...) > > > > But now I did hit a real problem. > > > > "../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** unaligned store type=6 s/o/a=32/0/32 > > "../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** unaligned load_indirect type=6 s/a=32/32 > > > > Here is the code, but it's not likely to be of much help... > > > > PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.T RAISES { Scheme.E } = > > BEGIN > > VAR res : SchemePair.T:=NIL; BEGIN > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),ToScheme_Atom_T(x.type)),res); > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modificationTime"),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),ToScheme_VAL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) > > RETURN res > > END > > END ToScheme_File_Status; > > > > > > ... > > > > PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0, LONGINT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = > > BEGIN > > RETURN ToScheme_LONGINT(x) (* line 981 *) > > END ToScheme_VAL0LONGINT__VAL16778080LONGINT; > > > > > > for reference, ToScheme_LONGINT is: > > > > PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISES { Scheme.E } = > > BEGIN > > WITH ref = NEW(REF LONGINT) DO > > ref^ := x; > > RETURN SchemeModula3Types.ToScheme_LONGINT(ref) > > END > > END ToScheme_LONGINT; > > > > Mika > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 13 23:32:41 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Dec 2010 22:32:41 +0000 Subject: [M3devel] hardware woes (sort of).. Message-ID: Oops. Anyone in USA want an Itanium, no strings attached (but some suggested)? eBay item 290507974646 http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rt=nc&nma=true&item=290507974646 Thanks, - Jay From mika at async.caltech.edu Mon Dec 13 23:40:56 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 13 Dec 2010 14:40:56 -0800 Subject: [M3devel] file descriptor confusion? Message-ID: <20101213224056.18B341A2078@async.async.caltech.edu> Hi m3devel, Still fiddling with I386_DARWIN. I've been able to get everything that I need compiling with the release compiler so I haven't upgraded to the head yet. I'm trying hard to get a new product ready and am already behind, was hoping I could debug my own code on this new laptop... Maybe soon (actually I have already found a bug in my own code under the compiler so I shouldn't complain). But I've run into a mystery that I think may be due to some change in CM3, but it might also be a bug of mine, so please just let me know if there *might* have been some changes that could have had the following effect. My code uses a pretty elaborate debugging framework with a "Debug" module that prints debug messages and conditionally can turn on and off various input streams (types of debug messages) and output streams (targets: terminal, files, etc.) I have a program that connects over TCP to a server, using Wr and Rd on ConnFD.T, TCP.T, and such objects. I am now finding that my debug output is going to the server! It's supposed to be a completely separate stream. It looks like the file descriptors have gotten confused. Maybe. Does this ring a bell for anyone? Sometime in the last year I would guess. Code works perfectly under PM3 (as always). If it does ring a bell anywhere, what are the chances it's different in the head? Mika From jay.krell at cornell.edu Mon Dec 13 23:52:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Dec 2010 22:52:35 +0000 Subject: [M3devel] file descriptor confusion? In-Reply-To: <20101213224056.18B341A2078@async.async.caltech.edu> References: <20101213224056.18B341A2078@async.async.caltech.edu> Message-ID: Maybe some detail of fork? Does problem occur on other systems? Are you interfacing with C at all, besides what m3core/libm3 does for you? - Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Mon, 13 Dec 2010 14:40:56 -0800 > From: mika at async.caltech.edu > Subject: [M3devel] file descriptor confusion? > > Hi m3devel, > > Still fiddling with I386_DARWIN. > > I've been able to get everything that I need compiling with the release > compiler so I haven't upgraded to the head yet. I'm trying hard to > get a new product ready and am already behind, was hoping I could debug > my own code on this new laptop... Maybe soon (actually I have already > found a bug in my own code under the compiler so I shouldn't complain). > > But I've run into a mystery that I think may be due to some change in CM3, > but it might also be a bug of mine, so please just let me know if there > *might* have been some changes that could have had the following effect. > > My code uses a pretty elaborate debugging framework with a "Debug" > module that prints debug messages and conditionally can turn on and > off various input streams (types of debug messages) and output streams > (targets: terminal, files, etc.) > > I have a program that connects over TCP to a server, using Wr and Rd on > ConnFD.T, TCP.T, and such objects. I am now finding that my debug > output is going to the server! It's supposed to be a completely separate > stream. It looks like the file descriptors have gotten confused. Maybe. > > Does this ring a bell for anyone? Sometime in the last year I would guess. > Code works perfectly under PM3 (as always). If it does ring a bell > anywhere, what are the chances it's different in the head? > > Mika From wagner at elegosoft.com Tue Dec 14 11:03:08 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 14 Dec 2010 11:03:08 +0100 Subject: [M3devel] file descriptor confusion? In-Reply-To: <20101213224056.18B341A2078@async.async.caltech.edu> References: <20101213224056.18B341A2078@async.async.caltech.edu> Message-ID: <20101214110308.5q5cl8v484o8844g@mail.elegosoft.com> Quoting Mika Nystrom : > Hi m3devel, > > Still fiddling with I386_DARWIN. > > I've been able to get everything that I need compiling with the release > compiler so I haven't upgraded to the head yet. I'm trying hard to > get a new product ready and am already behind, was hoping I could debug > my own code on this new laptop... Maybe soon (actually I have already > found a bug in my own code under the compiler so I shouldn't complain). > > But I've run into a mystery that I think may be due to some change in CM3, > but it might also be a bug of mine, so please just let me know if there > *might* have been some changes that could have had the following effect. > > My code uses a pretty elaborate debugging framework with a "Debug" > module that prints debug messages and conditionally can turn on and > off various input streams (types of debug messages) and output streams > (targets: terminal, files, etc.) > > I have a program that connects over TCP to a server, using Wr and Rd on > ConnFD.T, TCP.T, and such objects. I am now finding that my debug > output is going to the server! It's supposed to be a completely separate > stream. It looks like the file descriptors have gotten confused. Maybe. > > Does this ring a bell for anyone? Sometime in the last year I would guess. > Code works perfectly under PM3 (as always). If it does ring a bell > anywhere, what are the chances it's different in the head? I think the main differences that one should look at are these two: o CM3 now uses a different threading implementation on most platforms (operating system (p)threads), and not self-implemented user threads any more. o Process.Create has been changed in order to cope with the change above, IIRC. All user threads used to be duplicated by fork, whereas the pthreads now need to be restarted in the child process. Please correct me if I remember this wrong, Jay. There's nothing more specific I can think of though that would explain the behaviour. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Dec 15 23:37:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Dec 2010 22:37:33 +0000 Subject: [M3devel] bit field operations for insert/extract In-Reply-To: References: , , <4FC6CE6F-FE19-461E-ACCC-41D6762CA3BC@cs.purdue.edu>, , , , , , Message-ID: I'm a bit nervous, like, that the semantics are the same esp. at the edge or past-the-edge cases -- extracting 0, 1, 31, 32, 33 bits, etc. I guess testing should show one way or the other -- assuming there aren't "undefined" things in gcc that vary per target (not sure if I have the patience or not to look at all the assembly for all the targets for all of the particular test case where I combinatorially generate everything, I probably should bite that bullet though, maybe split it into 4 easier to digest cases (32bit, 64bit, big endian, little endian). - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] bit field operations for insert/extract > Date: Tue, 23 Nov 2010 22:53:25 +0000 > > > Fair enough, easy enough. > I'd want to double check that the existing use is wanting that interpretation. > > > Obviously for that matter, we can leave the code asis for big endian. > And just take your code as it was, but under if (target_is_little_endian). > Big endian is the minority anyway. > :) > (no, I won't do that) > > > It would be cool if the frontend never checked target endianness. > It does it very little as it is. But ok either way. > (I want to move the Target.m3 stuff to the config files -- endianness, > setjmp name, jmpbuf size/align, etc., though that's about all that is left) > > > > - Jay > > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Tue, 23 Nov 2010 17:46:06 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] bit field operations for insert/extract > > > > If that's the case then I would argue for adjusting the offset accordingly in parse.c. > > extract_mn and insert_mn are defined as equivalent to Word.Extract/Word.Insert, respectively. > > > > On Nov 23, 2010, at 4:46 PM, Jay K wrote: > > > > > > > > Let me clarify. > > > Remember when you used bit field operations for extract_mn? > > > And they didn't work on any big endian system? > > > And I had to undo it? With your approval. > > > > > > > > > I believe the way to go: > > > the change you did in parse.c; it was correct, highly likely > > > removing those endian checks in m3front, which you didn't do at the time > > > > > > > > > Removing the endian checks will only affect big endian. > > > The code reads something like: > > > if little_endian extract_mn(offset, count) > > > else extract_mn(size - offset, size - count) > > > > > > > > > So just change it to: > > > extract_mn(offset, count) > > > > > > > > > And I strongly suspect it will affect it "in the right way". > > > But I'm going to try diffing assembly before/after to be sure. > > > And then watch the sparc and ppc hudson builds. :) > > > (and fix PPC_DARWIN beforehand as well) > > > > > > > > > > > > This is perhaps an interface change in m3cg, but there are no other big endian backends > > > and there are no other uses of extract_mn in the frontend, I think. > > > i.e. the meaning of extract_mn will have been changed to match gcc's interpretation, which it already did for little endian. Either that, or very reasonably in gcc we can check what the target endian is and adjust the count/offset. Either way. But one way involves target-specifieity in two places, the other zero. I like removing target-specificity. Though it is probably kind of implied in the next layer down, in gcc. > > > > > > > > > Anyway, still speculation at this point. > > > But this is pretty high on my list, low hanging fruit granted, probably no affect in the optimized code or perhaps unoptimized code, but I do like the idea to keep parse.c "thin" here if possible. > > > (ie: if this goes well, the next thing to look at is rotate, however in all of these bit operations, > > > I do worry that our definition of count/offset = 0, = type_precision, > type_precision may not match the gcc backend; > > > perhaps it is best to just leave everything asis...?) > > > > > > > > > and then I'll try to focus again on the type stuff, which is currently disabled because there was some problem, and then I decided I needed multiple passes, so I needed an in-memory form besides locals, so I wanted structs, declaratively declared (!) and depersisted, so I wanted C++, so I spent a week fixing that, oops...and there was also an m3cg/ir change which we found Hudson wasn't dealing with properly...and then configure enable-checking which I also have wanted...[i.e. I think have good excuses lately!] > > > > > > > > > (and then the later part of the type stuff is array/component_refs, and *then* enabling all optimizations, *including* not taking the address of so many things....(we're actually pretty good now and only disable one optimization, but taking the address probably is still a big downer)) > > > > > > > > > - Jay > > > > > > > > > ________________________________ > > >> Subject: Re: [M3devel] bit field operations for insert/extract > > >> From: hosking at cs.purdue.edu > > >> Date: Tue, 23 Nov 2010 16:34:25 -0500 > > >> CC: m3devel at elegosoft.com > > >> To: jay.krell at cornell.edu > > >> > > >> Are they wrong? Seems strange that they worked previously! > > >> > > >> On Nov 23, 2010, at 1:46 PM, Jay K wrote: > > >> > > >> None yet. But notice the endian checks around the insert_mn or > > >> extract_mn uses in cg.m3. > > >> The change would be to remove those. > > >> > > >> - Jay > > >> > > >> > > >> ________________________________ > > >> Subject: Re: [M3devel] bit field operations for insert/extract > > >> From: hosking at cs.purdue.edu > > >> Date: Tue, 23 Nov 2010 09:37:00 -0500 > > >> CC: m3devel at elegosoft.com > > >> To: jay.krell at cornell.edu > > >> > > >> Refresh my memory. What m3front change did you make? > > >> > > >> > > >> On Nov 23, 2010, at 3:33 AM, Jay K wrote: > > >> > > >> Tony, I'm going to try again to use bitfield operations for extract_mn. > > >> And insert_mn. > > >> I think I know what went wrong before for extract_mn: just remove the > > >> endian check in m3front. > > >> But I'm going to be sure test p240 covers it well. > > >> > > >> The easy part, duh, your original extract_mn was correct I think, just, > > >> again, missing the m3front change. > > >> > > >> Insert_mn is less obvious. > > >> I started writing it... bitfield_ref..modify_expr...uh, seems > > >> suspicious, to be modifying an existing value. > > >> > > >> I guess it's more like, that, but with a temp that starts with the full > > >> value of x: > > >> create temp > > >> modify(temp, x) > > >> modify(bitfield_ref(temp, count, offset), y); > > >> m3_load(temp) > > >> > > >> ? > > >> > > >> I'll try something like that. > > >> It seems unfortunate. > > >> Maybe we can know if x is already a value and not a variable? > > >> > > >> > > >> - Jay > > >> > > >> > > >> > > From dragisha at m3w.org Fri Dec 17 10:25:32 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 17 Dec 2010 10:25:32 +0100 Subject: [M3devel] swig Message-ID: Hi, GNU Modula-2 has this: http://www.nongnu.org/gm2/gm2.html#SEC23, and it's probably interesting for us too. Fancy approach there - instead of including a language parser into SWIG proper, a compiler emits .i files. SWIG is then used to process it to "client" platforms. d From jay.krell at cornell.edu Sat Dec 18 11:43:46 2010 From: jay.krell at cornell.edu (Jay) Date: Sat, 18 Dec 2010 02:43:46 -0800 Subject: [M3devel] TCardinal Message-ID: > CARDINAL is only ever used for values that should be in range on all > architectures. really? - Jay From hosking at cs.purdue.edu Sat Dec 18 16:45:42 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 18 Dec 2010 10:45:42 -0500 Subject: [M3devel] TCardinal In-Reply-To: References: Message-ID: <8530EEC4-872F-490B-94BB-3254834593B6@cs.purdue.edu> Yep. As far as I can tell. On Dec 18, 2010, at 5:43 AM, Jay wrote: >> CARDINAL is only ever used for values that should be in range on all >> architectures. > > really? > > - Jay From mika at async.caltech.edu Mon Dec 20 13:43:13 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 20 Dec 2010 04:43:13 -0800 Subject: [M3devel] swig In-Reply-To: References: Message-ID: <20101220124313.E25011A2061@async.async.caltech.edu> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >Hi, > >GNU Modula-2 has this: http://www.nongnu.org/gm2/gm2.html#SEC23, and = >it's probably interesting for us too. Fancy approach there - instead of = >including a language parser into SWIG proper, a compiler emits .i files. = >SWIG is then used to process it to "client" platforms. > >d One could also use m3tk for this. That's the approach I take for my Scheme environment, which I in principle have no objections to releasing, but haven't had the time to clean up properly.. (like so many other things). Of course since my Scheme interpreter is written in Modula-3, my code is (in principle) independent of implementation decisions in the Modula-3 compiler. (The code that the compiler sees is pure Modula-3.) Mika From dragisha at m3w.org Thu Dec 23 17:12:44 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 23 Dec 2010 17:12:44 +0100 Subject: [M3devel] still alive? Message-ID: <1293120764.8612.1.camel@boromir.m3w.org> Holiday season started already? -- Dragi?a Duri? From dabenavidesd at yahoo.es Fri Dec 24 15:13:38 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 24 Dec 2010 14:13:38 +0000 (GMT) Subject: [M3devel] still alive? In-Reply-To: <1293120764.8612.1.camel@boromir.m3w.org> Message-ID: <441851.14864.qm@web29708.mail.ird.yahoo.com> Hi all: I hope you had started, merry Christmas and let's wait this thing has very interesting things for us: https://groups.google.com/group/comp.std.c++/tree/browse_frm/month/1994-03/3dbb4bad549f75d4?rnum=51&_done=/group/comp.std.c%2B%2B/browse_frm/month/1994-03?&hl=pt&pli=1 check for the post for he third message: There is someone who was the mentioned OS sources, he was wondering in there what would mean CAMEL (the Application Manager at some time in that not commercialized project told me that it might be Compiler for Acorn Modula-2 Extended Language), it seems those guys there liked a lot to use exceptions, but the Application Manager said that there were in Xerox/Alto machines program crashes a lot times with run-time message uncaught exception. Hope it helps to awareness of this things --- El jue, 23/12/10, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: [M3devel] still alive? > Para: "m3devel" > Fecha: jueves, 23 de diciembre, 2010 11:12 > Holiday season started already? > -- > Dragi?a Duri? > > From dragisha at m3w.org Sat Dec 25 22:22:34 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 25 Dec 2010 22:22:34 +0100 Subject: [M3devel] Out-of-place error? Message-ID: I am getting this message *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "../src/types/XLTypeList.m3", line 235 *** And code is: 235 RETURN RefSeq.Sub(o1, from-1, XLTypeNumber.FromInt(range.get(1))); In this environment (just to get an idea): IF range.get(1) = NIL THEN RETURN RefSeq.Sub(o1, from-1); ELSE RETURN RefSeq.Sub(o1, from-1, XLTypeNumber.FromInt(range.get(1))); END; Same crash, same line :), happened when I inserted <* DEBUG range.get(1) *> before RETURN statement in ELSE branch.. Why this happens? TIA, dd p.s. Merry Christmass, of course :) From jay.krell at cornell.edu Sun Dec 26 00:41:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Dec 2010 23:41:28 +0000 Subject: [M3devel] Out-of-place error? In-Reply-To: References: Message-ID: I don't understand the question. > From: dragisha at m3w.org > Date: Sat, 25 Dec 2010 22:22:34 +0100 > To: m3devel at elegosoft.com > Subject: [M3devel] Out-of-place error? > > I am getting this message > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/types/XLTypeList.m3", line 235 > *** > > And code is: > 235 RETURN RefSeq.Sub(o1, from-1, XLTypeNumber.FromInt(range.get(1))); > > In this environment (just to get an idea): > IF range.get(1) = NIL THEN > RETURN RefSeq.Sub(o1, from-1); > ELSE > RETURN RefSeq.Sub(o1, from-1, XLTypeNumber.FromInt(range.get(1))); > END; > > Same crash, same line :), happened when I inserted > <* DEBUG range.get(1) *> > > before RETURN statement in ELSE branch.. > > Why this happens? > > TIA, > dd > > p.s. Merry Christmass, of course :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 26 11:02:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Dec 2010 10:02:12 +0000 Subject: [M3devel] assertion failure in compiler Message-ID: MODULE bug1; PROCEDURE F1()= CONST a=ARRAY OF INTEGER{0}; VAR b := SUBARRAY(0,1,a); BEGIN END F1; BEGIN END bug1. new source -> compiling bug1.m3 "../src/bug1.m3", line 5: SUBARRAY: first argument must be an array *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/exprs/Expr.m3", line 337 *** -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 26 11:28:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Dec 2010 10:28:40 +0000 Subject: [M3devel] offsetof, et. al? Message-ID: construction various data? So, I have this C: typedef struct _enum_t { const char* name; uint64_t value; } enum_t; typedef struct _field_t { char name[16]; uchar offset; uchar size; uchar element_size; uchar str; uchar macho_string; uchar enum_table_count; const enum_t* enum_table; } field_t; #define FIELD(t, f) {STRINGIZE(f), offsetof(t, f), sizeof((((t*)0)->f))} #define FIELD_ARRAY(t, f) {STRINGIZE(f), offsetof(t, f), sizeof((((t*)0)->f)), sizeof((((t*)0)->f)[0]) } #define FIELD_STRING(t, f) {STRINGIZE(f), offsetof(t, f), sizeof((((t*)0)->f)), sizeof((((t*)0)->f)[0]), 1 } #define FIELD_ENUM(t, f, e) {STRINGIZE(f), offsetof(t, f), sizeof((((t*)0)->f)), 0, 0, 0, sizeof(e)/sizeof((e)[0]), e } #define FIELD_MACHO_STRING(t, f) {STRINGIZE(f), offsetof(t, f), sizeof((((t*)0)->f)), 0, 0, 1 } typedef struct _struct_t { const char* name; uint size; uint nfields; const field_t* fields; int widest_field; } struct_t; #define STRUCT(a) {STRINGIZE(a), sizeof(a), NUMBER_OF(PASTE(a,_fields)), PASTE(a,_fields)} extern_const enum_t macho_magic_names[] = { { "magic32", macho_magic32 }, { "magic64", macho_magic64 } }; extern_const enum_t macho_cputype_names[] = { { "x86", macho_cpu_type_x86 }, { "amd64", macho_cpu_type_amd64 }, { "powerpc", macho_cpu_type_powerpc }, { "powerpc64", macho_cpu_type_powerpc64 } }; extern_const enum_t macho_cpusubtype_names[] = { { "powerpc_all", macho_cpu_subtype_powerpc_all }, { "x86_all", macho_cpu_subtype_x86_all } }; extern_const enum_t macho_filetype_names[] = { { "object", macho_type_object }, { "execute", macho_type_execute }, { "fixed_vm_library", macho_type_fixed_vm_library }, { "core", macho_type_core }, { "preload", macho_type_preload }, { "dylib", macho_type_dylib }, { "dylinker", macho_type_dylinker }, { "bundle", macho_type_bundle }, { "dylib_stub", macho_type_dylib_stub }, { "dsym", macho_type_dsym } }; extern_const field_t macho_header32_t_fields[] = { FIELD_ENUM(macho_header32_t, magic, macho_magic_names), FIELD_ENUM(macho_header32_t, cputype, macho_cputype_names), FIELD_ENUM(macho_header32_t, cpusubtype, macho_cpusubtype_names), FIELD_ENUM(macho_header32_t, filetype, macho_filetype_names), FIELD(macho_header32_t, ncmds), FIELD(macho_header32_t, sizeofcmds), FIELD(macho_header32_t, flags) }; how do I "best" convert this to Modula-3? I don't see a good analog to offsetof. I don't see a good analog of variably sized non-copying arrays, esp. constants. I have something kind of close, but I have to use VAR in places instead of CONST, and I have to make copies of the arrays, and I have to compute the offsets/sizes myself, which isn't difficult. I understand that using offset of is necesssarily unsafe. What I have, C and Modula-3, is checked in, in scratch/macho. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 26 21:15:37 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Dec 2010 15:15:37 -0500 Subject: [M3devel] Out-of-place error? In-Reply-To: References: Message-ID: <00F41A55-5306-4C7D-8E7C-1BE206AAF47C@cs.purdue.edu> Weird. What does the signature of range.get look like? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 25, 2010, at 6:41 PM, Jay K wrote: > I don't understand the question. > > > From: dragisha at m3w.org > > Date: Sat, 25 Dec 2010 22:22:34 +0100 > > To: m3devel at elegosoft.com > > Subject: [M3devel] Out-of-place error? > > > > I am getting this message > > > > *** > > *** runtime error: > > *** An enumeration or subrange value was out of range. > > *** file "../src/types/XLTypeList.m3", line 235 > > *** > > > > And code is: > > 235 RETURN RefSeq.Sub(o1, from-1, XLTypeNumber.FromInt(range.get(1))); > > > > In this environment (just to get an idea): > > IF range.get(1) = NIL THEN > > RETURN RefSeq.Sub(o1, from-1); > > ELSE > > RETURN RefSeq.Sub(o1, from-1, XLTypeNumber.FromInt(range.get(1))); > > END; > > > > Same crash, same line :), happened when I inserted > > <* DEBUG range.get(1) *> > > > > before RETURN statement in ELSE branch.. > > > > Why this happens? > > > > TIA, > > dd > > > > p.s. Merry Christmass, of course :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 26 21:25:42 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Dec 2010 15:25:42 -0500 Subject: [M3devel] assertion failure in compiler In-Reply-To: References: Message-ID: I think this is a known bug, related to one we already have a testcase for. On Dec 26, 2010, at 5:02 AM, Jay K wrote: > MODULE bug1; > > PROCEDURE F1()= > CONST a=ARRAY OF INTEGER{0}; > VAR b := SUBARRAY(0,1,a); > BEGIN > END F1; > > BEGIN > END bug1. > > > new source -> compiling bug1.m3 > "../src/bug1.m3", line 5: SUBARRAY: first argument must be an array > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/exprs/Expr.m3", line 337 > *** > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 27 03:11:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 02:11:28 +0000 Subject: [M3devel] pointers/arrays? Message-ID: a: UNTRACED REF T; i: INTEGER; a[i] ? (a + i)^ ? Or I'm really stuck with LOOPEHOLE(a + i * BYTESIZE(a^), UNTRACED REF T) Seems kind of stinky. I've got some nice efficient readable safe-enough C and it doesn't seem to translate well easily efficiently to Modula-3. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 27 05:37:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 04:37:07 +0000 Subject: [M3devel] pointers/arrays? In-Reply-To: References: Message-ID: I'm still wrestling with this. I have found a few options that work and they all have glaring problems. VAR macho_header32_t_fields := ARRAY [0..6] OF field_t{ field_t{ "magic", 0, 4, enum_table := EnumTable(macho_magic_names)}, ... field_t{ "flags", 24, 4}}; 1) I shouldn't have to give the size of the array. 2) I shouldn't have to copy the enum table to make it an indexable array. Disappointing.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 27 Dec 2010 02:11:28 +0000 Subject: [M3devel] pointers/arrays? a: UNTRACED REF T; i: INTEGER; a[i] ? (a + i)^ ? Or I'm really stuck with LOOPEHOLE(a + i * BYTESIZE(a^), UNTRACED REF T) Seems kind of stinky. I've got some nice efficient readable safe-enough C and it doesn't seem to translate well easily efficiently to Modula-3. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 27 08:15:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 07:15:26 +0000 Subject: [M3devel] constants/offsetof? Message-ID: Is it unreasonble to expect more/all of these to be constant? UNSAFE MODULE bug1; TYPE T1 = RECORD i,j:INTEGER END; <*NOWARN*>VAR a:T1; <*NOWARN*>CONST b: UNTRACED REF T1 = NIL; <*NOWARN*>CONST c: ADDRESS = ADR(a); (* line 7 *) <*NOWARN*>CONST d: ADDRESS = ADR(a.i); <*NOWARN*>CONST e: ADDRESS = ADR(a.j); <*NOWARN*>CONST f: INTEGER = ADR(a.j) - NIL; <*NOWARN*>CONST g: ADDRESS = ADR(b.i); <*NOWARN*>CONST h: ADDRESS = ADR(b.j); <*NOWARN*>CONST i: INTEGER = ADR(b.j) - NIL; <*NOWARN*>VAR vc: ADDRESS := ADR(a); <*NOWARN*>VAR vd: ADDRESS := ADR(a.i); <*NOWARN*>VAR ve: ADDRESS := ADR(a.j); <*NOWARN*>VAR vf: INTEGER := ADR(a.j) - NIL; (* oops, didn't mean this one *) <*NOWARN*>VAR vg: ADDRESS := ADR(b.i); <*NOWARN*>VAR vh: ADDRESS := ADR(b.j); <*NOWARN*>VAR vi: INTEGER := ADR(b.j) - NIL; BEGIN END bug1. "../src/bug1.m3", line 7: value is not constant "../src/bug1.m3", line 8: value is not constant "../src/bug1.m3", line 9: value is not constant "../src/bug1.m3", line 10: value is not constant "../src/bug1.m3", line 11: value is not constant "../src/bug1.m3", line 12: value is not constant "../src/bug1.m3", line 13: value is not constant It works in C... #include typedef struct { ptrdiff_t i, j;}T1; T1 a; #define b ((T1*)0) T1* const c = &a; ptrdiff_t* const d = &a.i; ptrdiff_t* const e = &a.j; ptrdiff_t const f = offsetof(T1,j); ptrdiff_t* const g = &b->i; ptrdiff_t* const h = &b->j; ptrdiff_t const i = &b->j - (ptrdiff_t*)0; Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Dec 27 11:14:21 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Dec 2010 02:14:21 -0800 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <20101212201458.BEFA41A2079@async.async.caltech.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu> Message-ID: <20101227101421.38A6A1A205B@async.async.caltech.edu> I upgraded to the CVS head and now I get the following: ... "../I386_DARWIN/FSSchemeStubs.m3", line 872: warning: unreachable statement "../I386_DARWIN/FSSchemeStubs.m3", line 903: warning: unreachable statement "../I386_DARWIN/FSSchemeStubs.m3", line 434: 2 code generation errors 1 error and 23 warnings encountered new exporters -> recompiling FSSchemeStubs.i3 ... The source code is: TYPE FS_Iterator_Surrogate = FS.Iterator OBJECT (* line 434 *) interp : Scheme.T; next_slot : SchemeObject.T := NIL; close_slot : SchemeObject.T := NIL; nextWithStatus_slot : SchemeObject.T := NIL; OVERRIDES next := FS_Iterator_next_default; close := FS_Iterator_close_default; nextWithStatus := FS_Iterator_nextWithStatus_default; END; Mika Mika Nystrom writes: >Hi everyone, > >Well I was able to get past all my linking issues (mostly questions >of dynamic vs. static linking and how to do it, which seems to change from >version to version...) > >But now I did hit a real problem. > >"../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** unaligne >d store type=6 s/o/a=32/0/32 >"../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** unaligne >d load_indirect type=6 s/a=32/32 > >Here is the code, but it's not likely to be of much help... > >PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.T RAIS >ES { Scheme.E } = > BEGIN > VAR res : SchemePair.T:=NIL; BEGIN > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),T >oScheme_Atom_T(x.type)),res); > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modifica >tionTime"),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),T >oScheme_VAL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) > RETURN res > END > END ToScheme_File_Status; > > >... > >PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0, LONGI >NT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = > BEGIN > RETURN ToScheme_LONGINT(x) (* line 981 *) > END ToScheme_VAL0LONGINT__VAL16778080LONGINT; > > >for reference, ToScheme_LONGINT is: > >PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISES { S >cheme.E } = > BEGIN > WITH ref = NEW(REF LONGINT) DO > ref^ := x; > RETURN SchemeModula3Types.ToScheme_LONGINT(ref) > END > END ToScheme_LONGINT; > > Mika From mika at async.caltech.edu Mon Dec 27 11:16:53 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Dec 2010 02:16:53 -0800 Subject: [M3devel] another Snow Leopard compiler crash Message-ID: <20101227101653.307241A205B@async.async.caltech.edu> ===> calarm/regress/ximport --- building in I386_DARWIN --- new source -> compiling Main.m3 "../src/Main.m3", line 258: warning: potentially unhandled exception: Main.ParamErr "../src/Main.m3", line 260: warning: potentially unhandled exception: Main.ParamErr "../src/Main.m3", line 261: warning: potentially unhandled exception: Main.ParamErr 3 warnings encountered ../src/Main.m3: In function 'Main__DumpMatching__DumpOne': ../src/Main.m3:225:0: error: unable to find a register to spill in class 'CREG' ../src/Main.m3:225:0: error: this is the insn: (insn 5 4 6 2 ../src/Main.m3:204 (parallel [ (set (reg:SI 0 ax [130]) (const_int 0 [0x0])) (set (reg:SI 1 dx [128]) (plus:SI (ashift:SI (reg:SI 0 ax [130]) (const_int 2 [0x2])) (reg:SI 1 dx [128]))) (set (reg:SI 4 si [129]) (plus:SI (ashift:SI (reg:SI 0 ax [130]) (const_int 2 [0x2])) (reg:SI 4 si [129]))) (set (mem/s/c:BLK (reg:SI 1 dx [128]) [0 trade+0 S24 A64]) (mem/s/c:BLK (reg:SI 4 si [129]) [0 trade+0 S24 A32])) (use (reg:SI 0 ax [130])) ]) 838 {*rep_movsi} (expr_list:REG_UNUSED (reg:SI 0 ax [130]) (expr_list:REG_UNUSED (reg:SI 4 si [129]) (expr_list:REG_UNUSED (reg:SI 1 dx [128]) (nil))))) ../src/Main.m3:225:0: internal compiler error: in spill_failure, at reload1.c:2163 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: Main.mc compilation failed => not building program "ximport" Fatal Error: package build failed Here is the code: PROCEDURE DumpMatching(tr : TickerRef; trades, bids, asks : HFDataSSeq.T) RAISES { Wr.Failure } = PROCEDURE DumpOne(trade, bid, ask : HFData.S) RAISES { Wr.Failure } = BEGIN <* ASSERT trade.time = bid.time AND bid.time = ask.time *> Wr.PutText(wr, Fmt.LongReal(trade.time)); Wr.PutChar(wr, ' '); Wr.PutText(wr, Fmt.LongReal(aFactor*trade.pv.price)); Wr.PutChar(wr, ' '); Wr.PutText(wr, Fmt.LongReal(FLOAT(trade.pv.volume,LONGREAL)/aFactor)); Wr.PutChar(wr, ' '); Wr.PutText(wr, Fmt.LongReal(aFactor*bid.pv.price)); Wr.PutChar(wr, ' '); Wr.PutText(wr, Fmt.LongReal(FLOAT(bid.pv.volume,LONGREAL)/aFactor)); Wr.PutChar(wr, ' '); Wr.PutText(wr, Fmt.LongReal(aFactor*ask.pv.price)); Wr.PutChar(wr, ' '); Wr.PutText(wr, Fmt.LongReal(FLOAT(ask.pv.volume,LONGREAL)/aFactor)); Wr.PutChar(wr, '\n') END DumpOne; CONST NoTime = FIRST(Time.T); VAR wr := FileWr.Open(odir & "/" & tr.ticker); tp, bp, ap := 0; ttime, btime, atime := NoTime; aFactor : LONGREAL := 1.0d0; BEGIN WHILE tp < trades.size() AND bp < bids.size() AND ap < asks.size() DO IF ttime = NoTime THEN ttime := trades.get(tp).time END; IF btime = NoTime THEN btime := bids.get(bp).time END; IF atime = NoTime THEN atime := asks.get(ap).time END; IF ttime = btime AND btime = atime THEN DumpOne(trades.get(tp),bids.get(bp),asks.get(ap)); INC(tp); INC(bp); INC(ap); ttime := NoTime; btime := NoTime; atime := NoTime ELSIF ttime < btime OR ttime < atime THEN INC(tp); ttime := NoTime ELSIF btime < atime OR btime < ttime THEN INC(bp); btime := NoTime ELSIF atime < btime OR atime < ttime THEN INC(ap); atime := NoTime END END; Wr.Close(wr) END DumpMatching; Miika From jay.krell at cornell.edu Mon Dec 27 11:17:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 10:17:51 +0000 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <20101227101421.38A6A1A205B@async.async.caltech.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, <20101227101421.38A6A1A205B@async.async.caltech.edu> Message-ID: Can you put all your code in our CVS repository? > "../I386_DARWIN/FSSchemeStubs.m3", line 434: 2 code generation errors There is a way to get that to show more information.. Or does it already? - Jay > To: m3devel at elegosoft.com > Date: Mon, 27 Dec 2010 02:14:21 -0800 > From: mika at async.caltech.edu > Subject: Re: [M3devel] compiler problems on Snow Leopard > > I upgraded to the CVS head and now I get the following: > > ... > "../I386_DARWIN/FSSchemeStubs.m3", line 872: warning: unreachable statement > "../I386_DARWIN/FSSchemeStubs.m3", line 903: warning: unreachable statement > "../I386_DARWIN/FSSchemeStubs.m3", line 434: 2 code generation errors > 1 error and 23 warnings encountered > new exporters -> recompiling FSSchemeStubs.i3 > ... > > The source code is: > > TYPE FS_Iterator_Surrogate = FS.Iterator OBJECT (* line 434 *) > interp : Scheme.T; > next_slot : SchemeObject.T := NIL; > close_slot : SchemeObject.T := NIL; > nextWithStatus_slot : SchemeObject.T := NIL; > OVERRIDES > next := FS_Iterator_next_default; > close := FS_Iterator_close_default; > nextWithStatus := FS_Iterator_nextWithStatus_default; > END; > > Mika > > Mika Nystrom writes: > >Hi everyone, > > > >Well I was able to get past all my linking issues (mostly questions > >of dynamic vs. static linking and how to do it, which seems to change from > >version to version...) > > > >But now I did hit a real problem. > > > >"../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** unaligne > >d store type=6 s/o/a=32/0/32 > >"../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** unaligne > >d load_indirect type=6 s/a=32/32 > > > >Here is the code, but it's not likely to be of much help... > > > >PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.T RAIS > >ES { Scheme.E } = > > BEGIN > > VAR res : SchemePair.T:=NIL; BEGIN > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),T > >oScheme_Atom_T(x.type)),res); > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modifica > >tionTime"),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),T > >oScheme_VAL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) > > RETURN res > > END > > END ToScheme_File_Status; > > > > > >... > > > >PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0, LONGI > >NT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = > > BEGIN > > RETURN ToScheme_LONGINT(x) (* line 981 *) > > END ToScheme_VAL0LONGINT__VAL16778080LONGINT; > > > > > >for reference, ToScheme_LONGINT is: > > > >PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISES { S > >cheme.E } = > > BEGIN > > WITH ref = NEW(REF LONGINT) DO > > ref^ := x; > > RETURN SchemeModula3Types.ToScheme_LONGINT(ref) > > END > > END ToScheme_LONGINT; > > > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Dec 27 11:38:10 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Dec 2010 02:38:10 -0800 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, <20101227101421.38A6A1A205B@async.async.caltech.edu> Message-ID: <20101227103810.94DF21A205B@async.async.caltech.edu> Jay K writes: >--_6f82bcb2-663f-4046-87f2-073a1528a819_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Can you put all your code in our CVS repository? > I can't put all the code I work with in m3devel's repository: some of it is proprietary. The Scheme code however I have no restrictions on distributing (that's what's got problems in this case). It is however large and unwieldy and I'd like to have other people's suggestions for how to submit/incorporate it with CM3 before I just dump it in the repository. It also overlaps a bit with "caltech-parser", so there should probably be a "caltech-common" package for the overlaps? If you run the following commands in a fresh directory, you should get to the error I emailed: setenv CM3 1 cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -d . make regress # GNU make : 'gmake regress' on BSD cd mscheme/sstubgen/example cm3 -x Mika From jay.krell at cornell.edu Mon Dec 27 11:35:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 10:35:24 +0000 Subject: [M3devel] enable/disableswitching around external calls? Message-ID: I noticed calls to free in M3toC missing Enable/DisableSwitching. I'm going to generalize this, somewhat, in m3core.h, but that still leaves a fair number of custom wrappers. This area seems extremely error prone and extremely difficult to get test coverage on. These functions only do anything for user threads. Which we only use by default on OpenBSD. How about the frontend emit the calls around any external calls? Theory being: external calls are rare? Perhaps frontend/m3middle would know if user threads are in use and only emit the calls in that case. Perhaps. I don't like sprinking much target-specific information around. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 27 11:46:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 10:46:55 +0000 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <20101227103810.94DF21A205B@async.async.caltech.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , <20101227103810.94DF21A205B@async.async.caltech.edu> Message-ID: aside: overlap with caltech_parser: if you can come up with a merged version that works with both, good If you can't, I think you have to rename one or the other. Maybe someday we can support some sort of hierarchy that automatically maps to/from the file system hierarchy... I'll try to reproduce the problem. All targets? Workaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) - Jay > To: jay.krell at cornell.edu > Date: Mon, 27 Dec 2010 02:38:10 -0800 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] compiler problems on Snow Leopard > > Jay K writes: > >--_6f82bcb2-663f-4046-87f2-073a1528a819_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Can you put all your code in our CVS repository? > > > > I can't put all the code I work with in m3devel's repository: some of > it is proprietary. > > The Scheme code however I have no restrictions on distributing (that's > what's got problems in this case). It is however large and unwieldy and > I'd like to have other people's suggestions for how to submit/incorporate > it with CM3 before I just dump it in the repository. It also overlaps a bit > with "caltech-parser", so there should probably be a "caltech-common" > package for the overlaps? > > If you run the following commands in a fresh directory, you should get > to the error I emailed: > > setenv CM3 1 > cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -d . > make regress # GNU make : 'gmake regress' on BSD > cd mscheme/sstubgen/example > cm3 -x > > Mika > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 27 11:51:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 10:51:10 +0000 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , , , <20101227103810.94DF21A205B@async.async.caltech.edu>, Message-ID: I can't quite reproduce it, but I can compile a bunch of your code. new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-lib.a" -> archiving libsstubgen.a ===> mscheme/sstubgen/program --- building in I386_DARWIN --- -> linking sstubgen i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/libmscheme.a: No such file or directory m3_link => 1 linker failed linking: sstubgen Fatal Error: package build failed jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example jbook2:example jay$ c,3 -bash: c,3: command not found jbook2:example jay$ cm3 --- building in I386_DARWIN --- ignoring ../src/m3overrides "/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3makefile", line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/I386_DARWIN/.M3EXPORTS" for reading --procedure-- -line- -file--- import -- include_dir 3 /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3makefile - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu Date: Mon, 27 Dec 2010 10:46:55 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] compiler problems on Snow Leopard aside: overlap with caltech_parser: if you can come up with a merged version that works with both, good If you can't, I think you have to rename one or the other. Maybe someday we can support some sort of hierarchy that automatically maps to/from the file system hierarchy... I'll try to reproduce the problem. All targets? Workaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) - Jay > To: jay.krell at cornell.edu > Date: Mon, 27 Dec 2010 02:38:10 -0800 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] compiler problems on Snow Leopard > > Jay K writes: > >--_6f82bcb2-663f-4046-87f2-073a1528a819_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Can you put all your code in our CVS repository? > > > > I can't put all the code I work with in m3devel's repository: some of > it is proprietary. > > The Scheme code however I have no restrictions on distributing (that's > what's got problems in this case). It is however large and unwieldy and > I'd like to have other people's suggestions for how to submit/incorporate > it with CM3 before I just dump it in the repository. It also overlaps a bit > with "caltech-parser", so there should probably be a "caltech-common" > package for the overlaps? > > If you run the following commands in a fresh directory, you should get > to the error I emailed: > > setenv CM3 1 > cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -d . > make regress # GNU make : 'gmake regress' on BSD > cd mscheme/sstubgen/example > cm3 -x > > Mika > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Dec 27 11:53:17 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Dec 2010 02:53:17 -0800 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , <20101227103810.94DF21A205B@async.async.caltech.edu> Message-ID: <20101227105317.52A861A205B@async.async.caltech.edu> I'mu sure a merged version is possible. I still have a separate version of caltech-parser in "my" repository that works with "my" Debug.i3, etc. I have only tried Snow Leopard (I386_DARWIN). I use PM3 on FreeBSD... I haven't tried workarounds here because I don't desperately need this code to work (at least not yet). The problem I reported a couple of weeks ago with "file descriptors" turned out to have something to do with closing a file through C somehow.. not sure exactly what was going on since I am using a helper C process to do terminal I/O using GNU readline. Mika Jay K writes: >--_f9584f16-e235-418f-823d-1c2a51c6bc9b_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >aside: overlap with caltech_parser: >if you can come up with a merged version that works with both=2C good >If you can't=2C I think you have to rename one or the other. > >Maybe someday we can support some sort of hierarchy that automatically maps= > to/from the file system hierarchy... > >I'll try to reproduce the problem. > >All targets? >Workaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) > > - Jay > > >> To: jay.krell at cornell.edu >> Date: Mon=2C 27 Dec 2010 02:38:10 -0800 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] compiler problems on Snow Leopard >>=20 >> Jay K writes: >> >--_6f82bcb2-663f-4046-87f2-073a1528a819_ >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> >Can you put all your code in our CVS repository? >> > >>=20 >> I can't put all the code I work with in m3devel's repository: some of=20 >> it is proprietary. >>=20 >> The Scheme code however I have no restrictions on distributing (that's >> what's got problems in this case). It is however large and unwieldy and >> I'd like to have other people's suggestions for how to submit/incorporate >> it with CM3 before I just dump it in the repository. It also overlaps a = >bit >> with "caltech-parser"=2C so there should probably be a "caltech-common" >> package for the overlaps? >>=20 >> If you run the following commands in a fresh directory=2C you should get >> to the error I emailed: >>=20 >> setenv CM3 1 >> cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -d . >> make regress # GNU make : 'gmake regress' on BSD >> cd mscheme/sstubgen/example >> cm3 -x >>=20 >> Mika >>=20 >>=20 > = > >--_f9584f16-e235-418f-823d-1c2a51c6bc9b_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >aside: overlap with caltech_parser:
if you can come up with a merged ver= >sion that works with both=2C good
If you can't=2C I think you have to re= >name one or the other.

Maybe someday we can support some sort of hie= >rarchy that automatically maps to/from the file system hierarchy...

= >I'll try to reproduce the problem.

All targets?
Workaround with d= >ifferent cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?)

 =3B- Jay>

>=3B To: jay.krell at cornell.edu
>=3B Date: Mon=2C 27 Dec 201= >0 02:38:10 -0800
>=3B From: mika at async.caltech.edu
>=3B CC: m3dev= >el at elegosoft.com
>=3B Subject: Re: [M3devel] compiler problems on Snow= > Leopard
>=3B
>=3B Jay K writes:
>=3B >=3B--_6f82bcb2-663= >f-4046-87f2-073a1528a819_
>=3B >=3BContent-Type: text/plain=3B chars= >et=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encoding: quoted-printab= >le
>=3B >=3B
>=3B >=3B
>=3B >=3BCan you put all your c= >ode in our CVS repository?
>=3B >=3B
>=3B
>=3B I can't pu= >t all the code I work with in m3devel's repository: some of
>=3B it i= >s proprietary.
>=3B
>=3B The Scheme code however I have no restr= >ictions on distributing (that's
>=3B what's got problems in this case)= >. It is however large and unwieldy and
>=3B I'd like to have other pe= >ople's suggestions for how to submit/incorporate
>=3B it with CM3 befo= >re I just dump it in the repository. It also overlaps a bit
>=3B with= > "caltech-parser"=2C so there should probably be a "caltech-common"
>= >=3B package for the overlaps?
>=3B
>=3B If you run the following= > commands in a fresh directory=2C you should get
>=3B to the error I e= >mailed:
>=3B
>=3B setenv CM3 1
>=3B cvs -d :pserver:anonymo= >us at pluto.gcapltd.com:/home/gcap-public-cvs up -d .
>=3B make regress = > # GNU make : 'gmake regress' on BSD
>=3B cd mscheme/sstubgen/example= >
>=3B cm3 -x
>=3B
>=3B Mika
>=3B
>=3B
= > >= > >--_f9584f16-e235-418f-823d-1c2a51c6bc9b_-- From mika at async.caltech.edu Mon Dec 27 11:58:59 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Dec 2010 02:58:59 -0800 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , , , <20101227103810.94DF21A205B@async.async.caltech.edu>, Message-ID: <20101227105859.8E1F21A205B@async.async.caltech.edu> Run cm3 -x instead of just cm3. Did you get an error compiling package "mscheme"? I certainly have a libmscheme.a in there. /m3overrides has build_standalone() in it. I normally didn't use build_standalone() but something has changed in how the system searches for shared libs when building with overrides and this was the easiest solution (at least for now). Mika Jay K writes: >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >I can't quite reproduce it=2C but I can compile a bunch of your code. > > >new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-lib.a" = >-> archiving libsstubgen.a > >=3D=3D=3D> mscheme/sstubgen/program >--- building in I386_DARWIN --- > > -> linking sstubgen >i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/lib= >mscheme.a: No such file or directory > m3_link =3D> 1 >linker failed linking: sstubgen >Fatal Error: package build failed > >jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example >jbook2:example jay$ c=2C3 >-bash: c=2C3: command not found >jbook2:example jay$ cm3 >--- building in I386_DARWIN --- > >ignoring ../src/m3overrides > >"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3makefile"= >=2C line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/I386_DARW= >IN/.M3EXPORTS" for reading > >--procedure-- -line- -file--- >import -- >include_dir 3 /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/exa= >mple/src/m3makefile > > > - Jay > > > > > > >From: jay.krell at cornell.edu >To: mika at async.caltech.edu >Date: Mon=2C 27 Dec 2010 10:46:55 +0000 >CC: m3devel at elegosoft.com >Subject: Re: [M3devel] compiler problems on Snow Leopard > > > > > > > > >aside: overlap with caltech_parser: >if you can come up with a merged version that works with both=2C good >If you can't=2C I think you have to rename one or the other. > >Maybe someday we can support some sort of hierarchy that automatically maps= > to/from the file system hierarchy... > >I'll try to reproduce the problem. > >All targets? >Workaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) > > - Jay > > >> To: jay.krell at cornell.edu >> Date: Mon=2C 27 Dec 2010 02:38:10 -0800 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] compiler problems on Snow Leopard >>=20 >> Jay K writes: >> >--_6f82bcb2-663f-4046-87f2-073a1528a819_ >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> >Can you put all your code in our CVS repository? >> > >>=20 >> I can't put all the code I work with in m3devel's repository: some of=20 >> it is proprietary. >>=20 >> The Scheme code however I have no restrictions on distributing (that's >> what's got problems in this case). It is however large and unwieldy and >> I'd like to have other people's suggestions for how to submit/incorporate >> it with CM3 before I just dump it in the repository. It also overlaps a = >bit >> with "caltech-parser"=2C so there should probably be a "caltech-common" >> package for the overlaps? >>=20 >> If you run the following commands in a fresh directory=2C you should get >> to the error I emailed: >>=20 >> setenv CM3 1 >> cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -d . >> make regress # GNU make : 'gmake regress' on BSD >> cd mscheme/sstubgen/example >> cm3 -x >>=20 >> Mika >>=20 >>=20 > = > >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >I can't quite reproduce it=2C but I can compile a bunch of your code.
r>
new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-l= >ib.a" ->=3B archiving libsstubgen.a

=3D=3D=3D>=3B mscheme/sstubg= >en/program
--- building in I386_DARWIN ---

 =3B->=3B linkin= >g sstubgen
i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I= >386_DARWIN/libmscheme.a: No such file or directory
 =3B m3_link =3D&= >gt=3B 1
linker failed linking: sstubgen
Fatal Error: package build fa= >iled

jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example
jboo= >k2:example jay$ c=2C3
-bash: c=2C3: command not found
jbook2:example = >jay$ cm3
--- building in I386_DARWIN ---

ignoring ../src/m3overri= >des

"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3= >makefile"=2C line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/= >I386_DARWIN/.M3EXPORTS" for reading

--procedure-- =3B -line-&nbs= >p=3B -file---
import =3B =3B =3B =3B =3B =3B&nbs= >p=3B =3B =3B =3B =3B =3B -- =3B <=3Bbuiltin>=3B= >
include_dir =3B =3B =3B =3B =3B =3B =3B&nbs= >p=3B 3 =3B /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src= >/m3makefile


 =3B- Jay






topSpelling">From: jay.krell at cornell.edu
To: mika at async.caltech.edu
D= >ate: Mon=2C 27 Dec 2010 10:46:55 +0000
CC: m3devel at elegosoft.com
Subj= >ect: Re: [M3devel] compiler problems on Snow Leopard

> >"> > > > > >aside: overlap with caltech_parser:
if you can come up with a merged ver= >sion that works with both=2C good
If you can't=2C I think you have to re= >name one or the other.

Maybe someday we can support some sort of hie= >rarchy that automatically maps to/from the file system hierarchy...

= >I'll try to reproduce the problem.

All targets?
Workaround with d= >ifferent cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?)

 =3B- Jay>

>=3B To: jay.krell at cornell.edu
>=3B Date: Mon=2C 27 Dec 201= >0 02:38:10 -0800
>=3B From: mika at async.caltech.edu
>=3B CC: m3dev= >el at elegosoft.com
>=3B Subject: Re: [M3devel] compiler problems on Snow= > Leopard
>=3B
>=3B Jay K writes:
>=3B >=3B--_6f82bcb2-663= >f-4046-87f2-073a1528a819_
>=3B >=3BContent-Type: text/plain=3B chars= >et=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encoding: quoted-printab= >le
>=3B >=3B
>=3B >=3B
>=3B >=3BCan you put all your c= >ode in our CVS repository?
>=3B >=3B
>=3B
>=3B I can't pu= >t all the code I work with in m3devel's repository: some of
>=3B it i= >s proprietary.
>=3B
>=3B The Scheme code however I have no restr= >ictions on distributing (that's
>=3B what's got problems in this case)= >. It is however large and unwieldy and
>=3B I'd like to have other pe= >ople's suggestions for how to submit/incorporate
>=3B it with CM3 befo= >re I just dump it in the repository. It also overlaps a bit
>=3B with= > "caltech-parser"=2C so there should probably be a "caltech-common"
>= >=3B package for the overlaps?
>=3B
>=3B If you run the following= > commands in a fresh directory=2C you should get
>=3B to the error I e= >mailed:
>=3B
>=3B setenv CM3 1
>=3B cvs -d :pserver:anonymo= >us at pluto.gcapltd.com:/home/gcap-public-cvs up -d .
>=3B make regress = > # GNU make : 'gmake regress' on BSD
>=3B cd mscheme/sstubgen/example= >
>=3B cm3 -x
>=3B
>=3B Mika
>=3B
>=3B
= > >= > >--_9ece0c56-2524-4879-9a65-2407b1dbf664_-- From jay.krell at cornell.edu Mon Dec 27 12:04:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 11:04:11 +0000 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <20101227105859.8E1F21A205B@async.async.caltech.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , , , <20101227103810.94DF21A205B@async.async.caltech.edu>, , <20101227105859.8E1F21A205B@async.async.caltech.edu> Message-ID: Yes, overrides and standalone is a problem. Maybe I'll get around to addressing this for the next release. A proposed solution is: go back to mostly the old method: hard coded runpaths, with much overlap for global builds (to be shipped/installed), monstrously long paths for local builds (not to be shipped), AND link upon install Some systems allow for "slight relinking", including Solaris and Darwin, where just the paths get edited. That would be nicer. The old approach had problems too. If you build the system yourself, I think you automatically already today get what is described -- hardcoded run paths, with much overlap for global builds. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] compiler problems on Snow Leopard > Date: Mon, 27 Dec 2010 02:58:59 -0800 > From: mika at async.caltech.edu > > Run cm3 -x instead of just cm3. > > Did you get an error compiling package "mscheme"? I certainly have a > libmscheme.a in there. > > /m3overrides has build_standalone() in it. > > I normally didn't use build_standalone() but something has changed in > how the system searches for shared libs when building with overrides > and this was the easiest solution (at least for now). > > Mika > > Jay K writes: > >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >I can't quite reproduce it=2C but I can compile a bunch of your code. > > > > > >new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-lib.a" = > >-> archiving libsstubgen.a > > > >=3D=3D=3D> mscheme/sstubgen/program > >--- building in I386_DARWIN --- > > > > -> linking sstubgen > >i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/lib= > >mscheme.a: No such file or directory > > m3_link =3D> 1 > >linker failed linking: sstubgen > >Fatal Error: package build failed > > > >jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example > >jbook2:example jay$ c=2C3 > >-bash: c=2C3: command not found > >jbook2:example jay$ cm3 > >--- building in I386_DARWIN --- > > > >ignoring ../src/m3overrides > > > >"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3makefile"= > >=2C line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/I386_DARW= > >IN/.M3EXPORTS" for reading > > > >--procedure-- -line- -file--- > >import -- > >include_dir 3 /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/exa= > >mple/src/m3makefile > > > > > > - Jay > > > > > > > > > > > > > >From: jay.krell at cornell.edu > >To: mika at async.caltech.edu > >Date: Mon=2C 27 Dec 2010 10:46:55 +0000 > >CC: m3devel at elegosoft.com > >Subject: Re: [M3devel] compiler problems on Snow Leopard > > > > > > > > > > > > > > > > > >aside: overlap with caltech_parser: > >if you can come up with a merged version that works with both=2C good > >If you can't=2C I think you have to rename one or the other. > > > >Maybe someday we can support some sort of hierarchy that automatically maps= > > to/from the file system hierarchy... > > > >I'll try to reproduce the problem. > > > >All targets? > >Workaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) > > > > - Jay > > > > > >> To: jay.krell at cornell.edu > >> Date: Mon=2C 27 Dec 2010 02:38:10 -0800 > >> From: mika at async.caltech.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] compiler problems on Snow Leopard > >>=20 > >> Jay K writes: > >> >--_6f82bcb2-663f-4046-87f2-073a1528a819_ > >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> >Can you put all your code in our CVS repository? > >> > > >>=20 > >> I can't put all the code I work with in m3devel's repository: some of=20 > >> it is proprietary. > >>=20 > >> The Scheme code however I have no restrictions on distributing (that's > >> what's got problems in this case). It is however large and unwieldy and > >> I'd like to have other people's suggestions for how to submit/incorporate > >> it with CM3 before I just dump it in the repository. It also overlaps a = > >bit > >> with "caltech-parser"=2C so there should probably be a "caltech-common" > >> package for the overlaps? > >>=20 > >> If you run the following commands in a fresh directory=2C you should get > >> to the error I emailed: > >>=20 > >> setenv CM3 1 > >> cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -d . > >> make regress # GNU make : 'gmake regress' on BSD > >> cd mscheme/sstubgen/example > >> cm3 -x > >>=20 > >> Mika > >>=20 > >>=20 > > = > > > >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >I can't quite reproduce it=2C but I can compile a bunch of your code.
>r>
new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-l= > >ib.a" ->=3B archiving libsstubgen.a

=3D=3D=3D>=3B mscheme/sstubg= > >en/program
--- building in I386_DARWIN ---

 =3B->=3B linkin= > >g sstubgen
i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I= > >386_DARWIN/libmscheme.a: No such file or directory
 =3B m3_link =3D&= > >gt=3B 1
linker failed linking: sstubgen
Fatal Error: package build fa= > >iled

jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example
jboo= > >k2:example jay$ c=2C3
-bash: c=2C3: command not found
jbook2:example = > >jay$ cm3
--- building in I386_DARWIN ---

ignoring ../src/m3overri= > >des

"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3= > >makefile"=2C line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/= > >I386_DARWIN/.M3EXPORTS" for reading

--procedure-- =3B -line-&nbs= > >p=3B -file---
import =3B =3B =3B =3B =3B =3B&nbs= > >p=3B =3B =3B =3B =3B =3B -- =3B <=3Bbuiltin>=3B= > >
include_dir =3B =3B =3B =3B =3B =3B =3B&nbs= > >p=3B 3 =3B /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src= > >/m3makefile


 =3B- Jay






>topSpelling">From: jay.krell at cornell.edu
To: mika at async.caltech.edu
D= > >ate: Mon=2C 27 Dec 2010 10:46:55 +0000
CC: m3devel at elegosoft.com
Subj= > >ect: Re: [M3devel] compiler problems on Snow Leopard

> > > > >"> > > > > > > > > > >aside: overlap with caltech_parser:
if you can come up with a merged ver= > >sion that works with both=2C good
If you can't=2C I think you have to re= > >name one or the other.

Maybe someday we can support some sort of hie= > >rarchy that automatically maps to/from the file system hierarchy...

= > >I'll try to reproduce the problem.

All targets?
Workaround with d= > >ifferent cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?)

 =3B- Jay >>

>=3B To: jay.krell at cornell.edu
>=3B Date: Mon=2C 27 Dec 201= > >0 02:38:10 -0800
>=3B From: mika at async.caltech.edu
>=3B CC: m3dev= > >el at elegosoft.com
>=3B Subject: Re: [M3devel] compiler problems on Snow= > > Leopard
>=3B
>=3B Jay K writes:
>=3B >=3B--_6f82bcb2-663= > >f-4046-87f2-073a1528a819_
>=3B >=3BContent-Type: text/plain=3B chars= > >et=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encoding: quoted-printab= > >le
>=3B >=3B
>=3B >=3B
>=3B >=3BCan you put all your c= > >ode in our CVS repository?
>=3B >=3B
>=3B
>=3B I can't pu= > >t all the code I work with in m3devel's repository: some of
>=3B it i= > >s proprietary.
>=3B
>=3B The Scheme code however I have no restr= > >ictions on distributing (that's
>=3B what's got problems in this case)= > >. It is however large and unwieldy and
>=3B I'd like to have other pe= > >ople's suggestions for how to submit/incorporate
>=3B it with CM3 befo= > >re I just dump it in the repository. It also overlaps a bit
>=3B with= > > "caltech-parser"=2C so there should probably be a "caltech-common"
>= > >=3B package for the overlaps?
>=3B
>=3B If you run the following= > > commands in a fresh directory=2C you should get
>=3B to the error I e= > >mailed:
>=3B
>=3B setenv CM3 1
>=3B cvs -d :pserver:anonymo= > >us at pluto.gcapltd.com:/home/gcap-public-cvs up -d .
>=3B make regress = > > # GNU make : 'gmake regress' on BSD
>=3B cd mscheme/sstubgen/example= > >
>=3B cm3 -x
>=3B
>=3B Mika
>=3B
>=3B
= > > > >= > > > >--_9ece0c56-2524-4879-9a65-2407b1dbf664_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 27 12:16:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 11:16:00 +0000 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>,,, , <20101227101421.38A6A1A205B@async.async.caltech.edu>, ,,, , , <20101227103810.94DF21A205B@async.async.caltech.edu>, , , , , <20101227105859.8E1F21A205B@async.async.caltech.edu>, Message-ID: something wanted cit_util. --- building in AMD64_DARWIN --- ignoring ../src/m3overrides "/Users/jay/dev2/gcap-public-cvs/cit_util/src/texthack.tmpl", line 2: quake runtime error: undefined variable: TOP --procedure-- -line- -file--- template 2 /Users/jay/dev2/gcap-public-cvs/cit_util/src/texthack.tmpl include_dir 13 /Users/jay/dev2/gcap-public-cvs/cit_util/src/m3makefile 4 /Users/jay/dev2/gcap-public-cvs/cit_util/AMD64_DARWIN/m3make.args % $Id: texthack.tmpl,v 1.7 2002/12/13 22:20:12 kp Exp $ _M3TEXTHACK = TOP & "/m3texthack/" & BUILD_DIR & "/m3texthack" _DERIVGEN = TOP & "/m3texthack/src/derivgen.sh" I don't have m3texthack anywhere I think. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu Date: Mon, 27 Dec 2010 11:04:11 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] compiler problems on Snow Leopard Yes, overrides and standalone is a problem. Maybe I'll get around to addressing this for the next release. A proposed solution is: go back to mostly the old method: hard coded runpaths, with much overlap for global builds (to be shipped/installed), monstrously long paths for local builds (not to be shipped), AND link upon install Some systems allow for "slight relinking", including Solaris and Darwin, where just the paths get edited. That would be nicer. The old approach had problems too. If you build the system yourself, I think you automatically already today get what is described -- hardcoded run paths, with much overlap for global builds. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] compiler problems on Snow Leopard > Date: Mon, 27 Dec 2010 02:58:59 -0800 > From: mika at async.caltech.edu > > Run cm3 -x instead of just cm3. > > Did you get an error compiling package "mscheme"? I certainly have a > libmscheme.a in there. > > /m3overrides has build_standalone() in it. > > I normally didn't use build_standalone() but something has changed in > how the system searches for shared libs when building with overrides > and this was the easiest solution (at least for now). > > Mika > > Jay K writes: > >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >I can't quite reproduce it=2C but I can compile a bunch of your code. > > > > > >new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-lib.a" = > >-> archiving libsstubgen.a > > > >=3D=3D=3D> mscheme/sstubgen/program > >--- building in I386_DARWIN --- > > > > -> linking sstubgen > >i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/lib= > >mscheme.a: No such file or directory > > m3_link =3D> 1 > >linker failed linking: sstubgen > >Fatal Error: package build failed > > > >jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example > >jbook2:example jay$ c=2C3 > >-bash: c=2C3: command not found > >jbook2:example jay$ cm3 > >--- building in I386_DARWIN --- > > > >ignoring ../src/m3overrides > > > >"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3makefile"= > >=2C line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/I386_DARW= > >IN/.M3EXPORTS" for reading > > > >--procedure-- -line- -file--- > >import -- > >include_dir 3 /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/exa= > >mple/src/m3makefile > > > > > > - Jay > > > > > > > > > > > > > >From: jay.krell at cornell.edu > >To: mika at async.caltech.edu > >Date: Mon=2C 27 Dec 2010 10:46:55 +0000 > >CC: m3devel at elegosoft.com > >Subject: Re: [M3devel] compiler problems on Snow Leopard > > > > > > > > > > > > > > > > > >aside: overlap with caltech_parser: > >if you can come up with a merged version that works with both=2C good > >If you can't=2C I think you have to rename one or the other. > > > >Maybe someday we can support some sort of hierarchy that automatically maps= > > to/from the file system hierarchy... > > > >I'll try to reproduce the problem. > > > >All targets? > >Workaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) > > > > - Jay > > > > > >> To: jay.krell at cornell.edu > >> Date: Mon=2C 27 Dec 2010 02:38:10 -0800 > >> From: mika at async.caltech.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] compiler problems on Snow Leopard > >>=20 > >> Jay K writes: > >> >--_6f82bcb2-663f-4046-87f2-073a1528a819_ > >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> >Can you put all your code in our CVS repository? > >> > > >>=20 > >> I can't put all the code I work with in m3devel's repository: some of=20 > >> it is proprietary. > >>=20 > >> The Scheme code however I have no restrictions on distributing (that's > >> what's got problems in this case). It is however large and unwieldy and > >> I'd like to have other people's suggestions for how to submit/incorporate > >> it with CM3 before I just dump it in the repository. It also overlaps a = > >bit > >> with "caltech-parser"=2C so there should probably be a "caltech-common" > >> package for the overlaps? > >>=20 > >> If you run the following commands in a fresh directory=2C you should get > >> to the error I emailed: > >>=20 > >> setenv CM3 1 > >> cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -d . > >> make regress # GNU make : 'gmake regress' on BSD > >> cd mscheme/sstubgen/example > >> cm3 -x > >>=20 > >> Mika > >>=20 > >>=20 > > = > > > >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >I can't quite reproduce it=2C but I can compile a bunch of your code.
>r>
new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-l= > >ib.a" ->=3B archiving libsstubgen.a

=3D=3D=3D>=3B mscheme/sstubg= > >en/program
--- building in I386_DARWIN ---

 =3B->=3B linkin= > >g sstubgen
i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I= > >386_DARWIN/libmscheme.a: No such file or directory
 =3B m3_link =3D&= > >gt=3B 1
linker failed linking: sstubgen
Fatal Error: package build fa= > >iled

jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example
jboo= > >k2:example jay$ c=2C3
-bash: c=2C3: command not found
jbook2:example = > >jay$ cm3
--- building in I386_DARWIN ---

ignoring ../src/m3overri= > >des

"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3= > >makefile"=2C line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/= > >I386_DARWIN/.M3EXPORTS" for reading

--procedure-- =3B -line-&nbs= > >p=3B -file---
import =3B =3B =3B =3B =3B =3B&nbs= > >p=3B =3B =3B =3B =3B =3B -- =3B <=3Bbuiltin>=3B= > >
include_dir =3B =3B =3B =3B =3B =3B =3B&nbs= > >p=3B 3 =3B /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src= > >/m3makefile


 =3B- Jay






>topSpelling">From: jay.krell at cornell.edu
To: mika at async.caltech.edu
D= > >ate: Mon=2C 27 Dec 2010 10:46:55 +0000
CC: m3devel at elegosoft.com
Subj= > >ect: Re: [M3devel] compiler problems on Snow Leopard

> > > > >"> > > > > > > > > > >aside: overlap with caltech_parser:
if you can come up with a merged ver= > >sion that works with both=2C good
If you can't=2C I think you have to re= > >name one or the other.

Maybe someday we can support some sort of hie= > >rarchy that automatically maps to/from the file system hierarchy...

= > >I'll try to reproduce the problem.

All targets?
Workaround with d= > >ifferent cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?)

 =3B- Jay >>

>=3B To: jay.krell at cornell.edu
>=3B Date: Mon=2C 27 Dec 201= > >0 02:38:10 -0800
>=3B From: mika at async.caltech.edu
>=3B CC: m3dev= > >el at elegosoft.com
>=3B Subject: Re: [M3devel] compiler problems on Snow= > > Leopard
>=3B
>=3B Jay K writes:
>=3B >=3B--_6f82bcb2-663= > >f-4046-87f2-073a1528a819_
>=3B >=3BContent-Type: text/plain=3B chars= > >et=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encoding: quoted-printab= > >le
>=3B >=3B
>=3B >=3B
>=3B >=3BCan you put all your c= > >ode in our CVS repository?
>=3B >=3B
>=3B
>=3B I can't pu= > >t all the code I work with in m3devel's repository: some of
>=3B it i= > >s proprietary.
>=3B
>=3B The Scheme code however I have no restr= > >ictions on distributing (that's
>=3B what's got problems in this case)= > >. It is however large and unwieldy and
>=3B I'd like to have other pe= > >ople's suggestions for how to submit/incorporate
>=3B it with CM3 befo= > >re I just dump it in the repository. It also overlaps a bit
>=3B with= > > "caltech-parser"=2C so there should probably be a "caltech-common"
>= > >=3B package for the overlaps?
>=3B
>=3B If you run the following= > > commands in a fresh directory=2C you should get
>=3B to the error I e= > >mailed:
>=3B
>=3B setenv CM3 1
>=3B cvs -d :pserver:anonymo= > >us at pluto.gcapltd.com:/home/gcap-public-cvs up -d .
>=3B make regress = > > # GNU make : 'gmake regress' on BSD
>=3B cd mscheme/sstubgen/example= > >
>=3B cm3 -x
>=3B
>=3B Mika
>=3B
>=3B
= > > > >= > > > >--_9ece0c56-2524-4879-9a65-2407b1dbf664_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Dec 27 12:24:24 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Dec 2010 03:24:24 -0800 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , , , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , , , , , <20101227103810.94DF21A205B@async.async.caltech.edu>, , , , , <20101227105859.8E1F21A205B@async.async.caltech.edu>, Message-ID: <20101227112424.C13401A205B@async.async.caltech.edu> Don't think you need m3texthack. The first thing that happens when you run make ought to be that a file called ".top" is created at the top level of the repository, with a definition of TOP. This file is included by the top-level m3overrides, which is included by every m3overrides when you run with -x. Mika Jay K writes: >--_d61e805f-545e-4b3d-abe7-a20c582bec2e_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >something wanted cit_util. > > > >--- building in AMD64_DARWIN --- > > > >ignoring ../src/m3overrides > > > >"/Users/jay/dev2/gcap-public-cvs/cit_util/src/texthack.tmpl"=2C line 2: qua= >ke runtime error: undefined variable: TOP > > > >--procedure-- -line- -file--- > >template 2 /Users/jay/dev2/gcap-public-cvs/cit_util/src/texthac= >k.tmpl > >include_dir 13 /Users/jay/dev2/gcap-public-cvs/cit_util/src/m3makef= >ile > > 4 /Users/jay/dev2/gcap-public-cvs/cit_util/AMD64_DARWI= >N/m3make.args > > > > > >% $Id: texthack.tmpl=2Cv 1.7 2002/12/13 22:20:12 kp Exp $ > >_M3TEXTHACK =3D TOP & "/m3texthack/" & BUILD_DIR & "/m3texthack" > >_DERIVGEN =3D TOP & "/m3texthack/src/derivgen.sh" > > >I don't have m3texthack anywhere I think. > > - Jay > >From: jay.krell at cornell.edu >To: mika at async.caltech.edu >Date: Mon=2C 27 Dec 2010 11:04:11 +0000 >CC: m3devel at elegosoft.com >Subject: Re: [M3devel] compiler problems on Snow Leopard > > > > > > > > >Yes=2C overrides and standalone is a problem. > >Maybe I'll get around to addressing this for the next release. > >A proposed solution is: > go back to mostly the old method: hard coded runpaths=2C with much overla= >p for global builds (to be shipped/installed)=2C monstrously long paths for= > local builds (not to be shipped)=2C AND link upon install > Some systems allow for "slight relinking"=2C including Solaris and Darwin= >=2C where just the paths get edited. That would be nicer. > > The old approach had problems too. > > If you build the system yourself=2C I think you automatically already to= >day get what is described -- hardcoded run paths=2C with much overlap for g= >lobal builds. > > > - Jay > >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] compiler problems on Snow Leopard=20 >> Date: Mon=2C 27 Dec 2010 02:58:59 -0800 >> From: mika at async.caltech.edu >>=20 >> Run cm3 -x instead of just cm3. >>=20 >> Did you get an error compiling package "mscheme"? I certainly have a >> libmscheme.a in there. >>=20 >> /m3overrides has build_standalone() in it. >>=20 >> I normally didn't use build_standalone() but something has changed in >> how the system searches for shared libs when building with overrides >> and this was the easiest solution (at least for now). >>=20 >> Mika >>=20 >> Jay K writes: >> >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> >I can't quite reproduce it=3D2C but I can compile a bunch of your code. >> > >> > >> >new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-lib.= >a" =3D >> >-> archiving libsstubgen.a >> > >> >=3D3D=3D3D=3D3D> mscheme/sstubgen/program >> >--- building in I386_DARWIN --- >> > >> > -> linking sstubgen >> >i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/= >lib=3D >> >mscheme.a: No such file or directory >> > m3_link =3D3D> 1 >> >linker failed linking: sstubgen >> >Fatal Error: package build failed >> > >> >jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example >> >jbook2:example jay$ c=3D2C3 >> >-bash: c=3D2C3: command not found >> >jbook2:example jay$ cm3 >> >--- building in I386_DARWIN --- >> > >> >ignoring ../src/m3overrides >> > >> >"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3makefile= >"=3D >> >=3D2C line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/I386= >_DARW=3D >> >IN/.M3EXPORTS" for reading >> > >> >--procedure-- -line- -file--- >> >import -- >> >include_dir 3 /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/= >exa=3D >> >mple/src/m3makefile >> > >> > >> > - Jay >> > >> > >> > >> > >> > >> > >> >From: jay.krell at cornell.edu >> >To: mika at async.caltech.edu >> >Date: Mon=3D2C 27 Dec 2010 10:46:55 +0000 >> >CC: m3devel at elegosoft.com >> >Subject: Re: [M3devel] compiler problems on Snow Leopard >> > >> > >> > >> > >> > >> > >> > >> > >> >aside: overlap with caltech_parser: >> >if you can come up with a merged version that works with both=3D2C good >> >If you can't=3D2C I think you have to rename one or the other. >> > >> >Maybe someday we can support some sort of hierarchy that automatically m= >aps=3D >> > to/from the file system hierarchy... >> > >> >I'll try to reproduce the problem. >> > >> >All targets? >> >Workaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) >> > >> > - Jay >> > >> > >> >> To: jay.krell at cornell.edu >> >> Date: Mon=3D2C 27 Dec 2010 02:38:10 -0800 >> >> From: mika at async.caltech.edu >> >> CC: m3devel at elegosoft.com >> >> Subject: Re: [M3devel] compiler problems on Snow Leopard >> >>=3D20 >> >> Jay K writes: >> >> >--_6f82bcb2-663f-4046-87f2-073a1528a819_ >> >> >Content-Type: text/plain=3D3B charset=3D3D"iso-8859-1" >> >> >Content-Transfer-Encoding: quoted-printable >> >> > >> >> > >> >> >Can you put all your code in our CVS repository? >> >> > >> >>=3D20 >> >> I can't put all the code I work with in m3devel's repository: some of= >=3D20 >> >> it is proprietary. >> >>=3D20 >> >> The Scheme code however I have no restrictions on distributing (that's >> >> what's got problems in this case). It is however large and unwieldy a= >nd >> >> I'd like to have other people's suggestions for how to submit/incorpor= >ate >> >> it with CM3 before I just dump it in the repository. It also overlaps= > a =3D >> >bit >> >> with "caltech-parser"=3D2C so there should probably be a "caltech-comm= >on" >> >> package for the overlaps? >> >>=3D20 >> >> If you run the following commands in a fresh directory=3D2C you should= > get >> >> to the error I emailed: >> >>=3D20 >> >> setenv CM3 1 >> >> cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -= >d . >> >> make regress # GNU make : 'gmake regress' on BSD >> >> cd mscheme/sstubgen/example >> >> cm3 -x >> >>=3D20 >> >> Mika >> >>=3D20 >> >>=3D20 >> > =3D >> > >> >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ >> >Content-Type: text/html=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> > >> > >> > >> > >> >I can't quite reproduce it=3D2C but I can compile a bunch of your code.<= >br>> >r>
new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libschem= >e-l=3D >> >ib.a" ->=3D3B archiving libsstubgen.a

=3D3D=3D3D=3D3D>=3D3B m= >scheme/sstubg=3D >> >en/program
--- building in I386_DARWIN ---

 =3D3B->=3D3B= > linkin=3D >> >g sstubgen
i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mschem= >e/I=3D >> >386_DARWIN/libmscheme.a: No such file or directory
 =3D3B m3_link= > =3D3D&=3D >> >gt=3D3B 1
linker failed linking: sstubgen
Fatal Error: package bui= >ld fa=3D >> >iled

jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example
j= >boo=3D >> >k2:example jay$ c=3D2C3
-bash: c=3D2C3: command not found
jbook2:e= >xample =3D >> >jay$ cm3
--- building in I386_DARWIN ---

ignoring ../src/m3ove= >rri=3D >> >des

"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src= >/m3=3D >> >makefile"=3D2C line 3: quake runtime error: unable to open "/cm3/pkg/msc= >heme/=3D >> >I386_DARWIN/.M3EXPORTS" for reading

--procedure-- =3D3B -line= >-&nbs=3D >> >p=3D3B -file---
import =3D3B =3D3B =3D3B =3D3B = >=3D3B =3D3B&nbs=3D >> >p=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B -- =3D3B &l= >t=3D3Bbuiltin>=3D3B=3D >> >
include_dir =3D3B =3D3B =3D3B =3D3B =3D3B = >=3D3B =3D3B&nbs=3D >> >p=3D3B 3 =3D3B /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/exam= >ple/src=3D >> >/m3makefile


 =3D3B- Jay






=3D3D"s=3D >> >topSpelling">From: jay.krell at cornell.edu
To: mika at async.caltech.edur>D=3D >> >ate: Mon=3D2C 27 Dec 2010 10:46:55 +0000
CC: m3devel at elegosoft.com>Subj=3D >> >ect: Re: [M3devel] compiler problems on Snow Leopard

>> > >> >=3D3Dunicode=3D >> >"> >> > >> > >> > >> > >> >aside: overlap with caltech_parser:
if you can come up with a merged = >ver=3D >> >sion that works with both=3D2C good
If you can't=3D2C I think you hav= >e to re=3D >> >name one or the other.

Maybe someday we can support some sort of = >hie=3D >> >rarchy that automatically maps to/from the file system hierarchy...
<= >br>=3D >> >I'll try to reproduce the problem.

All targets?
Workaround wit= >h d=3D >> >ifferent cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?)

 =3D3B- J= >ay> >>

>=3D3B To: jay.krell at cornell.edu
>=3D3B Date: Mon=3D2C 2= >7 Dec 201=3D >> >0 02:38:10 -0800
>=3D3B From: mika at async.caltech.edu
>=3D3B CC= >: m3dev=3D >> >el at elegosoft.com
>=3D3B Subject: Re: [M3devel] compiler problems on= > Snow=3D >> > Leopard
>=3D3B
>=3D3B Jay K writes:
>=3D3B >=3D3B--_6= >f82bcb2-663=3D >> >f-4046-87f2-073a1528a819_
>=3D3B >=3D3BContent-Type: text/plain= >=3D3B chars=3D >> >et=3D3D"iso-8859-1"
>=3D3B >=3D3BContent-Transfer-Encoding: quote= >d-printab=3D >> >le
>=3D3B >=3D3B
>=3D3B >=3D3B
>=3D3B >=3D3BCan you= > put all your c=3D >> >ode in our CVS repository?
>=3D3B >=3D3B
>=3D3B
>=3D3B= > I can't pu=3D >> >t all the code I work with in m3devel's repository: some of
>=3D3B= > it i=3D >> >s proprietary.
>=3D3B
>=3D3B The Scheme code however I have n= >o restr=3D >> >ictions on distributing (that's
>=3D3B what's got problems in this = >case)=3D >> >. It is however large and unwieldy and
>=3D3B I'd like to have oth= >er pe=3D >> >ople's suggestions for how to submit/incorporate
>=3D3B it with CM3= > befo=3D >> >re I just dump it in the repository. It also overlaps a bit
>=3D3B= > with=3D >> > "caltech-parser"=3D2C so there should probably be a "caltech-common">>=3D >> >=3D3B package for the overlaps?
>=3D3B
>=3D3B If you run the = >following=3D >> > commands in a fresh directory=3D2C you should get
>=3D3B to the er= >ror I e=3D >> >mailed:
>=3D3B
>=3D3B setenv CM3 1
>=3D3B cvs -d :pserve= >r:anonymo=3D >> >us at pluto.gcapltd.com:/home/gcap-public-cvs up -d .
>=3D3B make regr= >ess =3D >> > # GNU make : 'gmake regress' on BSD
>=3D3B cd mscheme/sstubgen/ex= >ample=3D >> >
>=3D3B cm3 -x
>=3D3B
>=3D3B Mika
>=3D3B
&= >gt=3D3B
=3D >> > >> >=3D >> > >> >--_9ece0c56-2524-4879-9a65-2407b1dbf664_-- > = > >--_d61e805f-545e-4b3d-abe7-a20c582bec2e_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >something wanted cit_util.
>
>--- building in AMD64_DARWIN ---
>
>ignoring ../src/m3overrides
>
>"/Users/jay/dev2/gcap-public-cvs/cit_util/src/texthack.tmpl"=2C line 2: qua= >ke runtime error: undefined variable: TOP
>
>--procedure-- =3B -line- =3B -file---
>template =3B =3B =3B =3B =3B =3B =3B =3B&nb= >sp=3B =3B =3B 2 =3B /Users/jay/dev2/gcap-public-cvs/cit_util/sr= >c/texthack.tmpl
>include_dir =3B =3B =3B =3B =3B =3B =3B 13 = >=3B /Users/jay/dev2/gcap-public-cvs/cit_util/src/m3makefile
> =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= >sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = >=3B 4 =3B /Users/jay/dev2/gcap-public-cvs/cit_util/AMD64_DARWIN/m3make.= >args
>
>
>% $Id: texthack.tmpl=2Cv 1.7 2002/12/13 22:20:12 kp Exp $
>_M3TEXTHACK =3D TOP &=3B "/m3texthack/" &=3B BUILD_DIR &=3B "/m3te= >xthack"
>_DERIVGEN =3B =3B =3D TOP &=3B "/m3texthack/src/derivgen.sh"
>
I don't have m3texthack anywhere I think.

 =3B- Jay

<= >hr id=3D"stopSpelling">From: jay.krell at cornell.edu
To: mika at async.caltec= >h.edu
Date: Mon=2C 27 Dec 2010 11:04:11 +0000
CC: m3devel at elegosoft.c= >om
Subject: Re: [M3devel] compiler problems on Snow Leopard

> >"> > > > > >Yes=2C overrides and standalone is a problem.

Maybe I'll get around = >to addressing this for the next release.

A proposed solution is:
= > =3B go back to mostly the old method: hard coded runpaths=2C with much= > overlap for global builds (to be shipped/installed)=2C monstrously long pa= >ths for local builds (not to be shipped)=2C AND link upon install
 = >=3B Some systems allow for "slight relinking"=2C including Solaris and Darw= >in=2C where just the paths get edited. That would be nicer.

 =3B= > The old approach had problems too.

 =3B =3B If you build th= >e system yourself=2C I think you automatically already today get what is de= >scribed -- hardcoded run paths=2C with much overlap for global builds.
<= >br>
 =3B- Jay

>=3B To: jay.krell at cornell.edu
>=3B CC: = >m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] compiler problems on= > Snow Leopard
>=3B Date: Mon=2C 27 Dec 2010 02:58:59 -0800
>=3B = >From: mika at async.caltech.edu
>=3B
>=3B Run cm3 -x instead of jus= >t cm3.
>=3B
>=3B Did you get an error compiling package "mscheme= >"? I certainly have a
>=3B libmscheme.a in there.
>=3B
>= >=3B <=3Btop>=3B/m3overrides has build_standalone() in it.
>=3B >>=3B I normally didn't use build_standalone() but something has changed = >in
>=3B how the system searches for shared libs when building with ove= >rrides
>=3B and this was the easiest solution (at least for now).
&= >gt=3B
>=3B Mika
>=3B
>=3B Jay K writes:
>=3B >= >=3B--_9ece0c56-2524-4879-9a65-2407b1dbf664_
>=3B >=3BContent-Type: t= >ext/plain=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encodi= >ng: quoted-printable
>=3B >=3B
>=3B >=3B
>=3B >=3BI ca= >n't quite reproduce it=3D2C but I can compile a bunch of your code.
>= >=3B >=3B
>=3B >=3B
>=3B >=3Bnew "/dev2/gcap-public-cvs/msch= >eme/scheme-lib/I386_DARWIN/libscheme-lib.a" =3D
>=3B >=3B->=3B arc= >hiving libsstubgen.a
>=3B >=3B
>=3B >=3B=3D3D=3D3D=3D3D>=3B= > mscheme/sstubgen/program
>=3B >=3B--- building in I386_DARWIN ---r>>=3B >=3B
>=3B >=3B ->=3B linking sstubgen
>=3B >=3Bi= >686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/lib= >=3D
>=3B >=3Bmscheme.a: No such file or directory
>=3B >=3B = >m3_link =3D3D>=3B 1
>=3B >=3Blinker failed linking: sstubgen
&g= >t=3B >=3BFatal Error: package build failed
>=3B >=3B
>=3B >= >=3Bjbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example
>=3B >=3B= >jbook2:example jay$ c=3D2C3
>=3B >=3B-bash: c=3D2C3: command not fou= >nd
>=3B >=3Bjbook2:example jay$ cm3
>=3B >=3B--- building in = >I386_DARWIN ---
>=3B >=3B
>=3B >=3Bignoring ../src/m3override= >s
>=3B >=3B
>=3B >=3B"/Users/jay/dev2/gcap-public-cvs/mscheme= >/sstubgen/example/src/m3makefile"=3D
>=3B >=3B=3D2C line 3: quake ru= >ntime error: unable to open "/cm3/pkg/mscheme/I386_DARW=3D
>=3B >=3B= >IN/.M3EXPORTS" for reading
>=3B >=3B
>=3B >=3B--procedure-- = >-line- -file---
>=3B >=3Bimport -- <=3Bbuiltin>=3B= >
>=3B >=3Binclude_dir 3 /Users/jay/dev2/gcap-public-cvs/msc= >heme/sstubgen/exa=3D
>=3B >=3Bmple/src/m3makefile
>=3B >=3Br>>=3B >=3B
>=3B >=3B - Jay
>=3B >=3B
>=3B >=3B>>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B= > >=3BFrom: jay.krell at cornell.edu
>=3B >=3BTo: mika at async.caltech.e= >du
>=3B >=3BDate: Mon=3D2C 27 Dec 2010 10:46:55 +0000
>=3B >= >=3BCC: m3devel at elegosoft.com
>=3B >=3BSubject: Re: [M3devel] compile= >r problems on Snow Leopard
>=3B >=3B
>=3B >=3B
>=3B >= >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
= >>=3B >=3B
>=3B >=3Baside: overlap with caltech_parser:
>=3B= > >=3Bif you can come up with a merged version that works with both=3D2C g= >ood
>=3B >=3BIf you can't=3D2C I think you have to rename one or the= > other.
>=3B >=3B
>=3B >=3BMaybe someday we can support some = >sort of hierarchy that automatically maps=3D
>=3B >=3B to/from the f= >ile system hierarchy...
>=3B >=3B
>=3B >=3BI'll try to reprod= >uce the problem.
>=3B >=3B
>=3B >=3BAll targets?
>=3B &g= >t=3BWorkaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?)>>=3B >=3B
>=3B >=3B - Jay
>=3B >=3B
>=3B >=3B
= >>=3B >=3B>=3B To: jay.krell at cornell.edu
>=3B >=3B>=3B Date: = >Mon=3D2C 27 Dec 2010 02:38:10 -0800
>=3B >=3B>=3B From: mika at async= >.caltech.edu
>=3B >=3B>=3B CC: m3devel at elegosoft.com
>=3B >= >=3B>=3B Subject: Re: [M3devel] compiler problems on Snow Leopard
>= >=3B >=3B>=3B=3D20
>=3B >=3B>=3B Jay K writes:
>=3B >=3B= >>=3B >=3B--_6f82bcb2-663f-4046-87f2-073a1528a819_
>=3B >=3B>= >=3B >=3BContent-Type: text/plain=3D3B charset=3D3D"iso-8859-1"
>=3B = >>=3B>=3B >=3BContent-Transfer-Encoding: quoted-printable
>=3B &g= >t=3B>=3B >=3B
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= >=3BCan you put all your code in our CVS repository?
>=3B >=3B>=3B = >>=3B
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B I can't put all t= >he code I work with in m3devel's repository: some of=3D20
>=3B >=3B&= >gt=3B it is proprietary.
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B= > The Scheme code however I have no restrictions on distributing (that's
= >>=3B >=3B>=3B what's got problems in this case). It is however large= > and unwieldy and
>=3B >=3B>=3B I'd like to have other people's su= >ggestions for how to submit/incorporate
>=3B >=3B>=3B it with CM3 = >before I just dump it in the repository. It also overlaps a =3D
>=3B = >>=3Bbit
>=3B >=3B>=3B with "caltech-parser"=3D2C so there should= > probably be a "caltech-common"
>=3B >=3B>=3B package for the over= >laps?
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B If you run the fol= >lowing commands in a fresh directory=3D2C you should get
>=3B >=3B&g= >t=3B to the error I emailed:
>=3B >=3B>=3B=3D20
>=3B >=3B&g= >t=3B setenv CM3 1
>=3B >=3B>=3B cvs -d :pserver:anonymous at pluto.gc= >apltd.com:/home/gcap-public-cvs up -d .
>=3B >=3B>=3B make regress= > # GNU make : 'gmake regress' on BSD
>=3B >=3B>=3B cd mscheme/s= >stubgen/example
>=3B >=3B>=3B cm3 -x
>=3B >=3B>=3B=3D20r>>=3B >=3B>=3B Mika
>=3B >=3B>=3B=3D20
>=3B >= >=3B>=3B=3D20
>=3B >=3B =3Dr>>=3B >=3B
>=3B &= >gt=3B--_9ece0c56-2524-4879-9a65-2407b1dbf664_
>=3B >=3BContent-Type:= > text/html=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encod= >ing: quoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>=3B
= >>=3B >=3B<=3Bhead>=3B
>=3B >=3B<=3Bstyle>=3B<=3B!-->>=3B >=3B.hmmessage P
>=3B >=3B{
>=3B >=3Bmargin:0px=3D3= >B
>=3B >=3Bpadding:0px
>=3B >=3B}
>=3B >=3Bbody.hmmess= >age
>=3B >=3B{
>=3B >=3Bfont-size: 10pt=3D3B
>=3B >=3B= >font-family:Tahoma
>=3B >=3B}
>=3B >=3B-->=3B<=3B/style&g= >t=3B
>=3B >=3B<=3B/head>=3B
>=3B >=3B<=3Bbody class=3D3= >D'hmmessage'>=3B
>=3B >=3BI can't quite reproduce it=3D2C but I ca= >n compile a bunch of your code.<=3Bbr>=3B<=3Bb=3D
>=3B >=3Br&g= >t=3B<=3Bbr>=3Bnew "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN= >/libscheme-l=3D
>=3B >=3Bib.a" -&=3Bgt=3D3B archiving libsstubgen= >.a<=3Bbr>=3B<=3Bbr>=3B=3D3D=3D3D=3D3D&=3Bgt=3D3B mscheme/sstubg= >=3D
>=3B >=3Ben/program<=3Bbr>=3B--- building in I386_DARWIN ---= ><=3Bbr>=3B<=3Bbr>=3B&=3Bnbsp=3D3B-&=3Bgt=3D3B linkin=3D
&g= >t=3B >=3Bg sstubgen<=3Bbr>=3Bi686-apple-darwin9-gcc-4.0.1: /dev2/gcap= >-public-cvs/mscheme/I=3D
>=3B >=3B386_DARWIN/libmscheme.a: No such f= >ile or directory<=3Bbr>=3B&=3Bnbsp=3D3B m3_link =3D3D&=3B=3D
&= >gt=3B >=3Bgt=3D3B 1<=3Bbr>=3Blinker failed linking: sstubgen<=3Bbr&= >gt=3BFatal Error: package build fa=3D
>=3B >=3Biled<=3Bbr>=3B<= >=3Bbr>=3Bjbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example<=3Bbr&= >gt=3Bjboo=3D
>=3B >=3Bk2:example jay$ c=3D2C3<=3Bbr>=3B-bash: c= >=3D2C3: command not found<=3Bbr>=3Bjbook2:example =3D
>=3B >=3Bj= >ay$ cm3<=3Bbr>=3B--- building in I386_DARWIN ---<=3Bbr>=3B<=3Bbr&= >gt=3Bignoring ../src/m3overri=3D
>=3B >=3Bdes<=3Bbr>=3B<=3Bbr&= >gt=3B"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3=3D>>=3B >=3Bmakefile"=3D2C line 3: quake runtime error: unable to open "/= >cm3/pkg/mscheme/=3D
>=3B >=3BI386_DARWIN/.M3EXPORTS" for reading<= >=3Bbr>=3B<=3Bbr>=3B--procedure--&=3Bnbsp=3D3B -line-&=3Bnbs=3D<= >br>>=3B >=3Bp=3D3B -file---<=3Bbr>=3Bimport&=3Bnbsp=3D3B&=3Bn= >bsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&am= >p=3Bnbs=3D
>=3B >=3Bp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbs= >p=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B --&=3Bnbsp=3D3B &=3Blt=3D3Bbui= >ltin&=3Bgt=3D3B=3D
>=3B >=3B<=3Bbr>=3Binclude_dir&=3Bnbsp= >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&= >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbs=3D
>=3B >=3Bp=3D3B 3&=3Bnb= >sp=3D3B /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src=3D
= >>=3B >=3B/m3makefile<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B&=3Bnb= >sp=3D3B- Jay<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bb= >r>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bhr id=3D3D"s=3D
>=3B >=3Bto= >pSpelling">=3BFrom: jay.krell at cornell.edu<=3Bbr>=3BTo: mika at async.cal= >tech.edu<=3Bbr>=3BD=3D
>=3B >=3Bate: Mon=3D2C 27 Dec 2010 10:46:= >55 +0000<=3Bbr>=3BCC: m3devel at elegosoft.com<=3Bbr>=3BSubj=3D
>= >=3B >=3Bect: Re: [M3devel] compiler problems on Snow Leopard<=3Bbr>= >=3B<=3Bbr>=3B
>=3B >=3B
>=3B >=3B<=3Bmeta http-equiv=3D= >3D"Content-Type" content=3D3D"text/html=3D3B charset=3D3Dunicode=3D
>= >=3B >=3B">=3B
>=3B >=3B<=3Bmeta name=3D3D"Generator" content= >=3D3D"Microsoft SafeHTML">=3B
>=3B >=3B<=3Bstyle>=3B
>=3B= > >=3B.ExternalClass .ecxhmmessage P
>=3B >=3B{padding:0px=3D3B}>>=3B >=3B.ExternalClass body.ecxhmmessage
>=3B >=3B{font-size:1= >0pt=3D3Bfont-family:Tahoma=3D3B}
>=3B >=3B
>=3B >=3B<=3B/st= >yle>=3B
>=3B >=3B
>=3B >=3B
>=3B >=3Baside: overlap = >with caltech_parser:<=3Bbr>=3Bif you can come up with a merged ver=3Dr>>=3B >=3Bsion that works with both=3D2C good<=3Bbr>=3BIf you can'= >t=3D2C I think you have to re=3D
>=3B >=3Bname one or the other.<= >=3Bbr>=3B<=3Bbr>=3BMaybe someday we can support some sort of hie=3Dr>>=3B >=3Brarchy that automatically maps to/from the file system hiera= >rchy...<=3Bbr>=3B<=3Bbr>=3B=3D
>=3B >=3BI'll try to reproduc= >e the problem.<=3Bbr>=3B<=3Bbr>=3BAll targets?<=3Bbr>=3BWorkaro= >und with d=3D
>=3B >=3Bifferent cm3cg switches (e.g. -O0 vs. -O1 vs.= > -O2?)<=3Bbr>=3B<=3Bbr>=3B&=3Bnbsp=3D3B- Jay<=3Bbr=3D
>= >=3B >=3B>=3B<=3Bbr>=3B<=3Bbr>=3B&=3Bgt=3D3B To: jay.krell at co= >rnell.edu<=3Bbr>=3B&=3Bgt=3D3B Date: Mon=3D2C 27 Dec 201=3D
>= >=3B >=3B0 02:38:10 -0800<=3Bbr>=3B&=3Bgt=3D3B From: mika at async.cal= >tech.edu<=3Bbr>=3B&=3Bgt=3D3B CC: m3dev=3D
>=3B >=3Bel at elegos= >oft.com<=3Bbr>=3B&=3Bgt=3D3B Subject: Re: [M3devel] compiler problem= >s on Snow=3D
>=3B >=3B Leopard<=3Bbr>=3B&=3Bgt=3D3B <=3Bbr&= >gt=3B&=3Bgt=3D3B Jay K writes:<=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3= >B--_6f82bcb2-663=3D
>=3B >=3Bf-4046-87f2-073a1528a819_<=3Bbr>=3B= >&=3Bgt=3D3B &=3Bgt=3D3BContent-Type: text/plain=3D3B chars=3D
>= >=3B >=3Bet=3D3D"iso-8859-1"<=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3BCon= >tent-Transfer-Encoding: quoted-printab=3D
>=3B >=3Ble<=3Bbr>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3B<=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3B<= >=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3BCan you put all your c=3D
>=3B= > >=3Bode in our CVS repository?<=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3= >B<=3Bbr>=3B&=3Bgt=3D3B <=3Bbr>=3B&=3Bgt=3D3B I can't pu=3D>>=3B >=3Bt all the code I work with in m3devel's repository: some of &= >lt=3Bbr>=3B&=3Bgt=3D3B it i=3D
>=3B >=3Bs proprietary.<=3Bbr&= >gt=3B&=3Bgt=3D3B <=3Bbr>=3B&=3Bgt=3D3B The Scheme code however I = >have no restr=3D
>=3B >=3Bictions on distributing (that's<=3Bbr>= >=3B&=3Bgt=3D3B what's got problems in this case)=3D
>=3B >=3B. I= >t is however large and unwieldy and<=3Bbr>=3B&=3Bgt=3D3B I'd like to= > have other pe=3D
>=3B >=3Bople's suggestions for how to submit/inco= >rporate<=3Bbr>=3B&=3Bgt=3D3B it with CM3 befo=3D
>=3B >=3Bre = >I just dump it in the repository. It also overlaps a bit<=3Bbr>=3B&= >=3Bgt=3D3B with=3D
>=3B >=3B "caltech-parser"=3D2C so there should p= >robably be a "caltech-common"<=3Bbr>=3B&=3Bgt=3D
>=3B >=3B=3D= >3B package for the overlaps?<=3Bbr>=3B&=3Bgt=3D3B <=3Bbr>=3B&= >=3Bgt=3D3B If you run the following=3D
>=3B >=3B commands in a fresh= > directory=3D2C you should get<=3Bbr>=3B&=3Bgt=3D3B to the error I e= >=3D
>=3B >=3Bmailed:<=3Bbr>=3B&=3Bgt=3D3B <=3Bbr>=3B&= >=3Bgt=3D3B setenv CM3 1<=3Bbr>=3B&=3Bgt=3D3B cvs -d :pserver:anonymo= >=3D
>=3B >=3Bus at pluto.gcapltd.com:/home/gcap-public-cvs up -d .<= >=3Bbr>=3B&=3Bgt=3D3B make regress =3D
>=3B >=3B # GNU make : = >'gmake regress' on BSD<=3Bbr>=3B&=3Bgt=3D3B cd mscheme/sstubgen/exam= >ple=3D
>=3B >=3B<=3Bbr>=3B&=3Bgt=3D3B cm3 -x<=3Bbr>=3B&am= >p=3Bgt=3D3B <=3Bbr>=3B&=3Bgt=3D3B Mika<=3Bbr>=3B&=3Bgt= >=3D3B <=3Bbr>=3B&=3Bgt=3D3B <=3Bbr>=3B =3D
>=3B >=3B > = > <=3B/body>=3B
>=3B >=3B<=3B/html>=3B=3D
> >=3B >= >=3B
>=3B >=3B--_9ece0c56-2524-4879-9a65-2407b1dbf664_--
> = > >= > >--_d61e805f-545e-4b3d-abe7-a20c582bec2e_-- From jay.krell at cornell.edu Mon Dec 27 12:34:09 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 11:34:09 +0000 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <20101227112424.C13401A205B@async.async.caltech.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , , ,,<20101227101421.38A6A1A205B@async.async.caltech.edu>, , ,,, , ,,<20101227103810.94DF21A205B@async.async.caltech.edu>, , , , , , , , <20101227105859.8E1F21A205B@async.async.caltech.edu>, , , , <20101227112424.C13401A205B@async.async.caltech.edu> Message-ID: I started over. rm -rf various changed toolset to I386_DARWIN, hopefully correctly cvs -z3 upd -dAP export CM3=1 gnumake regress .. lots of stuf compiles .. .. and then: ===> mscheme/sstubgen/program --- building in I386_DARWIN --- new source -> compiling Main.m3 -> linking sstubgen i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/libmscheme.a: No such file or directory m3_link => 1 linker failed linking: sstubgen Fatal Error: package build failed jbook2:gcap-public-cvs jay$ cd mscheme/ jbook2:mscheme jay$ ls CVS doc interactive modula3scheme schemereadline src threads I386_DARWIN examples interactive_r scheme-lib schemesig sstubgen jbook2:mscheme jay$ cm3 --- building in I386_DARWIN --- ignoring ../src/m3overrides "/Users/jay/dev2/gcap-public-cvs/mscheme/src/sgenerics.tmpl", line 3: quake runtime error: undefined variable: TOP --procedure-- -line- -file--- template 3 /Users/jay/dev2/gcap-public-cvs/mscheme/src/sgenerics.tmpl include_dir 69 /Users/jay/dev2/gcap-public-cvs/mscheme/src/m3makefile 4 /Users/jay/dev2/gcap-public-cvs/mscheme/I386_DARWIN/m3make.args Fatal Error: package build failed jbook2:mscheme jay$ jbook2:mscheme jay$ cm3 -DTOP=/dev2/gcap-public-cvs --- building in I386_DARWIN --- ignoring ../src/m3overrides "/Users/jay/dev2/gcap-public-cvs/mscheme/src/m3makefile", line 73: quake runtime error: undefined variable: Netobj --procedure-- -line- -file--- include_dir 73 /Users/jay/dev2/gcap-public-cvs/mscheme/src/m3makefile 5 /Users/jay/dev2/gcap-public-cvs/mscheme/I386_DARWIN/m3make.args Fatal Error: package build failed j jbook2:mscheme jay$ cm3 -DTOP=/dev2/gcap-public-cvs -x --- building in I386_DARWIN --- ignoring override("mscheme", "/dev2/gcap-public-cvs") new source -> compiling SchemeEnvironment_Public_v1.m3 "../I386_DARWIN/SchemeEnvironment_Public_v1.m3", line 546: illegal INTEGER literal, zero used "../I386_DARWIN/SchemeEnvironment_Public_v1.m3", line 547: illegal INTEGER literal, zero used 2 errors encountered compilation failed => not building library "libmscheme.a" Fatal Error: package build failed jbook2:mscheme jay$ minArgs_arg := StubLib.InInteger(c, rep, 0, 9223372036854775807); maxArgs_arg := StubLib.InInteger(c, rep, 0, 9223372036854775807); > To: jay.krell at cornell.edu > Date: Mon, 27 Dec 2010 03:24:24 -0800 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] compiler problems on Snow Leopard > > Don't think you need m3texthack. > > The first thing that happens when you run make ought to be that a file > called ".top" is created at the top level of the repository, with a > definition of TOP. This file is included by the top-level m3overrides, > which is included by every m3overrides when you run with -x. > > Mika > > Jay K writes: > >--_d61e805f-545e-4b3d-abe7-a20c582bec2e_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >something wanted cit_util. > > > > > > > >--- building in AMD64_DARWIN --- > > > > > > > >ignoring ../src/m3overrides > > > > > > > >"/Users/jay/dev2/gcap-public-cvs/cit_util/src/texthack.tmpl"=2C line 2: qua= > >ke runtime error: undefined variable: TOP > > > > > > > >--procedure-- -line- -file--- > > > >template 2 /Users/jay/dev2/gcap-public-cvs/cit_util/src/texthac= > >k.tmpl > > > >include_dir 13 /Users/jay/dev2/gcap-public-cvs/cit_util/src/m3makef= > >ile > > > > 4 /Users/jay/dev2/gcap-public-cvs/cit_util/AMD64_DARWI= > >N/m3make.args > > > > > > > > > > > >% $Id: texthack.tmpl=2Cv 1.7 2002/12/13 22:20:12 kp Exp $ > > > >_M3TEXTHACK =3D TOP & "/m3texthack/" & BUILD_DIR & "/m3texthack" > > > >_DERIVGEN =3D TOP & "/m3texthack/src/derivgen.sh" > > > > > >I don't have m3texthack anywhere I think. > > > > - Jay > > > >From: jay.krell at cornell.edu > >To: mika at async.caltech.edu > >Date: Mon=2C 27 Dec 2010 11:04:11 +0000 > >CC: m3devel at elegosoft.com > >Subject: Re: [M3devel] compiler problems on Snow Leopard > > > > > > > > > > > > > > > > > >Yes=2C overrides and standalone is a problem. > > > >Maybe I'll get around to addressing this for the next release. > > > >A proposed solution is: > > go back to mostly the old method: hard coded runpaths=2C with much overla= > >p for global builds (to be shipped/installed)=2C monstrously long paths for= > > local builds (not to be shipped)=2C AND link upon install > > Some systems allow for "slight relinking"=2C including Solaris and Darwin= > >=2C where just the paths get edited. That would be nicer. > > > > The old approach had problems too. > > > > If you build the system yourself=2C I think you automatically already to= > >day get what is described -- hardcoded run paths=2C with much overlap for g= > >lobal builds. > > > > > > - Jay > > > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] compiler problems on Snow Leopard=20 > >> Date: Mon=2C 27 Dec 2010 02:58:59 -0800 > >> From: mika at async.caltech.edu > >>=20 > >> Run cm3 -x instead of just cm3. > >>=20 > >> Did you get an error compiling package "mscheme"? I certainly have a > >> libmscheme.a in there. > >>=20 > >> /m3overrides has build_standalone() in it. > >>=20 > >> I normally didn't use build_standalone() but something has changed in > >> how the system searches for shared libs when building with overrides > >> and this was the easiest solution (at least for now). > >>=20 > >> Mika > >>=20 > >> Jay K writes: > >> >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ > >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> >I can't quite reproduce it=3D2C but I can compile a bunch of your code. > >> > > >> > > >> >new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-lib.= > >a" =3D > >> >-> archiving libsstubgen.a > >> > > >> >=3D3D=3D3D=3D3D> mscheme/sstubgen/program > >> >--- building in I386_DARWIN --- > >> > > >> > -> linking sstubgen > >> >i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/= > >lib=3D > >> >mscheme.a: No such file or directory > >> > m3_link =3D3D> 1 > >> >linker failed linking: sstubgen > >> >Fatal Error: package build failed > >> > > >> >jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example > >> >jbook2:example jay$ c=3D2C3 > >> >-bash: c=3D2C3: command not found > >> >jbook2:example jay$ cm3 > >> >--- building in I386_DARWIN --- > >> > > >> >ignoring ../src/m3overrides > >> > > >> >"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3makefile= > >"=3D > >> >=3D2C line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/I386= > >_DARW=3D > >> >IN/.M3EXPORTS" for reading > >> > > >> >--procedure-- -line- -file--- > >> >import -- > >> >include_dir 3 /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/= > >exa=3D > >> >mple/src/m3makefile > >> > > >> > > >> > - Jay > >> > > >> > > >> > > >> > > >> > > >> > > >> >From: jay.krell at cornell.edu > >> >To: mika at async.caltech.edu > >> >Date: Mon=3D2C 27 Dec 2010 10:46:55 +0000 > >> >CC: m3devel at elegosoft.com > >> >Subject: Re: [M3devel] compiler problems on Snow Leopard > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> >aside: overlap with caltech_parser: > >> >if you can come up with a merged version that works with both=3D2C good > >> >If you can't=3D2C I think you have to rename one or the other. > >> > > >> >Maybe someday we can support some sort of hierarchy that automatically m= > >aps=3D > >> > to/from the file system hierarchy... > >> > > >> >I'll try to reproduce the problem. > >> > > >> >All targets? > >> >Workaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) > >> > > >> > - Jay > >> > > >> > > >> >> To: jay.krell at cornell.edu > >> >> Date: Mon=3D2C 27 Dec 2010 02:38:10 -0800 > >> >> From: mika at async.caltech.edu > >> >> CC: m3devel at elegosoft.com > >> >> Subject: Re: [M3devel] compiler problems on Snow Leopard > >> >>=3D20 > >> >> Jay K writes: > >> >> >--_6f82bcb2-663f-4046-87f2-073a1528a819_ > >> >> >Content-Type: text/plain=3D3B charset=3D3D"iso-8859-1" > >> >> >Content-Transfer-Encoding: quoted-printable > >> >> > > >> >> > > >> >> >Can you put all your code in our CVS repository? > >> >> > > >> >>=3D20 > >> >> I can't put all the code I work with in m3devel's repository: some of= > >=3D20 > >> >> it is proprietary. > >> >>=3D20 > >> >> The Scheme code however I have no restrictions on distributing (that's > >> >> what's got problems in this case). It is however large and unwieldy a= > >nd > >> >> I'd like to have other people's suggestions for how to submit/incorpor= > >ate > >> >> it with CM3 before I just dump it in the repository. It also overlaps= > > a =3D > >> >bit > >> >> with "caltech-parser"=3D2C so there should probably be a "caltech-comm= > >on" > >> >> package for the overlaps? > >> >>=3D20 > >> >> If you run the following commands in a fresh directory=3D2C you should= > > get > >> >> to the error I emailed: > >> >>=3D20 > >> >> setenv CM3 1 > >> >> cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -= > >d . > >> >> make regress # GNU make : 'gmake regress' on BSD > >> >> cd mscheme/sstubgen/example > >> >> cm3 -x > >> >>=3D20 > >> >> Mika > >> >>=3D20 > >> >>=3D20 > >> > =3D > >> > > >> >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ > >> >Content-Type: text/html=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> > > >> > > >> > > >> > > >> >I can't quite reproduce it=3D2C but I can compile a bunch of your code.<= > >br> >> >r>
new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libschem= > >e-l=3D > >> >ib.a" ->=3D3B archiving libsstubgen.a

=3D3D=3D3D=3D3D>=3D3B m= > >scheme/sstubg=3D > >> >en/program
--- building in I386_DARWIN ---

 =3D3B->=3D3B= > > linkin=3D > >> >g sstubgen
i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mschem= > >e/I=3D > >> >386_DARWIN/libmscheme.a: No such file or directory
 =3D3B m3_link= > > =3D3D&=3D > >> >gt=3D3B 1
linker failed linking: sstubgen
Fatal Error: package bui= > >ld fa=3D > >> >iled

jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example
j= > >boo=3D > >> >k2:example jay$ c=3D2C3
-bash: c=3D2C3: command not found
jbook2:e= > >xample =3D > >> >jay$ cm3
--- building in I386_DARWIN ---

ignoring ../src/m3ove= > >rri=3D > >> >des

"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src= > >/m3=3D > >> >makefile"=3D2C line 3: quake runtime error: unable to open "/cm3/pkg/msc= > >heme/=3D > >> >I386_DARWIN/.M3EXPORTS" for reading

--procedure-- =3D3B -line= > >-&nbs=3D > >> >p=3D3B -file---
import =3D3B =3D3B =3D3B =3D3B = > >=3D3B =3D3B&nbs=3D > >> >p=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B -- =3D3B &l= > >t=3D3Bbuiltin>=3D3B=3D > >> >
include_dir =3D3B =3D3B =3D3B =3D3B =3D3B = > >=3D3B =3D3B&nbs=3D > >> >p=3D3B 3 =3D3B /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/exam= > >ple/src=3D > >> >/m3makefile


 =3D3B- Jay






>=3D3D"s=3D > >> >topSpelling">From: jay.krell at cornell.edu
To: mika at async.caltech.edu >r>D=3D > >> >ate: Mon=3D2C 27 Dec 2010 10:46:55 +0000
CC: m3devel at elegosoft.com >>Subj=3D > >> >ect: Re: [M3devel] compiler problems on Snow Leopard

> >> > > >> > >=3D3Dunicode=3D > >> >"> > >> > > >> > > >> > > >> > > >> >aside: overlap with caltech_parser:
if you can come up with a merged = > >ver=3D > >> >sion that works with both=3D2C good
If you can't=3D2C I think you hav= > >e to re=3D > >> >name one or the other.

Maybe someday we can support some sort of = > >hie=3D > >> >rarchy that automatically maps to/from the file system hierarchy...
<= > >br>=3D > >> >I'll try to reproduce the problem.

All targets?
Workaround wit= > >h d=3D > >> >ifferent cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?)

 =3D3B- J= > >ay >> >>

>=3D3B To: jay.krell at cornell.edu
>=3D3B Date: Mon=3D2C 2= > >7 Dec 201=3D > >> >0 02:38:10 -0800
>=3D3B From: mika at async.caltech.edu
>=3D3B CC= > >: m3dev=3D > >> >el at elegosoft.com
>=3D3B Subject: Re: [M3devel] compiler problems on= > > Snow=3D > >> > Leopard
>=3D3B
>=3D3B Jay K writes:
>=3D3B >=3D3B--_6= > >f82bcb2-663=3D > >> >f-4046-87f2-073a1528a819_
>=3D3B >=3D3BContent-Type: text/plain= > >=3D3B chars=3D > >> >et=3D3D"iso-8859-1"
>=3D3B >=3D3BContent-Transfer-Encoding: quote= > >d-printab=3D > >> >le
>=3D3B >=3D3B
>=3D3B >=3D3B
>=3D3B >=3D3BCan you= > > put all your c=3D > >> >ode in our CVS repository?
>=3D3B >=3D3B
>=3D3B
>=3D3B= > > I can't pu=3D > >> >t all the code I work with in m3devel's repository: some of
>=3D3B= > > it i=3D > >> >s proprietary.
>=3D3B
>=3D3B The Scheme code however I have n= > >o restr=3D > >> >ictions on distributing (that's
>=3D3B what's got problems in this = > >case)=3D > >> >. It is however large and unwieldy and
>=3D3B I'd like to have oth= > >er pe=3D > >> >ople's suggestions for how to submit/incorporate
>=3D3B it with CM3= > > befo=3D > >> >re I just dump it in the repository. It also overlaps a bit
>=3D3B= > > with=3D > >> > "caltech-parser"=3D2C so there should probably be a "caltech-common" >>>=3D > >> >=3D3B package for the overlaps?
>=3D3B
>=3D3B If you run the = > >following=3D > >> > commands in a fresh directory=3D2C you should get
>=3D3B to the er= > >ror I e=3D > >> >mailed:
>=3D3B
>=3D3B setenv CM3 1
>=3D3B cvs -d :pserve= > >r:anonymo=3D > >> >us at pluto.gcapltd.com:/home/gcap-public-cvs up -d .
>=3D3B make regr= > >ess =3D > >> > # GNU make : 'gmake regress' on BSD
>=3D3B cd mscheme/sstubgen/ex= > >ample=3D > >> >
>=3D3B cm3 -x
>=3D3B
>=3D3B Mika
>=3D3B
&= > >gt=3D3B
=3D > >> > > >> >=3D > >> > > >> >--_9ece0c56-2524-4879-9a65-2407b1dbf664_-- > > = > > > >--_d61e805f-545e-4b3d-abe7-a20c582bec2e_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >something wanted cit_util.
> >
> >--- building in AMD64_DARWIN ---
> >
> >ignoring ../src/m3overrides
> >
> >"/Users/jay/dev2/gcap-public-cvs/cit_util/src/texthack.tmpl"=2C line 2: qua= > >ke runtime error: undefined variable: TOP
> >
> >--procedure-- =3B -line- =3B -file---
> >template =3B =3B =3B =3B =3B =3B =3B =3B&nb= > >sp=3B =3B =3B 2 =3B /Users/jay/dev2/gcap-public-cvs/cit_util/sr= > >c/texthack.tmpl
> >include_dir =3B =3B =3B =3B =3B =3B =3B 13 = > >=3B /Users/jay/dev2/gcap-public-cvs/cit_util/src/m3makefile
> > =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= > >sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = > >=3B 4 =3B /Users/jay/dev2/gcap-public-cvs/cit_util/AMD64_DARWIN/m3make.= > >args
> >
> >
> >% $Id: texthack.tmpl=2Cv 1.7 2002/12/13 22:20:12 kp Exp $
> >_M3TEXTHACK =3D TOP &=3B "/m3texthack/" &=3B BUILD_DIR &=3B "/m3te= > >xthack"
> >_DERIVGEN =3B =3B =3D TOP &=3B "/m3texthack/src/derivgen.sh"
> >
I don't have m3texthack anywhere I think.

 =3B- Jay

<= > >hr id=3D"stopSpelling">From: jay.krell at cornell.edu
To: mika at async.caltec= > >h.edu
Date: Mon=2C 27 Dec 2010 11:04:11 +0000
CC: m3devel at elegosoft.c= > >om
Subject: Re: [M3devel] compiler problems on Snow Leopard

> > > > >"> > > > > > > > > > >Yes=2C overrides and standalone is a problem.

Maybe I'll get around = > >to addressing this for the next release.

A proposed solution is:
= > > =3B go back to mostly the old method: hard coded runpaths=2C with much= > > overlap for global builds (to be shipped/installed)=2C monstrously long pa= > >ths for local builds (not to be shipped)=2C AND link upon install
 = > >=3B Some systems allow for "slight relinking"=2C including Solaris and Darw= > >in=2C where just the paths get edited. That would be nicer.

 =3B= > > The old approach had problems too.

 =3B =3B If you build th= > >e system yourself=2C I think you automatically already today get what is de= > >scribed -- hardcoded run paths=2C with much overlap for global builds.
<= > >br>
 =3B- Jay

>=3B To: jay.krell at cornell.edu
>=3B CC: = > >m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] compiler problems on= > > Snow Leopard
>=3B Date: Mon=2C 27 Dec 2010 02:58:59 -0800
>=3B = > >From: mika at async.caltech.edu
>=3B
>=3B Run cm3 -x instead of jus= > >t cm3.
>=3B
>=3B Did you get an error compiling package "mscheme= > >"? I certainly have a
>=3B libmscheme.a in there.
>=3B
>= > >=3B <=3Btop>=3B/m3overrides has build_standalone() in it.
>=3B >>>=3B I normally didn't use build_standalone() but something has changed = > >in
>=3B how the system searches for shared libs when building with ove= > >rrides
>=3B and this was the easiest solution (at least for now).
&= > >gt=3B
>=3B Mika
>=3B
>=3B Jay K writes:
>=3B >= > >=3B--_9ece0c56-2524-4879-9a65-2407b1dbf664_
>=3B >=3BContent-Type: t= > >ext/plain=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encodi= > >ng: quoted-printable
>=3B >=3B
>=3B >=3B
>=3B >=3BI ca= > >n't quite reproduce it=3D2C but I can compile a bunch of your code.
>= > >=3B >=3B
>=3B >=3B
>=3B >=3Bnew "/dev2/gcap-public-cvs/msch= > >eme/scheme-lib/I386_DARWIN/libscheme-lib.a" =3D
>=3B >=3B->=3B arc= > >hiving libsstubgen.a
>=3B >=3B
>=3B >=3B=3D3D=3D3D=3D3D>=3B= > > mscheme/sstubgen/program
>=3B >=3B--- building in I386_DARWIN --- >r>>=3B >=3B
>=3B >=3B ->=3B linking sstubgen
>=3B >=3Bi= > >686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/lib= > >=3D
>=3B >=3Bmscheme.a: No such file or directory
>=3B >=3B = > >m3_link =3D3D>=3B 1
>=3B >=3Blinker failed linking: sstubgen
&g= > >t=3B >=3BFatal Error: package build failed
>=3B >=3B
>=3B >= > >=3Bjbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example
>=3B >=3B= > >jbook2:example jay$ c=3D2C3
>=3B >=3B-bash: c=3D2C3: command not fou= > >nd
>=3B >=3Bjbook2:example jay$ cm3
>=3B >=3B--- building in = > >I386_DARWIN ---
>=3B >=3B
>=3B >=3Bignoring ../src/m3override= > >s
>=3B >=3B
>=3B >=3B"/Users/jay/dev2/gcap-public-cvs/mscheme= > >/sstubgen/example/src/m3makefile"=3D
>=3B >=3B=3D2C line 3: quake ru= > >ntime error: unable to open "/cm3/pkg/mscheme/I386_DARW=3D
>=3B >=3B= > >IN/.M3EXPORTS" for reading
>=3B >=3B
>=3B >=3B--procedure-- = > >-line- -file---
>=3B >=3Bimport -- <=3Bbuiltin>=3B= > >
>=3B >=3Binclude_dir 3 /Users/jay/dev2/gcap-public-cvs/msc= > >heme/sstubgen/exa=3D
>=3B >=3Bmple/src/m3makefile
>=3B >=3B >r>>=3B >=3B
>=3B >=3B - Jay
>=3B >=3B
>=3B >=3B >>>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B= > > >=3BFrom: jay.krell at cornell.edu
>=3B >=3BTo: mika at async.caltech.e= > >du
>=3B >=3BDate: Mon=3D2C 27 Dec 2010 10:46:55 +0000
>=3B >= > >=3BCC: m3devel at elegosoft.com
>=3B >=3BSubject: Re: [M3devel] compile= > >r problems on Snow Leopard
>=3B >=3B
>=3B >=3B
>=3B >= > >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
= > >>=3B >=3B
>=3B >=3Baside: overlap with caltech_parser:
>=3B= > > >=3Bif you can come up with a merged version that works with both=3D2C g= > >ood
>=3B >=3BIf you can't=3D2C I think you have to rename one or the= > > other.
>=3B >=3B
>=3B >=3BMaybe someday we can support some = > >sort of hierarchy that automatically maps=3D
>=3B >=3B to/from the f= > >ile system hierarchy...
>=3B >=3B
>=3B >=3BI'll try to reprod= > >uce the problem.
>=3B >=3B
>=3B >=3BAll targets?
>=3B &g= > >t=3BWorkaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) >>>=3B >=3B
>=3B >=3B - Jay
>=3B >=3B
>=3B >=3B
= > >>=3B >=3B>=3B To: jay.krell at cornell.edu
>=3B >=3B>=3B Date: = > >Mon=3D2C 27 Dec 2010 02:38:10 -0800
>=3B >=3B>=3B From: mika at async= > >.caltech.edu
>=3B >=3B>=3B CC: m3devel at elegosoft.com
>=3B >= > >=3B>=3B Subject: Re: [M3devel] compiler problems on Snow Leopard
>= > >=3B >=3B>=3B=3D20
>=3B >=3B>=3B Jay K writes:
>=3B >=3B= > >>=3B >=3B--_6f82bcb2-663f-4046-87f2-073a1528a819_
>=3B >=3B>= > >=3B >=3BContent-Type: text/plain=3D3B charset=3D3D"iso-8859-1"
>=3B = > >>=3B>=3B >=3BContent-Transfer-Encoding: quoted-printable
>=3B &g= > >t=3B>=3B >=3B
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= > >=3BCan you put all your code in our CVS repository?
>=3B >=3B>=3B = > >>=3B
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B I can't put all t= > >he code I work with in m3devel's repository: some of=3D20
>=3B >=3B&= > >gt=3B it is proprietary.
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B= > > The Scheme code however I have no restrictions on distributing (that's
= > >>=3B >=3B>=3B what's got problems in this case). It is however large= > > and unwieldy and
>=3B >=3B>=3B I'd like to have other people's su= > >ggestions for how to submit/incorporate
>=3B >=3B>=3B it with CM3 = > >before I just dump it in the repository. It also overlaps a =3D
>=3B = > >>=3Bbit
>=3B >=3B>=3B with "caltech-parser"=3D2C so there should= > > probably be a "caltech-common"
>=3B >=3B>=3B package for the over= > >laps?
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B If you run the fol= > >lowing commands in a fresh directory=3D2C you should get
>=3B >=3B&g= > >t=3B to the error I emailed:
>=3B >=3B>=3B=3D20
>=3B >=3B&g= > >t=3B setenv CM3 1
>=3B >=3B>=3B cvs -d :pserver:anonymous at pluto.gc= > >apltd.com:/home/gcap-public-cvs up -d .
>=3B >=3B>=3B make regress= > > # GNU make : 'gmake regress' on BSD
>=3B >=3B>=3B cd mscheme/s= > >stubgen/example
>=3B >=3B>=3B cm3 -x
>=3B >=3B>=3B=3D20 >r>>=3B >=3B>=3B Mika
>=3B >=3B>=3B=3D20
>=3B >= > >=3B>=3B=3D20
>=3B >=3B =3D >r>>=3B >=3B
>=3B &= > >gt=3B--_9ece0c56-2524-4879-9a65-2407b1dbf664_
>=3B >=3BContent-Type:= > > text/html=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encod= > >ing: quoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>=3B
= > >>=3B >=3B<=3Bhead>=3B
>=3B >=3B<=3Bstyle>=3B<=3B!-- >>>=3B >=3B.hmmessage P
>=3B >=3B{
>=3B >=3Bmargin:0px=3D3= > >B
>=3B >=3Bpadding:0px
>=3B >=3B}
>=3B >=3Bbody.hmmess= > >age
>=3B >=3B{
>=3B >=3Bfont-size: 10pt=3D3B
>=3B >=3B= > >font-family:Tahoma
>=3B >=3B}
>=3B >=3B-->=3B<=3B/style&g= > >t=3B
>=3B >=3B<=3B/head>=3B
>=3B >=3B<=3Bbody class=3D3= > >D'hmmessage'>=3B
>=3B >=3BI can't quite reproduce it=3D2C but I ca= > >n compile a bunch of your code.<=3Bbr>=3B<=3Bb=3D
>=3B >=3Br&g= > >t=3B<=3Bbr>=3Bnew "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN= > >/libscheme-l=3D
>=3B >=3Bib.a" -&=3Bgt=3D3B archiving libsstubgen= > >.a<=3Bbr>=3B<=3Bbr>=3B=3D3D=3D3D=3D3D&=3Bgt=3D3B mscheme/sstubg= > >=3D
>=3B >=3Ben/program<=3Bbr>=3B--- building in I386_DARWIN ---= > ><=3Bbr>=3B<=3Bbr>=3B&=3Bnbsp=3D3B-&=3Bgt=3D3B linkin=3D
&g= > >t=3B >=3Bg sstubgen<=3Bbr>=3Bi686-apple-darwin9-gcc-4.0.1: /dev2/gcap= > >-public-cvs/mscheme/I=3D
>=3B >=3B386_DARWIN/libmscheme.a: No such f= > >ile or directory<=3Bbr>=3B&=3Bnbsp=3D3B m3_link =3D3D&=3B=3D
&= > >gt=3B >=3Bgt=3D3B 1<=3Bbr>=3Blinker failed linking: sstubgen<=3Bbr&= > >gt=3BFatal Error: package build fa=3D
>=3B >=3Biled<=3Bbr>=3B<= > >=3Bbr>=3Bjbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example<=3Bbr&= > >gt=3Bjboo=3D
>=3B >=3Bk2:example jay$ c=3D2C3<=3Bbr>=3B-bash: c= > >=3D2C3: command not found<=3Bbr>=3Bjbook2:example =3D
>=3B >=3Bj= > >ay$ cm3<=3Bbr>=3B--- building in I386_DARWIN ---<=3Bbr>=3B<=3Bbr&= > >gt=3Bignoring ../src/m3overri=3D
>=3B >=3Bdes<=3Bbr>=3B<=3Bbr&= > >gt=3B"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3=3D >>>=3B >=3Bmakefile"=3D2C line 3: quake runtime error: unable to open "/= > >cm3/pkg/mscheme/=3D
>=3B >=3BI386_DARWIN/.M3EXPORTS" for reading<= > >=3Bbr>=3B<=3Bbr>=3B--procedure--&=3Bnbsp=3D3B -line-&=3Bnbs=3D<= > >br>>=3B >=3Bp=3D3B -file---<=3Bbr>=3Bimport&=3Bnbsp=3D3B&=3Bn= > >bsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&am= > >p=3Bnbs=3D
>=3B >=3Bp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbs= > >p=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B --&=3Bnbsp=3D3B &=3Blt=3D3Bbui= > >ltin&=3Bgt=3D3B=3D
>=3B >=3B<=3Bbr>=3Binclude_dir&=3Bnbsp= > >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&= > >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbs=3D
>=3B >=3Bp=3D3B 3&=3Bnb= > >sp=3D3B /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src=3D
= > >>=3B >=3B/m3makefile<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B&=3Bnb= > >sp=3D3B- Jay<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bb= > >r>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bhr id=3D3D"s=3D
>=3B >=3Bto= > >pSpelling">=3BFrom: jay.krell at cornell.edu<=3Bbr>=3BTo: mika at async.cal= > >tech.edu<=3Bbr>=3BD=3D
>=3B >=3Bate: Mon=3D2C 27 Dec 2010 10:46:= > >55 +0000<=3Bbr>=3BCC: m3devel at elegosoft.com<=3Bbr>=3BSubj=3D
>= > >=3B >=3Bect: Re: [M3devel] compiler problems on Snow Leopard<=3Bbr>= > >=3B<=3Bbr>=3B
>=3B >=3B
>=3B >=3B<=3Bmeta http-equiv=3D= > >3D"Content-Type" content=3D3D"text/html=3D3B charset=3D3Dunicode=3D
>= > >=3B >=3B">=3B
>=3B >=3B<=3Bmeta name=3D3D"Generator" content= > >=3D3D"Microsoft SafeHTML">=3B
>=3B >=3B<=3Bstyle>=3B
>=3B= > > >=3B.ExternalClass .ecxhmmessage P
>=3B >=3B{padding:0px=3D3B} >>>=3B >=3B.ExternalClass body.ecxhmmessage
>=3B >=3B{font-size:1= > >0pt=3D3Bfont-family:Tahoma=3D3B}
>=3B >=3B
>=3B >=3B<=3B/st= > >yle>=3B
>=3B >=3B
>=3B >=3B
>=3B >=3Baside: overlap = > >with caltech_parser:<=3Bbr>=3Bif you can come up with a merged ver=3D >r>>=3B >=3Bsion that works with both=3D2C good<=3Bbr>=3BIf you can'= > >t=3D2C I think you have to re=3D
>=3B >=3Bname one or the other.<= > >=3Bbr>=3B<=3Bbr>=3BMaybe someday we can support some sort of hie=3D >r>>=3B >=3Brarchy that automatically maps to/from the file system hiera= > >rchy...<=3Bbr>=3B<=3Bbr>=3B=3D
>=3B >=3BI'll try to reproduc= > >e the problem.<=3Bbr>=3B<=3Bbr>=3BAll targets?<=3Bbr>=3BWorkaro= > >und with d=3D
>=3B >=3Bifferent cm3cg switches (e.g. -O0 vs. -O1 vs.= > > -O2?)<=3Bbr>=3B<=3Bbr>=3B&=3Bnbsp=3D3B- Jay<=3Bbr=3D
>= > >=3B >=3B>=3B<=3Bbr>=3B<=3Bbr>=3B&=3Bgt=3D3B To: jay.krell at co= > >rnell.edu<=3Bbr>=3B&=3Bgt=3D3B Date: Mon=3D2C 27 Dec 201=3D
>= > >=3B >=3B0 02:38:10 -0800<=3Bbr>=3B&=3Bgt=3D3B From: mika at async.cal= > >tech.edu<=3Bbr>=3B&=3Bgt=3D3B CC: m3dev=3D
>=3B >=3Bel at elegos= > >oft.com<=3Bbr>=3B&=3Bgt=3D3B Subject: Re: [M3devel] compiler problem= > >s on Snow=3D
>=3B >=3B Leopard<=3Bbr>=3B&=3Bgt=3D3B <=3Bbr&= > >gt=3B&=3Bgt=3D3B Jay K writes:<=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3= > >B--_6f82bcb2-663=3D
>=3B >=3Bf-4046-87f2-073a1528a819_<=3Bbr>=3B= > >&=3Bgt=3D3B &=3Bgt=3D3BContent-Type: text/plain=3D3B chars=3D
>= > >=3B >=3Bet=3D3D"iso-8859-1"<=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3BCon= > >tent-Transfer-Encoding: quoted-printab=3D
>=3B >=3Ble<=3Bbr>=3B&= > >amp=3Bgt=3D3B &=3Bgt=3D3B<=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3B<= > >=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3BCan you put all your c=3D
>=3B= > > >=3Bode in our CVS repository?<=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3= > >B<=3Bbr>=3B&=3Bgt=3D3B <=3Bbr>=3B&=3Bgt=3D3B I can't pu=3D >>>=3B >=3Bt all the code I work with in m3devel's repository: some of &= > >lt=3Bbr>=3B&=3Bgt=3D3B it i=3D
>=3B >=3Bs proprietary.<=3Bbr&= > >gt=3B&=3Bgt=3D3B <=3Bbr>=3B&=3Bgt=3D3B The Scheme code however I = > >have no restr=3D
>=3B >=3Bictions on distributing (that's<=3Bbr>= > >=3B&=3Bgt=3D3B what's got problems in this case)=3D
>=3B >=3B. I= > >t is however large and unwieldy and<=3Bbr>=3B&=3Bgt=3D3B I'd like to= > > have other pe=3D
>=3B >=3Bople's suggestions for how to submit/inco= > >rporate<=3Bbr>=3B&=3Bgt=3D3B it with CM3 befo=3D
>=3B >=3Bre = > >I just dump it in the repository. It also overlaps a bit<=3Bbr>=3B&= > >=3Bgt=3D3B with=3D
>=3B >=3B "caltech-parser"=3D2C so there should p= > >robably be a "caltech-common"<=3Bbr>=3B&=3Bgt=3D
>=3B >=3B=3D= > >3B package for the overlaps?<=3Bbr>=3B&=3Bgt=3D3B <=3Bbr>=3B&= > >=3Bgt=3D3B If you run the following=3D
>=3B >=3B commands in a fresh= > > directory=3D2C you should get<=3Bbr>=3B&=3Bgt=3D3B to the error I e= > >=3D
>=3B >=3Bmailed:<=3Bbr>=3B&=3Bgt=3D3B <=3Bbr>=3B&= > >=3Bgt=3D3B setenv CM3 1<=3Bbr>=3B&=3Bgt=3D3B cvs -d :pserver:anonymo= > >=3D
>=3B >=3Bus at pluto.gcapltd.com:/home/gcap-public-cvs up -d .<= > >=3Bbr>=3B&=3Bgt=3D3B make regress =3D
>=3B >=3B # GNU make : = > >'gmake regress' on BSD<=3Bbr>=3B&=3Bgt=3D3B cd mscheme/sstubgen/exam= > >ple=3D
>=3B >=3B<=3Bbr>=3B&=3Bgt=3D3B cm3 -x<=3Bbr>=3B&am= > >p=3Bgt=3D3B <=3Bbr>=3B&=3Bgt=3D3B Mika<=3Bbr>=3B&=3Bgt= > >=3D3B <=3Bbr>=3B&=3Bgt=3D3B <=3Bbr>=3B =3D
>=3B >=3B > > = > > <=3B/body>=3B
>=3B >=3B<=3B/html>=3B=3D
> > >=3B >= > >=3B
>=3B >=3B--_9ece0c56-2524-4879-9a65-2407b1dbf664_--
> > = > > > >= > > > >--_d61e805f-545e-4b3d-abe7-a20c582bec2e_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 27 18:19:24 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Dec 2010 12:19:24 -0500 Subject: [M3devel] pointers/arrays? In-Reply-To: References: Message-ID: Have you played around with SUBARRAY? On Dec 26, 2010, at 11:37 PM, Jay K wrote: > I'm still wrestling with this. I have found a few options that work and they all have glaring problems. > > > VAR macho_header32_t_fields := ARRAY [0..6] OF field_t{ > field_t{ "magic", 0, 4, enum_table := EnumTable(macho_magic_names)}, > ... > field_t{ "flags", 24, 4}}; > > > 1) I shouldn't have to give the size of the array. > 2) I shouldn't have to copy the enum table to make it an indexable array. > > > Disappointing.. > > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 27 Dec 2010 02:11:28 +0000 > Subject: [M3devel] pointers/arrays? > > a: UNTRACED REF T; > i: INTEGER; > > > a[i] ? > (a + i)^ ? > > > Or I'm really stuck with > LOOPEHOLE(a + i * BYTESIZE(a^), UNTRACED REF T) > > > Seems kind of stinky. > I've got some nice efficient readable safe-enough C and it doesn't seem to translate well easily efficiently to Modula-3. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 27 18:20:25 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Dec 2010 12:20:25 -0500 Subject: [M3devel] constants/offsetof? In-Reply-To: References: Message-ID: <69FCE67E-DA1E-46EA-BD6C-6A0F680E8628@cs.purdue.edu> I really don't understand yet what you are trying to achieve. Do you have a distilled example? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 27, 2010, at 2:15 AM, Jay K wrote: > Is it unreasonble to expect more/all of these to be constant? > > > UNSAFE MODULE bug1; > > > TYPE T1 = RECORD i,j:INTEGER END; > > > <*NOWARN*>VAR a:T1; > <*NOWARN*>CONST b: UNTRACED REF T1 = NIL; > <*NOWARN*>CONST c: ADDRESS = ADR(a); (* line 7 *) > <*NOWARN*>CONST d: ADDRESS = ADR(a.i); > <*NOWARN*>CONST e: ADDRESS = ADR(a.j); > <*NOWARN*>CONST f: INTEGER = ADR(a.j) - NIL; > <*NOWARN*>CONST g: ADDRESS = ADR(b.i); > <*NOWARN*>CONST h: ADDRESS = ADR(b.j); > <*NOWARN*>CONST i: INTEGER = ADR(b.j) - NIL; > > <*NOWARN*>VAR vc: ADDRESS := ADR(a); > <*NOWARN*>VAR vd: ADDRESS := ADR(a.i); > <*NOWARN*>VAR ve: ADDRESS := ADR(a.j); > <*NOWARN*>VAR vf: INTEGER := ADR(a.j) - NIL; (* oops, didn't mean this one *) > <*NOWARN*>VAR vg: ADDRESS := ADR(b.i); > <*NOWARN*>VAR vh: ADDRESS := ADR(b.j); > <*NOWARN*>VAR vi: INTEGER := ADR(b.j) - NIL; > > BEGIN > END bug1. > > > "../src/bug1.m3", line 7: value is not constant > "../src/bug1.m3", line 8: value is not constant > "../src/bug1.m3", line 9: value is not constant > "../src/bug1.m3", line 10: value is not constant > "../src/bug1.m3", line 11: value is not constant > "../src/bug1.m3", line 12: value is not constant > "../src/bug1.m3", line 13: value is not constant > > It works in C... > > #include > > typedef struct { ptrdiff_t i, j;}T1; > > T1 a; > #define b ((T1*)0) > T1* const c = &a; > ptrdiff_t* const d = &a.i; > ptrdiff_t* const e = &a.j; > ptrdiff_t const f = offsetof(T1,j); > ptrdiff_t* const g = &b->i; > ptrdiff_t* const h = &b->j; > ptrdiff_t const i = &b->j - (ptrdiff_t*)0; > > > Thanks, > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 27 18:21:12 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Dec 2010 12:21:12 -0500 Subject: [M3devel] another Snow Leopard compiler crash In-Reply-To: <20101227101653.307241A205B@async.async.caltech.edu> References: <20101227101653.307241A205B@async.async.caltech.edu> Message-ID: Which version of the backend are you using? Release? There has been so much churn in the trunk lately that I have lost track of things. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 27, 2010, at 5:16 AM, Mika Nystrom wrote: > > ===> calarm/regress/ximport > --- building in I386_DARWIN --- > > new source -> compiling Main.m3 > "../src/Main.m3", line 258: warning: potentially unhandled exception: Main.ParamErr > "../src/Main.m3", line 260: warning: potentially unhandled exception: Main.ParamErr > "../src/Main.m3", line 261: warning: potentially unhandled exception: Main.ParamErr > 3 warnings encountered > ../src/Main.m3: In function 'Main__DumpMatching__DumpOne': > ../src/Main.m3:225:0: error: unable to find a register to spill in class 'CREG' > ../src/Main.m3:225:0: error: this is the insn: > (insn 5 4 6 2 ../src/Main.m3:204 (parallel [ > (set (reg:SI 0 ax [130]) > (const_int 0 [0x0])) > (set (reg:SI 1 dx [128]) > (plus:SI (ashift:SI (reg:SI 0 ax [130]) > (const_int 2 [0x2])) > (reg:SI 1 dx [128]))) > (set (reg:SI 4 si [129]) > (plus:SI (ashift:SI (reg:SI 0 ax [130]) > (const_int 2 [0x2])) > (reg:SI 4 si [129]))) > (set (mem/s/c:BLK (reg:SI 1 dx [128]) [0 trade+0 S24 A64]) > (mem/s/c:BLK (reg:SI 4 si [129]) [0 trade+0 S24 A32])) > (use (reg:SI 0 ax [130])) > ]) 838 {*rep_movsi} (expr_list:REG_UNUSED (reg:SI 0 ax [130]) > (expr_list:REG_UNUSED (reg:SI 4 si [129]) > (expr_list:REG_UNUSED (reg:SI 1 dx [128]) > (nil))))) > ../src/Main.m3:225:0: internal compiler error: in spill_failure, at reload1.c:2163 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: Main.mc > compilation failed => not building program "ximport" > Fatal Error: package build failed > > Here is the code: > > PROCEDURE DumpMatching(tr : TickerRef; > trades, bids, asks : HFDataSSeq.T) RAISES { Wr.Failure } = > > PROCEDURE DumpOne(trade, bid, ask : HFData.S) RAISES { Wr.Failure } = > BEGIN > <* ASSERT trade.time = bid.time AND bid.time = ask.time *> > Wr.PutText(wr, Fmt.LongReal(trade.time)); > > Wr.PutChar(wr, ' '); > Wr.PutText(wr, Fmt.LongReal(aFactor*trade.pv.price)); > Wr.PutChar(wr, ' '); > Wr.PutText(wr, Fmt.LongReal(FLOAT(trade.pv.volume,LONGREAL)/aFactor)); > > Wr.PutChar(wr, ' '); > Wr.PutText(wr, Fmt.LongReal(aFactor*bid.pv.price)); > Wr.PutChar(wr, ' '); > Wr.PutText(wr, Fmt.LongReal(FLOAT(bid.pv.volume,LONGREAL)/aFactor)); > > Wr.PutChar(wr, ' '); > Wr.PutText(wr, Fmt.LongReal(aFactor*ask.pv.price)); > Wr.PutChar(wr, ' '); > Wr.PutText(wr, Fmt.LongReal(FLOAT(ask.pv.volume,LONGREAL)/aFactor)); > > Wr.PutChar(wr, '\n') > END DumpOne; > > CONST > NoTime = FIRST(Time.T); > VAR > wr := FileWr.Open(odir & "/" & tr.ticker); > tp, bp, ap := 0; > ttime, btime, atime := NoTime; > aFactor : LONGREAL := 1.0d0; > BEGIN > WHILE tp < trades.size() AND bp < bids.size() AND ap < asks.size() DO > IF ttime = NoTime THEN ttime := trades.get(tp).time END; > IF btime = NoTime THEN btime := bids.get(bp).time END; > IF atime = NoTime THEN atime := asks.get(ap).time END; > > IF ttime = btime AND btime = atime THEN > DumpOne(trades.get(tp),bids.get(bp),asks.get(ap)); > INC(tp); INC(bp); INC(ap); > ttime := NoTime; btime := NoTime; atime := NoTime > ELSIF ttime < btime OR ttime < atime THEN > INC(tp); ttime := NoTime > ELSIF btime < atime OR btime < ttime THEN > INC(bp); btime := NoTime > ELSIF atime < btime OR atime < ttime THEN > INC(ap); atime := NoTime > END > END; > Wr.Close(wr) > END DumpMatching; > > Miika From hosking at cs.purdue.edu Mon Dec 27 18:22:28 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Dec 2010 12:22:28 -0500 Subject: [M3devel] enable/disableswitching around external calls? In-Reply-To: References: Message-ID: No way! I don't understand your problem. Are you saying you have thread-unsafe C code? What is the problem. Please don't do damage here! On Dec 27, 2010, at 5:35 AM, Jay K wrote: > I noticed calls to free in M3toC missing Enable/DisableSwitching. > > I'm going to generalize this, somewhat, in m3core.h, but that still leaves a fair number of custom wrappers. > > This area seems extremely error prone and extremely difficult to get test coverage on. > > These functions only do anything for user threads. > Which we only use by default on OpenBSD. > > How about the frontend emit the calls around any external calls? > > Theory being: external calls are rare? > > Perhaps frontend/m3middle would know if user threads are in use and only emit the calls in that case. Perhaps. > I don't like sprinking much target-specific information around. > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 27 18:23:35 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Dec 2010 12:23:35 -0500 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, <20101227101421.38A6A1A205B@async.async.caltech.edu> Message-ID: Rather than cluttering up CVS, why not put it in the bug-tracker? That's what it is for! Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 27, 2010, at 5:17 AM, Jay K wrote: > Can you put all your code in our CVS repository? > > > "../I386_DARWIN/FSSchemeStubs.m3", line 434: 2 code generation errors > > There is a way to get that to show more information.. > Or does it already? > > - Jay > > > To: m3devel at elegosoft.com > > Date: Mon, 27 Dec 2010 02:14:21 -0800 > > From: mika at async.caltech.edu > > Subject: Re: [M3devel] compiler problems on Snow Leopard > > > > I upgraded to the CVS head and now I get the following: > > > > ... > > "../I386_DARWIN/FSSchemeStubs.m3", line 872: warning: unreachable statement > > "../I386_DARWIN/FSSchemeStubs.m3", line 903: warning: unreachable statement > > "../I386_DARWIN/FSSchemeStubs.m3", line 434: 2 code generation errors > > 1 error and 23 warnings encountered > > new exporters -> recompiling FSSchemeStubs.i3 > > ... > > > > The source code is: > > > > TYPE FS_Iterator_Surrogate = FS.Iterator OBJECT (* line 434 *) > > interp : Scheme.T; > > next_slot : SchemeObject.T := NIL; > > close_slot : SchemeObject.T := NIL; > > nextWithStatus_slot : SchemeObject.T := NIL; > > OVERRIDES > > next := FS_Iterator_next_default; > > close := FS_Iterator_close_default; > > nextWithStatus := FS_Iterator_nextWithStatus_default; > > END; > > > > Mika > > > > Mika Nystrom writes: > > >Hi everyone, > > > > > >Well I was able to get past all my linking issues (mostly questions > > >of dynamic vs. static linking and how to do it, which seems to change from > > >version to version...) > > > > > >But now I did hit a real problem. > > > > > >"../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** unaligne > > >d store type=6 s/o/a=32/0/32 > > >"../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** unaligne > > >d load_indirect type=6 s/a=32/32 > > > > > >Here is the code, but it's not likely to be of much help... > > > > > >PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.T RAIS > > >ES { Scheme.E } = > > > BEGIN > > > VAR res : SchemePair.T:=NIL; BEGIN > > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),T > > >oScheme_Atom_T(x.type)),res); > > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modifica > > >tionTime"),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); > > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),T > > >oScheme_VAL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) > > > RETURN res > > > END > > > END ToScheme_File_Status; > > > > > > > > >... > > > > > >PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0, LONGI > > >NT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = > > > BEGIN > > > RETURN ToScheme_LONGINT(x) (* line 981 *) > > > END ToScheme_VAL0LONGINT__VAL16778080LONGINT; > > > > > > > > >for reference, ToScheme_LONGINT is: > > > > > >PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISES { S > > >cheme.E } = > > > BEGIN > > > WITH ref = NEW(REF LONGINT) DO > > > ref^ := x; > > > RETURN SchemeModula3Types.ToScheme_LONGINT(ref) > > > END > > > END ToScheme_LONGINT; > > > > > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Dec 27 19:54:53 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Dec 2010 10:54:53 -0800 Subject: [M3devel] another Snow Leopard compiler crash In-Reply-To: References: <20101227101653.307241A205B@async.async.caltech.edu> Message-ID: <20101227185453.97CE51A205B@async.async.caltech.edu> No I had to upgrade the backend to get it to work at all, it's at head too (as of 4-5 days ago). Tony Hosking writes: >Which version of the backend are you using? Release? There has been so = >much churn in the trunk lately that I have lost track of things. > > > >Antony Hosking | Associate Professor | Computer Science | Purdue = From hosking at cs.purdue.edu Mon Dec 27 20:36:14 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Dec 2010 14:36:14 -0500 Subject: [M3devel] another Snow Leopard compiler crash In-Reply-To: <20101227185453.97CE51A205B@async.async.caltech.edu> References: <20101227101653.307241A205B@async.async.caltech.edu> <20101227185453.97CE51A205B@async.async.caltech.edu> Message-ID: OK. Jay? On Dec 27, 2010, at 1:54 PM, Mika Nystrom wrote: > No I had to upgrade the backend to get it to work at all, it's at head > too (as of 4-5 days ago). > > Tony Hosking writes: >> Which version of the backend are you using? Release? There has been so = >> much churn in the trunk lately that I have lost track of things. >> >> >> >> Antony Hosking | Associate Professor | Computer Science | Purdue = From jay.krell at cornell.edu Mon Dec 27 22:41:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 21:41:31 +0000 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , Message-ID: > Rather than cluttering up CVS, why not put it in the bug-tracker? That's what it is for! It is large. It is more code that could be repeatedly tested, by building the entire "system", for a gradually growing definition of "system". We have had a number of problems that only appear in one or two or a few pieces of code. e.g. the removal of referenced nested functions. e.g. optimizations causing compilation to fail (which this appears to be as well). A smaller example would be nice, but that is more work to get. - Jay From: hosking at cs.purdue.edu Date: Mon, 27 Dec 2010 12:23:35 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] compiler problems on Snow Leopard Rather than cluttering up CVS, why not put it in the bug-tracker? That's what it is for! Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 27, 2010, at 5:17 AM, Jay K wrote:Can you put all your code in our CVS repository? > "../I386_DARWIN/FSSchemeStubs.m3", line 434: 2 code generation errors There is a way to get that to show more information.. Or does it already? - Jay > To: m3devel at elegosoft.com > Date: Mon, 27 Dec 2010 02:14:21 -0800 > From: mika at async.caltech.edu > Subject: Re: [M3devel] compiler problems on Snow Leopard > > I upgraded to the CVS head and now I get the following: > > ... > "../I386_DARWIN/FSSchemeStubs.m3", line 872: warning: unreachable statement > "../I386_DARWIN/FSSchemeStubs.m3", line 903: warning: unreachable statement > "../I386_DARWIN/FSSchemeStubs.m3", line 434: 2 code generation errors > 1 error and 23 warnings encountered > new exporters -> recompiling FSSchemeStubs.i3 > ... > > The source code is: > > TYPE FS_Iterator_Surrogate = FS.Iterator OBJECT (* line 434 *) > interp : Scheme.T; > next_slot : SchemeObject.T := NIL; > close_slot : SchemeObject.T := NIL; > nextWithStatus_slot : SchemeObject.T := NIL; > OVERRIDES > next := FS_Iterator_next_default; > close := FS_Iterator_close_default; > nextWithStatus := FS_Iterator_nextWithStatus_default; > END; > > Mika > > Mika Nystrom writes: > >Hi everyone, > > > >Well I was able to get past all my linking issues (mostly questions > >of dynamic vs. static linking and how to do it, which seems to change from > >version to version...) > > > >But now I did hit a real problem. > > > >"../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** unaligne > >d store type=6 s/o/a=32/0/32 > >"../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** unaligne > >d load_indirect type=6 s/a=32/32 > > > >Here is the code, but it's not likely to be of much help... > > > >PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.T RAIS > >ES { Scheme.E } = > > BEGIN > > VAR res : SchemePair.T:=NIL; BEGIN > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),T > >oScheme_Atom_T(x.type)),res); > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modifica > >tionTime"),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),T > >oScheme_VAL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) > > RETURN res > > END > > END ToScheme_File_Status; > > > > > >... > > > >PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0, LONGI > >NT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = > > BEGIN > > RETURN ToScheme_LONGINT(x) (* line 981 *) > > END ToScheme_VAL0LONGINT__VAL16778080LONGINT; > > > > > >for reference, ToScheme_LONGINT is: > > > >PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISES { S > >cheme.E } = > > BEGIN > > WITH ref = NEW(REF LONGINT) DO > > ref^ := x; > > RETURN SchemeModula3Types.ToScheme_LONGINT(ref) > > END > > END ToScheme_LONGINT; > > > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 28 11:48:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Dec 2010 10:48:58 +0000 Subject: [M3devel] C/Modula-3 interop with smaller than word/register parameters? In-Reply-To: References: Message-ID: (same question for return values -- use INTEGER/ptrdiff_t instead of int?) - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: C/Modula-3 interop with smaller than word/register parameters? Date: Tue, 28 Dec 2010 10:47:16 +0000 Are we super confident that passing an "int" (Ctypes.int) from Modula-3 to C will handle the upper bits correctly, for systems with 64bit registers, register-passing calling conventions? That is, zero or sign extended, if the ABI mandates it? I realize, on the C side, the upper bits may or may not be ignored, depending on the ABI. Maybe I'm being too paranoid. Maybe I should stick to ptrdiff_t/INTEGER parameters? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 28 11:47:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Dec 2010 10:47:16 +0000 Subject: [M3devel] C/Modula-3 interop with smaller than word/register parameters? Message-ID: Are we super confident that passing an "int" (Ctypes.int) from Modula-3 to C will handle the upper bits correctly, for systems with 64bit registers, register-passing calling conventions? That is, zero or sign extended, if the ABI mandates it? I realize, on the C side, the upper bits may or may not be ignored, depending on the ABI. Maybe I'm being too paranoid. Maybe I should stick to ptrdiff_t/INTEGER parameters? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 29 10:53:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Dec 2010 09:53:27 +0000 Subject: [M3devel] gui problems? BadBricks? columns? Message-ID: Could anyone look into BadBricks and columns? They see very broken -- don't seem to accept input. BadBricks occasionally does. tetris and Juno seem ok. mentor probably also though I didn't try today. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 29 13:45:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Dec 2010 12:45:58 +0000 Subject: [M3devel] ternary operator Message-ID: C code: m.swap32 = swapped ? swap32 : no_swap32; m.swap64 = swapped ? swap64 : no_swap64; m.macho_header_size = m64 ? sizeof(macho_header64_t) : sizeof(macho_header32_t); Modula-3? file.swap32 := no_swap32; file.swap64 := no_swap64; IF swapped THEN file.swap32 := swap32; file.swap64 := swap64; END; file.header_size := (ORD(m64) * BYTESIZE(header64_t)) + (ORD(NOT m64) * BYTESIZE(header32_t)); I don't like either of those forms nor IF swapped THEN file.swap32 := swap32; file.swap64 := swap64; ELSE file.swap32 := no_swap32; file.swap64 := no_swap64; END; If static type inference was more prevalent, I wouldn't mind like: m.swap32 = {no_swap32, swap32}[ORD(swapped)]; m.swap64 = {no_swap64, swap64}[ORD(swapped)]; m.macho_header_size = {sizeof(macho_header32_t), sizeof(macho_header64_t)}[ORD m64]; but I assume {no_swap32, swap32} has to be a typed constant... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Wed Dec 29 16:38:16 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 29 Dec 2010 10:38:16 -0500 Subject: [M3devel] ternary operator In-Reply-To: References: Message-ID: <20101229153816.GA17912@topoi.pooq.com> On Wed, Dec 29, 2010 at 12:45:58PM +0000, Jay K wrote: > > C code: > > m.swap32 = swapped ? swap32 : no_swap32; > m.swap64 = swapped ? swap64 : no_swap64; > m.macho_header_size = m64 ? sizeof(macho_header64_t) : sizeof(macho_header32_t); Algol 60 code: m.swap32 := IF swapped THEN swap32 ELSE no_swap32; m.swap64 := IF swapped THEN swap64 ELSE no_swap64; ...(but no such thing as sizeof)... Algol 68 code: m.swap32 := IF swapped THEN swap32 ELSE no_swap32 FI; m.swap64 := IF swapped THEN swap64 ELSE no_swap64 FI; ...(but no such thing as sizeof)... > > > Modula-3? > > > file.swap32 := no_swap32; > file.swap64 := no_swap64; > IF swapped THEN > file.swap32 := swap32; > file.swap64 := swap64; > END; > file.header_size := (ORD(m64) * BYTESIZE(header64_t)) + (ORD(NOT m64) * BYTESIZE(header32_t)); > > > > I don't like either of those forms nor > > > IF swapped THEN > > file.swap32 := swap32; > > file.swap64 := swap64; > > ELSE > > file.swap32 := no_swap32; > > > file.swap64 := no_swap64; > > > END; > > > > If static type inference was more prevalent, I wouldn't mind like: > > > m.swap32 = {no_swap32, swap32}[ORD(swapped)]; > > m.swap64 = {no_swap64, swap64}[ORD(swapped)]; > > m.macho_header_size = {sizeof(macho_header32_t), sizeof(macho_header64_t)}[ORD m64]; > > > > but I assume {no_swap32, swap32} has to be a typed constant... Abd if it no_awap32 and swap32 were como,licated expressions, it would waste time evaluating things never used. > > > - Jay > From hosking at cs.purdue.edu Wed Dec 29 17:36:40 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 29 Dec 2010 11:36:40 -0500 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: References: Message-ID: These used to work perfectly well. This is a regression. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 29, 2010, at 4:53 AM, Jay K wrote: > Could anyone look into BadBricks and columns? > They see very broken -- don't seem to accept input. > BadBricks occasionally does. > > > tetris and Juno seem ok. > mentor probably also though I didn't try today. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Dec 29 20:06:57 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 29 Dec 2010 19:06:57 +0000 (GMT) Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: Message-ID: <472423.41361.qm@web29708.mail.ird.yahoo.com> Hi all: It seemes to me they should, but currently are not in the standard build package list? Besides could be a problem in the threading? That's why I still like the traditional package, the scheduler might need adjustments, but still it has some nice things like @M3nopreemption, it seems John Polstra wrote something about using it on Digital Unix to run cvsup, see: Are there any cases of test no this runtime parameter? http://www.mavetju.org/mail/view_message.php?list=freebsd-hubs&id=551523 Thanks in advance --- El mi?, 29/12/10, Tony Hosking escribi?: De: Tony Hosking Asunto: Re: [M3devel] gui problems? BadBricks? columns? Para: "Jay K" CC: "m3devel" Fecha: mi?rcoles, 29 de diciembre, 2010 11:36 These used to work perfectly well. ?This is a regression. Antony Hosking?|?Associate Professor?| Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice?+1 765 494 6001 |?Mobile?+1 765 427 5484 On Dec 29, 2010, at 4:53 AM, Jay K wrote: Could anyone look into BadBricks and columns? They see very broken -- don't seem to accept input. BadBricks occasionally does. tetris and Juno seem ok. mentor probably also though I didn't try today. ?- Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Thu Dec 30 00:51:35 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 29 Dec 2010 23:51:35 +0000 (GMT) Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: <472423.41361.qm@web29708.mail.ird.yahoo.com> Message-ID: <60437.40903.qm@web29717.mail.ird.yahoo.com> Hi all: this reminds me that we need anyway to proof the system on errors like locking and anything else, I guess we can try again of the folks in the HP research lab if they would have the sources of the ESC/Modula-3 checker compile them for us and if they agree like before they did with the ESC/Java to make a release for us. I think they planned to do it, just that, nobody gave any new version DEC SRC M3, and it was one of the last things to be scheduled to be released. The original post explaining this same reason is here inside DEC: http://groups.google.com/group/comp.lang.modula3/browse_thread/thread/246542d2609608c7/6e9f7b0a0dd35ce9?hl=en&ie=UTF-8&q=modula3+release+3.6#6e9f7b0a0dd35ce9 Perhaps if we enough petitions we will have some day, what do you think? Perhaps is worth the time, the most difficult thing is finding it, but I guess it would be in the same part they worked or a file server over there, if they allow someone a permission to seek in their files, is just that, we can try to find it. I hope so. I mean what is the reason for keeping it if they did it to use it and explore it, and just because of time they didn't published. Have a nice and happy new year folks! --- El mi?, 29/12/10, Daniel Alejandro Benavides D. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] gui problems? BadBricks? columns? Para: "Jay K" , "Tony Hosking" CC: "m3devel" Fecha: mi?rcoles, 29 de diciembre, 2010 14:06 Hi all: It seemes to me they should, but currently are not in the standard build package list? Besides could be a problem in the threading? That's why I still like the traditional package, the scheduler might need adjustments, but still it has some nice things like @M3nopreemption, it seems John Polstra wrote something about using it on Digital Unix to run cvsup, see: Are there any cases of test no this runtime parameter? http://www.mavetju.org/mail/view_message.php?list=freebsd-hubs&id=551523 Thanks in advance --- El mi?, 29/12/10, Tony Hosking escribi?: De: Tony Hosking Asunto: Re: [M3devel] gui problems? BadBricks? columns? Para: "Jay K" CC: "m3devel" Fecha: mi?rcoles, 29 de diciembre, 2010 11:36 These used to work perfectly well. ?This is a regression. Antony Hosking?|?Associate Professor?| Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice?+1 765 494 6001 |?Mobile?+1 765 427 5484 On Dec 29, 2010, at 4:53 AM, Jay K wrote: Could anyone look into BadBricks and columns? They see very broken -- don't seem to accept input. BadBricks occasionally does. tetris and Juno seem ok. mentor probably also though I didn't try today. ?- Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 30 01:27:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 00:27:43 +0000 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: <60437.40903.qm@web29717.mail.ird.yahoo.com> References: <472423.41361.qm@web29708.mail.ird.yahoo.com>, <60437.40903.qm@web29717.mail.ird.yahoo.com> Message-ID: >These used to work perfectly well. This is a regression. I think not in a long time. Can anyone dig around? > It seemes to me they should, but currently are not in the standard build package list? Yes they are. > @M3nopreemption Probably something to do with user threads and not possible these days. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Thu Dec 30 02:23:12 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 29 Dec 2010 20:23:12 -0500 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: <60437.40903.qm@web29717.mail.ird.yahoo.com> References: <472423.41361.qm@web29708.mail.ird.yahoo.com> <60437.40903.qm@web29717.mail.ird.yahoo.com> Message-ID: Daniel et al: I tried a year or so ago to pursue getting the sources for the ESC. I'd have to dig up my old emails, but my recollection is that I ran into a dead end getting the sources and the permission to put them in our repository. I don't think the Modula-3 edition was kept up when the project moved on to other languages. Regards, Randy Coleburn From: Daniel Alejandro Benavides D. [mailto:dabenavidesd at yahoo.es] Sent: Wednesday, December 29, 2010 6:52 PM To: Jay K; Tony Hosking Cc: m3devel Subject: Re: [M3devel] gui problems? BadBricks? columns? Hi all: this reminds me that we need anyway to proof the system on errors like locking and anything else, I guess we can try again of the folks in the HP research lab if they would have the sources of the ESC/Modula-3 checker compile them for us and if they agree like before they did with the ESC/Java to make a release for us. I think they planned to do it, just that, nobody gave any new version DEC SRC M3, and it was one of the last things to be scheduled to be released. The original post explaining this same reason is here inside DEC: http://groups.google.com/group/comp.lang.modula3/browse_thread/thread/246542d2609608c7/6e9f7b0a0dd35ce9?hl=en&ie=UTF-8&q=modula3+release+3.6#6e9f7b0a0dd35ce9 Perhaps if we enough petitions we will have some day, what do you think? Perhaps is worth the time, the most difficult thing is finding it, but I guess it would be in the same part they worked or a file server over there, if they allow someone a permission to seek in their files, is just that, we can try to find it. I hope so. I mean what is the reason for keeping it if they did it to use it and explore it, and just because of time they didn't published. Have a nice and happy new year folks! --- El mi?, 29/12/10, Daniel Alejandro Benavides D. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] gui problems? BadBricks? columns? Para: "Jay K" , "Tony Hosking" CC: "m3devel" Fecha: mi?rcoles, 29 de diciembre, 2010 14:06 Hi all: It seemes to me they should, but currently are not in the standard build package list? Besides could be a problem in the threading? That's why I still like the traditional package, the scheduler might need adjustments, but still it has some nice things like @M3nopreemption, it seems John Polstra wrote something about using it on Digital Unix to run cvsup, see: Are there any cases of test no this runtime parameter? http://www.mavetju.org/mail/view_message.php?list=freebsd-hubs&id=551523 Thanks in advance --- El mi?, 29/12/10, Tony Hosking escribi?: De: Tony Hosking Asunto: Re: [M3devel] gui problems? BadBricks? columns? Para: "Jay K" CC: "m3devel" Fecha: mi?rcoles, 29 de diciembre, 2010 11:36 These used to work perfectly well. This is a regression. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 29, 2010, at 4:53 AM, Jay K wrote: Could anyone look into BadBricks and columns? They see very broken -- don't seem to accept input. BadBricks occasionally does. tetris and Juno seem ok. mentor probably also though I didn't try today. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Thu Dec 30 02:26:38 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 29 Dec 2010 20:26:38 -0500 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: References: <472423.41361.qm@web29708.mail.ird.yahoo.com>, <60437.40903.qm@web29717.mail.ird.yahoo.com> Message-ID: Both badbricks and columns seem to be working for me on Windows 7. Regards, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Wednesday, December 29, 2010 7:28 PM To: dabenavidesd at yahoo.es; Tony Cc: m3devel Subject: Re: [M3devel] gui problems? BadBricks? columns? >These used to work perfectly well. This is a regression. I think not in a long time. Can anyone dig around? > It seemes to me they should, but currently are not in the standard build package list? Yes they are. > @M3nopreemption Probably something to do with user threads and not possible these days. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Dec 30 04:26:37 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 29 Dec 2010 22:26:37 -0500 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: References: <472423.41361.qm@web29708.mail.ird.yahoo.com> <60437.40903.qm@web29717.mail.ird.yahoo.com> Message-ID: <20101230032636.GA31254@topoi.pooq.com> On Wed, Dec 29, 2010 at 08:23:12PM -0500, Coleburn, Randy wrote: > Daniel et al: > > I tried a year or so ago to pursue getting the sources for the ESC. > I'd have to dig up my old emails, but my recollection is that I ran into a dead end getting the sources and the permission to put them in our repository. > I don't think the Modula-3 edition was kept up when the project moved on to other languages. What does the ESC do that's relevant to threading? I mean, not just an answer like "deadlock and race detection", but what algorithms does it use to accomplish it? Does the Modula 3 compiler construct the proper data structures that could provide the raw data those algorithms would need? How much work would it be to reimplement this from scratch? -- hendrik From hosking at cs.purdue.edu Thu Dec 30 07:39:16 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Dec 2010 01:39:16 -0500 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: References: <472423.41361.qm@web29708.mail.ird.yahoo.com>, <60437.40903.qm@web29717.mail.ird.yahoo.com> Message-ID: <40D2C08F-4A14-43DE-B3DF-660BC2266001@cs.purdue.edu> I know I have used them in the last year or so. On Dec 29, 2010, at 7:27 PM, Jay K wrote: > >These used to work perfectly well. This is a regression. > > I think not in a long time. Can anyone dig around? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 30 10:45:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 09:45:51 +0000 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: <40D2C08F-4A14-43DE-B3DF-660BC2266001@cs.purdue.edu> References: <472423.41361.qm@web29708.mail.ird.yahoo.com>, , <60437.40903.qm@web29717.mail.ird.yahoo.com>, , <40D2C08F-4A14-43DE-B3DF-660BC2266001@cs.purdue.edu> Message-ID: Release 5.8.6 I386_DARWIN BadBricks and columns run locally don't work on MacOSX 10.5. They come up and draw reasonably, but they don't accept any mouse or keyboard input. I'll try some other versions, platforms, X servers, though I know several current don't work remotely to MacOSX 10.5. I'd be curious to hear from others. - Jay From: hosking at cs.purdue.edu Date: Thu, 30 Dec 2010 01:39:16 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] gui problems? BadBricks? columns? I know I have used them in the last year or so. On Dec 29, 2010, at 7:27 PM, Jay K wrote: >These used to work perfectly well. This is a regression. I think not in a long time. Can anyone dig around? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 30 11:13:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 10:13:47 +0000 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: References: <472423.41361.qm@web29708.mail.ird.yahoo.com>, , , <60437.40903.qm@web29717.mail.ird.yahoo.com>, , , , <40D2C08F-4A14-43DE-B3DF-660BC2266001@cs.purdue.edu>, Message-ID: LINUXLIBC6 5.4.0 just doesn't work -- its m3bundle segfaults right away.. cm3-min-POSIX-FreeBSD4-5.4.0.tgz on FreeBSD 4 the cminstall and cm3 right away hit bad syscall.. I might try bootstrapping the modern tree to FreeBSD 4 and try building 5.4.0 there... - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Thu, 30 Dec 2010 09:45:51 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] gui problems? BadBricks? columns? Release 5.8.6 I386_DARWIN BadBricks and columns run locally don't work on MacOSX 10.5. They come up and draw reasonably, but they don't accept any mouse or keyboard input. I'll try some other versions, platforms, X servers, though I know several current don't work remotely to MacOSX 10.5. I'd be curious to hear from others. - Jay From: hosking at cs.purdue.edu Date: Thu, 30 Dec 2010 01:39:16 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] gui problems? BadBricks? columns? I know I have used them in the last year or so. On Dec 29, 2010, at 7:27 PM, Jay K wrote: >These used to work perfectly well. This is a regression. I think not in a long time. Can anyone dig around? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Dec 30 12:23:14 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Dec 2010 12:23:14 +0100 Subject: [M3devel] CM3 status Message-ID: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com> Hi all, after reading a couple of Modula-3 mails again after some time of 'abstinence' I'm a little bit confused about the state of the code and the direction of development. I see that several different failures and ideas are discussed, but don't seem to get resolved; none of them is documented in our Trac instance as far as I know. Some things I remember offhand: o at least 2 different compiler/assembler problems on Darwin/Snow Leopard o current gcc not working on Solaris (?!) o stack walker code abandoned o possibly unsafe OS calls in new C code (this may be a wrong deduction from my side) o GUI input not working for BadBricks and other games (only on Darwin?) o no clean way for exception handling with current gcc o still alignment issues I'm concerned that things get tried out, don't work properly for all our target platforms, but are left then and not cleaned up and something else gets tried. I'm not sure this is correct, it is just me feeling unwell after reading all those mails. Hudson and Tinderbox status seem to be mostly OK though, but I haven't checked in detail (FreeBSD failing was a disk failure on my system recently). But the tests don't cover all the things we should check. I think it would be good to have an overview of the projects/work that is in progress or pending and its status. For example, we've imported a new gcc version, but that doesn't seem to work well on all targets, or does it? If not, how are we going to address this? Use older versions on some platforms? Can I read up on that somewhere? I'd like to suggest to simply use our Trac WiKi to document the ongoing work (everybody can get write access to that on request) and to record all errors, failures and major tasks there as issues. This should help everybody to participate and make me much more relaxed if I consider the M3 emails (if anybody should care about my personal discomfort at all :-) Just for reference: the trac instance can be found at https://projects.elego.de/cm3 Several of the committers should already have access, and using the WiKi and the issue tracker should not be much more work than writing emails. But the information will be easier to access then. I hope to have offended nobody by this; I just wanted to make a suggestion how to improve collaboration and discussion. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Dec 30 12:42:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 11:42:13 +0000 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: References: <472423.41361.qm@web29708.mail.ird.yahoo.com>,,, , <60437.40903.qm@web29717.mail.ird.yahoo.com>, ,,, , , <40D2C08F-4A14-43DE-B3DF-660BC2266001@cs.purdue.edu>, , , Message-ID: ok, well, I386_DARWIN head remoted to Cygwin/X works. Something about Mac X Server maybe. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Thu, 30 Dec 2010 10:13:47 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] gui problems? BadBricks? columns? LINUXLIBC6 5.4.0 just doesn't work -- its m3bundle segfaults right away.. cm3-min-POSIX-FreeBSD4-5.4.0.tgz on FreeBSD 4 the cminstall and cm3 right away hit bad syscall.. I might try bootstrapping the modern tree to FreeBSD 4 and try building 5.4.0 there... - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Thu, 30 Dec 2010 09:45:51 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] gui problems? BadBricks? columns? Release 5.8.6 I386_DARWIN BadBricks and columns run locally don't work on MacOSX 10.5. They come up and draw reasonably, but they don't accept any mouse or keyboard input. I'll try some other versions, platforms, X servers, though I know several current don't work remotely to MacOSX 10.5. I'd be curious to hear from others. - Jay From: hosking at cs.purdue.edu Date: Thu, 30 Dec 2010 01:39:16 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] gui problems? BadBricks? columns? I know I have used them in the last year or so. On Dec 29, 2010, at 7:27 PM, Jay K wrote: >These used to work perfectly well. This is a regression. I think not in a long time. Can anyone dig around? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Dec 30 13:04:11 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Dec 2010 13:04:11 +0100 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: References: <472423.41361.qm@web29708.mail.ird.yahoo.com>,,, , <60437.40903.qm@web29717.mail.ird.yahoo.com>, ,,, , , <40D2C08F-4A14-43DE-B3DF-660BC2266001@cs.purdue.edu>, , , Message-ID: <20101230130411.mgdi3tjdioocg40g@mail.elegosoft.com> Quoting Jay K : > > ok, well, I386_DARWIN head remoted to Cygwin/X works. > Something about Mac X Server maybe. My 2 cent (tries): % ll /usr/local/cm3/bin/BadBricks -rwxrwxr-x 1 wagner m3 3380338 19 Nov 20:37 /usr/local/cm3/bin/BadBricks* works OK. % ll /ad0e/home/hudson/work/cm3-inst/luthien/current--all-pkgs/bin/BadBricks -rwxr-xr-x 1 hudson hudson 90590 29 Dec 13:46 /ad0e/home/hudson/work/cm3-inst/luthien/current--all-pkgs/bin/BadBricks* runs, but incorrectly displays 0 for all bricks :-( Olaf > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Thu, 30 Dec 2010 10:13:47 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] gui problems? BadBricks? columns? > > > > > > > > > LINUXLIBC6 5.4.0 just doesn't work -- its m3bundle segfaults right away.. > cm3-min-POSIX-FreeBSD4-5.4.0.tgz on FreeBSD 4 the cminstall and cm3 > right away hit bad syscall.. > I might try bootstrapping the modern tree to FreeBSD 4 and try > building 5.4.0 there... > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Thu, 30 Dec 2010 09:45:51 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] gui problems? BadBricks? columns? > > > > > > > > > Release 5.8.6 I386_DARWIN BadBricks and columns run locally don't > work on MacOSX 10.5. > They come up and draw reasonably, but they don't accept any mouse or > keyboard input. > I'll try some other versions, platforms, X servers, though I know > several current don't work remotely to MacOSX 10.5. > I'd be curious to hear from others. > > - Jay > > From: hosking at cs.purdue.edu > Date: Thu, 30 Dec 2010 01:39:16 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] gui problems? BadBricks? columns? > > > > I know I have used them in the last year or so. > > > On Dec 29, 2010, at 7:27 PM, Jay K wrote: >These used to work > perfectly well. This is a regression. > > I think not in a long time. Can anyone dig around? > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Dec 30 13:01:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 12:01:39 +0000 Subject: [M3devel] CM3 status In-Reply-To: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com> References: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com> Message-ID: > o at least 2 different compiler/assembler problems on Darwin/Snow Leopard Needs more investigation. Occurs in code not in our tree, with optimization. The error message fyi is one that people occasionally see with mainline gcc also, though hopefully not in recent releases. Something about a shortage of registers. A significant codebase, not easily built, no small reproduction case yet presented or in hand. Some of the problems are in release 5.8.6 but fixed in head. But not all understood. I suggest the code be added to our CVS and be made buildable and regularly built there. > o current gcc not working on Solaris (?!) I don't know what this is referring to. Do you mean 4.5 vs. 4.3? Well, sort of but really. Keep reading. > o stack walker code abandoned Tony ok'ed this for Solaris/sparc32 a few months ago. I couldn't get it working with gcc 4.5, not even without optimization. That was the last step in moving off of gcc 4.3 backend. Alpha/OSF also doesn't work. I didn't look much into it, and I really don't think it matters. It is an extremely little used platform. This year I saw it work on 4.0 and 5.1 but otherwise it had been unused for several years I believe, and I don't see its use continuing much. Upgrade of Solaris/sparc32 from gcc 4.3 to 4.5: 2010-10-13 11:18 jkrell * m3-sys/cminstall/src/config-no-install/SPARC32_SOLARIS.common, m3-sys/m3cc/gcc/gcc/m3cg/parse.c, m3-sys/m3cc/src/clean_marker.txt, m3-sys/m3cc/src/m3makefile, m3-libs/m3core/src/runtime/m3makefile, m3-sys/m3middle/src/Target.m3, m3-libs/m3core/src/runtime/SOLgnu/m3makefile, m3-libs/m3core/src/runtime/SOLgnu/m3makefile-old, m3-libs/m3core/src/runtime/SOLsun/m3makefile, m3-libs/m3core/src/runtime/SOLsun/m3makefile-old: disable Solaris/sparc32 stack walker switch Solaris/sparc32 to gcc 4.5 backend function.c: make failure to volatilize when setjmp/vfork present an error instead of a warning add missing volatilization pin Solaris/sparc32 at -O1 in the config file as -O2/-O3 were seen to hit internal compiler errors (assertion failures) remove the "all volatile" paths from parse.c (since they were only for Solaris/sparc32's stack walker) Tony ok'ing (in my interpretation) the abandonment of our stack walker: https://mail.elegosoft.com/pipermail/m3devel/2010-October/008019.html At least that was my interpretation. Using gcc's exception handling support and *its* stack walker (libgcc/libunwind) should provide the better and more portable functionality on many platforms. I'm not certain what'd it look like on systems where gcc isn't the usual C compiler (e.g. Solaris) but it's bound to work well on Linux, NetBSD, FreeBSD, OpenBSD, and Solaris using gcc. "more portable" as in, across all architectures. Perhaps I should have stuck back with 4.3 until implementing this however. It is definitely a step backward to not have the stack walker on Solaris/sparc32, but that is the only platform in years that has had one, and it is not terrible to have every platform on gcc 4.5.2 and not sprinkling volatile around. There are some backward steps but definitely a lot forward. I tried using 5.4.0 tonight and I didn't get far. > o possibly unsafe OS calls in new C code (this may be a wrong deduction > from my side) I don't know what this is referring to. The Enable/DisableScheduling? I all but undid that. It should be in a few functions, e.g. malloc/free/realloc/calloc/opendir/readdir/closedir/fopen/fclose. Some of those it already is in. With OpenBSD moving to pthreads it matters less. It only matters for user threads. > o GUI input not working for BadBricks and other games (only on Darwin?) Yes this is still a problem, and occurs in 5.8.6 release, on Darwin local X Server. Doesn't reproduce when remoted to Cygwin/X. Other X apps do work locally. Not understood. It'd be good to get confirmation if/when they ever worked. > o no clean way for exception handling with current gcc This is how things have *always* been, *except* on Alpha/OSF and Solaris/sparc32. Those two platforms have "regressed", but for Solaris/sparc32 it was discussed and Alpha/OSF I really don't think is important. Exception handling has always been very inefficient on all but approx. those two platforms. It has always been desirable to fix. The inefficiency has a few parts. Mainly that "try" costs pthread_getspecific and setjmp. The inefficiency of the actual throw/catch is not as worrisome. > o still alignment issues Details? > I'm concerned that things get tried out, don't work properly for all > our target platforms, but are left then and not cleaned up and something > else gets tried. I'm not sure this is correct, it is just me feeling > unwell after reading all those mails. Not really. > Hudson and Tinderbox status seem to be mostly OK though, but I haven't > checked in detail (FreeBSD failing was a disk failure on my system > recently). But the tests don't cover all the things we should check. Yep I try to remember to check Hudson fairly regularly. I never look at Tinderbox though. > I think it would be good to have an overview of the projects/work that > is in progress or pending and its status. For example, we've imported > a new gcc version, but that doesn't seem to work well on all targets, > or does it? If not, how are we going to address this? Use older versions > on some platforms? Can I read up on that somewhere? All platforms (except NT386) use gcc 4.5.2 for the backend. (I did the upgrade after the release was made but before it was announced; they delay announcement while it propagates to mirrors.) Ok, also ARM_DARWIN hypothetically uses 4.2. Apple forks gcc fairly aggressively. Perhaps we should merge the two forks. Perhaps. ARM_DARWIN isn't really supported currently. Probably that should be worked on. It'd also be interesting to see what Apple did to 4.2 for ppc/x86... > I'd like to suggest to simply use our Trac WiKi to document the ongoing Agreed but I'm lazy. I just throw "bombs" around.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 30 13:19:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 12:19:08 +0000 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: <20101230130411.mgdi3tjdioocg40g@mail.elegosoft.com> References: <472423.41361.qm@web29708.mail.ird.yahoo.com>,,, , , <60437.40903.qm@web29717.mail.ird.yahoo.com>, , , , , , ,,<40D2C08F-4A14-43DE-B3DF-660BC2266001@cs.purdue.edu>, , , , , , , <20101230130411.mgdi3tjdioocg40g@mail.elegosoft.com> Message-ID: > % ll /usr/local/cm3/bin/BadBricks > -rwxrwxr-x 1 wagner m3 3380338 19 Nov 20:37 /usr/local/cm3/bin/BadBricks* > > works OK. > > % ll /ad0e/home/hudson/work/cm3-inst/luthien/current--all-pkgs/bin/BadBricks > -rwxr-xr-x 1 hudson hudson 90590 29 Dec 13:46 > /ad0e/home/hudson/work/cm3-inst/luthien/current--all-pkgs/bin/BadBricks* > > runs, but incorrectly displays 0 for all bricks :-( > Thanks. uname -a ? AMD64_FREEBSD I assume? Huh, wierd, a different seemingly recent regression. That doesn't occur for me I386_DARWIN remoted to Cygwin/X. Need to isolate it...try other platforms...? Maybe I turned optimization off on my system (lately I've been doing everything with -O3 via a local edit, but occasionally I undo that). Imho the problem I'm seeing might have been there forever. Definitely not fully understood yet. I'll try PPC_DARWIN 10.4 as that is handy... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 30 13:14:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 12:14:21 +0000 Subject: [M3devel] m3-libs/m3core/src/runtime/common/Compiler.tmpl? Message-ID: So..I spent a few minutes tonight trying to use/build an old release: 5.4.0. One of the problems I hit was building the 5.4.0 release with a current "I386_FREEBSD" compiler. One of the problems in the system, just a small number of occurences, is m3makefiles having lists of platforms, that don't have current platforms. In some ways this might be inevitable. I have however reduced the problem by using lists of OS (Linux, FreeBSD, etc.) and processor architecture (x86, AMD64, SPARC32, etc.). So new combinations thereof don't require visiting so many places. However this reminded me of something that has bugged me a bit. In m3core: INTERFACE Compiler; (* this is generated by quake code *) enum OS = { POSIX, WIN32} not so bad, hasn't changed in over 10 years enum Platform = { big list of all targets } changes whenever a target is added, fairly often CONST ThisOS = OS.POSIX or OS.WIN32 not so bad CONST ThisPlatform:Platform = ... a small problem, the subject here CONST ThisPlatform_String:TEXT = "..."; not a problem I'd like to remove the enum Platform and ThisPlatform. This increases portability in terms of the ability of older/newer cm3 to build newer/older cm3. i.e...I guess...just...for a cm3 hosted on a renamed platform (I386_LINUX vs. LINUXLIBC6, etc.) It also is one less file to edit when adding a new target. Ideally that number is just one file, though currently it is a few. I'll try it out, see if anything in our tree uses it. Any uses are probably suspicious anyway. Perhaps we should provide the two smaller "composed" enums rename ThisOS to ThisOSType then ThisOS in {Linux, OpenBSD, FreeBSD, Solaris, etc.} and ThisProcessorArchitecture in {x86, AMD64, sparc32, etc.} (possibly x86, sparc, powerpc, and then can check BITSIZE(INTEGER) to get 32/64). The one place I knew of that used this stuff I changed to do something else -- use quake code to produce true/false. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 30 13:26:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 12:26:26 +0000 Subject: [M3devel] CM3 status In-Reply-To: References: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com>, Message-ID: > Alpha/OSF also doesn't work Clarification -- the target works, but not its stack walker. I moved it back to setjmp/longjmp a few months ago when an Alpha/OSF machine was presented to me, when the stack walker didn't work on the first try. This stuff is fairly difficult to debug, reading the Alpha or Sparc assembly to find the mistakes in it, and the payoff is very small... - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Thu, 30 Dec 2010 12:01:39 +0000 Subject: Re: [M3devel] CM3 status > o at least 2 different compiler/assembler problems on Darwin/Snow Leopard Needs more investigation. Occurs in code not in our tree, with optimization. The error message fyi is one that people occasionally see with mainline gcc also, though hopefully not in recent releases. Something about a shortage of registers. A significant codebase, not easily built, no small reproduction case yet presented or in hand. Some of the problems are in release 5.8.6 but fixed in head. But not all understood. I suggest the code be added to our CVS and be made buildable and regularly built there. > o current gcc not working on Solaris (?!) I don't know what this is referring to. Do you mean 4.5 vs. 4.3? Well, sort of but really. Keep reading. > o stack walker code abandoned Tony ok'ed this for Solaris/sparc32 a few months ago. I couldn't get it working with gcc 4.5, not even without optimization. That was the last step in moving off of gcc 4.3 backend. Alpha/OSF also doesn't work. I didn't look much into it, and I really don't think it matters. It is an extremely little used platform. This year I saw it work on 4.0 and 5.1 but otherwise it had been unused for several years I believe, and I don't see its use continuing much. Upgrade of Solaris/sparc32 from gcc 4.3 to 4.5: 2010-10-13 11:18 jkrell * m3-sys/cminstall/src/config-no-install/SPARC32_SOLARIS.common, m3-sys/m3cc/gcc/gcc/m3cg/parse.c, m3-sys/m3cc/src/clean_marker.txt, m3-sys/m3cc/src/m3makefile, m3-libs/m3core/src/runtime/m3makefile, m3-sys/m3middle/src/Target.m3, m3-libs/m3core/src/runtime/SOLgnu/m3makefile, m3-libs/m3core/src/runtime/SOLgnu/m3makefile-old, m3-libs/m3core/src/runtime/SOLsun/m3makefile, m3-libs/m3core/src/runtime/SOLsun/m3makefile-old: disable Solaris/sparc32 stack walker switch Solaris/sparc32 to gcc 4.5 backend function.c: make failure to volatilize when setjmp/vfork present an error instead of a warning add missing volatilization pin Solaris/sparc32 at -O1 in the config file as -O2/-O3 were seen to hit internal compiler errors (assertion failures) remove the "all volatile" paths from parse.c (since they were only for Solaris/sparc32's stack walker) Tony ok'ing (in my interpretation) the abandonment of our stack walker: https://mail.elegosoft.com/pipermail/m3devel/2010-October/008019.html At least that was my interpretation. Using gcc's exception handling support and *its* stack walker (libgcc/libunwind) should provide the better and more portable functionality on many platforms. I'm not certain what'd it look like on systems where gcc isn't the usual C compiler (e.g. Solaris) but it's bound to work well on Linux, NetBSD, FreeBSD, OpenBSD, and Solaris using gcc. "more portable" as in, across all architectures. Perhaps I should have stuck back with 4.3 until implementing this however. It is definitely a step backward to not have the stack walker on Solaris/sparc32, but that is the only platform in years that has had one, and it is not terrible to have every platform on gcc 4.5.2 and not sprinkling volatile around. There are some backward steps but definitely a lot forward. I tried using 5.4.0 tonight and I didn't get far. > o possibly unsafe OS calls in new C code (this may be a wrong deduction > from my side) I don't know what this is referring to. The Enable/DisableScheduling? I all but undid that. It should be in a few functions, e.g. malloc/free/realloc/calloc/opendir/readdir/closedir/fopen/fclose. Some of those it already is in. With OpenBSD moving to pthreads it matters less. It only matters for user threads. > o GUI input not working for BadBricks and other games (only on Darwin?) Yes this is still a problem, and occurs in 5.8.6 release, on Darwin local X Server. Doesn't reproduce when remoted to Cygwin/X. Other X apps do work locally. Not understood. It'd be good to get confirmation if/when they ever worked. > o no clean way for exception handling with current gcc This is how things have *always* been, *except* on Alpha/OSF and Solaris/sparc32. Those two platforms have "regressed", but for Solaris/sparc32 it was discussed and Alpha/OSF I really don't think is important. Exception handling has always been very inefficient on all but approx. those two platforms. It has always been desirable to fix. The inefficiency has a few parts. Mainly that "try" costs pthread_getspecific and setjmp. The inefficiency of the actual throw/catch is not as worrisome. > o still alignment issues Details? > I'm concerned that things get tried out, don't work properly for all > our target platforms, but are left then and not cleaned up and something > else gets tried. I'm not sure this is correct, it is just me feeling > unwell after reading all those mails. Not really. > Hudson and Tinderbox status seem to be mostly OK though, but I haven't > checked in detail (FreeBSD failing was a disk failure on my system > recently). But the tests don't cover all the things we should check. Yep I try to remember to check Hudson fairly regularly. I never look at Tinderbox though. > I think it would be good to have an overview of the projects/work that > is in progress or pending and its status. For example, we've imported > a new gcc version, but that doesn't seem to work well on all targets, > or does it? If not, how are we going to address this? Use older versions > on some platforms? Can I read up on that somewhere? All platforms (except NT386) use gcc 4.5.2 for the backend. (I did the upgrade after the release was made but before it was announced; they delay announcement while it propagates to mirrors.) Ok, also ARM_DARWIN hypothetically uses 4.2. Apple forks gcc fairly aggressively. Perhaps we should merge the two forks. Perhaps. ARM_DARWIN isn't really supported currently. Probably that should be worked on. It'd also be interesting to see what Apple did to 4.2 for ppc/x86... > I'd like to suggest to simply use our Trac WiKi to document the ongoing Agreed but I'm lazy. I just throw "bombs" around.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 30 13:55:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 12:55:31 +0000 Subject: [M3devel] cross builds and netobj/proxy generation Message-ID: I found this problem trying to build Mika's Scheme implementation I hadn't rebuilt all tools to be I386_DARWIN -- some were still AMD64_DARWIN. It seems the proxy code got values for LAST(INTEGER) in it, but they were for the host, not the target. Tools need to not assume they are the same... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 30 15:28:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 14:28:31 +0000 Subject: [M3devel] factoring jmpbuf size via alloca(global constant)? Message-ID: factoring out jmpbuf size? Hey, um, how about something like this: somefile.c: #include extern const int sizeof_jmpbuf = sizeof(jmp_buf); where the frontend would allocate a local jmp_buf, instead issue a call to alloca(sizeof_jmpbuf), actually reading the constant out of the global. Yes I know this is a deoptimization. It is already slow. We hope hope hope to replace it all anyway. This would remove lots of target-specific code in Target.m3. Related, I'm again trying removing from m3core the knowledge of the size/alignment of jmpbuf. Or rather, to see if it really needs it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dknoto at next.com.pl Thu Dec 30 20:09:53 2010 From: dknoto at next.com.pl (Dariusz =?ISO-8859-2?Q?Knoci=F1ski?=) Date: Thu, 30 Dec 2010 20:09:53 +0100 Subject: [M3devel] Array indexing Message-ID: <20101230200953.1b229a27.dknoto@next.com.pl> Hi all, my name is Dariusz Knoci?ski, I am new in this list, it is my first letter. Best wishes for New Year to all. I have a problem with two-dimensional arrays. In my simple source code I can't get value from array indexed by two variables. But, I can get these values by indexing by constants. The program compile successfully but generates idiotic output. Source: MODULE aib EXPORTS Main; IMPORT IO, Fmt; CONST tab = ARRAY [0..2], [0..15] OF CARDINAL { ARRAY OF CARDINAL { 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17 }, ARRAY OF CARDINAL { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 17, 17, 17, 17, 17, 17 }, ARRAY OF CARDINAL { 17, 11, 12, 13, 14, 15, 16, 17, 17, 17, 17, 17, 17, 17, 17, 17 } }; VAR k, l : CARDINAL; BEGIN k := 1; l := 9; IO.Put( "k = " & Fmt.Int(k) & ", " ); IO.Put( "l = " & Fmt.Int(l) & "\n" ); k := tab[k][l]; IO.Put( "k = tab[k][l] => 0x" & Fmt.F( "%02s", Fmt.Unsigned(k)) & "\n" ); k := tab[1][9]; IO.Put( "k = tab[1][9] => 0x" & Fmt.F( "%02s", Fmt.Unsigned(k)) & "\n" ); FOR i := 0 TO 2 DO FOR j := 0 TO 15 DO IO.Put( Fmt.F( " %02s", Fmt.Int( tab[i][j] ) ) ); END; IO.Put( "\n" ); END; END aib. Output: k = 1, l = 9 k = tab[k][l] => 0x00 k = tab[1][9] => 0x0a 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 My system and compiler version is: $ uname -a Linux wenus.next.com.pl 2.6.35.10-74.fc14.x86_64 #1 SMP Thu Dec 23 16:04:50\ UTC 2010 x86_64 x86_64 x86_64 GNU/Linux $ cm3 -version Critical Mass Modula-3 version 5.8.6 last updated: 2010-04-11 compiled: 2010-07-12 20:10:34 configuration: /usr/local/cm3/bin/cm3.cfg host: AMD64_LINUX target: AMD64_LINUX or Critical Mass Modula-3 version d5.9.0 last updated: 2010-07-21 compiled: 2010-12-16 03:15:26 configuration: /usr/local/cm3/bin/cm3.cfg host: AMD64_LINUX quake runtime error: "/usr/local/cm3/bin/cm3.cfg", line 2: quake runtime error:\ undefined variable: SL --procedure-- -line- -file--- 2 /usr/local/cm3/bin/cm3.cfg target: Both compilers generate same results. Best regards DKnoto. From rodney_bates at lcwb.coop Thu Dec 30 21:12:22 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 30 Dec 2010 14:12:22 -0600 Subject: [M3devel] Array indexing In-Reply-To: <20101230200953.1b229a27.dknoto@next.com.pl> References: <20101230200953.1b229a27.dknoto@next.com.pl> Message-ID: <4D1CE7A6.4050409@lcwb.coop> I reproduced this immediately on LINUXLIBC6 and AMD64_LINUX. It's a compiler bug. A version of cm3 several years old, and an old pm3, both with the (much older) gcc backend and the x86 internal backend also all show the same problem. The memory area for each row of tab is getting initialized with dope for an open array, instead of the actual values. Moreover, the dope is not right either, though it's recognizable. Since the open array row constructor is assignable to the fixed array row of tab, the code is correct and the compiler should take care of the representation change. Making tab a VAR instead of CONST shows the same bad behavior. As a workaround, you can change the row constructors to fixed array constructors: CONST tab = ARRAY [0..2], [0..15] OF CARDINAL { ARRAY [0..15] OF CARDINAL { 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17 }, ARRAY [0..15] OF CARDINAL { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 17, 17, 17, 17, 17, 17 }, ARRAY [0..15] OF CARDINAL { 17, 11, 12, 13, 14, 15, 16, 17, 17, 17, 17, 17, 17, 17, 17, 17 } }; and this works as expected: (m3gdb) run Starting program: /home/rodney/proj/m3/exp/dknoto/AMD64_LINUX/prog Can't disable VM GC. Signal Stop Print Pass to program Description SIG64 No No Yes Real-time event 64 [Thread debugging using libthread_db enabled] [New LWP 9108] k = 1, l = 9 k = tab[k][l] => 0x0a k = tab[1][9] => 0x0a 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 01 02 03 04 05 06 07 08 09 10 17 17 17 17 17 17 17 11 12 13 14 15 16 17 17 17 17 17 17 17 17 17 Program exited normally. (m3gdb) Amazing that in all these years, nobody has coded a 2-D array constructor this way before, or at least didn't complain. Rodney Bates Dariusz Knoci?ski wrote: > Hi all, > > my name is Dariusz Knoci?ski, I am new in this list, it is my first letter. > Best wishes for New Year to all. > > I have a problem with two-dimensional arrays. In my simple source code I can't > get value from array indexed by two variables. But, I can get these values by > indexing by constants. The program compile successfully but generates idiotic > output. > > Source: > > MODULE aib EXPORTS Main; > > IMPORT IO, Fmt; > > CONST > tab = ARRAY [0..2], [0..15] OF CARDINAL { > ARRAY OF CARDINAL > { 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17 }, > ARRAY OF CARDINAL > { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 17, 17, 17, 17, 17, 17 }, > ARRAY OF CARDINAL > { 17, 11, 12, 13, 14, 15, 16, 17, 17, 17, 17, 17, 17, 17, 17, 17 } > }; > > VAR > k, l : CARDINAL; > > BEGIN > > k := 1; > l := 9; > > IO.Put( "k = " & Fmt.Int(k) & ", " ); > IO.Put( "l = " & Fmt.Int(l) & "\n" ); > k := tab[k][l]; > IO.Put( "k = tab[k][l] => 0x" & > Fmt.F( "%02s", Fmt.Unsigned(k)) & "\n" ); > > k := tab[1][9]; > IO.Put( "k = tab[1][9] => 0x" & > Fmt.F( "%02s", Fmt.Unsigned(k)) & "\n" ); > > FOR i := 0 TO 2 DO > FOR j := 0 TO 15 DO > IO.Put( Fmt.F( " %02s", Fmt.Int( tab[i][j] ) ) ); > END; > IO.Put( "\n" ); > END; > > END aib. > > Output: > > k = 1, l = 9 > k = tab[k][l] => 0x00 > k = tab[1][9] => 0x0a > 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > My system and compiler version is: > > $ uname -a > > Linux wenus.next.com.pl 2.6.35.10-74.fc14.x86_64 #1 SMP Thu Dec 23 16:04:50\ > UTC 2010 x86_64 x86_64 x86_64 GNU/Linux > > $ cm3 -version > > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-12 20:10:34 > configuration: /usr/local/cm3/bin/cm3.cfg > host: AMD64_LINUX > target: AMD64_LINUX > > or > > Critical Mass Modula-3 version d5.9.0 > last updated: 2010-07-21 > compiled: 2010-12-16 03:15:26 > configuration: /usr/local/cm3/bin/cm3.cfg > host: AMD64_LINUX > quake runtime error: "/usr/local/cm3/bin/cm3.cfg", line 2: quake runtime error:\ > undefined variable: SL > > --procedure-- -line- -file--- > 2 /usr/local/cm3/bin/cm3.cfg > target: > > Both compilers generate same results. > > Best regards > DKnoto. > From dknoto at next.com.pl Thu Dec 30 22:17:19 2010 From: dknoto at next.com.pl (Dariusz =?ISO-8859-2?Q?Knoci=F1ski?=) Date: Thu, 30 Dec 2010 22:17:19 +0100 Subject: [M3devel] Array indexing In-Reply-To: <4D1CE7A6.4050409@lcwb.coop> References: <20101230200953.1b229a27.dknoto@next.com.pl> <4D1CE7A6.4050409@lcwb.coop> Message-ID: <20101230221719.85e9d885.dknoto@next.com.pl> On Thu, 30 Dec 2010 14:12:22 -0600 "Rodney M. Bates" wrote: [...] > As a workaround, you can change the row constructors to fixed array constructors: > > CONST > tab = ARRAY [0..2], [0..15] OF CARDINAL { > ARRAY [0..15] OF CARDINAL > { 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17 }, > ARRAY [0..15] OF CARDINAL > { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 17, 17, 17, 17, 17, 17 }, > ARRAY [0..15] OF CARDINAL > { 17, 11, 12, 13, 14, 15, 16, 17, 17, 17, 17, 17, 17, 17, 17, 17 } > }; > Thankyou very much for workaround. > Amazing that in all these years, nobody has coded a 2-D array constructor this > way before, or at least didn't complain. > > Code similar to this I found on pages in tutorial, in chapter "Array Constructor": tictactoe := ARRAY [1..3], [1..3] OF CHAR{ ARRAY OF CHAR{' ', ' ', ' '}, ARRAY OF CHAR{' ', ' ', ' '}, ARRAY OF CHAR{' ', ' ', ' '} }; Best regards Dariusz Knoci?ski. From dabenavidesd at yahoo.es Thu Dec 30 22:31:04 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 30 Dec 2010 21:31:04 +0000 (GMT) Subject: [M3devel] Array indexing In-Reply-To: <4D1CE7A6.4050409@lcwb.coop> Message-ID: <280842.77354.qm@web29702.mail.ird.yahoo.com> Hi all: it seems the same to me, perhaps this uncovered bug has been there for years or a systematic problem, we would need to apply verification for the compiler intermediate code generation, though might be a problem in the code generation, we don't know, it should be provable that for a given input the Modula-3 compiler will gave the same intermediate code, this would open also a door for optimization, like in HP, was built a compiler like that, it will take some time, but eventually, before we can believe it, we may have the compiler specified front end (still if it were 100000 lines verifying would take 60 years/man, if its 10000, 6 years/man), like the Hoare utopia was to built itself. So between more correct more efficient! --- El jue, 30/12/10, Rodney M. Bates escribi?: > De: Rodney M. Bates > Asunto: Re: [M3devel] Array indexing > Para: "Dariusz Knoci?ski" > CC: m3devel at elegosoft.com > Fecha: jueves, 30 de diciembre, 2010 15:12 > I reproduced this immediately on > LINUXLIBC6 and AMD64_LINUX. It's a compiler bug. > A version of cm3 several years old, and an old pm3, both > with the (much older) > gcc backend and the x86 internal backend also all show the > same problem. > > The memory area for each row of tab is getting initialized > with dope for an > open array, instead of the actual values. Moreover, > the dope is not right > either, though it's recognizable. Since the open > array row constructor is > assignable to the fixed array row of tab, the code is > correct and the compiler > should take care of the representation change. > > Making tab a VAR instead of CONST shows the same bad > behavior. > > As a workaround, you can change the row constructors to > fixed array constructors: > > CONST > tab = ARRAY [0..2], [0..15] OF CARDINAL { > ARRAY [0..15] OF CARDINAL > { 17, 17, 17, 17, 17, 17, > 17, 17, 17, 17, 17, 17, 17, 17, 17, 17 }, > ARRAY [0..15] OF CARDINAL > { 1, 2, > 3, 4, 5, 6, 7, 8, 9, 10, > 17, 17, 17, 17, 17, 17 }, > ARRAY [0..15] OF CARDINAL > { 17, 11, 12, 13, 14, 15, > 16, 17, 17, 17, 17, 17, 17, 17, 17, 17 } > }; > > and this works as expected: > > (m3gdb) run > Starting program: > /home/rodney/proj/m3/exp/dknoto/AMD64_LINUX/prog > Can't disable VM GC. > Signal Stop > Print Pass to program Description > SIG64 No > No Yes > Real-time event 64 > [Thread debugging using libthread_db enabled] > [New LWP 9108] > k = 1, l = 9 > k = tab[k][l] => 0x0a > k = tab[1][9] => 0x0a > 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 > 01 02 03 04 05 06 07 08 09 10 17 17 17 17 17 17 > 17 11 12 13 14 15 16 17 17 17 17 17 17 17 17 17 > > Program exited normally. > (m3gdb) > > Amazing that in all these years, nobody has coded a 2-D > array constructor this > way before, or at least didn't complain. > > > Rodney Bates > > > Dariusz Knoci?ski wrote: > > Hi all, > > > > my name is Dariusz Knoci?ski, I am new in this list, > it is my first letter. > > Best wishes for New Year to all. > > > > I have a problem with two-dimensional arrays. In my > simple source code I can't > > get value from array indexed by two variables. But, I > can get these values by > > indexing by constants. The program compile > successfully but generates idiotic > > output. > > > > Source: > > > > MODULE aib EXPORTS Main; > > > > IMPORT IO, Fmt; > > > > CONST > > tab = ARRAY [0..2], [0..15] OF > CARDINAL { > > ARRAY OF CARDINAL > > { 17, 17, 17, 17, 17, > 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17 }, > > ARRAY OF CARDINAL > { 1, 2, > 3, 4, 5, 6, 7, 8, 9, 10, > 17, 17, 17, 17, 17, 17 }, > > ARRAY OF CARDINAL > { 17, 11, 12, 13, 14, 15, > 16, 17, 17, 17, 17, 17, 17, 17, 17, 17 } > > }; > > > > VAR > > k, l : CARDINAL; > > > > BEGIN > > > > k := 1; > > l := 9; > > > > IO.Put( "k = " & > Fmt.Int(k) & ", " ); > > IO.Put( "l = " & > Fmt.Int(l) & "\n" ); > > k := > tab[k][l]; > > IO.Put( "k = tab[k][l] => > 0x" & Fmt.F( "%02s", Fmt.Unsigned(k)) > & "\n" ); > > > > k := tab[1][9]; > > IO.Put( "k = > tab[1][9] => 0x" & > Fmt.F( "%02s", Fmt.Unsigned(k)) & > "\n" ); > > > > FOR i := 0 TO 2 DO > > FOR j := 0 TO 15 DO > > IO.Put( Fmt.F( " > %02s", Fmt.Int( tab[i][j] ) ) ); > > END; > > IO.Put( "\n" ); > > END; > > > > END aib. > > > > Output: > > > > k = 1, l = 9 > > k = tab[k][l] => 0x00 > > k = tab[1][9] => 0x0a > > 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 > > 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 > > 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 > > > > My system and compiler version is: > > > > $ uname -a > > > > Linux wenus.next.com.pl 2.6.35.10-74.fc14.x86_64 #1 > SMP Thu Dec 23 16:04:50\ > > UTC 2010 x86_64 x86_64 x86_64 > GNU/Linux > > $ cm3 -version > > > > Critical Mass Modula-3 version 5.8.6 > > last updated: 2010-04-11 > > compiled: 2010-07-12 20:10:34 > > configuration: > /usr/local/cm3/bin/cm3.cfg > > host: AMD64_LINUX > > target: AMD64_LINUX > > > > or > > > > Critical Mass Modula-3 version d5.9.0 > > last updated: 2010-07-21 > > compiled: 2010-12-16 03:15:26 > > configuration: > /usr/local/cm3/bin/cm3.cfg > > host: AMD64_LINUX > > quake runtime error: "/usr/local/cm3/bin/cm3.cfg", > line 2: quake runtime error:\ > > undefined variable: SL > > > > --procedure-- -line- -file--- > > > 2 /usr/local/cm3/bin/cm3.cfg > > target: > > Both compilers generate same results. > > > > Best regards > > DKnoto. > > > From dknoto at next.com.pl Thu Dec 30 23:14:42 2010 From: dknoto at next.com.pl (Dariusz =?UTF-8?B?S25vY2nFhHNraQ==?=) Date: Thu, 30 Dec 2010 23:14:42 +0100 Subject: [M3devel] Interpretation of numbers Message-ID: <20101230231442.2f3ee9a3.dknoto@next.com.pl> Hi all, in my spare time I write a lexer to Modula-3 for Scintilla library and I found mistake in numeric constants with explicitly given base number system, eg. octal numbers. This simple program in C generates compiler error: #include int main( void ) { unsigned o; o = 0787; printf( "o = %u\n", o ); return 0; } in gcc 4.5.1 20100924 (Red Hat 4.5.1-4) this is: Numbers.c: In function ?main?: Numbers.c:7:6: error: invalid digit "8" in octal constant but CM3 with analogical program: MODULE Numbers EXPORTS Main; IMPORT IO, Fmt; VAR o : CARDINAL; BEGIN o := 8_787; IO.Put( "o = 8_" & Fmt.Unsigned( o, 8 ) & "\n" ); END Numbers. compiles his properly and the program generate output: o = 8_1007 This is correct number, 519 decimal, but similar mistakes can be difficult to find. Best regards Dariusz Knoci?ski. From rcolebur at SCIRES.COM Thu Dec 30 23:29:50 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Thu, 30 Dec 2010 17:29:50 -0500 Subject: [M3devel] CM3 status In-Reply-To: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com> References: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com> Message-ID: Olaf et al: I think I share the concern you've voiced. My observation from the M3COMMIT log emails is that Jay seems to be the most prolific these days with changes, but I find it impossible to keep track of what problem he is trying to solve. Indeed, it seems he is working on multiple issues at the same time, but it is difficult from the posts to differentiate which issue goes with which posting, and this problem is compounded by the fact that my M3COMMIT/M3DEVEL e-mails don't always seem to be received in chronological order. Thus, it is extremely difficult to know how to channel the limited time I have available into helping cooperate to solve a particular problem. Maybe it would be a good idea when each person posts something to M3COMMIT or M3DEVEL that they tag it up front with a comment or reference to the problem the post is addressing. Another idea, and perhaps your TRAC system supports it, is to assign certain problems to specific individuals who work the problem and report back their solution approach for some type of concurrence before going off on a tangent to solve. This might cut down on some of the subsequent backtracking and reverting changes. It would also allow others to offer constructive comments on the solution approach, even if they don't have time to actually implement the solution. [In reading the posts, I'm seeing many places where work is done, then later someone disagrees with it, and wants the changes reverted.] Even if one person is assigned as the lead for a particular problem, perhaps others could join in on helping solve it, coordinating their effort thru the lead person. I really do want to help as much as I can, and we definitely need to grow the development support base, so anything we can do to foster teamwork and an up-to-date awareness of the major problem areas and proposed solution paths would be helpful I think. I certainly don't want to squash anyone's individual efforts, but right now I don't think we're maximizing our use of the team concept. Regards, Randy Coleburn -----Original Message----- From: Olaf Wagner [mailto:wagner at elegosoft.com] Sent: Thursday, December 30, 2010 6:23 AM To: m3devel at elegosoft.com Subject: [M3devel] CM3 status Hi all, after reading a couple of Modula-3 mails again after some time of 'abstinence' I'm a little bit confused about the state of the code and the direction of development. I see that several different failures and ideas are discussed, but don't seem to get resolved; none of them is documented in our Trac instance as far as I know. Some things I remember offhand: o at least 2 different compiler/assembler problems on Darwin/Snow Leopard o current gcc not working on Solaris (?!) o stack walker code abandoned o possibly unsafe OS calls in new C code (this may be a wrong deduction from my side) o GUI input not working for BadBricks and other games (only on Darwin?) o no clean way for exception handling with current gcc o still alignment issues I'm concerned that things get tried out, don't work properly for all our target platforms, but are left then and not cleaned up and something else gets tried. I'm not sure this is correct, it is just me feeling unwell after reading all those mails. Hudson and Tinderbox status seem to be mostly OK though, but I haven't checked in detail (FreeBSD failing was a disk failure on my system recently). But the tests don't cover all the things we should check. I think it would be good to have an overview of the projects/work that is in progress or pending and its status. For example, we've imported a new gcc version, but that doesn't seem to work well on all targets, or does it? If not, how are we going to address this? Use older versions on some platforms? Can I read up on that somewhere? I'd like to suggest to simply use our Trac WiKi to document the ongoing work (everybody can get write access to that on request) and to record all errors, failures and major tasks there as issues. This should help everybody to participate and make me much more relaxed if I consider the M3 emails (if anybody should care about my personal discomfort at all :-) Just for reference: the trac instance can be found at https://projects.elego.de/cm3 Several of the committers should already have access, and using the WiKi and the issue tracker should not be much more work than writing emails. But the information will be easier to access then. I hope to have offended nobody by this; I just wanted to make a suggestion how to improve collaboration and discussion. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Thu Dec 30 23:55:39 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 30 Dec 2010 14:55:39 -0800 Subject: [M3devel] cross builds and netobj/proxy generation In-Reply-To: References: Message-ID: <20101230225539.0B9A91A205B@async.async.caltech.edu> This is probably a bug in my code, actually. I should represent LAST(INTEGER) as LAST(INTEGER) and not as whatever it evaluates to. Although hm the evaluation probably comes from inside m3tk. That is how m3tk represents subranges (including the "subrange" FIRST(INTEGER)..LAST(INTEGER)). Mika Jay K writes: >--_a816f733-bbaf-451a-ba85-0ff058a4a08f_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >I found this problem trying to build Mika's Scheme implementation >I hadn't rebuilt all tools to be I386_DARWIN -- some were still AMD64_DARWI= >N. >It seems the proxy code got values for LAST(INTEGER) in it=2C but they >were for the host=2C not the target. >Tools need to not assume they are the same... > > > - Jay > = > >--_a816f733-bbaf-451a-ba85-0ff058a4a08f_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >I found this problem trying to build Mika's Scheme implementation
I hadn= >'t rebuilt all tools to be I386_DARWIN -- some were still AMD64_DARWIN.
= >It seems the proxy code got values for LAST(INTEGER) in it=2C but they
w= >ere for the host=2C not the target.
Tools need to not assume they are th= >e same...


 =3B- Jay
> >= > >--_a816f733-bbaf-451a-ba85-0ff058a4a08f_-- From mika at async.caltech.edu Thu Dec 30 23:58:27 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 30 Dec 2010 14:58:27 -0800 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , , Message-ID: <20101230225827.B99371A205B@async.async.caltech.edu> All right, I have been able to whittle down a test for the "code generation error": INTERFACE CG_Error; END CG_Error. MODULE CG_Error; TYPE SchemeObject_T = REFANY; EXCEPTION Scheme_E; PROCEDURE ToScheme_VAL0LONGINT__VAL0LONGINT(READONLY x : [ VAL(0, LONGINT )..VAL(0, LONGINT ) ]) : SchemeObject_T RAISES { Scheme_E } = BEGIN RETURN ToScheme_LONGINT(x) END ToScheme_VAL0LONGINT__VAL0LONGINT; PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject_T RAISES { Scheme_E } = BEGIN WITH ref = NEW(REF LONGINT) DO ref^ := x; END END ToScheme_LONGINT; BEGIN END CG_Error. new source -> compiling CG_Error.i3 new source -> compiling CG_Error.m3 "../src/CG_Error.m3", line 12: warning: exception is never raised: CG_Error.Scheme_E "../src/CG_Error.m3", line 6: warning: not used (ToScheme_VAL0LONGINT__VAL0LONGINT) "../src/CG_Error.m3", line 15: warning: function may not return a value (ToScheme_LONGINT) "../src/CG_Error.m3", line 1: 1 code generation error 1 error and 3 warnings encountered Mika From dabenavidesd at yahoo.es Fri Dec 31 00:13:57 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 30 Dec 2010 23:13:57 +0000 (GMT) Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: <20101230032636.GA31254@topoi.pooq.com> Message-ID: <206460.28608.qm@web29714.mail.ird.yahoo.com> Hi all: it makes and abstraction of the code in terms of Guarded commands of Dijkstra, then applies the static checking of the calculus of weakest preconditions type checking as a normal program too the code and then translates to first order logic formulae, if the annotated program can be satisfied then it will give no output, but if does prove that the program doesn't produce the anottated output, it will complain on where it fails, wherever it doesn't like the proof. The important thing is that if the checker satisfies all of his conditions, it doesn't mean it does not break, i.e it could be that the checker will no complain but still can't prove absolutely that is not to crash, is a kind of liberal, perhaps because of its logic calculus. There is also the case of possible false alarms, which could be triggered, but this is almost the case in any compiler and here too, even the M3 compiler (something called completeness, just very simple known type systems have), so we can't expect to type check in the semantic analyser it wrong and to accept it in the checker, but we could instead just to make that a unsound program, lets say unsafe, will not lock or crash because and specific error because of the non-completeness issue. However the ESC didn't accept some special kind of almost safe programs, recursive, partly I believe because of a problem exposed below, is perhaps that the program doesn't end, unlike a for loop. There is also the need of a efficient and smarter automatic theorem prover, Simplify is one of the best available for some time now, but still, the same problems arise on it, it could be that because of the first order logic, the program could not terminate but the prover believe it will and it apparently does it, but that its proofs will be not totally proved for all cases, if so, then we would need to take care of those by applying hand formal verification measures like below I explain a case. Also Simplify could rise that he can't prove that something is not provable by itself, but turn that it is doable, just that it can't by its own, so we need to also verify those cases. In the end, the best case our checks will end, but sometimes, the first order logic could be an endless proof or undefined, in those cases we would need a threshold given by the experience, so we might start sooner than later to make our own. The best of this is that are many things that have room for improvement as Dr Greg Nelson told me some time ago, would be nice thing to have the TODO list from him. My personal wish is to make Modula-3 totally verifiable, learning this by hand would be harder, but by the tools we could make it for using its internal logic, the most critical part, the Professor Greg Nelson did some work on that part of that I believe. Then the important parts are the semantic checker which it self is built on its internal logic, e.g a biased logic (i.e an unsound one, the proofs could not end or be too large to finish and unable to realize that after it spends time on it) it could be that never ends a proof or check it badly as good, the most perfect it checks it would be less efficient at some point (perhaps this was the reason to not check the total correctness besides the effort needed) so might be easier to pass the checks but less profitable in the checking. I really would like the most inner parts to be self provable, like more functional style programming then, but those are not verifiable by the ESC checker, it just doesn't do that, similar to when I had a problem on the checker I used sasylf.org, it had unimplemented the mutual induction proving part by that time of a course back in 2008, this is a theorem proof technique you need to use in advanced type theory of type system soundness proofs, sasylf is a programming language by itself to proof it is sound, so it turns out that if we can trust on them more than in any part of the checker we could move on from there to more advanced techniques, also this is harder I believe based on my small experience of type systems proofing. ESC developers say, the most provable source of those mis-checkings is automatic theorem prover, not in checker, then it might be more valuable to start there than in the checker's logic by itself, being more practical, more pragmatic. I have some experience with the use of automatic theorem provers part use by hand with sasylf, writing the proofs and let it check for one (say I was the ESC checker and sasylf was the automatic theorem prover), and it turns out not to be so difficult to use after some work and time of use, still there are many challenges open in the checkers for now, so the room for improvements there is also too big (i.e we can check more things, say, the Modula-3 arithmetic over and/or under flow, recurrence, by improving the core logic calculus and later working on the "second pass" or backend first order logic prover). A special feature was the Locking level notation developed by writing the Trestle library, as it was coded threaded, it is perhaps the most advanced part of it, more details than that I don't now, but more probably coming on the way. I just know its logic is more advanced from what I recall, it requires some clever reasoning and calculus too I guess. So we can have a lot discussion, perhaps the first kick is given now. I also hope its not too much blah, ... sorry for the long message Thanks in advance --- El mi?, 29/12/10, Hendrik Boom escribi?: > De: Hendrik Boom > Asunto: Re: [M3devel] gui problems? BadBricks? columns? > Para: m3devel at elegosoft.com > Fecha: mi?rcoles, 29 de diciembre, 2010 22:26 > On Wed, Dec 29, 2010 at 08:23:12PM > -0500, Coleburn, Randy wrote: > > Daniel et al: > > > > I tried a year or so ago to pursue getting the sources > for the ESC. > > I'd have to dig up my old emails, but my recollection > is that I ran into a dead end getting the sources and the > permission to put them in our repository. > > I don't think the Modula-3 edition was kept up when > the project moved on to other languages. > > What does the ESC do that's relevant to threading? I > mean, not just an > answer like "deadlock and race detection", but what > algorithms does it > use to accomplish it? Does the Modula 3 compiler > construct the proper > data structures that could provide the raw data those > algorithms would > need? How much work would it be to reimplement this > from scratch? > > -- hendrik > From hendrik at topoi.pooq.com Fri Dec 31 02:57:43 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 30 Dec 2010 20:57:43 -0500 Subject: [M3devel] ESC In-Reply-To: <206460.28608.qm@web29714.mail.ird.yahoo.com> References: <20101230032636.GA31254@topoi.pooq.com> <206460.28608.qm@web29714.mail.ird.yahoo.com> Message-ID: <20101231015743.GA17628@topoi.pooq.com> On Thu, Dec 30, 2010 at 11:13:57PM +0000, Daniel Alejandro Benavides D. wrote: > Hi all: > it makes and abstraction of the code in terms of Guarded commands of > Dijkstra, then applies the static checking of the calculus of weakest > preconditions type checking as a normal program too the code This will be difficult for loops. Dijkstra's formalism more or less requires a variant to decrease around the loop. In fact, in his "A Discipline of Programming", he shows multiple examples where the choice of variant and invariant that are used to prove the program correct more -r less determines the program itself. A lovely book. > and then translates to first order logic formulae, if the annotated > program can be satisfied then it will give no output, but if does > prove that the program doesn't produce the anottated output, it will > complain on where it fails, wherever it doesn't like the proof. > The important thing is that if the checker satisfies all of his > conditions, it doesn't mean it does not break, i.e it could be that > the checker will no complain but still can't prove absolutely that is > not to crash, is a kind of liberal, perhaps because of its logic > calculus. That's definitely not Dijkstra's weakest preconditions, then, but something similar. > There is also the case of possible false alarms, which could be > triggered, but this is almost the case in any compiler and here too, > even the M3 compiler (something called completeness, just very simple > known type systems have), so we can't expect to type check in the > semantic analyser it wrong and to accept it in the checker, but we > could instead just to make that a unsound program, lets say unsafe, > will not lock or crash because and specific error because of the > non-completeness issue. However the ESC didn't accept some special > kind of almost safe programs, recursive, partly I believe because of a > problem exposed below, is perhaps that the program doesn't end, unlike > a for loop. Dijkstra in his calculus in "A Discipline of Programming" didn't consider recursion. So far I get the impression that ESC didn't guarantee that the program would run properly if it passed all the checks, nor that failure to pass the checks implied invalidity. It just sort of points put things that may need attention. Kind of like a formal verificatin system that's implemented half-heartedly. > There is also the need of a efficient and smarter automatic theorem > prover, Simplify is one of the best available for some time now, Is it? Got references? I recall that formula simplification was a basic technique in one of the first formal-verification systems back in the late 60's, and that it solved a lot of complicated cases. They originated by substituting into standard formulas that expressed particular predicate transformations. You got a lot of things like i > 0 & i >= 0 & i < 2, which can be simplified to i = 0 if you know i is in integer. There were a huge number of these simplifications, trivial and tedious, and often they sufficed to shos one formula was equivalend to another. > but still, the same problems arise on it, it could be that because > of the first order logic, the program could not terminate but the > prover believe it will and it apparently does it, but that its > proofs will be not totally proved for all cases, if so, then we would > need to take care of those by applying hand formal verification > measures like below I explain a case. > Also Simplify could rise that he can't prove that something is not > provable by itself, but turn that it is doable, just that it can't by > its own, so we need to also verify those cases. > In the end, the best case our checks will end, but sometimes, the > first order logic could be an endless proof or undefined, in those > cases we would need a threshold given by the experience, so we might > start sooner than later to make our own. > The best of this is that are many things that have room for > improvement as Dr Greg Nelson told me some time ago, would be nice > thing to have the TODO list from him. > My personal wish is to make Modula-3 totally verifiable, learning this > by hand would be harder, but by the tools we could make it for using > its internal logic, the most critical part, the Professor Greg Nelson > did some work on that part of that I believe. Formal verification is a hard problem. > Then the important parts are the semantic checker which it self is > built on its internal logic, e.g a biased logic (i.e an unsound one, > the proofs could not end or be too large to finish and unable to > realize that after it spends time on it) it could be that never ends a > proof or check it badly as good, the most perfect it checks it would > be less efficient at some point (perhaps this was the reason to not > check the total correctness besides the effort needed) so might be > easier to pass the checks but less profitable in the checking. I > really would like the most inner parts to be self provable, like more > functional style programming then, but those are not verifiable by the > ESC checker, it just doesn't do that, similar to when I had a problem > on the checker I used sasylf.org, I'll have to look into that. > it had unimplemented the mutual > induction proving part by that time of a course back in 2008, this is > a theorem proof technique you need to use in advanced type theory of > type system soundness proofs, sasylf is a programming language by > itself to proof it is sound, so it turns out that if we can trust on > them more than in any part of the checker we could move on from there > to more advanced techniques, also this is harder I believe based on my > small experience of type systems proofing. I was working with Martin-Lof's type theory in the eighties. I ended up with a verifier, and manages to mechanically proof-check a merge-sort, written in the lazy functional language that's implicit in the logic. It was difficult to use, and really taxed the resources of our Vax 780, even though it has a whole 5 megabytes of memory! And the first verified sort had a bug -- not that it didn't sort; that had been proved, but that it wasn't the merge sort I had intended; it took quadratic time. That verifier is where I learned you have to debug the specifications as well as the code. Right now, the most sophisticated poof-checker of this kind seems to be coq, but some users of coq find they have to more-or-less rewrite coq to achieve efficiency of effort. > ESC developers say, the most provable source of those mis-checkings is > automatic theorem prover, not in checker, then it might be more > valuable to start there than in the checker's logic by itself, being > more practical, more pragmatic. I have some experience with the use of > automatic theorem provers part use by hand with sasylf, writing the > proofs and let it check for one (say I was the ESC checker and sasylf > was the automatic theorem prover), and it turns out not to be so > difficult to use after some work and time of use, still there are many > challenges open in the checkers for now, so the room for improvements > there is also too big (i.e we can check more things, say, the Modula-3 > arithmetic over and/or under flow, recurrence, by improving the core > logic calculus and later working on the "second pass" or backend first > order logic prover). > A special feature was the Locking level notation developed by writing > the Trestle library, Those locking levels were something special. I remember thinking deeply about the way those assertions worked, deciding that they were the right kind of assertions to base proofs on, and proceeded to ignore them when I read the rest of the code. > as it was coded threaded, it is perhaps the most > advanced part of it, more details than that I don't now, but more > probably coming on the way. I just know its logic is more advanced > from what I recall, it requires some clever reasoning and calculus too > I guess. Yeah... this is what we'd need to catch races and deadlocks and such. And it does seem to be mostly independent of the partial-correctness theorem proving described above. Deadlock and races are global issues. > So we can have a lot discussion, perhaps the first kick is given now. > I also hope its not too much blah, ... sorry for the long message Mostly you've outlined some traditional verification technology. ESC seems to use that, possibly with a restricted class of assertions (not clear just which ones), and has the limitations of the same. But the locking levels in trestle do seem to be something else. > Thanks in advance You're welcome. It seems to be a big project. to answer one of my original questions. The question is, whether there are smaller subprojects that are more feasible and will lead to a checker with code structure that can be easily grown. Without small successes, the motivation is often absent to proceed on to the large successes. That's especially true with FLOSS. Once you have something that actually does something useful, people start to use it, and suddenly your users realise how it could be improved, tell you, and if you're lucky, start to make the improvements themselves. --- My view of formal verification is that the proof has to be primary. You write a proof that there is some code that satisfies a spec, and the details of the proof reveal the program. This is completely different from the inductive-assertion method, in that you can use general theorems about particular loop structures, for example, and specialize then as necessary. In fact, I suspect that the theoretical feasibility of this approach is possibly the only reason why people can understand programs at all. You look at some code, decide after a while that there's a nest of six corecursive procedures, look at how parameters are passed down, and realize that it's recursion on a particulat tree structure -- at least you hope it's a tree structure, because its finite, noncyclic structure is nowhere explicit in the code. You reason backwards from patterns in the code to the reasoning the original programmer must have had in mind when he wrote it -- reasoning which rarely appears in the code, rarely even in comments. But using any of these methods for formal verification is still impractical except where the requirements for reliability justify extreme efforts. And I suspect strongly that the logic -- and the particular easy-to-use theorems about synthesizing program structures -- should dictate the structure of the programming language, which quite possibly won't end up being Modula 3. But who knows? The logic people use to decompose problems into implementable program components are largely independent of the pangauge they use, except for * restrictions of parameterization * absenes of convenient coding patterns for desired code structures * reliance on the particular properties that the language implementation guarantees (and therefore needs less explicit thought). I can imagine that the higher-order logics involved are similar for many programming languages, just as things like the Deduction Theorem are similar in many quite different formal logics (though the details of the proofs can be quite different). -- hendrik > > --- El mi?, 29/12/10, Hendrik Boom escribi?: > > > De: Hendrik Boom > > Asunto: Re: [M3devel] gui problems? BadBricks? columns? > > Para: m3devel at elegosoft.com > > Fecha: mi?rcoles, 29 de diciembre, 2010 22:26 > > On Wed, Dec 29, 2010 at 08:23:12PM > > -0500, Coleburn, Randy wrote: > > > Daniel et al: > > > > > > I tried a year or so ago to pursue getting the sources > > for the ESC. > > > I'd have to dig up my old emails, but my recollection > > is that I ran into a dead end getting the sources and the > > permission to put them in our repository. > > > I don't think the Modula-3 edition was kept up when > > the project moved on to other languages. > > > > What does the ESC do that's relevant to threading? I > > mean, not just an > > answer like "deadlock and race detection", but what > > algorithms does it > > use to accomplish it? Does the Modula 3 compiler > > construct the proper > > data structures that could provide the raw data those > > algorithms would > > need? How much work would it be to reimplement this > > from scratch? > > > > -- hendrik > > > > > From jay.krell at cornell.edu Fri Dec 31 07:51:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Dec 2010 06:51:21 +0000 Subject: [M3devel] CM3 status In-Reply-To: References: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com>, Message-ID: The system works fairly well, but also could use some obvious improvement. What do people want to work on that I am in the way of? If you do actually work on the same file as I do, you can still merge. Source control is not mutual exclusion. Granted, CVS doesn't help nearly as much as other source control systems. Perforce is the best I have used, by far, among just a few. Some of the possible future directions moot others. For example, enabling/fixing the typinfo in the gcc backend would be nice, but replacing it with LLVM and/or C++ and/or integrated backends moots that. Ditto for using the gcc exception handling infrastructure. Anything anyone is interested in doing, please speak up, and/or send diffs, and/or commit changes. Please don't be offended or discouraged if changes are backed out, if they don't work for some people. If there is target-dependence, consider some way to enable/disable based on target, and only enabling what you can test, waiting for others to test/enable others. I agree we have too little contribution from too few people, but not clear why. There are possibilities other than blaming me. The system has its interesting characteristics asis, but competition from other languages and libraries are probably more the cause (be careful not to confuse them!): C, C++, Qt, Java, GWT, C#, Perl, Python, Ruby, Tcl, Bash, "HTML", PHP, JavaScript, wxWindows, LUA, etc. It is indeed unusual to have a system with optional safety and native code generation (vs. interpreter or JIT). Just optional safety is rare, and present mainly only C#. I can't think of another language with optional safety and native code generation (granted, I can only name two languages with optional safety: Modula-3 and C#). Having a proper module system is also great, as it makes compilation very fast, on NT386 (similar to Java and C#). - Jay > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Thu, 30 Dec 2010 17:29:50 -0500 > Subject: Re: [M3devel] CM3 status > > Olaf et al: > > I think I share the concern you've voiced. > > My observation from the M3COMMIT log emails is that Jay seems to be the most prolific these days with changes, but I find it impossible to keep track of what problem he is trying to solve. Indeed, it seems he is working on multiple issues at the same time, but it is difficult from the posts to differentiate which issue goes with which posting, and this problem is compounded by the fact that my M3COMMIT/M3DEVEL e-mails don't always seem to be received in chronological order. > > Thus, it is extremely difficult to know how to channel the limited time I have available into helping cooperate to solve a particular problem. > > Maybe it would be a good idea when each person posts something to M3COMMIT or M3DEVEL that they tag it up front with a comment or reference to the problem the post is addressing. > > Another idea, and perhaps your TRAC system supports it, is to assign certain problems to specific individuals who work the problem and report back their solution approach for some type of concurrence before going off on a tangent to solve. This might cut down on some of the subsequent backtracking and reverting changes. It would also allow others to offer constructive comments on the solution approach, even if they don't have time to actually implement the solution. [In reading the posts, I'm seeing many places where work is done, then later someone disagrees with it, and wants the changes reverted.] > > Even if one person is assigned as the lead for a particular problem, perhaps others could join in on helping solve it, coordinating their effort thru the lead person. > > I really do want to help as much as I can, and we definitely need to grow the development support base, so anything we can do to foster teamwork and an up-to-date awareness of the major problem areas and proposed solution paths would be helpful I think. > > I certainly don't want to squash anyone's individual efforts, but right now I don't think we're maximizing our use of the team concept. > > Regards, > Randy Coleburn > > -----Original Message----- > From: Olaf Wagner [mailto:wagner at elegosoft.com] > Sent: Thursday, December 30, 2010 6:23 AM > To: m3devel at elegosoft.com > Subject: [M3devel] CM3 status > > Hi all, > > after reading a couple of Modula-3 mails again after some time of > 'abstinence' I'm a little bit confused about the state of the code > and the direction of development. I see that several different failures > and ideas are discussed, but don't seem to get resolved; none of them > is documented in our Trac instance as far as I know. Some things I > remember offhand: > > o at least 2 different compiler/assembler problems on Darwin/Snow Leopard > o current gcc not working on Solaris (?!) > o stack walker code abandoned > o possibly unsafe OS calls in new C code (this may be a wrong deduction > from my side) > o GUI input not working for BadBricks and other games (only on Darwin?) > o no clean way for exception handling with current gcc > o still alignment issues > > I'm concerned that things get tried out, don't work properly for all > our target platforms, but are left then and not cleaned up and something > else gets tried. I'm not sure this is correct, it is just me feeling > unwell after reading all those mails. > > Hudson and Tinderbox status seem to be mostly OK though, but I haven't > checked in detail (FreeBSD failing was a disk failure on my system > recently). But the tests don't cover all the things we should check. > > I think it would be good to have an overview of the projects/work that > is in progress or pending and its status. For example, we've imported > a new gcc version, but that doesn't seem to work well on all targets, > or does it? If not, how are we going to address this? Use older versions > on some platforms? Can I read up on that somewhere? > > I'd like to suggest to simply use our Trac WiKi to document the ongoing > work (everybody can get write access to that on request) and to record > all errors, failures and major tasks there as issues. This should help > everybody to participate and make me much more relaxed if I consider > the M3 emails (if anybody should care about my personal discomfort > at all :-) > > Just for reference: the trac instance can be found at > https://projects.elego.de/cm3 > > Several of the committers should already have access, and using > the WiKi and the issue tracker should not be much more work than > writing emails. But the information will be easier to access then. > > I hope to have offended nobody by this; I just wanted to make a suggestion > how to improve collaboration and discussion. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 31 08:11:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Dec 2010 07:11:24 +0000 Subject: [M3devel] factoring jmpbuf size via alloca(global constant)? In-Reply-To: References: Message-ID: The more I think about this, the more I like it. However there might be a better option. Gcc has some notion of built-in setjmp. For that matter, maybe using the gcc exception handling mechanism isn't difficult? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: factoring jmpbuf size via alloca(global constant)? Date: Thu, 30 Dec 2010 14:28:31 +0000 factoring out jmpbuf size? Hey, um, how about something like this: somefile.c: #include extern const int sizeof_jmpbuf = sizeof(jmp_buf); where the frontend would allocate a local jmp_buf, instead issue a call to alloca(sizeof_jmpbuf), actually reading the constant out of the global. Yes I know this is a deoptimization. It is already slow. We hope hope hope to replace it all anyway. This would remove lots of target-specific code in Target.m3. Related, I'm again trying removing from m3core the knowledge of the size/alignment of jmpbuf. Or rather, to see if it really needs it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 31 14:52:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Dec 2010 13:52:27 +0000 Subject: [M3devel] expressing 128 bit alignment? Message-ID: The alignment of jmpbuf is 128 bits for some targets. It seems like a hole in the language that this can't be expressed. Or maybe I just don't know how. Or maybe Target.max_align gets in the way?? I'd like to soon remove an accurately described jmpbuf from m3core, making this maybe moot. Linux/powerpc: /usr/include/bits/setjmp.h #ifndef _ASM # if __WORDSIZE == 64 typedef long int __jmp_buf[64] __attribute__ ((__aligned__ (16))); # else /* The alignment is not essential, i.e.the buffer can be copied to a 4 byte aligned buffer as per the ABI it is just added for performance reasons. */ typedef long int __jmp_buf[64 + (12 * 4)] __attribute__ ((__aligned__ (16))); # endif #endif Notice that the 128bit alignment on powerpc64 is not commented as being unessential, only for powerpc32. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Fri Dec 31 19:50:01 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 31 Dec 2010 10:50:01 -0800 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , , Message-ID: <20101231185001.2E77A1A205B@async.async.caltech.edu> I reported two compiler crashes on Snow Leopard. Earlier I provided a distilled version of the code that produces one crash. Here is the other one: MODULE Main; IMPORT FileWr, Wr; IMPORT Fmt; TYPE PV = RECORD price : LONGREAL; volume : CARDINAL; END; HFData_S = RECORD time : LONGREAL; pv : PV; END; PROCEDURE DumpMatching() = PROCEDURE DumpOne(trade : HFData_S) RAISES { Wr.Failure } = BEGIN Wr.PutText(wr, Fmt.LongReal(trade.time)); END DumpOne; VAR wr := FileWr.Open("out"); BEGIN END DumpMatching; BEGIN END Main. [hal:regress/ximport2/src] mika% cm3 -x --- building in ../I386_DARWIN --- new source -> compiling Main.m3 "../src/Main.m3", line 28: warning: potentially unhandled exception: OSError.E "../src/Main.m3", line 24: warning: potentially unhandled exception: Thread.Alerted "../src/Main.m3", line 22: warning: not used (DumpOne) "../src/Main.m3", line 20: warning: not used (DumpMatching) 4 warnings encountered ../src/Main.m3: In function 'Main__DumpMatching__DumpOne': ../src/Main.m3:25:0: error: unable to find a register to spill in class 'CREG' ../src/Main.m3:25:0: error: this is the insn: (insn 5 4 6 2 ../src/Main.m3:22 (parallel [ (set (reg:SI 0 ax [66]) (const_int 0 [0x0])) (set (reg:SI 1 dx [64]) (plus:SI (ashift:SI (reg:SI 0 ax [66]) (const_int 2 [0x2])) (reg:SI 1 dx [64]))) (set (reg:SI 4 si [65]) (plus:SI (ashift:SI (reg:SI 0 ax [66]) (const_int 2 [0x2])) (reg:SI 4 si [65]))) (set (mem/s/c:BLK (reg:SI 1 dx [64]) [0 trade+0 S24 A64]) (mem/s/c:BLK (reg:SI 4 si [65]) [0 trade+0 S24 A32])) (use (reg:SI 0 ax [66])) ]) 838 {*rep_movsi} (expr_list:REG_UNUSED (reg:SI 0 ax [66]) (expr_list:REG_UNUSED (reg:SI 4 si [65]) (expr_list:REG_UNUSED (reg:SI 1 dx [64]) (nil))))) ../src/Main.m3:25:0: internal compiler error: in spill_failure, at reload1.c:2163 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: Main.mc compilation failed => not building program "ximport" Fatal Error: package build failed [hal:regress/ximport2/src] mika% Happy New Year! Mika Jay K writes: >--_2d6969dc-a0fa-42e3-85e1-71600a2e9b7d_ >Content-Type: multipart/alternative; > boundary="_4765c0a9-911e-4b00-a171-d643958a7caa_" > >--_4765c0a9-911e-4b00-a171-d643958a7caa_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >From: jay.krell at cornell.edu >To: hosking at cs.purdue.edu >CC: m3devel at elegosoft.com >Subject: RE: [M3devel] compiler problems on Snow Leopard >Date: Mon=2C 27 Dec 2010 21:41:31 +0000 > > > > > > > > > > Rather than cluttering up CVS=2C why not put it in the bug-tracker? Tha= >t's what it is for! > >It is large. >It is more code that could be repeatedly tested=2C by building the entire "= >system"=2C for a gradually growing >definition of "system". > >We have had a number of problems that only appear in one or two or a few pi= >eces of code. >e.g. the removal of referenced nested functions. >e.g. optimizations causing compilation to fail (which this appears to be as= > well). > >A smaller example would be nice=2C but that is more work to get. > > - Jay > >From: hosking at cs.purdue.edu >Date: Mon=2C 27 Dec 2010 12:23:35 -0500 >To: jay.krell at cornell.edu >CC: m3devel at elegosoft.com >Subject: Re: [M3devel] compiler problems on Snow Leopard > > > >Rather than cluttering up CVS=2C why not put it in the bug-tracker? That's= > what it is for! > >Antony Hosking | Associate Professor | Computer Science | Purdue University= >305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494= > 6001 | Mobile +1 765 427 5484 > > >On Dec 27=2C 2010=2C at 5:17 AM=2C Jay K wrote:Can you put all your code in= > our CVS repository? > >> "../I386_DARWIN/FSSchemeStubs.m3"=2C line 434: 2 code generation errors > >There is a way to get that to show more information.. >Or does it already? > > - Jay > >> To: m3devel at elegosoft.com >> Date: Mon=2C 27 Dec 2010 02:14:21 -0800 >> From: mika at async.caltech.edu >> Subject: Re: [M3devel] compiler problems on Snow Leopard >>=20 >> I upgraded to the CVS head and now I get the following: >>=20 >> ... >> "../I386_DARWIN/FSSchemeStubs.m3"=2C line 872: warning: unreachable state= >ment >> "../I386_DARWIN/FSSchemeStubs.m3"=2C line 903: warning: unreachable state= >ment >> "../I386_DARWIN/FSSchemeStubs.m3"=2C line 434: 2 code generation errors >> 1 error and 23 warnings encountered >> new exporters -> recompiling FSSchemeStubs.i3 >> ... >>=20 >> The source code is: >>=20 >> TYPE FS_Iterator_Surrogate =3D FS.Iterator OBJECT (* line 434 *) >> interp : Scheme.T=3B >> next_slot : SchemeObject.T :=3D NIL=3B >> close_slot : SchemeObject.T :=3D NIL=3B >> nextWithStatus_slot : SchemeObject.T :=3D NIL=3B >> OVERRIDES >> next :=3D FS_Iterator_next_default=3B >> close :=3D FS_Iterator_close_default=3B >> nextWithStatus :=3D FS_Iterator_nextWithStatus_default=3B >> END=3B >>=20 >> Mika >>=20 >> Mika Nystrom writes: >> >Hi everyone=2C >> > >> >Well I was able to get past all my linking issues (mostly questions >> >of dynamic vs. static linking and how to do it=2C which seems to change = >from >> >version to version...) >> > >> >But now I did hit a real problem. >> > >> >"../I386_DARWIN/FSSchemeStubs.m3"=2C line 934: ** INTERNAL CG ERROR *** = >unaligne >> >d store type=3D6 s/o/a=3D32/0/32 >> >"../I386_DARWIN/FSSchemeStubs.m3"=2C line 981: ** INTERNAL CG ERROR *** = >unaligne >> >d load_indirect type=3D6 s/a=3D32/32 >> > >> >Here is the code=2C but it's not likely to be of much help... >> > >> >PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.= >T RAIS >> >ES { Scheme.E } =3D >> > BEGIN >> > VAR res : SchemePair.T:=3DNIL=3B BEGIN >> > res :=3D SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"= >)=2CT >> >oScheme_Atom_T(x.type))=2Cres)=3B >> > res :=3D SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modif= >ica >> >tionTime")=2CSchemeModula3Types.ToScheme_LONGREAL(x.modificationTime))= >=2Cres)=3B >> > res :=3D SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"= >)=2CT >> >oScheme_VAL0LONGINT__VAL16778080LONGINT(x.size))=2Cres)=3B (* line 934 *= >) >> > RETURN res >> > END >> > END ToScheme_File_Status=3B >> > >> > >> >... >> > >> >PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0= >=2C LONGI >> >NT )..VAL(16778080=2C LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = >=3D >> > BEGIN >> > RETURN ToScheme_LONGINT(x) (* line 981 *) >> > END ToScheme_VAL0LONGINT__VAL16778080LONGINT=3B >> > >> > >> >for reference=2C ToScheme_LONGINT is: >> > >> >PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISE= >S { S >> >cheme.E } =3D >> > BEGIN >> > WITH ref =3D NEW(REF LONGINT) DO >> > ref^ :=3D x=3B >> > RETURN SchemeModula3Types.ToScheme_LONGINT(ref) >> > END >> > END ToScheme_LONGINT=3B >> > >> > Mika > > = > >--_4765c0a9-911e-4b00-a171-d643958a7caa_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >


From: jay.krell at cornell.edu
To: hosk= >ing at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] co= >mpiler problems on Snow Leopard
Date: Mon=2C 27 Dec 2010 21:41:31 +0000<= >br>
> >"> > > > > > =3B>=3B Rather than cluttering up CVS=2C why not put it in the bug-t= >racker?  =3BThat's what it is for!

It is large.
It is more co= >de that could be repeatedly tested=2C by building the entire "system"=2C fo= >r a gradually growing
definition of "system".

We have had a numbe= >r of problems that only appear in one or two or a few pieces of code.
e.= >g. the removal of referenced nested functions.
e.g. optimizations causin= >g compilation to fail (which this appears to be as well).

A smaller = >example would be nice=2C but that is more work to get.

 =3B- Jay= >

From: hosking at cs.purdue.edu
Date: Mon= >=2C 27 Dec 2010 12:23:35 -0500
To: jay.krell at cornell.edu
CC: m3devel@= >elegosoft.com
Subject: Re: [M3devel] compiler problems on Snow Leopardr>
> >Rather than cluttering up CVS=2C why not put it in the bug-tracker?  = >=3BThat's what it is for!

>olor: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font= >-style: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spa= >cing: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: = >none=3B white-space: normal=3B word-spacing: 0px=3B">e-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)= >=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font= >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h= >eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n= >ormal=3B word-spacing: 0px=3B">
n class=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B color= >: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-sty= >le: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing= >: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: none= >=3B white-space: normal=3B word-spacing: 0px=3B">yle-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B = >font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-var= >iant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-heigh= >t: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: norma= >l=3B word-spacing: 0px=3B">der-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica= >=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B font-w= >eight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-inde= >nt: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing: 0px= >=3B">=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B= > font-style: normal=3B font-variant: normal=3B font-weight: normal=3B lette= >r-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-transf= >orm: none=3B white-space: normal=3B word-spacing: 0px=3B">xApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0= >=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal= >=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: normal= >=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whit= >e-space: normal=3B word-spacing: 0px=3B">" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-fam= >ily: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: no= >rmal=3B font-weight: normal=3B letter-spacing: normal=3B line-height: norma= >l=3B text-indent: 0px=3B text-transform: none=3B white-space: normal=3B wor= >d-spacing: 0px=3B">apse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font= >-size: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: n= >ormal=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px= >=3B text-transform: none=3B white-space: normal=3B word-spacing: 0px=3B">pan class=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B col= >or: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-s= >tyle: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spaci= >ng: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: no= >ne=3B white-space: normal=3B word-spacing: 0px=3B">
pple-style-span" color=3D"#0000ff">=3D"Gill Sans"> 0=2C 255)=3B font-family: 'Gill Sans'=3B">an" style=3D"color: rgb(0=2C 0=2C 255)=3B font-family: 'Gill Sans'=3B">Anto= >ny Hoskingace=3D"Gill Sans"> 'Gill Sans'=3B">'Gill Sans'=3B"> =3B|pan class=3D"ecxApple-converted-space"> =3Blass=3D"ecxApple-style-span" style=3D"font-family: 'Gill Sans'=3B">ass=3D"ecxApple-style-span" style=3D"font-family: 'Gill Sans'=3B">Associate= > Professoramily: 'Gill Sans'=3B">mily: 'Gill Sans'=3B"> =3B| Computer Science | Purdue University= >
ns-Light">s-Light=3B">305 N. University Street | West Lafayette | IN 47907 | USAn>
ace=3D"Gill Sans">=2C 0=2C 255)=3B font-family: 'Gill Sans'=3B">-span" style=3D"color: rgb(0=2C 0=2C 255)=3B font-family: 'Gill Sans'=3B">O= >fficeans-Light">ns-Light=3B">Sans-Light=3B"> =3B+1 765 494 6001 |pace"> =3Bn" color=3D"#0000ff" face=3D"Gill Sans"> style=3D"color: rgb(0=2C 0=2C 255)=3B font-family: 'Gill Sans'=3B">lass=3D"ecxApple-style-span" style=3D"color: rgb(0=2C 0=2C 255)=3B font-fam= >ily: 'Gill Sans'=3B">Mobilele-span" face=3D"GillSans-Light">=3D"font-family: GillSans-Light=3B">le=3D"font-family: GillSans-Light=3B">ce"> =3B+1 765 427 5484
ss=3D"ecxApple-style-span" face=3D"GillSans-Light">
ock-placeholder">
pan>
<= >br class=3D"ecxApple-interchange-newline"> >
>
On Dec 27=2C 2010=2C at 5:17 AM=2C Jay K wrote:

s=3D"ecxApple-interchange-newline">
e-span" style=3D"border-collapse: separate=3B font-family: Helvetica=3B fon= >t-style: normal=3B font-variant: normal=3B font-weight: normal=3B letter-sp= >acing: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform:= > none=3B white-space: normal=3B word-spacing: 0px=3B font-size: medium=3B">= >
=3B">Can you put all your code in our CVS repository?

>=3B "../I38= >6_DARWIN/FSSchemeStubs.m3"=2C line 434: 2 code generation errors

The= >re is a way to get that to show more information..
Or does it already?r>
 =3B- Jay

>=3B To:e"> =3Bm3devel at elegosof= >t.com
>=3B Date: Mon=2C 27 Dec 2010 02:14:21 -0800
>=3B From:= > =3Bika at async.caltech.edu">mika at async.caltech.edu
>=3B Subject: Re: [M= >3devel] compiler problems on Snow Leopard
>=3Bconverted-space"> =3B
>=3B I upgraded to the CVS head and n= >ow I get the following:
>=3B&= >nbsp=3B
>=3B ...
>=3B "../I386_DARWIN/FSSchemeStubs.m3"=2C= > line 872: warning: unreachable statement
>=3B "../I386_DARWIN/FSSchem= >eStubs.m3"=2C line 903: warning: unreachable statement
>=3B "../I386_D= >ARWIN/FSSchemeStubs.m3"=2C line 434: 2 code generation errors
>=3B 1 e= >rror and 23 warnings encountered
>=3B new exporters ->=3B recompilin= >g FSSchemeStubs.i3
>=3B ...
>=3B-space"> =3B
>=3B The source code is:
>=3B=3D"ecxApple-converted-space"> =3B
>=3B TYPE FS_Iterator_Su= >rrogate =3D FS.Iterator OBJECT (* line 434 *)
>=3B interp : Scheme.T= >=3B
>=3B next_slot : SchemeObject.T :=3D NIL=3B
>=3B close_slot := > SchemeObject.T :=3D NIL=3B
>=3B nextWithStatus_slot : SchemeObject.T = >:=3D NIL=3B
>=3B OVERRIDES
>=3B next :=3D FS_Iterator_next_defaul= >t=3B
>=3B close :=3D FS_Iterator_close_default=3B
>=3B nextWithSt= >atus :=3D FS_Iterator_nextWithStatus_default=3B
>=3B END=3B
>=3B<= >span class=3D"ecxApple-converted-space"> =3B
>=3B Mika
&= >gt=3B =3B
>=3B Mik= >a Nystrom writes:
>=3B >=3BHi everyone=2C
>=3B >=3B
>=3B= > >=3BWell I was able to get past all my linking issues (mostly questions<= >br>>=3B >=3Bof dynamic vs. static linking and how to do it=2C which see= >ms to change from
>=3B >=3Bversion to version...)
>=3B >=3Br>>=3B >=3BBut now I did hit a real problem.
>=3B >=3B
>=3B= > >=3B"../I386_DARWIN/FSSchemeStubs.m3"=2C line 934: ** INTERNAL CG ERROR = >*** unaligne
>=3B >=3Bd store type=3D6 s/o/a=3D32/0/32
>=3B >= >=3B"../I386_DARWIN/FSSchemeStubs.m3"=2C line 981: ** INTERNAL CG ERROR *** = >unaligne
>=3B >=3Bd load_indirect type=3D6 s/a=3D32/32
>=3B >= >=3B
>=3B >=3BHere is the code=2C but it's not likely to be of much h= >elp...
>=3B >=3B
>=3B >=3BPROCEDURE ToScheme_File_Status(READ= >ONLY x : File.Status) : SchemeObject.T RAIS
>=3B >=3BES { Scheme.E }= > =3D
>=3B >=3B BEGIN
>=3B >=3B VAR res : SchemePair.T:=3DNIL= >=3B BEGIN
>=3B >=3B res :=3D SchemeUtils.Cons(SchemeUtils.Cons(Schem= >eSymbol.FromText("type")=2CT
>=3B >=3BoScheme_Atom_T(x.type))=2Cres)= >=3B
>=3B >=3B res :=3D SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbo= >l.FromText("modifica
>=3B >=3BtionTime")=2CSchemeModula3Types.ToSche= >me_LONGREAL(x.modificationTime))=2Cres)=3B
>=3B >=3B res :=3D Scheme= >Utils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size")=2CT
>=3B >= >=3BoScheme_VAL0LONGINT__VAL16778080LONGINT(x.size))=2Cres)=3B (* line 934 *= >)
>=3B >=3B RETURN res
>=3B >=3B END
>=3B >=3B END ToS= >cheme_File_Status=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B...<= >br>>=3B >=3B
>=3B >=3BPROCEDURE ToScheme_VAL0LONGINT__VAL1677808= >0LONGINT(READONLY x : [ VAL(0=2C LONGI
>=3B >=3BNT )..VAL(16778080= >=2C LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } =3D
>=3B >=3B = >BEGIN
>=3B >=3B RETURN ToScheme_LONGINT(x) (* line 981 *)
>=3B = >>=3B END ToScheme_VAL0LONGINT__VAL16778080LONGINT=3B
>=3B >=3B
= >>=3B >=3B
>=3B >=3Bfor reference=2C ToScheme_LONGINT is:
>= >=3B >=3B
>=3B >=3BPROCEDURE ToScheme_LONGINT(READONLY x : LONGINT = >) : SchemeObject.T RAISES { S
>=3B >=3Bcheme.E } =3D
>=3B >= >=3B BEGIN
>=3B >=3B WITH ref =3D NEW(REF LONGINT) DO
>=3B >= >=3B ref^ :=3D x=3B
>=3B >=3B RETURN SchemeModula3Types.ToScheme_LONG= >INT(ref)
>=3B >=3B END
>=3B >=3B END ToScheme_LONGINT=3B
&= >gt=3B >=3B
>=3B >=3B Mika

<= >/div>
>= > >--_4765c0a9-911e-4b00-a171-d643958a7caa_-- > >--_2d6969dc-a0fa-42e3-85e1-71600a2e9b7d_ >Content-Type: application/octet-stream >Content-Transfer-Encoding: base64 >Content-Disposition: attachment; filename="FSSchemeStubs.i3" > >SU5URVJGQUNFIEZTU2NoZW1lU3R1YnM7CigqIEFVVE9NQVRJQ0FMTFkgR0VORVJBVEVEIERPIE5P >VCBFRElUICopCklNUE9SVCBTY2hlbWU7CklNUE9SVCBTY2hlbWVPYmplY3Q7CklNUE9SVCBTY2hl >bWVQYWlyOwpJTVBPUlQgU2NoZW1lTW9kdWxhM1R5cGVzOwpJTVBPUlQgT1NFcnJvcjsKSU1QT1JU >IEZpbGU7CklNUE9SVCBGUzsKSU1QT1JUIFNjaGVtZVN5bWJvbDsKSU1QT1JUIFNjaGVtZVV0aWxz >OwpJTVBPUlQgU2NoZW1lQXBwbHk7CklNUE9SVCBBdG9tTGlzdDsKSU1QT1JUIFNjaGVtZUJvb2xl >YW47CklNUE9SVCBBdG9tOwoKUFJPQ0VEVVJFIFJlZ2lzdGVyU3R1YnMoKTsKClBST0NFRFVSRSBU >b1NjaGVtZV9BdG9tTGlzdF9UKFJFQURPTkxZIHggOiBBdG9tTGlzdC5UKSA6IFNjaGVtZU9iamVj >dC5UIFJBSVNFUyB7IH07CgpQUk9DRURVUkUgVG9TY2hlbWVfRlNfSXRlcmF0b3IoUkVBRE9OTFkg >eCA6IEZTLkl0ZXJhdG9yKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IH07CgpQUk9DRURVUkUg >VG9TY2hlbWVfRmlsZV9UKFJFQURPTkxZIHggOiBGaWxlLlQpIDogU2NoZW1lT2JqZWN0LlQgUkFJ >U0VTIHsgfTsKClBST0NFRFVSRSBUb1NjaGVtZV9GaWxlX1N0YXR1cyhSRUFET05MWSB4IDogRmls >ZS5TdGF0dXMpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUgfTsKClBST0NFRFVS >RSBUb01vZHVsYV9GU19DcmVhdGVPcHRpb24oeCA6IFNjaGVtZU9iamVjdC5UKSA6IChGUy5DcmVh >dGVPcHRpb24pIFJBSVNFUyB7IFNjaGVtZS5FIH07CgpQUk9DRURVUkUgVG9Nb2R1bGFfRlNfQWNj >ZXNzT3B0aW9uKHggOiBTY2hlbWVPYmplY3QuVCkgOiAoRlMuQWNjZXNzT3B0aW9uKSBSQUlTRVMg >eyBTY2hlbWUuRSB9OwoKUFJPQ0VEVVJFIFRvTW9kdWxhX0ZpbGVfVCh4IDogU2NoZW1lT2JqZWN0 >LlQpIDogKEZpbGUuVCkgUkFJU0VTIHsgU2NoZW1lLkUgfTsKClBST0NFRFVSRSBUb1NjaGVtZV9W >QUwwTE9OR0lOVF9fVkFMMTA3Mzc0NTExMkxPTkdJTlQoUkVBRE9OTFkgeCA6IFsgVkFMKDAsIExP >TkdJTlQgKS4uVkFMKC0xMDczNzQ1MTEyLCBMT05HSU5UICkgXSkgOiBTY2hlbWVPYmplY3QuVCBS >QUlTRVMgeyBTY2hlbWUuRSB9OwoKUFJPQ0VEVVJFIFRvU2NoZW1lX0F0b21fVChSRUFET05MWSB4 >IDogQXRvbS5UKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IH07CgpQUk9DRURVUkUgVG9TY2hl >bWVfTE9OR0lOVChSRUFET05MWSB4IDogIExPTkdJTlQgKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNF >UyB7IFNjaGVtZS5FIH07CkNPTlNUIEJyYW5kID0gIkZTU2NoZW1lU3R1YnMiOwoKRU5EIEZTU2No >ZW1lU3R1YnMuCg== > >--_2d6969dc-a0fa-42e3-85e1-71600a2e9b7d_ >Content-Type: application/octet-stream >Content-Transfer-Encoding: base64 >Content-Disposition: attachment; filename="FSSchemeStubs.m3" > >TU9EVUxFIEZTU2NoZW1lU3R1YnM7CigqIEFVVE9NQVRJQ0FMTFkgR0VORVJBVEVEIERPIE5PVCBF >RElUICopCklNUE9SVCBTY2hlbWU7CklNUE9SVCBTY2hlbWVPYmplY3Q7CklNUE9SVCBTY2hlbWVQ >YWlyOwpJTVBPUlQgU2NoZW1lTW9kdWxhM1R5cGVzOwpJTVBPUlQgT1NFcnJvcjsKSU1QT1JUIEZp >bGU7CklNUE9SVCBTY2hlbWVQcm9jZWR1cmVTdHViczsKSU1QT1JUIEZTOwpJTVBPUlQgU2NoZW1l >U3ltYm9sOwpJTVBPUlQgU2NoZW1lVXRpbHM7CklNUE9SVCBTY2hlbWVBcHBseTsKSU1QT1JUIFJU >MDsKSU1QT1JUIEF0b21MaXN0OwpJTVBPUlQgU2NoZW1lQm9vbGVhbjsKSU1QT1JUIEF0b207CgpQ >Uk9DRURVUkUgQ2FsbFN0dWJfRlNfR2V0QWJzb2x1dGVQYXRobmFtZShpbnRlcnAgOiBTY2hlbWUu >VDsKICAgICAgICAgICAgICAgICAgICAgIGFyZ3MgOiBTY2hlbWVPYmplY3QuVDsKICAgICAgICAg >ICAgICAgICAgICAgIGV4Y0hhbmRsZXIgOiBTY2hlbWVPYmplY3QuVCkgOiBTY2hlbWVPYmplY3Qu >VAogIFJBSVNFUyB7IFNjaGVtZS5FIH0gPSAKIAogIFBST0NFRFVSRSBOZXh0KCkgOiBTY2hlbWVP >YmplY3QuVCBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAgICBCRUdJTgogICAgICBUUlkgUkVUVVJO >IFNjaGVtZVV0aWxzLkZpcnN0KHBfXykgRklOQUxMWSBwX18gOj0gU2NoZW1lUGFpci5QYWlyKFNj >aGVtZVV0aWxzLlJlc3QocF9fKSkgRU5ECiAgICBFTkQgTmV4dDsKIAogIFZBUiBwX18gOj0gU2No >ZW1lUGFpci5QYWlyKGFyZ3MpOwogIEJFR0lOCiAgICBUUlkKICAgICAgKCogdW5wYWNrIGZvcm1h >bHMgKikKICAgICAgVkFSIDwqTk9XQVJOKj5qdW5rX18gOj0gMDsKICAgICAgICAgICBmb3JtYWxf >cCA6PSBTY2hlbWVNb2R1bGEzVHlwZXMuVG9Nb2R1bGFfVEVYVChOZXh0KCkpOyBCRUdJTgogICAg >ICAgICgqIGNhcnJ5IG91dCBOSUwgY2hlY2tzIGZvciBvcGVuIGFycmF5cyAqKQoKICAgICAgICAo >KiBtYWtlIHByb2NlZHVyZSBjYWxsICopCiAgICAgICAgV0lUSCByZXMgPSBTY2hlbWVNb2R1bGEz >VHlwZXMuVG9TY2hlbWVfVEVYVChGUy5HZXRBYnNvbHV0ZVBhdGhuYW1lKGZvcm1hbF9wKSkgRE8K >ICAgICAgICAoKiB1bnBhY2sgVkFSIHBhcmFtcyAqKQogICAgICAgIHBfXyA6PSBTY2hlbWVQYWly >LlBhaXIoYXJncyk7CiAgICAgICAgRVZBTCBOZXh0KCk7CgogICAgICAgICgqIHJldHVybiBwcm9j >ZWR1cmUgcmVzdWx0ICopCiAgICAgICAgUkVUVVJOIHJlcwogICAgICAgIEVORAogICAgICBFTkQo >KldJVEgqKQogICAgRVhDRVBUCiAgICAgIHwgT1NFcnJvci5FKHhhcmcpID0+IEVWQUwgU2NoZW1l >QXBwbHkuT25lQXJnKGludGVycCxleGNIYW5kbGVyLFNjaGVtZVV0aWxzLkxpc3QyKFNjaGVtZVN5 >bWJvbC5Gcm9tVGV4dCgicXVvdGUiKSxTY2hlbWVVdGlscy5Db25zKFNjaGVtZVN5bWJvbC5Gcm9t >VGV4dCgiT1NFcnJvci5FIiksIFRvU2NoZW1lX0F0b21MaXN0X1QoeGFyZykpKSkKICAgIEVORDsK >ICAgIDwqTk9XQVJOKj5SRVRVUk4gU2NoZW1lQm9vbGVhbi5GYWxzZSgpCiAgRU5EIENhbGxTdHVi >X0ZTX0dldEFic29sdXRlUGF0aG5hbWU7CgpQUk9DRURVUkUgQ2FsbFN0dWJfRlNfT3BlbkZpbGUo >aW50ZXJwIDogU2NoZW1lLlQ7CiAgICAgICAgICAgICAgICAgICAgICBhcmdzIDogU2NoZW1lT2Jq >ZWN0LlQ7CiAgICAgICAgICAgICAgICAgICAgICBleGNIYW5kbGVyIDogU2NoZW1lT2JqZWN0LlQp >IDogU2NoZW1lT2JqZWN0LlQKICBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAKICBQUk9DRURVUkUg >TmV4dCgpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUgfSA9IAogICAgQkVHSU4K >ICAgICAgVFJZIFJFVFVSTiBTY2hlbWVVdGlscy5GaXJzdChwX18pIEZJTkFMTFkgcF9fIDo9IFNj >aGVtZVBhaXIuUGFpcihTY2hlbWVVdGlscy5SZXN0KHBfXykpIEVORAogICAgRU5EIE5leHQ7CiAK >ICBWQVIgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICBCRUdJTgogICAgVFJZCiAgICAg >ICgqIHVucGFjayBmb3JtYWxzICopCiAgICAgIFZBUiA8Kk5PV0FSTio+anVua19fIDo9IDA7CiAg >ICAgICAgICAgZm9ybWFsX3AgOj0gU2NoZW1lTW9kdWxhM1R5cGVzLlRvTW9kdWxhX1RFWFQoTmV4 >dCgpKTsKICAgICAgICAgICBmb3JtYWxfdHJ1bmNhdGUgOj0gU2NoZW1lTW9kdWxhM1R5cGVzLlRv >TW9kdWxhX0JPT0xFQU4oTmV4dCgpKTsKICAgICAgICAgICBmb3JtYWxfY3JlYXRlIDo9IFRvTW9k >dWxhX0ZTX0NyZWF0ZU9wdGlvbihOZXh0KCkpOwogICAgICAgICAgIGZvcm1hbF90ZW1wbGF0ZSA6 >PSBUb01vZHVsYV9GaWxlX1QoTmV4dCgpKTsKICAgICAgICAgICBmb3JtYWxfYWNjZXNzIDo9IFRv >TW9kdWxhX0ZTX0FjY2Vzc09wdGlvbihOZXh0KCkpOyBCRUdJTgogICAgICAgICgqIGNhcnJ5IG91 >dCBOSUwgY2hlY2tzIGZvciBvcGVuIGFycmF5cyAqKQoKICAgICAgICAoKiBtYWtlIHByb2NlZHVy >ZSBjYWxsICopCiAgICAgICAgV0lUSCByZXMgPSBUb1NjaGVtZV9GaWxlX1QoRlMuT3BlbkZpbGUo >Zm9ybWFsX3AsIGZvcm1hbF90cnVuY2F0ZSwgZm9ybWFsX2NyZWF0ZSwgZm9ybWFsX3RlbXBsYXRl >LCBmb3JtYWxfYWNjZXNzKSkgRE8KICAgICAgICAoKiB1bnBhY2sgVkFSIHBhcmFtcyAqKQogICAg >ICAgIHBfXyA6PSBTY2hlbWVQYWlyLlBhaXIoYXJncyk7CiAgICAgICAgRVZBTCBOZXh0KCk7CiAg >ICAgICAgRVZBTCBOZXh0KCk7CiAgICAgICAgRVZBTCBOZXh0KCk7CiAgICAgICAgRVZBTCBOZXh0 >KCk7CiAgICAgICAgRVZBTCBOZXh0KCk7CgogICAgICAgICgqIHJldHVybiBwcm9jZWR1cmUgcmVz >dWx0ICopCiAgICAgICAgUkVUVVJOIHJlcwogICAgICAgIEVORAogICAgICBFTkQoKldJVEgqKQog >ICAgRVhDRVBUCiAgICAgIHwgT1NFcnJvci5FKHhhcmcpID0+IEVWQUwgU2NoZW1lQXBwbHkuT25l >QXJnKGludGVycCxleGNIYW5kbGVyLFNjaGVtZVV0aWxzLkxpc3QyKFNjaGVtZVN5bWJvbC5Gcm9t >VGV4dCgicXVvdGUiKSxTY2hlbWVVdGlscy5Db25zKFNjaGVtZVN5bWJvbC5Gcm9tVGV4dCgiT1NF >cnJvci5FIiksIFRvU2NoZW1lX0F0b21MaXN0X1QoeGFyZykpKSkKICAgIEVORDsKICAgIDwqTk9X >QVJOKj5SRVRVUk4gU2NoZW1lQm9vbGVhbi5GYWxzZSgpCiAgRU5EIENhbGxTdHViX0ZTX09wZW5G >aWxlOwoKUFJPQ0VEVVJFIENhbGxTdHViX0ZTX09wZW5GaWxlUmVhZG9ubHkoaW50ZXJwIDogU2No >ZW1lLlQ7CiAgICAgICAgICAgICAgICAgICAgICBhcmdzIDogU2NoZW1lT2JqZWN0LlQ7CiAgICAg >ICAgICAgICAgICAgICAgICBleGNIYW5kbGVyIDogU2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2Jq >ZWN0LlQKICBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAKICBQUk9DRURVUkUgTmV4dCgpIDogU2No >ZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUgfSA9IAogICAgQkVHSU4KICAgICAgVFJZIFJF >VFVSTiBTY2hlbWVVdGlscy5GaXJzdChwX18pIEZJTkFMTFkgcF9fIDo9IFNjaGVtZVBhaXIuUGFp >cihTY2hlbWVVdGlscy5SZXN0KHBfXykpIEVORAogICAgRU5EIE5leHQ7CiAKICBWQVIgcF9fIDo9 >IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICBCRUdJTgogICAgVFJZCiAgICAgICgqIHVucGFjayBm >b3JtYWxzICopCiAgICAgIFZBUiA8Kk5PV0FSTio+anVua19fIDo9IDA7CiAgICAgICAgICAgZm9y >bWFsX3AgOj0gU2NoZW1lTW9kdWxhM1R5cGVzLlRvTW9kdWxhX1RFWFQoTmV4dCgpKTsgQkVHSU4K >ICAgICAgICAoKiBjYXJyeSBvdXQgTklMIGNoZWNrcyBmb3Igb3BlbiBhcnJheXMgKikKCiAgICAg >ICAgKCogbWFrZSBwcm9jZWR1cmUgY2FsbCAqKQogICAgICAgIFdJVEggcmVzID0gVG9TY2hlbWVf >RmlsZV9UKEZTLk9wZW5GaWxlUmVhZG9ubHkoZm9ybWFsX3ApKSBETwogICAgICAgICgqIHVucGFj >ayBWQVIgcGFyYW1zICopCiAgICAgICAgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICAg >ICAgICBFVkFMIE5leHQoKTsKCiAgICAgICAgKCogcmV0dXJuIHByb2NlZHVyZSByZXN1bHQgKikK >ICAgICAgICBSRVRVUk4gcmVzCiAgICAgICAgRU5ECiAgICAgIEVORCgqV0lUSCopCiAgICBFWENF >UFQKICAgICAgfCBPU0Vycm9yLkUoeGFyZykgPT4gRVZBTCBTY2hlbWVBcHBseS5PbmVBcmcoaW50 >ZXJwLGV4Y0hhbmRsZXIsU2NoZW1lVXRpbHMuTGlzdDIoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJx >dW90ZSIpLFNjaGVtZVV0aWxzLkNvbnMoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJPU0Vycm9yLkUi >KSwgVG9TY2hlbWVfQXRvbUxpc3RfVCh4YXJnKSkpKQogICAgRU5EOwogICAgPCpOT1dBUk4qPlJF >VFVSTiBTY2hlbWVCb29sZWFuLkZhbHNlKCkKICBFTkQgQ2FsbFN0dWJfRlNfT3BlbkZpbGVSZWFk >b25seTsKClBST0NFRFVSRSBDYWxsU3R1Yl9GU19DcmVhdGVEaXJlY3RvcnkoaW50ZXJwIDogU2No >ZW1lLlQ7CiAgICAgICAgICAgICAgICAgICAgICBhcmdzIDogU2NoZW1lT2JqZWN0LlQ7CiAgICAg >ICAgICAgICAgICAgICAgICBleGNIYW5kbGVyIDogU2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2Jq >ZWN0LlQKICBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAKICBQUk9DRURVUkUgTmV4dCgpIDogU2No >ZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUgfSA9IAogICAgQkVHSU4KICAgICAgVFJZIFJF >VFVSTiBTY2hlbWVVdGlscy5GaXJzdChwX18pIEZJTkFMTFkgcF9fIDo9IFNjaGVtZVBhaXIuUGFp >cihTY2hlbWVVdGlscy5SZXN0KHBfXykpIEVORAogICAgRU5EIE5leHQ7CiAKICBWQVIgcF9fIDo9 >IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICBCRUdJTgogICAgVFJZCiAgICAgICgqIHVucGFjayBm >b3JtYWxzICopCiAgICAgIFZBUiA8Kk5PV0FSTio+anVua19fIDo9IDA7CiAgICAgICAgICAgZm9y >bWFsX3AgOj0gU2NoZW1lTW9kdWxhM1R5cGVzLlRvTW9kdWxhX1RFWFQoTmV4dCgpKTsgQkVHSU4K >ICAgICAgICAoKiBjYXJyeSBvdXQgTklMIGNoZWNrcyBmb3Igb3BlbiBhcnJheXMgKikKCiAgICAg >ICAgKCogbWFrZSBwcm9jZWR1cmUgY2FsbCAqKQogICAgICAgIEZTLkNyZWF0ZURpcmVjdG9yeShm >b3JtYWxfcCk7CiAgICAgICAgKCogdW5wYWNrIFZBUiBwYXJhbXMgKikKICAgICAgICBwX18gOj0g >U2NoZW1lUGFpci5QYWlyKGFyZ3MpOwogICAgICAgIEVWQUwgTmV4dCgpOwoKICAgICAgICAoKiBw >cm9wZXIgcHJvY2VkdXJlIDogcmV0dXJuIFRSVUUgKikKICAgICAgICBSRVRVUk4gU2NoZW1lQm9v >bGVhbi5UcnVlKCkKICAgICAgRU5EKCpXSVRIKikKICAgIEVYQ0VQVAogICAgICB8IE9TRXJyb3Iu >RSh4YXJnKSA9PiBFVkFMIFNjaGVtZUFwcGx5Lk9uZUFyZyhpbnRlcnAsZXhjSGFuZGxlcixTY2hl >bWVVdGlscy5MaXN0MihTY2hlbWVTeW1ib2wuRnJvbVRleHQoInF1b3RlIiksU2NoZW1lVXRpbHMu >Q29ucyhTY2hlbWVTeW1ib2wuRnJvbVRleHQoIk9TRXJyb3IuRSIpLCBUb1NjaGVtZV9BdG9tTGlz >dF9UKHhhcmcpKSkpCiAgICBFTkQ7CiAgICA8Kk5PV0FSTio+UkVUVVJOIFNjaGVtZUJvb2xlYW4u >RmFsc2UoKQogIEVORCBDYWxsU3R1Yl9GU19DcmVhdGVEaXJlY3Rvcnk7CgpQUk9DRURVUkUgQ2Fs >bFN0dWJfRlNfRGVsZXRlRGlyZWN0b3J5KGludGVycCA6IFNjaGVtZS5UOwogICAgICAgICAgICAg >ICAgICAgICAgYXJncyA6IFNjaGVtZU9iamVjdC5UOwogICAgICAgICAgICAgICAgICAgICAgZXhj >SGFuZGxlciA6IFNjaGVtZU9iamVjdC5UKSA6IFNjaGVtZU9iamVjdC5UCiAgUkFJU0VTIHsgU2No >ZW1lLkUgfSA9IAogCiAgUFJPQ0VEVVJFIE5leHQoKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7 >IFNjaGVtZS5FIH0gPSAKICAgIEJFR0lOCiAgICAgIFRSWSBSRVRVUk4gU2NoZW1lVXRpbHMuRmly >c3QocF9fKSBGSU5BTExZIHBfXyA6PSBTY2hlbWVQYWlyLlBhaXIoU2NoZW1lVXRpbHMuUmVzdChw >X18pKSBFTkQKICAgIEVORCBOZXh0OwogCiAgVkFSIHBfXyA6PSBTY2hlbWVQYWlyLlBhaXIoYXJn >cyk7CiAgQkVHSU4KICAgIFRSWQogICAgICAoKiB1bnBhY2sgZm9ybWFscyAqKQogICAgICBWQVIg >PCpOT1dBUk4qPmp1bmtfXyA6PSAwOwogICAgICAgICAgIGZvcm1hbF9wIDo9IFNjaGVtZU1vZHVs >YTNUeXBlcy5Ub01vZHVsYV9URVhUKE5leHQoKSk7IEJFR0lOCiAgICAgICAgKCogY2Fycnkgb3V0 >IE5JTCBjaGVja3MgZm9yIG9wZW4gYXJyYXlzICopCgogICAgICAgICgqIG1ha2UgcHJvY2VkdXJl >IGNhbGwgKikKICAgICAgICBGUy5EZWxldGVEaXJlY3RvcnkoZm9ybWFsX3ApOwogICAgICAgICgq >IHVucGFjayBWQVIgcGFyYW1zICopCiAgICAgICAgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdz >KTsKICAgICAgICBFVkFMIE5leHQoKTsKCiAgICAgICAgKCogcHJvcGVyIHByb2NlZHVyZSA6IHJl >dHVybiBUUlVFICopCiAgICAgICAgUkVUVVJOIFNjaGVtZUJvb2xlYW4uVHJ1ZSgpCiAgICAgIEVO >RCgqV0lUSCopCiAgICBFWENFUFQKICAgICAgfCBPU0Vycm9yLkUoeGFyZykgPT4gRVZBTCBTY2hl >bWVBcHBseS5PbmVBcmcoaW50ZXJwLGV4Y0hhbmRsZXIsU2NoZW1lVXRpbHMuTGlzdDIoU2NoZW1l >U3ltYm9sLkZyb21UZXh0KCJxdW90ZSIpLFNjaGVtZVV0aWxzLkNvbnMoU2NoZW1lU3ltYm9sLkZy >b21UZXh0KCJPU0Vycm9yLkUiKSwgVG9TY2hlbWVfQXRvbUxpc3RfVCh4YXJnKSkpKQogICAgRU5E >OwogICAgPCpOT1dBUk4qPlJFVFVSTiBTY2hlbWVCb29sZWFuLkZhbHNlKCkKICBFTkQgQ2FsbFN0 >dWJfRlNfRGVsZXRlRGlyZWN0b3J5OwoKUFJPQ0VEVVJFIENhbGxTdHViX0ZTX0RlbGV0ZUZpbGUo >aW50ZXJwIDogU2NoZW1lLlQ7CiAgICAgICAgICAgICAgICAgICAgICBhcmdzIDogU2NoZW1lT2Jq >ZWN0LlQ7CiAgICAgICAgICAgICAgICAgICAgICBleGNIYW5kbGVyIDogU2NoZW1lT2JqZWN0LlQp >IDogU2NoZW1lT2JqZWN0LlQKICBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAKICBQUk9DRURVUkUg >TmV4dCgpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUgfSA9IAogICAgQkVHSU4K >ICAgICAgVFJZIFJFVFVSTiBTY2hlbWVVdGlscy5GaXJzdChwX18pIEZJTkFMTFkgcF9fIDo9IFNj >aGVtZVBhaXIuUGFpcihTY2hlbWVVdGlscy5SZXN0KHBfXykpIEVORAogICAgRU5EIE5leHQ7CiAK >ICBWQVIgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICBCRUdJTgogICAgVFJZCiAgICAg >ICgqIHVucGFjayBmb3JtYWxzICopCiAgICAgIFZBUiA8Kk5PV0FSTio+anVua19fIDo9IDA7CiAg >ICAgICAgICAgZm9ybWFsX3AgOj0gU2NoZW1lTW9kdWxhM1R5cGVzLlRvTW9kdWxhX1RFWFQoTmV4 >dCgpKTsgQkVHSU4KICAgICAgICAoKiBjYXJyeSBvdXQgTklMIGNoZWNrcyBmb3Igb3BlbiBhcnJh >eXMgKikKCiAgICAgICAgKCogbWFrZSBwcm9jZWR1cmUgY2FsbCAqKQogICAgICAgIEZTLkRlbGV0 >ZUZpbGUoZm9ybWFsX3ApOwogICAgICAgICgqIHVucGFjayBWQVIgcGFyYW1zICopCiAgICAgICAg >cF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICAgICAgICBFVkFMIE5leHQoKTsKCiAgICAg >ICAgKCogcHJvcGVyIHByb2NlZHVyZSA6IHJldHVybiBUUlVFICopCiAgICAgICAgUkVUVVJOIFNj >aGVtZUJvb2xlYW4uVHJ1ZSgpCiAgICAgIEVORCgqV0lUSCopCiAgICBFWENFUFQKICAgICAgfCBP >U0Vycm9yLkUoeGFyZykgPT4gRVZBTCBTY2hlbWVBcHBseS5PbmVBcmcoaW50ZXJwLGV4Y0hhbmRs >ZXIsU2NoZW1lVXRpbHMuTGlzdDIoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJxdW90ZSIpLFNjaGVt >ZVV0aWxzLkNvbnMoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJPU0Vycm9yLkUiKSwgVG9TY2hlbWVf >QXRvbUxpc3RfVCh4YXJnKSkpKQogICAgRU5EOwogICAgPCpOT1dBUk4qPlJFVFVSTiBTY2hlbWVC >b29sZWFuLkZhbHNlKCkKICBFTkQgQ2FsbFN0dWJfRlNfRGVsZXRlRmlsZTsKClBST0NFRFVSRSBD >YWxsU3R1Yl9GU19SZW5hbWUoaW50ZXJwIDogU2NoZW1lLlQ7CiAgICAgICAgICAgICAgICAgICAg >ICBhcmdzIDogU2NoZW1lT2JqZWN0LlQ7CiAgICAgICAgICAgICAgICAgICAgICBleGNIYW5kbGVy >IDogU2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQKICBSQUlTRVMgeyBTY2hlbWUuRSB9 >ID0gCiAKICBQUk9DRURVUkUgTmV4dCgpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1l >LkUgfSA9IAogICAgQkVHSU4KICAgICAgVFJZIFJFVFVSTiBTY2hlbWVVdGlscy5GaXJzdChwX18p >IEZJTkFMTFkgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihTY2hlbWVVdGlscy5SZXN0KHBfXykpIEVO >RAogICAgRU5EIE5leHQ7CiAKICBWQVIgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICBC >RUdJTgogICAgVFJZCiAgICAgICgqIHVucGFjayBmb3JtYWxzICopCiAgICAgIFZBUiA8Kk5PV0FS >Tio+anVua19fIDo9IDA7CiAgICAgICAgICAgZm9ybWFsX3AwIDo9IFNjaGVtZU1vZHVsYTNUeXBl >cy5Ub01vZHVsYV9URVhUKE5leHQoKSk7CiAgICAgICAgICAgZm9ybWFsX3AxIDo9IFNjaGVtZU1v >ZHVsYTNUeXBlcy5Ub01vZHVsYV9URVhUKE5leHQoKSk7IEJFR0lOCiAgICAgICAgKCogY2Fycnkg >b3V0IE5JTCBjaGVja3MgZm9yIG9wZW4gYXJyYXlzICopCgogICAgICAgICgqIG1ha2UgcHJvY2Vk >dXJlIGNhbGwgKikKICAgICAgICBGUy5SZW5hbWUoZm9ybWFsX3AwLCBmb3JtYWxfcDEpOwogICAg >ICAgICgqIHVucGFjayBWQVIgcGFyYW1zICopCiAgICAgICAgcF9fIDo9IFNjaGVtZVBhaXIuUGFp >cihhcmdzKTsKICAgICAgICBFVkFMIE5leHQoKTsKICAgICAgICBFVkFMIE5leHQoKTsKCiAgICAg >ICAgKCogcHJvcGVyIHByb2NlZHVyZSA6IHJldHVybiBUUlVFICopCiAgICAgICAgUkVUVVJOIFNj >aGVtZUJvb2xlYW4uVHJ1ZSgpCiAgICAgIEVORCgqV0lUSCopCiAgICBFWENFUFQKICAgICAgfCBP >U0Vycm9yLkUoeGFyZykgPT4gRVZBTCBTY2hlbWVBcHBseS5PbmVBcmcoaW50ZXJwLGV4Y0hhbmRs >ZXIsU2NoZW1lVXRpbHMuTGlzdDIoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJxdW90ZSIpLFNjaGVt >ZVV0aWxzLkNvbnMoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJPU0Vycm9yLkUiKSwgVG9TY2hlbWVf >QXRvbUxpc3RfVCh4YXJnKSkpKQogICAgRU5EOwogICAgPCpOT1dBUk4qPlJFVFVSTiBTY2hlbWVC >b29sZWFuLkZhbHNlKCkKICBFTkQgQ2FsbFN0dWJfRlNfUmVuYW1lOwoKUFJPQ0VEVVJFIENhbGxT >dHViX0ZTX0l0ZXJhdGUoaW50ZXJwIDogU2NoZW1lLlQ7CiAgICAgICAgICAgICAgICAgICAgICBh >cmdzIDogU2NoZW1lT2JqZWN0LlQ7CiAgICAgICAgICAgICAgICAgICAgICBleGNIYW5kbGVyIDog >U2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQKICBSQUlTRVMgeyBTY2hlbWUuRSB9ID0g >CiAKICBQUk9DRURVUkUgTmV4dCgpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUg >fSA9IAogICAgQkVHSU4KICAgICAgVFJZIFJFVFVSTiBTY2hlbWVVdGlscy5GaXJzdChwX18pIEZJ >TkFMTFkgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihTY2hlbWVVdGlscy5SZXN0KHBfXykpIEVORAog >ICAgRU5EIE5leHQ7CiAKICBWQVIgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICBCRUdJ >TgogICAgVFJZCiAgICAgICgqIHVucGFjayBmb3JtYWxzICopCiAgICAgIFZBUiA8Kk5PV0FSTio+ >anVua19fIDo9IDA7CiAgICAgICAgICAgZm9ybWFsX3AgOj0gU2NoZW1lTW9kdWxhM1R5cGVzLlRv >TW9kdWxhX1RFWFQoTmV4dCgpKTsgQkVHSU4KICAgICAgICAoKiBjYXJyeSBvdXQgTklMIGNoZWNr >cyBmb3Igb3BlbiBhcnJheXMgKikKCiAgICAgICAgKCogbWFrZSBwcm9jZWR1cmUgY2FsbCAqKQog >ICAgICAgIFdJVEggcmVzID0gVG9TY2hlbWVfRlNfSXRlcmF0b3IoRlMuSXRlcmF0ZShmb3JtYWxf >cCkpIERPCiAgICAgICAgKCogdW5wYWNrIFZBUiBwYXJhbXMgKikKICAgICAgICBwX18gOj0gU2No >ZW1lUGFpci5QYWlyKGFyZ3MpOwogICAgICAgIEVWQUwgTmV4dCgpOwoKICAgICAgICAoKiByZXR1 >cm4gcHJvY2VkdXJlIHJlc3VsdCAqKQogICAgICAgIFJFVFVSTiByZXMKICAgICAgICBFTkQKICAg >ICAgRU5EKCpXSVRIKikKICAgIEVYQ0VQVAogICAgICB8IE9TRXJyb3IuRSh4YXJnKSA9PiBFVkFM >IFNjaGVtZUFwcGx5Lk9uZUFyZyhpbnRlcnAsZXhjSGFuZGxlcixTY2hlbWVVdGlscy5MaXN0MihT >Y2hlbWVTeW1ib2wuRnJvbVRleHQoInF1b3RlIiksU2NoZW1lVXRpbHMuQ29ucyhTY2hlbWVTeW1i >b2wuRnJvbVRleHQoIk9TRXJyb3IuRSIpLCBUb1NjaGVtZV9BdG9tTGlzdF9UKHhhcmcpKSkpCiAg >ICBFTkQ7CiAgICA8Kk5PV0FSTio+UkVUVVJOIFNjaGVtZUJvb2xlYW4uRmFsc2UoKQogIEVORCBD >YWxsU3R1Yl9GU19JdGVyYXRlOwoKUFJPQ0VEVVJFIENhbGxTdHViX0ZTX1N0YXR1cyhpbnRlcnAg >OiBTY2hlbWUuVDsKICAgICAgICAgICAgICAgICAgICAgIGFyZ3MgOiBTY2hlbWVPYmplY3QuVDsK >ICAgICAgICAgICAgICAgICAgICAgIGV4Y0hhbmRsZXIgOiBTY2hlbWVPYmplY3QuVCkgOiBTY2hl >bWVPYmplY3QuVAogIFJBSVNFUyB7IFNjaGVtZS5FIH0gPSAKIAogIFBST0NFRFVSRSBOZXh0KCkg >OiBTY2hlbWVPYmplY3QuVCBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAgICBCRUdJTgogICAgICBU >UlkgUkVUVVJOIFNjaGVtZVV0aWxzLkZpcnN0KHBfXykgRklOQUxMWSBwX18gOj0gU2NoZW1lUGFp >ci5QYWlyKFNjaGVtZVV0aWxzLlJlc3QocF9fKSkgRU5ECiAgICBFTkQgTmV4dDsKIAogIFZBUiBw >X18gOj0gU2NoZW1lUGFpci5QYWlyKGFyZ3MpOwogIEJFR0lOCiAgICBUUlkKICAgICAgKCogdW5w >YWNrIGZvcm1hbHMgKikKICAgICAgVkFSIDwqTk9XQVJOKj5qdW5rX18gOj0gMDsKICAgICAgICAg >ICBmb3JtYWxfcCA6PSBTY2hlbWVNb2R1bGEzVHlwZXMuVG9Nb2R1bGFfVEVYVChOZXh0KCkpOyBC >RUdJTgogICAgICAgICgqIGNhcnJ5IG91dCBOSUwgY2hlY2tzIGZvciBvcGVuIGFycmF5cyAqKQoK >ICAgICAgICAoKiBtYWtlIHByb2NlZHVyZSBjYWxsICopCiAgICAgICAgV0lUSCByZXMgPSBUb1Nj >aGVtZV9GaWxlX1N0YXR1cyhGUy5TdGF0dXMoZm9ybWFsX3ApKSBETwogICAgICAgICgqIHVucGFj >ayBWQVIgcGFyYW1zICopCiAgICAgICAgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICAg >ICAgICBFVkFMIE5leHQoKTsKCiAgICAgICAgKCogcmV0dXJuIHByb2NlZHVyZSByZXN1bHQgKikK >ICAgICAgICBSRVRVUk4gcmVzCiAgICAgICAgRU5ECiAgICAgIEVORCgqV0lUSCopCiAgICBFWENF >UFQKICAgICAgfCBPU0Vycm9yLkUoeGFyZykgPT4gRVZBTCBTY2hlbWVBcHBseS5PbmVBcmcoaW50 >ZXJwLGV4Y0hhbmRsZXIsU2NoZW1lVXRpbHMuTGlzdDIoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJx >dW90ZSIpLFNjaGVtZVV0aWxzLkNvbnMoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJPU0Vycm9yLkUi >KSwgVG9TY2hlbWVfQXRvbUxpc3RfVCh4YXJnKSkpKQogICAgRU5EOwogICAgPCpOT1dBUk4qPlJF >VFVSTiBTY2hlbWVCb29sZWFuLkZhbHNlKCkKICBFTkQgQ2FsbFN0dWJfRlNfU3RhdHVzOwoKUFJP >Q0VEVVJFIENhbGxTdHViX0ZTX1NldE1vZGlmaWNhdGlvblRpbWUoaW50ZXJwIDogU2NoZW1lLlQ7 >CiAgICAgICAgICAgICAgICAgICAgICBhcmdzIDogU2NoZW1lT2JqZWN0LlQ7CiAgICAgICAgICAg >ICAgICAgICAgICBleGNIYW5kbGVyIDogU2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQK >ICBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAKICBQUk9DRURVUkUgTmV4dCgpIDogU2NoZW1lT2Jq >ZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUgfSA9IAogICAgQkVHSU4KICAgICAgVFJZIFJFVFVSTiBT >Y2hlbWVVdGlscy5GaXJzdChwX18pIEZJTkFMTFkgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihTY2hl >bWVVdGlscy5SZXN0KHBfXykpIEVORAogICAgRU5EIE5leHQ7CiAKICBWQVIgcF9fIDo9IFNjaGVt >ZVBhaXIuUGFpcihhcmdzKTsKICBCRUdJTgogICAgVFJZCiAgICAgICgqIHVucGFjayBmb3JtYWxz >ICopCiAgICAgIFZBUiA8Kk5PV0FSTio+anVua19fIDo9IDA7CiAgICAgICAgICAgZm9ybWFsX3Ag >Oj0gU2NoZW1lTW9kdWxhM1R5cGVzLlRvTW9kdWxhX1RFWFQoTmV4dCgpKTsKICAgICAgICAgICBm >b3JtYWxfdCA6PSBTY2hlbWVNb2R1bGEzVHlwZXMuVG9Nb2R1bGFfTE9OR1JFQUwoTmV4dCgpKTsg >QkVHSU4KICAgICAgICAoKiBjYXJyeSBvdXQgTklMIGNoZWNrcyBmb3Igb3BlbiBhcnJheXMgKikK >CiAgICAgICAgKCogbWFrZSBwcm9jZWR1cmUgY2FsbCAqKQogICAgICAgIEZTLlNldE1vZGlmaWNh >dGlvblRpbWUoZm9ybWFsX3AsIGZvcm1hbF90KTsKICAgICAgICAoKiB1bnBhY2sgVkFSIHBhcmFt >cyAqKQogICAgICAgIHBfXyA6PSBTY2hlbWVQYWlyLlBhaXIoYXJncyk7CiAgICAgICAgRVZBTCBO >ZXh0KCk7CiAgICAgICAgRVZBTCBOZXh0KCk7CgogICAgICAgICgqIHByb3BlciBwcm9jZWR1cmUg >OiByZXR1cm4gVFJVRSAqKQogICAgICAgIFJFVFVSTiBTY2hlbWVCb29sZWFuLlRydWUoKQogICAg >ICBFTkQoKldJVEgqKQogICAgRVhDRVBUCiAgICAgIHwgT1NFcnJvci5FKHhhcmcpID0+IEVWQUwg >U2NoZW1lQXBwbHkuT25lQXJnKGludGVycCxleGNIYW5kbGVyLFNjaGVtZVV0aWxzLkxpc3QyKFNj >aGVtZVN5bWJvbC5Gcm9tVGV4dCgicXVvdGUiKSxTY2hlbWVVdGlscy5Db25zKFNjaGVtZVN5bWJv >bC5Gcm9tVGV4dCgiT1NFcnJvci5FIiksIFRvU2NoZW1lX0F0b21MaXN0X1QoeGFyZykpKSkKICAg >IEVORDsKICAgIDwqTk9XQVJOKj5SRVRVUk4gU2NoZW1lQm9vbGVhbi5GYWxzZSgpCiAgRU5EIENh >bGxTdHViX0ZTX1NldE1vZGlmaWNhdGlvblRpbWU7CgoKUFJPQ0VEVVJFIFJlZ2lzdGVyU3R1YnMo >KSA9IAogIEJFR0lOCiAgICBTY2hlbWVQcm9jZWR1cmVTdHVicy5SZWdpc3Rlck9wKFRZUEVDT0RF >KEZTLkl0ZXJhdG9yKSwiY2FsbC1tZXRob2QiLE1ldGhvZERpc3BhdGNoZXJfRlNfSXRlcmF0b3Ip >OwogICAgU2NoZW1lUHJvY2VkdXJlU3R1YnMuUmVnaXN0ZXJOZXcoTkVXKFNjaGVtZVByb2NlZHVy >ZVN0dWJzLlFpZCwgaW50ZiA6PSBBdG9tLkZyb21UZXh0KCJGUyIpLCBpdGVtIDo9IEF0b20uRnJv >bVRleHQoIkl0ZXJhdG9yIikpLCBOZXdfRlNfSXRlcmF0b3IpOwogICAgU2NoZW1lUHJvY2VkdXJl >U3R1YnMuUmVnaXN0ZXJPcChUWVBFQ09ERShGUy5JdGVyYXRvciksIm5ldyIsR2VuTmV3X0ZTX0l0 >ZXJhdG9yKTsKICAgIFNjaGVtZVByb2NlZHVyZVN0dWJzLlJlZ2lzdGVyT3AoVFlQRUNPREUoRlMu >SXRlcmF0b3IpLCJnZXQtZmllbGQiLEZpZWxkR2V0X0ZTX0l0ZXJhdG9yKTsKICAgIFNjaGVtZVBy >b2NlZHVyZVN0dWJzLlJlZ2lzdGVyT3AoVFlQRUNPREUoRlMuSXRlcmF0b3IpLCJzZXQtZmllbGQh >IixGaWVsZFNldF9GU19JdGVyYXRvcik7CiAgICBTY2hlbWVQcm9jZWR1cmVTdHVicy5SZWdpc3Rl >clRDKFRZUEVDT0RFKEZTLkl0ZXJhdG9yKSwiRlMuSXRlcmF0b3IiKTsKICAgIFNjaGVtZVByb2Nl >ZHVyZVN0dWJzLlJlZ2lzdGVyT3AoVFlQRUNPREUoRlMuUHVibGljSXRlcmF0b3IpLCJjYWxsLW1l >dGhvZCIsTWV0aG9kRGlzcGF0Y2hlcl9GU19QdWJsaWNJdGVyYXRvcik7CiAgICBTY2hlbWVQcm9j >ZWR1cmVTdHVicy5SZWdpc3Rlck5ldyhORVcoU2NoZW1lUHJvY2VkdXJlU3R1YnMuUWlkLCBpbnRm >IDo9IEF0b20uRnJvbVRleHQoIkZTIiksIGl0ZW0gOj0gQXRvbS5Gcm9tVGV4dCgiUHVibGljSXRl >cmF0b3IiKSksIE5ld19GU19QdWJsaWNJdGVyYXRvcik7CiAgICBTY2hlbWVQcm9jZWR1cmVTdHVi >cy5SZWdpc3Rlck9wKFRZUEVDT0RFKEZTLlB1YmxpY0l0ZXJhdG9yKSwibmV3IixHZW5OZXdfRlNf >UHVibGljSXRlcmF0b3IpOwogICAgU2NoZW1lUHJvY2VkdXJlU3R1YnMuUmVnaXN0ZXJPcChUWVBF >Q09ERShGUy5QdWJsaWNJdGVyYXRvciksImdldC1maWVsZCIsRmllbGRHZXRfRlNfUHVibGljSXRl >cmF0b3IpOwogICAgU2NoZW1lUHJvY2VkdXJlU3R1YnMuUmVnaXN0ZXJPcChUWVBFQ09ERShGUy5Q >dWJsaWNJdGVyYXRvciksInNldC1maWVsZCEiLEZpZWxkU2V0X0ZTX1B1YmxpY0l0ZXJhdG9yKTsK >ICAgIFNjaGVtZVByb2NlZHVyZVN0dWJzLlJlZ2lzdGVyVEMoVFlQRUNPREUoRlMuUHVibGljSXRl >cmF0b3IpLCJGUy5QdWJsaWNJdGVyYXRvciIpOwogICAgVkFSCiAgICAgIEFyZ19UQyA6PSBBUlJB >WSBbMC4uM10gT0YgWy0xLi5MQVNUKFJUMC5UeXBlY29kZSldIHsgLTEsIC0xLCBUWVBFQ09ERShG >Uy5JdGVyYXRvciksIFRZUEVDT0RFKEZTLlB1YmxpY0l0ZXJhdG9yKX07CiAgICBDT05TVAogICAg >ICBBcmdfTmFtZXMgPSBBUlJBWSBPRiBURVhUIHsgIkZTLkNyZWF0ZU9wdGlvbiIsICJGUy5BY2Nl >c3NPcHRpb24iLCAiRlMuSXRlcmF0b3IiLCAiRlMuUHVibGljSXRlcmF0b3IifTsKICAgICAgQXJn >X1BpY2tsZSA9IEFSUkFZIE9GIENIQVIgeyBWQUwoMzgsQ0hBUiksIFZBTCgzNyxDSEFSKSwgVkFM >KDUwLENIQVIpLCBWQUwoNzMsQ0hBUiksIFZBTCg3NixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >NzgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgxMTAsQ0hBUiksIFZBTCgx >MTcsQ0hBUiksIFZBTCgxMDgsQ0hBUiksIFZBTCgxMDgsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDEyOCxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDIy >MCxDSEFSKSwgVkFMKDE5NCxDSEFSKSwgVkFMKDU1LENIQVIpLCBWQUwoMjE3LENIQVIpLCBWQUwo >MTUsQ0hBUiksIFZBTCgyMDUsQ0hBUiksIFZBTCg4OCxDSEFSKSwgVkFMKDMwLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDIyOSxDSEFSKSwgVkFMKDYzLENIQVIpLCBWQUwoMzcsQ0hBUiksIFZBTCgxOTMs >Q0hBUiksIFZBTCgyMSxDSEFSKSwgVkFMKDU5LENIQVIpLCBWQUwoMjE3LENIQVIpLCBWQUwoMTgs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgyMjcsQ0hBUiksIFZBTCgyMTEs >Q0hBUiksIFZBTCgxNjEsQ0hBUiksIFZBTCg5OCxDSEFSKSwgVkFMKDQxLENIQVIpLCBWQUwoNDAs >Q0hBUiksIFZBTCgyNixDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwoMTEsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg4NSxDSEFSKSwgVkFMKDExNSxDSEFS >KSwgVkFMKDEwMSxDSEFSKSwgVkFMKDExNCxDSEFSKSwgVkFMKDY4LENIQVIpLCBWQUwoMTAxLENI >QVIpLCBWQUwoMTAyLENIQVIpLCBWQUwoMTA1LENIQVIpLCBWQUwoMTEwLENIQVIpLCBWQUwoMTAx >LENIQVIpLCBWQUwoMTAwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCg1LENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgx >MDgsQ0hBUiksIFZBTCgxMDUsQ0hBUiksIFZBTCg5NyxDSEFSKSwgVkFMKDExNSxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoODEsQ0hBUiksIFZBTCgxMDUsQ0hBUiks >IFZBTCgxMDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgxMDUsQ0hBUiksIFZBTCgxMTAsQ0hB >UiksIFZBTCgxMTYsQ0hBUiksIFZBTCgxMDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hB >UiksIFZBTCg1MyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgxNTYsQ0hBUiksIFZBTCgyMTIsQ0hB >UiksIFZBTCgxNyxDSEFSKSwgVkFMKDE2NCxDSEFSKSwgVkFMKDE3OCxDSEFSKSwgVkFMKDE5NixD >SEFSKSwgVkFMKDU4LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNzAsQ0hBUiksIFZBTCg4MyxDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDEwNSxDSEFSKSwgVkFMKDExNixDSEFSKSwgVkFMKDEwMSxDSEFS >KSwgVkFMKDEwOSxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg4OCxDSEFSKSwgVkFMKDU4LENIQVIpLCBW >QUwoNDQsQ0hBUiksIFZBTCgyMzAsQ0hBUiksIFZBTCgxODQsQ0hBUiksIFZBTCgxMzMsQ0hBUiks >IFZBTCg4NyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCgxMixDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDY3LENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwo >MTAxLENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMTYsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZB >TCg3OSxDSEFSKSwgVkFMKDExMixDSEFSKSwgVkFMKDExNixDSEFSKSwgVkFMKDEwNSxDSEFSKSwg >VkFMKDExMSxDSEFSKSwgVkFMKDExMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIp >LCBWQUwoNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDExMCxDSEFSKSwgVkFMKDk3LENIQVIpLCBWQUwoMTA5LENIQVIpLCBWQUwoMTAxLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >OSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTUsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDQ5LENIQVIpLCBWQUwoMTksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDIxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFM >KDcsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgxMTgs >Q0hBUiksIFZBTCgxMDUsQ0hBUiksIFZBTCgxMTUsQ0hBUiksIFZBTCgxMDUsQ0hBUiksIFZBTCgx >MTYsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZBTCgxMDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgxODcsQ0hBUiksIFZBTCgxNCxDSEFSKSwgVkFMKDQ2LENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgyMjcsQ0hBUiksIFZBTCgxOTIsQ0hBUiksIFZBTCgyNixDSEFSKSwgVkFM >KDE5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoOCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDk4LENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwoOTcs >Q0hBUiksIFZBTCgxMTAsQ0hBUiksIFZBTCgxMDAsQ0hBUiksIFZBTCgxMTUsQ0hBUiksIFZBTCg3 >OSxDSEFSKSwgVkFMKDc1LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg3LENIQVIpLCBWQUwoMSxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0 >LENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDEwMSxDSEFSKSwgVkFMKDEwOCxDSEFSKSwgVkFMKDExNixDSEFSKSwgVkFMKDExNSxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCg2LENIQVIpLCBW >QUwoNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDc4 >LENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoMTE4LENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwo >MTE0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCgxLENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg3OSxDSEFSKSwgVkFMKDEwNyxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDYsQ0hB >UiksIFZBTCg2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNjUsQ0hBUiksIFZBTCgxMDgsQ0hBUiksIFZBTCgxMTksQ0hBUiksIFZBTCg5NyxDSEFSKSwg >VkFMKDEyMSxDSEFSKSwgVkFMKDExNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFS >KSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDIsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MTMsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDE1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE5LENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDEyLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNjUsQ0hBUiksIFZB >TCg5OSxDSEFSKSwgVkFMKDk5LENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoMTE1LENIQVIpLCBW >QUwoMTE1LENIQVIpLCBWQUwoNzksQ0hBUiksIFZBTCgxMTIsQ0hBUiksIFZBTCgxMTYsQ0hBUiks >IFZBTCgxMDUsQ0hBUiksIFZBTCgxMTEsQ0hBUiksIFZBTCgxMTAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDEzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNDksQ0hBUiksIFZBTCgxNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOSxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBW >QUwoNjQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0 >OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzNCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBW >QUwoMzYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzksQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDQxLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDQ0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgyNDUsQ0hBUiksIFZBTCgyMjksQ0hBUiksIFZBTCgxMTQsQ0hBUiksIFZBTCg4 >MyxDSEFSKSwgVkFMKDIwMixDSEFSKSwgVkFMKDEzLENIQVIpLCBWQUwoMTY2LENIQVIpLCBWQUwo >MjYsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMjMs >Q0hBUiksIFZBTCgxMTQsQ0hBUiksIFZBTCg3OSxDSEFSKSwgVkFMKDE1OCxDSEFSKSwgVkFMKDE1 >OSxDSEFSKSwgVkFMKDE1NSxDSEFSKSwgVkFMKDE5NixDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwo >MTcsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg3OSxD >SEFSKSwgVkFMKDExMCxDSEFSKSwgVkFMKDEwOCxDSEFSKSwgVkFMKDEyMSxDSEFSKSwgVkFMKDc5 >LENIQVIpLCBWQUwoMTE5LENIQVIpLCBWQUwoMTEwLENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwo >MTE0LENIQVIpLCBWQUwoNjcsQ0hBUiksIFZBTCg5NyxDSEFSKSwgVkFMKDExMCxDSEFSKSwgVkFM >KDgyLENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDYsQ0hB >UiksIFZBTCg4LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoODIsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZBTCg5NyxDSEFSKSwgVkFMKDEwMCxDSEFSKSwg >VkFMKDc5LENIQVIpLCBWQUwoMTEwLENIQVIpLCBWQUwoMTA4LENIQVIpLCBWQUwoMTIxLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDcsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg2OCxDSEFSKSwgVkFMKDEw >MSxDSEFSKSwgVkFMKDEwMixDSEFSKSwgVkFMKDk3LENIQVIpLCBWQUwoMTE3LENIQVIpLCBWQUwo >MTA4LENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDc5LENIQVIpLCBWQUwoMTEyLENIQVIpLCBWQUwoOTcsQ0hBUiks >IFZBTCgxMTMsQ0hBUiksIFZBTCgxMTcsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTMs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDE1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE5LENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDgsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg3MyxDSEFSKSwgVkFMKDEx >NixDSEFSKSwgVkFMKDEwMSxDSEFSKSwgVkFMKDExNCxDSEFSKSwgVkFMKDk3LENIQVIpLCBWQUwo >MTE2LENIQVIpLCBWQUwoMTExLENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTMs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDE1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE5LENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzNCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzYsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDQxLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCg2LENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMTE2LENIQVIp >LCBWQUwoMTE0LENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCg5OSxDSEFSKSwgVkFMKDEwMSxDSEFS >KSwgVkFMKDEwMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzYsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDcsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg5OCxDSEFSKSwg >VkFMKDExNCxDSEFSKSwgVkFMKDk3LENIQVIpLCBWQUwoMTEwLENIQVIpLCBWQUwoMTAwLENIQVIp >LCBWQUwoMTAxLENIQVIpLCBWQUwoMTAwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzNixDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENI >QVIpLCBWQUwoNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDk4LENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMTAsQ0hBUiks >IFZBTCgxMDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNyxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDExNCxDSEFS >KSwgVkFMKDEwMSxDSEFSKSwgVkFMKDExOCxDSEFSKSwgVkFMKDczLENIQVIpLCBWQUwoMTEwLENI >QVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoMTAyLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoNCxDSEFSKSwgVkFMKDE3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoMTE4LENIQVIpLCBWQUwo >MTAxLENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMDgsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZB >TCgxMDAsQ0hBUiksIFZBTCg4MyxDSEFSKSwgVkFMKDExNyxDSEFSKSwgVkFMKDExMixDSEFSKSwg >VkFMKDEwMSxDSEFSKSwgVkFMKDExNCxDSEFSKSwgVkFMKDg0LENIQVIpLCBWQUwoMTIxLENIQVIp >LCBWQUwoMTEyLENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoNCxDSEFSKSwgVkFMKDYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCg3OSxDSEFSKSwgVkFMKDk4LENIQVIpLCBWQUwoMTA2LENIQVIpLCBWQUwoMTAx >LENIQVIpLCBWQUwoOTksQ0hBUiksIFZBTCgxMTYsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NDksQ0hBUiksIFZBTCg5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDEzLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgx >NSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDYsQ0hBUiksIFZBTCgxNCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDgwLENIQVIpLCBWQUwoMTE3LENIQVIp >LCBWQUwoOTgsQ0hBUiksIFZBTCgxMDgsQ0hBUiksIFZBTCgxMDUsQ0hBUiksIFZBTCg5OSxDSEFS >KSwgVkFMKDczLENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoMTE0LENI >QVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMTYsQ0hBUiksIFZBTCgxMTEsQ0hBUiksIFZBTCgxMTQs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzNixDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNDksQ0hBUiksIFZBTCgzOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoNDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBW >QUwoMTE1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >NDksQ0hBUiksIFZBTCgzNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMTksQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDEyMyxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDEyNyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCg1 >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMTE1LENI >QVIpLCBWQUwoMTE3LENIQVIpLCBWQUwoMTEyLENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoMTE0 >LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDYsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgxMDIsQ0hBUiksIFZBTCgx >MDUsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZBTCgxMDgsQ0hBUiksIFZBTCgxMDAsQ0hBUiksIFZB >TCgxMTUsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFM >KDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNyxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDEwOSxDSEFSKSwg >VkFMKDEwMSxDSEFSKSwgVkFMKDExNixDSEFSKSwgVkFMKDEwNCxDSEFSKSwgVkFMKDExMSxDSEFS >KSwgVkFMKDEwMCxDSEFSKSwgVkFMKDExNSxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwo >NixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDc3LENI >QVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoMTA0LENIQVIpLCBWQUwoMTEx >LENIQVIpLCBWQUwoMTAwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDI1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwo >NCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDExMCxD >SEFSKSwgVkFMKDEwMSxDSEFSKSwgVkFMKDEyMCxDSEFSKSwgVkFMKDExNixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiks >IFZBTCg0LENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDExNSxDSEFSKSwgVkFMKDEwNSxDSEFSKSwgVkFMKDEwMyxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCg5LENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoODMsQ0hBUiksIFZBTCgxMDUsQ0hBUiks >IFZBTCgxMDMsQ0hBUiksIFZBTCgxMTAsQ0hBUiksIFZBTCg5NyxDSEFSKSwgVkFMKDExNixDSEFS >KSwgVkFMKDExNyxDSEFSKSwgVkFMKDExNCxDSEFSKSwgVkFMKDEwMSxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCg0LENIQVIpLCBWQUwoNyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDEwMixDSEFSKSwgVkFMKDExMSxDSEFSKSwgVkFMKDExNCxDSEFSKSwgVkFMKDEw >OSxDSEFSKSwgVkFMKDk3LENIQVIpLCBWQUwoMTA4LENIQVIpLCBWQUwoMTE1LENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxD >SEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDQsQ0hBUiksIFZBTCg2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoNzAsQ0hBUiksIFZBTCgxMTEsQ0hBUiksIFZBTCgxMTQsQ0hBUiksIFZB >TCgxMDksQ0hBUiksIFZBTCg5NyxDSEFSKSwgVkFMKDEwOCxDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENI >QVIpLCBWQUwoNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDEwOSxDSEFSKSwgVkFMKDExMSxDSEFSKSwgVkFMKDEwMCxDSEFSKSwgVkFMKDEwMSxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwg >VkFMKDgsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg3 >NyxDSEFSKSwgVkFMKDExMSxDSEFSKSwgVkFMKDEwMCxDSEFSKSwgVkFMKDEwMSxDSEFSKSwgVkFM >KDQ2LENIQVIpLCBWQUwoODYsQ0hBUiksIFZBTCg5NyxDSEFSKSwgVkFMKDExNCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCg0LENIQVIpLCBWQUwoNyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDExMSxDSEFSKSwgVkFMKDExNyxDSEFSKSwgVkFMKDExNixDSEFSKSwg >VkFMKDc5LENIQVIpLCBWQUwoMTEwLENIQVIpLCBWQUwoMTA4LENIQVIpLCBWQUwoMTIxLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCgzNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoMjUsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoNCxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgxMTYsQ0hBUiksIFZBTCgxMjEsQ0hBUiksIFZBTCgxMTIsQ0hBUiks >IFZBTCgxMDEsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNDksQ0hBUiksIFZBTCg5MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDksQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDQ5LENIQVIpLCBWQUwoMTMsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE5LENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDg0LENIQVIpLCBWQUwoNjksQ0hBUiksIFZB >TCg4OCxDSEFSKSwgVkFMKDg0LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDM5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCg0MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMTUs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDExOSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzYsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTIzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDQ5LENIQVIpLCBWQUwoMTI3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENI >QVIpLCBWQUwoMTMxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDksQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg4MixDSEFSKSwgVkFMKDEwMSxD >SEFSKSwgVkFMKDEwMixDSEFSKSwgVkFMKDEwMSxDSEFSKSwgVkFMKDExNCxDSEFSKSwgVkFMKDEw >MSxDSEFSKSwgVkFMKDExMCxDSEFSKSwgVkFMKDk5LENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxD >SEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiks >IFZBTCgxMyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDQ5LENIQVIpLCBWQUwoMjE0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE5LENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDgyLENIQVIpLCBWQUwoNjksQ0hB >UiksIFZBTCg3MCxDSEFSKSwgVkFMKDY1LENIQVIpLCBWQUwoNzgsQ0hBUiksIFZBTCg4OSxDSEFS >KSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDM0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDks >Q0hBUiksIFZBTCgzNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzOSxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoNDEs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTE1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0MSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNDksQ0hBUiksIFZBTCgxMTksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDEyMyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDEyNyxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4LENIQVIp >LCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNyxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDEwMCxDSEFS >KSwgVkFMKDEwMSxDSEFSKSwgVkFMKDEwMixDSEFSKSwgVkFMKDk3LENIQVIpLCBWQUwoMTE3LENI >QVIpLCBWQUwoMTA4LENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxD >SEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCg2LENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwoMTAx >LENIQVIpLCBWQUwoMTE1LENIQVIpLCBWQUwoMTE3LENIQVIpLCBWQUwoMTA4LENIQVIpLCBWQUwo >MTE2LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxD >SEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDksQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMTMsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDIxNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgx >OSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDcsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg2NixDSEFSKSwgVkFM >KDc5LENIQVIpLCBWQUwoNzksQ0hBUiksIFZBTCg3NixDSEFSKSwgVkFMKDY5LENIQVIpLCBWQUwo >NjUsQ0hBUiksIFZBTCg3OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDM0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCgzOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDQ5LENIQVIpLCBWQUwoNDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoNDQsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDcwLENIQVIpLCBWQUwoNjUsQ0hBUiksIFZBTCg3NixDSEFS >KSwgVkFMKDgzLENIQVIpLCBWQUwoNjksQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCg0LENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDg0LENIQVIpLCBWQUwoODIsQ0hBUiksIFZBTCg4NSxDSEFSKSwgVkFMKDY5LENI >QVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwo >NixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDExNCxD >SEFSKSwgVkFMKDk3LENIQVIpLCBWQUwoMTA1LENIQVIpLCBWQUwoMTE1LENIQVIpLCBWQUwoMTAx >LENIQVIpLCBWQUwoMTE1LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxNzEsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCg2LENIQVIpLCBWQUwoMTQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgxMTAsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZBTCgxMjAsQ0hBUiksIFZB >TCgxMTYsQ0hBUiksIFZBTCg4NyxDSEFSKSwgVkFMKDEwNSxDSEFSKSwgVkFMKDExNixDSEFSKSwg >VkFMKDEwNCxDSEFSKSwgVkFMKDgzLENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoOTcsQ0hBUiks >IFZBTCgxMTYsQ0hBUiksIFZBTCgxMTcsQ0hBUiksIFZBTCgxMTUsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgx >NzksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxODIsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTg2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDE5MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOTQsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE5NixDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyMDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0 >OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgy >MDYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDIwOCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOTAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTk0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOTYsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMjAwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgy >NSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDYsQ0hBUiks >IFZBTCg0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MTE1LENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMTYsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjA2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFM >KDYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg4MixD >SEFSKSwgVkFMKDEwMSxDSEFSKSwgVkFMKDk5LENIQVIpLCBWQUwoMTExLENIQVIpLCBWQUwoMTE0 >LENIQVIpLCBWQUwoMTAwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDI1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >OSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDYsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNzAsQ0hBUiksIFZBTCgxMDUsQ0hBUiks >IFZBTCgxMDgsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MTksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCg2LENIQVIp >LCBWQUwoNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDgzLENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMTYsQ0hBUiksIFZB >TCgxMTcsQ0hBUiksIFZBTCgxMTUsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiks >IFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzQsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiks >IFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFM >KDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0MSxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NDksQ0hBUiksIFZBTCgxNjMsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDUsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg3MCxDSEFSKSwgVkFMKDEwNSxDSEFSKSwgVkFMKDEw >MSxDSEFSKSwgVkFMKDEwOCxDSEFSKSwgVkFMKDEwMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjA2LENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDIwNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDkxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxD >SEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiks >IFZBTCgxMyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDYs >Q0hBUiksIFZBTCg0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNjUsQ0hBUiksIFZBTCgxMTYsQ0hBUiksIFZBTCgxMTEsQ0hBUiksIFZBTCgxMDksQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCg2LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDg0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoMzQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM5LENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZB >TCg0MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMTUsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDExOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzYsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENI >QVIpLCBWQUwoMTIzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MTI3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTMxLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZB >TCgyMzQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0 >OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0LENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZB >TCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5NixD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCg5LENIQVIpLCBWQUwoMTcsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgxMDksQ0hBUiksIFZBTCgxMTEsQ0hBUiksIFZBTCgxMDAsQ0hBUiksIFZB >TCgxMDUsQ0hBUiksIFZBTCgxMDIsQ0hBUiksIFZBTCgxMDUsQ0hBUiksIFZBTCg5OSxDSEFSKSwg >VkFMKDk3LENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoMTA1LENIQVIpLCBWQUwoMTExLENIQVIp >LCBWQUwoMTEwLENIQVIpLCBWQUwoODQsQ0hBUiksIFZBTCgxMDUsQ0hBUiksIFZBTCgxMDksQ0hB >UiksIFZBTCgxMDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg0OSxDSEFSKSwgVkFMKDIwNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCg4LENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNzYsQ0hBUiksIFZB >TCgxMTEsQ0hBUiksIFZBTCgxMTAsQ0hBUiksIFZBTCgxMDMsQ0hBUiksIFZBTCg4MixDSEFSKSwg >VkFMKDEwMSxDSEFSKSwgVkFMKDk3LENIQVIpLCBWQUwoMTA4LENIQVIpLCBWQUwoNTMsQ0hBUiks >IFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFM >KDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDQ5LENIQVIpLCBWQUwoOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMyxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoMjE0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE5LENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoOCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDc2LENIQVIpLCBWQUwoNzksQ0hBUiksIFZBTCg3 >OCxDSEFSKSwgVkFMKDcxLENIQVIpLCBWQUwoODIsQ0hBUiksIFZBTCg2OSxDSEFSKSwgVkFMKDY1 >LENIQVIpLCBWQUwoNzYsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxD >SEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCgzNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoMzksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg0OSxDSEFSKSwgVkFMKDQxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoNCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENI >QVIpLCBWQUwoOTYsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hB >UiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMTE1LENIQVIpLCBWQUwoMTA1LENIQVIpLCBW >QUwoMTIyLENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0 >OSxDSEFSKSwgVkFMKDIwNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCg4LENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoODMsQ0hBUiksIFZBTCgx >MTcsQ0hBUiksIFZBTCg5OCxDSEFSKSwgVkFMKDExNCxDSEFSKSwgVkFMKDk3LENIQVIpLCBWQUwo >MTEwLENIQVIpLCBWQUwoMTAzLENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFM >KDQ5LENIQVIpLCBWQUwoMzQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDM5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDks >Q0hBUiksIFZBTCg0MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDk4LENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMTUsQ0hB >UiksIFZBTCgxMDEsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCgxNjYsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5LENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDEzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyMTQsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENI >QVIpLCBWQUwoMTksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZB >TCg3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNzYs >Q0hBUiksIFZBTCg3OSxDSEFSKSwgVkFMKDc4LENIQVIpLCBWQUwoNzEsQ0hBUiksIFZBTCg3MyxD >SEFSKSwgVkFMKDc4LENIQVIpLCBWQUwoODQsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzYsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDQ5LENIQVIpLCBWQUwoMzksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDQxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDE3NixDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDQ5LENIQVIpLCBWQUwoMTc4LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hBUiks >IFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMTA5LENIQVIpLCBWQUwoMTA1LENIQVIpLCBWQUwo >MTEwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDcsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg3NixDSEFSKSwg >VkFMKDExMSxDSEFSKSwgVkFMKDExMCxDSEFSKSwgVkFMKDEwMyxDSEFSKSwgVkFMKDEwNSxDSEFS >KSwgVkFMKDExMCxDSEFSKSwgVkFMKDExNixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgxNCxDSEFSKSwgVkFMKDQ2LENIQVIpLCBWQUwoMjQwLENIQVIp >LCBWQUwoNzcsQ0hBUiksIFZBTCgxNSxDSEFSKSwgVkFMKDE1MyxDSEFSKSwgVkFMKDc2LENIQVIp >LCBWQUwoMjMsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgyMjQsQ0hBUiksIFZBTCgx >OTUsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgxMDksQ0hBUiksIFZBTCg5NyxDSEFSKSwgVkFM >KDEyMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0 >OSxDSEFSKSwgVkFMKDE5OSxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDEwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMjI0LENIQVIpLCBWQUwoNjcsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOTYsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCg0LENIQVIpLCBWQUwoNyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDc5LENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwoMTAwLENIQVIpLCBWQUwoMTA1 >LENIQVIpLCBWQUwoMTEwLENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMDgsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgxMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDIwNCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDIxMSxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDEwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMTM0LENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgyMDgsQ0hBUiksIFZBTCgxOTMsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4 >LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoNCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNDksQ0hBUiksIFZBTCg4LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCgzNCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFS >KSwgVkFMKDksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg2OSxDSEFSKSwgVkFMKDEyMCxDSEFSKSwgVkFMKDk5LENIQVIpLCBWQUwoMTAxLENIQVIpLCBW >QUwoMTEyLENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoMTA1LENIQVIpLCBWQUwoMTExLENIQVIp >LCBWQUwoMTEwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMTEzLENIQVIpLCBWQUwoMTA1LENI >QVIpLCBWQUwoMTAwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDQ5LENIQVIpLCBWQUwoOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMyxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDYsQ0hBUiksIFZB >TCg3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNzks >Q0hBUiksIFZBTCg4MyxDSEFSKSwgVkFMKDY5LENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwoMTE0 >LENIQVIpLCBWQUwoMTExLENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiks >IFZBTCgxLENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg2OSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMTQsQ0hB >UiksIFZBTCgxMDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCgxMzQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5LENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDEzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDgsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg2NSxDSEFSKSwgVkFMKDExNixDSEFSKSwgVkFMKDExMSxD >SEFSKSwgVkFMKDEwOSxDSEFSKSwgVkFMKDc2LENIQVIpLCBWQUwoMTA1LENIQVIpLCBWQUwoMTE1 >LENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTks >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDExMixDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM0 >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCgzNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzOSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoNDEsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTE1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzNixDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NDksQ0hBUiksIFZBTCgxMTksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDEyMyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4 >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDEyNyxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE1OSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE2MyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCg5NixDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDYsQ0hBUiksIFZBTCg0LENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMTA0LENIQVIpLCBWQUwo >MTAxLENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENI >QVIpLCBWQUwoMjA2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCgxMDIsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoNCxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4LENIQVIp >LCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >OTYsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCg2LENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDExNixDSEFSKSwgVkFMKDk3LENIQVIp >LCBWQUwoMTA1LENIQVIpLCBWQUwoMTA4LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDIwNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMjQ4LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDQsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4 >LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoMTY3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDksQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgxMTEsQ0hBUiksIFZBTCgxMTgsQ0hBUiks >IFZBTCgxMDEsQ0hBUiksIFZBTCgxMTQsQ0hBUiksIFZBTCgxMTQsQ0hBUiksIFZBTCgxMDUsQ0hB >UiksIFZBTCgxMDAsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZBTCgxMTUsQ0hBUiksIFZBTCg0OCxD >SEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENI >QVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBW >QUwoNCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4 >LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoMTcxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDUsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg5OSxDSEFSKSwgVkFMKDEw >OCxDSEFSKSwgVkFMKDExMSxDSEFSKSwgVkFMKDExNSxDSEFSKSwgVkFMKDEwMSxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDE3OSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDE4MixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxODYsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg4LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDQ5LENIQVIpLCBWQUwoMzQsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDgs >Q0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiks >IFZBTCg0OSxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoNDIsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBW >QUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTM0 >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDEz >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCgxNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTQzLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiks >IFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5LENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDEzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCgxNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOSxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoMTQzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzQs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM5LENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0MSxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMTUsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0 >OSxDSEFSKSwgVkFMKDExOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MTIzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTI3LENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTU5LENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTYzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDQ5LENIQVIpLCBWQUwoMTY3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE3 >MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTc1LENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiks >IFZBTCg0OSxDSEFSKSwgVkFMKDE3OSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0 >OSxDSEFSKSwgVkFMKDE4MixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxODYsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTkwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDE5NCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMTk2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDIwMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MzYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiks >IFZBTCg0OSxDSEFSKSwgVkFMKDIwNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjA4LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDQsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoOCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTAsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENI >QVIpLCBWQUwoMzQsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZB >TCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0 >OSxDSEFSKSwgVkFMKDE3MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >NDMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTc5LENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTgyLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDE4NixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOTAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFM >KDQ5LENIQVIpLCBWQUwoMTk0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOTYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBW >QUwoMjAwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >NDksQ0hBUiksIFZBTCgzNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MjUsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjA2LENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyMDgsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDQ5LENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTkwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDE5NCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMTk2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDIwMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MzYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDcwLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiks >IFZBTCg0OSxDSEFSKSwgVkFMKDIwNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0 >OSxDSEFSKSwgVkFMKDc1LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoOSxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NDksQ0hBUiksIFZBTCgxMyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoODIsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MTksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDg2LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MzQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM5LENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0MSxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxNjMsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoOTYsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDIwNixDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyMDYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCg5MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDksQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDQ5LENIQVIpLCBWQUwoMTMsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDEwOCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCgxOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDQ5LENIQVIpLCBWQUwoMTEyLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENI >QVIpLCBWQUwoMzQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM5LENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiks >IFZBTCg0MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMTUsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDExOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzYsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMTIzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBW >QUwoMTI3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >NDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTMxLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiks >IFZBTCgyMzQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0LENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiks >IFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5 >NixDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTM0LENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiks >IFZBTCg0OSxDSEFSKSwgVkFMKDIwNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTM5LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDQsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDk2LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxNjEs >Q0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjA2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTY2LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDI1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzQsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM5LENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0MSxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxD >SEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCgxNzYsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE3OCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCgxOTYsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZB >TCgyMTEsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0 >OSxDSEFSKSwgVkFMKDIxMyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyMDQsQ0hBUiks >IFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyMTEsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgxMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDExMCxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMjA4LENIQVIpLCBW >QUwoMTkzLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENI >QVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBW >QUwoOCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMTAsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiks >IFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzQsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDIyOSxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyMzMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDEzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNDksQ0hBUiksIFZBTCgyMzgsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTksQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDI0MixDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI0NixD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDEzNCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg0OSxDSEFSKSwgVkFMKDksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTMsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDI1NCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOSxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTEyLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzQsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDM5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCgxMTUsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDExOSxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoMzYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTIzLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTI3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDQ5LENIQVIpLCBWQUwoMTU5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMTYzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDk2LENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyMixDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCgyMDYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg0OSxDSEFSKSwgVkFMKDE3OSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0LENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiks >IFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5 >NixDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzIsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDQ5LENIQVIpLCBWQUwoMjA2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNTMsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoNCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxNjcsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NDksQ0hBUiksIFZBTCg0MixDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENI >QVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNDksQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxD >SEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCgxNzEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDUwLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE3OSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE4MixDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFM >KDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDks >Q0hBUiksIFZBTCgxODYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiks >IFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZB >TCg4LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzQsQ0hBUiks >IFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4 >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDQsQ0hBUiks >IFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFM >KDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENI >QVIpLCBWQUwoNDIsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MixDSEFSKSwg >VkFMKDEwLENIQVIpIH07CiAgICBCRUdJTgogICAgICBTY2hlbWVQcm9jZWR1cmVTdHVicy5SZWdp >c3RlclR5cGVQaWNrbGUoQXJnX1RDLCBBcmdfTmFtZXMsIEFyZ19QaWNrbGUpCiAgICBFTkQ7CiAg >ICBTY2hlbWVQcm9jZWR1cmVTdHVicy5SZWdpc3RlcihORVcoU2NoZW1lUHJvY2VkdXJlU3R1YnMu >UWlkLCBpbnRmIDo9IEF0b20uRnJvbVRleHQoIkZTIiksIGl0ZW0gOj0gQXRvbS5Gcm9tVGV4dCgi >R2V0QWJzb2x1dGVQYXRobmFtZSIpKSwgQ2FsbFN0dWJfRlNfR2V0QWJzb2x1dGVQYXRobmFtZSk7 >CiAgICBTY2hlbWVQcm9jZWR1cmVTdHVicy5SZWdpc3RlcihORVcoU2NoZW1lUHJvY2VkdXJlU3R1 >YnMuUWlkLCBpbnRmIDo9IEF0b20uRnJvbVRleHQoIkZTIiksIGl0ZW0gOj0gQXRvbS5Gcm9tVGV4 >dCgiT3BlbkZpbGUiKSksIENhbGxTdHViX0ZTX09wZW5GaWxlKTsKICAgIFNjaGVtZVByb2NlZHVy >ZVN0dWJzLlJlZ2lzdGVyKE5FVyhTY2hlbWVQcm9jZWR1cmVTdHVicy5RaWQsIGludGYgOj0gQXRv >bS5Gcm9tVGV4dCgiRlMiKSwgaXRlbSA6PSBBdG9tLkZyb21UZXh0KCJPcGVuRmlsZVJlYWRvbmx5 >IikpLCBDYWxsU3R1Yl9GU19PcGVuRmlsZVJlYWRvbmx5KTsKICAgIFNjaGVtZVByb2NlZHVyZVN0 >dWJzLlJlZ2lzdGVyKE5FVyhTY2hlbWVQcm9jZWR1cmVTdHVicy5RaWQsIGludGYgOj0gQXRvbS5G >cm9tVGV4dCgiRlMiKSwgaXRlbSA6PSBBdG9tLkZyb21UZXh0KCJDcmVhdGVEaXJlY3RvcnkiKSks >IENhbGxTdHViX0ZTX0NyZWF0ZURpcmVjdG9yeSk7CiAgICBTY2hlbWVQcm9jZWR1cmVTdHVicy5S >ZWdpc3RlcihORVcoU2NoZW1lUHJvY2VkdXJlU3R1YnMuUWlkLCBpbnRmIDo9IEF0b20uRnJvbVRl >eHQoIkZTIiksIGl0ZW0gOj0gQXRvbS5Gcm9tVGV4dCgiRGVsZXRlRGlyZWN0b3J5IikpLCBDYWxs >U3R1Yl9GU19EZWxldGVEaXJlY3RvcnkpOwogICAgU2NoZW1lUHJvY2VkdXJlU3R1YnMuUmVnaXN0 >ZXIoTkVXKFNjaGVtZVByb2NlZHVyZVN0dWJzLlFpZCwgaW50ZiA6PSBBdG9tLkZyb21UZXh0KCJG >UyIpLCBpdGVtIDo9IEF0b20uRnJvbVRleHQoIkRlbGV0ZUZpbGUiKSksIENhbGxTdHViX0ZTX0Rl >bGV0ZUZpbGUpOwogICAgU2NoZW1lUHJvY2VkdXJlU3R1YnMuUmVnaXN0ZXIoTkVXKFNjaGVtZVBy >b2NlZHVyZVN0dWJzLlFpZCwgaW50ZiA6PSBBdG9tLkZyb21UZXh0KCJGUyIpLCBpdGVtIDo9IEF0 >b20uRnJvbVRleHQoIlJlbmFtZSIpKSwgQ2FsbFN0dWJfRlNfUmVuYW1lKTsKICAgIFNjaGVtZVBy >b2NlZHVyZVN0dWJzLlJlZ2lzdGVyKE5FVyhTY2hlbWVQcm9jZWR1cmVTdHVicy5RaWQsIGludGYg >Oj0gQXRvbS5Gcm9tVGV4dCgiRlMiKSwgaXRlbSA6PSBBdG9tLkZyb21UZXh0KCJJdGVyYXRlIikp >LCBDYWxsU3R1Yl9GU19JdGVyYXRlKTsKICAgIFNjaGVtZVByb2NlZHVyZVN0dWJzLlJlZ2lzdGVy >KE5FVyhTY2hlbWVQcm9jZWR1cmVTdHVicy5RaWQsIGludGYgOj0gQXRvbS5Gcm9tVGV4dCgiRlMi >KSwgaXRlbSA6PSBBdG9tLkZyb21UZXh0KCJTdGF0dXMiKSksIENhbGxTdHViX0ZTX1N0YXR1cyk7 >CiAgICBTY2hlbWVQcm9jZWR1cmVTdHVicy5SZWdpc3RlcihORVcoU2NoZW1lUHJvY2VkdXJlU3R1 >YnMuUWlkLCBpbnRmIDo9IEF0b20uRnJvbVRleHQoIkZTIiksIGl0ZW0gOj0gQXRvbS5Gcm9tVGV4 >dCgiU2V0TW9kaWZpY2F0aW9uVGltZSIpKSwgQ2FsbFN0dWJfRlNfU2V0TW9kaWZpY2F0aW9uVGlt >ZSk7CiAgRU5EIFJlZ2lzdGVyU3R1YnM7CgpQUk9DRURVUkUgTmV3X0ZTX0l0ZXJhdG9yKGludGVy >cCA6IFNjaGVtZS5UOyBpbml0cyA6IFNjaGVtZU9iamVjdC5UKSA6IFNjaGVtZU9iamVjdC5UIFJB >SVNFUyB7IFNjaGVtZS5FIH0gPQogIFZBUgogICAgcCA6PSBTY2hlbWVQYWlyLlBhaXIoaW5pdHMp >OwogICAgZ29iYmxlZCA6IEJPT0xFQU47CiAgQkVHSU4KICAgIFdJVEggcmVzID0gTkVXKEZTX0l0 >ZXJhdG9yX1N1cnJvZ2F0ZSwgaW50ZXJwIDo9IGludGVycCkgRE8KICAgICAgV0hJTEUgcCAjIE5J >TCBETwogICAgICAgIFdJVEggciA9IFNjaGVtZVBhaXIuUGFpcihwLmZpcnN0KSBETwogICAgICAg >ICAgZ29iYmxlZCA6PSBGQUxTRTsKICAgICAgICAgIElGIHIgIyBOSUwgVEhFTgogICAgICAgICAg >ICBJRiByLmZpcnN0ID0gU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJuZXh0IikgVEhFTgogICAgICAg >ICAgICAgICByZXMubmV4dF9zbG90IDo9IHIucmVzdDsgZ29iYmxlZCA6PSBUUlVFCiAgICAgICAg >ICAgIEVORDsKICAgICAgICAgICAgSUYgci5maXJzdCA9IFNjaGVtZVN5bWJvbC5Gcm9tVGV4dCgi >Y2xvc2UiKSBUSEVOCiAgICAgICAgICAgICAgIHJlcy5jbG9zZV9zbG90IDo9IHIucmVzdDsgZ29i >YmxlZCA6PSBUUlVFCiAgICAgICAgICAgIEVORDsKICAgICAgICAgICAgSUYgci5maXJzdCA9IFNj >aGVtZVN5bWJvbC5Gcm9tVGV4dCgibmV4dFdpdGhTdGF0dXMiKSBUSEVOCiAgICAgICAgICAgICAg >IHJlcy5uZXh0V2l0aFN0YXR1c19zbG90IDo9IHIucmVzdDsgZ29iYmxlZCA6PSBUUlVFCiAgICAg >ICAgICAgIEVORDsKICAgICAgICAgIEVORDsKICAgICAgICAgIElGIE5PVCBnb2JibGVkIFRIRU4K >ICAgICAgICAgICAgUkFJU0UgU2NoZW1lLkUoIkZTX0l0ZXJhdG9yOiBVbmtub3duIGZpZWxkL21l >dGhvZCAiICYgU2NoZW1lVXRpbHMuU3RyaW5naWZ5KHIuZmlyc3QpICYgIiBpbiAiICYgU2NoZW1l >VXRpbHMuU3RyaW5naWZ5KGluaXRzKSkKICAgICAgICAgIEVORAogICAgICAgIEVORDsKICAgICAg >ICBwIDo9IFNjaGVtZVBhaXIuUGFpcihwLnJlc3QpCiAgICAgIEVORDsKICAgICAgUkVUVVJOIHJl >cwogICAgRU5ECiAgRU5EIE5ld19GU19JdGVyYXRvcjsKClBST0NFRFVSRSBHZW5OZXdfRlNfSXRl >cmF0b3IoaW50ZXJwIDogU2NoZW1lLlQ7IDwqVU5VU0VEKj5vYmogOiBTY2hlbWVPYmplY3QuVDsg >aW5pdHMgOiBTY2hlbWVPYmplY3QuVCkgOiBTY2hlbWVPYmplY3QuVCBSQUlTRVMgeyBTY2hlbWUu >RSB9ID0KICBCRUdJTiBSRVRVUk4gTmV3X0ZTX0l0ZXJhdG9yKGludGVycCxpbml0cykgRU5EIEdl >bk5ld19GU19JdGVyYXRvcjsKClRZUEUgRlNfSXRlcmF0b3JfU3Vycm9nYXRlID0gRlMuSXRlcmF0 >b3IgT0JKRUNUIAogICAgaW50ZXJwIDogU2NoZW1lLlQ7CiAgICBuZXh0X3Nsb3QgOiBTY2hlbWVP >YmplY3QuVCA6PSBOSUw7IAogICAgY2xvc2Vfc2xvdCA6IFNjaGVtZU9iamVjdC5UIDo9IE5JTDsg >CiAgICBuZXh0V2l0aFN0YXR1c19zbG90IDogU2NoZW1lT2JqZWN0LlQgOj0gTklMOyAKICBPVkVS >UklERVMKICAgIG5leHQgOj0gRlNfSXRlcmF0b3JfbmV4dF9kZWZhdWx0OwogICAgY2xvc2UgOj0g >RlNfSXRlcmF0b3JfY2xvc2VfZGVmYXVsdDsKICAgIG5leHRXaXRoU3RhdHVzIDo9IEZTX0l0ZXJh >dG9yX25leHRXaXRoU3RhdHVzX2RlZmF1bHQ7CiAgRU5EOwoKUFJPQ0VEVVJFIE1ldGhvZERpc3Bh >dGNoZXJfRlNfSXRlcmF0b3IoaW50ZXJwIDogU2NoZW1lLlQ7IG9iaiA6IFNjaGVtZU9iamVjdC5U >OyBhcmdzIDogU2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1l >LkUgfSA9CiAgVkFSCiAgICBtZXRoTmFtZSA6PSBTY2hlbWUuU3ltYm9sQ2hlY2soU2NoZW1lVXRp >bHMuRmlyc3QoYXJncykpOwogICAgbWV0aEFyZ3MgOj0gU2NoZW1lVXRpbHMuQ29ucyhvYmosU2No >ZW1lVXRpbHMuU2Vjb25kKGFyZ3MpKTsKICAgIG1ldGhFeGNIYW5kbGVyIDo9IFNjaGVtZVV0aWxz >LlRoaXJkKGFyZ3MpOwogIEJFR0lOCiAgICBJRiBGQUxTRSBUSEVOIDwqQVNTRVJUIEZBTFNFKj4K >ICAgIEVMU0lGIG1ldGhOYW1lID0gU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJuZXh0IikgVEhFTgog >ICAgICBSRVRVUk4gTWV0aG9kU3R1Yl9GU19JdGVyYXRvcl9uZXh0KGludGVycCxtZXRoQXJncyxt >ZXRoRXhjSGFuZGxlcikKICAgIEVMU0lGIG1ldGhOYW1lID0gU2NoZW1lU3ltYm9sLkZyb21UZXh0 >KCJjbG9zZSIpIFRIRU4KICAgICAgUkVUVVJOIE1ldGhvZFN0dWJfRlNfSXRlcmF0b3JfY2xvc2Uo >aW50ZXJwLG1ldGhBcmdzLG1ldGhFeGNIYW5kbGVyKQogICAgRUxTSUYgbWV0aE5hbWUgPSBTY2hl >bWVTeW1ib2wuRnJvbVRleHQoIm5leHRXaXRoU3RhdHVzIikgVEhFTgogICAgICBSRVRVUk4gTWV0 >aG9kU3R1Yl9GU19JdGVyYXRvcl9uZXh0V2l0aFN0YXR1cyhpbnRlcnAsbWV0aEFyZ3MsbWV0aEV4 >Y0hhbmRsZXIpCiAgICBFTFNFCiAgICAgIFJBSVNFIFNjaGVtZS5FKCJ1bmtub3duIG1ldGhvZCAi >JlNjaGVtZVN5bWJvbC5Ub1RleHQobWV0aE5hbWUpJiIgZm9yIHR5cGUgRlMuSXRlcmF0b3IiKTsK >ICAgIEVORAogIEVORCBNZXRob2REaXNwYXRjaGVyX0ZTX0l0ZXJhdG9yOwoKUFJPQ0VEVVJFIEZT >X0l0ZXJhdG9yX25leHRfZGVmYXVsdChvYmplY3RfXyA6IEZTX0l0ZXJhdG9yX1N1cnJvZ2F0ZTsg >VkFSIGZvcm1hbF9uYW1lIDogIFRFWFQgKSA6ICBCT09MRUFOICA9IAogIEJFR0lOCiAgICBJRiBv >YmplY3RfXy5uZXh0X3Nsb3QgPSBOSUwgVEhFTgogICAgICAoKiBwdW50IHRvIE1vZHVsYS0zIG9i >amVjdCB0eXBlIGRlZm4gKikKICAgICAgUkVUVVJOIEZTLkl0ZXJhdG9yLm5leHQob2JqZWN0X18s >IGZvcm1hbF9uYW1lKQogICAgRUxTRQogICAgICAoKiBtZXRob2Qgb3ZlcnJpZGVuIGJ5IFNjaGVt >ZSBjb2RlICopCiAgICAgIFZBUgogICAgICAgIGFyZ3NfXyA6IFNjaGVtZVBhaXIuVCA6PSBORVco >U2NoZW1lUGFpci5ULCBmaXJzdCA6PSBvYmplY3RfXywgcmVzdCA6PSBOSUwpOwogICAgICBCRUdJ >TgogICAgICAgIGFyZ3NfXyA6PSBTY2hlbWVVdGlscy5Db25zKFNjaGVtZU1vZHVsYTNUeXBlcy5U >b1NjaGVtZV9URVhUKGZvcm1hbF9uYW1lKSxhcmdzX18pOwogICAgICAgIGFyZ3NfXyA6PSBTY2hl >bWVVdGlscy5SZXZlcnNlKGFyZ3NfXyk7CiAgICAgICAgUkVUVVJOIFNjaGVtZU1vZHVsYTNUeXBl >cy5Ub01vZHVsYV9CT09MRUFOKFNjaGVtZVByb2NlZHVyZVN0dWJzLkNhbGxTY2hlbWUob2JqZWN0 >X18uaW50ZXJwLCBvYmplY3RfXy5uZXh0X3Nsb3QsIGFyZ3NfXykpCiAgICAgICAgKCogYW5kIHRo >aXMgaXMgd2hlcmUgd2UgbmVlZCB0byB1bnBhY2sgVkFSIHBhcmFtcyAqKQogICAgICBFTkQKICAg >IEVORAogIEVORCBGU19JdGVyYXRvcl9uZXh0X2RlZmF1bHQ7CgpQUk9DRURVUkUgRlNfSXRlcmF0 >b3JfY2xvc2VfZGVmYXVsdChvYmplY3RfXyA6IEZTX0l0ZXJhdG9yX1N1cnJvZ2F0ZSkgPSAKICBC >RUdJTgogICAgSUYgb2JqZWN0X18uY2xvc2Vfc2xvdCA9IE5JTCBUSEVOCiAgICAgICgqIHB1bnQg >dG8gTW9kdWxhLTMgb2JqZWN0IHR5cGUgZGVmbiAqKQogICAgICBGUy5JdGVyYXRvci5jbG9zZShv >YmplY3RfXykKICAgIEVMU0UKICAgICAgKCogbWV0aG9kIG92ZXJyaWRlbiBieSBTY2hlbWUgY29k >ZSAqKQogICAgICBWQVIKICAgICAgICBhcmdzX18gOiBTY2hlbWVQYWlyLlQgOj0gTkVXKFNjaGVt >ZVBhaXIuVCwgZmlyc3QgOj0gb2JqZWN0X18sIHJlc3QgOj0gTklMKTsKICAgICAgQkVHSU4KICAg >ICAgICBhcmdzX18gOj0gU2NoZW1lVXRpbHMuUmV2ZXJzZShhcmdzX18pOwogICAgICAgIEVWQUwg >KFNjaGVtZVByb2NlZHVyZVN0dWJzLkNhbGxTY2hlbWUob2JqZWN0X18uaW50ZXJwLCBvYmplY3Rf >Xy5jbG9zZV9zbG90LCBhcmdzX18pKQogICAgICAgICgqIGFuZCB0aGlzIGlzIHdoZXJlIHdlIG5l >ZWQgdG8gdW5wYWNrIFZBUiBwYXJhbXMgKikKICAgICAgRU5ECiAgICBFTkQKICBFTkQgRlNfSXRl >cmF0b3JfY2xvc2VfZGVmYXVsdDsKClBST0NFRFVSRSBGU19JdGVyYXRvcl9uZXh0V2l0aFN0YXR1 >c19kZWZhdWx0KG9iamVjdF9fIDogRlNfSXRlcmF0b3JfU3Vycm9nYXRlOyBWQVIgZm9ybWFsX25h >bWUgOiAgVEVYVCA7IFZBUiBmb3JtYWxfc3RhdCA6IEZpbGUuU3RhdHVzKSA6ICBCT09MRUFOICBS >QUlTRVMgeyBPU0Vycm9yLkUgfSA9IAogIEJFR0lOCiAgICBJRiBvYmplY3RfXy5uZXh0V2l0aFN0 >YXR1c19zbG90ID0gTklMIFRIRU4KICAgICAgKCogcHVudCB0byBNb2R1bGEtMyBvYmplY3QgdHlw >ZSBkZWZuICopCiAgICAgIFJFVFVSTiBGUy5JdGVyYXRvci5uZXh0V2l0aFN0YXR1cyhvYmplY3Rf >XywgZm9ybWFsX25hbWUsIGZvcm1hbF9zdGF0KQogICAgRUxTRQogICAgICAoKiBtZXRob2Qgb3Zl >cnJpZGVuIGJ5IFNjaGVtZSBjb2RlICopCiAgICAgIFZBUgogICAgICAgIGFyZ3NfXyA6IFNjaGVt >ZVBhaXIuVCA6PSBORVcoU2NoZW1lUGFpci5ULCBmaXJzdCA6PSBvYmplY3RfXywgcmVzdCA6PSBO >SUwpOwogICAgICBCRUdJTgogICAgICAgIGFyZ3NfXyA6PSBTY2hlbWVVdGlscy5Db25zKFNjaGVt >ZU1vZHVsYTNUeXBlcy5Ub1NjaGVtZV9URVhUKGZvcm1hbF9uYW1lKSxhcmdzX18pOwogICAgICAg >IGFyZ3NfXyA6PSBTY2hlbWVVdGlscy5Db25zKFRvU2NoZW1lX0ZpbGVfU3RhdHVzKGZvcm1hbF9z >dGF0KSxhcmdzX18pOwogICAgICAgIGFyZ3NfXyA6PSBTY2hlbWVVdGlscy5SZXZlcnNlKGFyZ3Nf >Xyk7CiAgICAgICAgUkVUVVJOIFNjaGVtZU1vZHVsYTNUeXBlcy5Ub01vZHVsYV9CT09MRUFOKFNj >aGVtZVByb2NlZHVyZVN0dWJzLkNhbGxTY2hlbWUob2JqZWN0X18uaW50ZXJwLCBvYmplY3RfXy5u >ZXh0V2l0aFN0YXR1c19zbG90LCBhcmdzX18pKQogICAgICAgICgqIGFuZCB0aGlzIGlzIHdoZXJl >IHdlIG5lZWQgdG8gdW5wYWNrIFZBUiBwYXJhbXMgKikKICAgICAgRU5ECiAgICBFTkQKICBFTkQg >RlNfSXRlcmF0b3JfbmV4dFdpdGhTdGF0dXNfZGVmYXVsdDsKClBST0NFRFVSRSBNZXRob2RTdHVi >X0ZTX0l0ZXJhdG9yX25leHQoaW50ZXJwIDogU2NoZW1lLlQ7CiAgICAgICAgICAgICAgICAgICAg >ICBhcmdzIDogU2NoZW1lT2JqZWN0LlQ7CiAgICAgICAgICAgICAgICAgICAgICBleGNIYW5kbGVy >IDogU2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQKICBSQUlTRVMgeyBTY2hlbWUuRSB9 >ID0gCiAKICBQUk9DRURVUkUgTmV4dCgpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1l >LkUgfSA9IAogICAgQkVHSU4KICAgICAgVFJZIFJFVFVSTiBTY2hlbWVVdGlscy5GaXJzdChwX18p >IEZJTkFMTFkgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihTY2hlbWVVdGlscy5SZXN0KHBfXykpIEVO >RAogICAgRU5EIE5leHQ7CiAKICBWQVIgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICBC >RUdJTgogICAgVFJZCiAgICAgICgqIHVucGFjayBmb3JtYWxzICopCiAgICAgIFZBUiA8Kk5PV0FS >Tio+anVua19fIDo9IDA7CiAgICAgICAgICAgdGhpcyA6PSBUb01vZHVsYV9GU19JdGVyYXRvcihO >ZXh0KCkpOwogICAgICAgICAgIGZvcm1hbF9uYW1lIDo9IFNjaGVtZU1vZHVsYTNUeXBlcy5Ub01v >ZHVsYV9URVhUKE5leHQoKSk7IEJFR0lOCiAgICAgICAgKCogY2Fycnkgb3V0IE5JTCBjaGVja3Mg >Zm9yIG9wZW4gYXJyYXlzICopCgogICAgICAgICgqIG1ha2UgcHJvY2VkdXJlIGNhbGwgKikKICAg >ICAgICBXSVRIIHJlcyA9IFNjaGVtZU1vZHVsYTNUeXBlcy5Ub1NjaGVtZV9CT09MRUFOKHRoaXMu >bmV4dChmb3JtYWxfbmFtZSkpIERPCiAgICAgICAgKCogdW5wYWNrIFZBUiBwYXJhbXMgKikKICAg >ICAgICBwX18gOj0gU2NoZW1lUGFpci5QYWlyKGFyZ3MpOwogICAgICAgIEVWQUwgTmV4dCgpOwog >ICAgICAgIEVWQUwgU2NoZW1lVXRpbHMuU2V0Rmlyc3QocF9fLFNjaGVtZU1vZHVsYTNUeXBlcy5U >b1NjaGVtZV9URVhUKGZvcm1hbF9uYW1lKSk7CiAgICAgICAgRVZBTCBOZXh0KCk7CgogICAgICAg >ICgqIHJldHVybiBwcm9jZWR1cmUgcmVzdWx0ICopCiAgICAgICAgUkVUVVJOIHJlcwogICAgICAg >IEVORAogICAgICBFTkQoKldJVEgqKQogICAgRVhDRVBUCiAgICBFTkQ7CiAgICA8Kk5PV0FSTio+ >UkVUVVJOIFNjaGVtZUJvb2xlYW4uRmFsc2UoKQogIEVORCBNZXRob2RTdHViX0ZTX0l0ZXJhdG9y >X25leHQ7ClBST0NFRFVSRSBNZXRob2RTdHViX0ZTX0l0ZXJhdG9yX2Nsb3NlKGludGVycCA6IFNj >aGVtZS5UOwogICAgICAgICAgICAgICAgICAgICAgYXJncyA6IFNjaGVtZU9iamVjdC5UOwogICAg >ICAgICAgICAgICAgICAgICAgZXhjSGFuZGxlciA6IFNjaGVtZU9iamVjdC5UKSA6IFNjaGVtZU9i >amVjdC5UCiAgUkFJU0VTIHsgU2NoZW1lLkUgfSA9IAogCiAgUFJPQ0VEVVJFIE5leHQoKSA6IFNj >aGVtZU9iamVjdC5UIFJBSVNFUyB7IFNjaGVtZS5FIH0gPSAKICAgIEJFR0lOCiAgICAgIFRSWSBS >RVRVUk4gU2NoZW1lVXRpbHMuRmlyc3QocF9fKSBGSU5BTExZIHBfXyA6PSBTY2hlbWVQYWlyLlBh >aXIoU2NoZW1lVXRpbHMuUmVzdChwX18pKSBFTkQKICAgIEVORCBOZXh0OwogCiAgVkFSIHBfXyA6 >PSBTY2hlbWVQYWlyLlBhaXIoYXJncyk7CiAgQkVHSU4KICAgIFRSWQogICAgICAoKiB1bnBhY2sg >Zm9ybWFscyAqKQogICAgICBWQVIgPCpOT1dBUk4qPmp1bmtfXyA6PSAwOwogICAgICAgICAgIHRo >aXMgOj0gVG9Nb2R1bGFfRlNfSXRlcmF0b3IoTmV4dCgpKTsgQkVHSU4KICAgICAgICAoKiBjYXJy >eSBvdXQgTklMIGNoZWNrcyBmb3Igb3BlbiBhcnJheXMgKikKCiAgICAgICAgKCogbWFrZSBwcm9j >ZWR1cmUgY2FsbCAqKQogICAgICAgIHRoaXMuY2xvc2UoKTsKICAgICAgICAoKiB1bnBhY2sgVkFS >IHBhcmFtcyAqKQogICAgICAgIHBfXyA6PSBTY2hlbWVQYWlyLlBhaXIoYXJncyk7CiAgICAgICAg >RVZBTCBOZXh0KCk7CgogICAgICAgICgqIHByb3BlciBwcm9jZWR1cmUgOiByZXR1cm4gVFJVRSAq >KQogICAgICAgIFJFVFVSTiBTY2hlbWVCb29sZWFuLlRydWUoKQogICAgICBFTkQoKldJVEgqKQog >ICAgRVhDRVBUCiAgICBFTkQ7CiAgICA8Kk5PV0FSTio+UkVUVVJOIFNjaGVtZUJvb2xlYW4uRmFs >c2UoKQogIEVORCBNZXRob2RTdHViX0ZTX0l0ZXJhdG9yX2Nsb3NlOwpQUk9DRURVUkUgTWV0aG9k >U3R1Yl9GU19JdGVyYXRvcl9uZXh0V2l0aFN0YXR1cyhpbnRlcnAgOiBTY2hlbWUuVDsKICAgICAg >ICAgICAgICAgICAgICAgIGFyZ3MgOiBTY2hlbWVPYmplY3QuVDsKICAgICAgICAgICAgICAgICAg >ICAgIGV4Y0hhbmRsZXIgOiBTY2hlbWVPYmplY3QuVCkgOiBTY2hlbWVPYmplY3QuVAogIFJBSVNF >UyB7IFNjaGVtZS5FIH0gPSAKIAogIFBST0NFRFVSRSBOZXh0KCkgOiBTY2hlbWVPYmplY3QuVCBS >QUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAgICBCRUdJTgogICAgICBUUlkgUkVUVVJOIFNjaGVtZVV0 >aWxzLkZpcnN0KHBfXykgRklOQUxMWSBwX18gOj0gU2NoZW1lUGFpci5QYWlyKFNjaGVtZVV0aWxz >LlJlc3QocF9fKSkgRU5ECiAgICBFTkQgTmV4dDsKIAogIFZBUiBwX18gOj0gU2NoZW1lUGFpci5Q >YWlyKGFyZ3MpOwogIEJFR0lOCiAgICBUUlkKICAgICAgKCogdW5wYWNrIGZvcm1hbHMgKikKICAg >ICAgVkFSIDwqTk9XQVJOKj5qdW5rX18gOj0gMDsKICAgICAgICAgICB0aGlzIDo9IFRvTW9kdWxh >X0ZTX0l0ZXJhdG9yKE5leHQoKSk7CiAgICAgICAgICAgZm9ybWFsX25hbWUgOj0gU2NoZW1lTW9k >dWxhM1R5cGVzLlRvTW9kdWxhX1RFWFQoTmV4dCgpKTsKICAgICAgICAgICBmb3JtYWxfc3RhdCA6 >PSBUb01vZHVsYV9GaWxlX1N0YXR1cyhOZXh0KCkpOyBCRUdJTgogICAgICAgICgqIGNhcnJ5IG91 >dCBOSUwgY2hlY2tzIGZvciBvcGVuIGFycmF5cyAqKQoKICAgICAgICAoKiBtYWtlIHByb2NlZHVy ZSBjYWxsICopCiAgICAgICAgV0lUSCByZXMgPSBTY2hlbWVNb2R1bGEzVHlwZXMuVG9TY2hlbWVf >Qk9PTEVBTih0aGlzLm5leHRXaXRoU3RhdHVzKGZvcm1hbF9uYW1lLCBmb3JtYWxfc3RhdCkpIERP >CiAgICAgICAgKCogdW5wYWNrIFZBUiBwYXJhbXMgKikKICAgICAgICBwX18gOj0gU2NoZW1lUGFp >ci5QYWlyKGFyZ3MpOwogICAgICAgIEVWQUwgTmV4dCgpOwogICAgICAgIEVWQUwgU2NoZW1lVXRp >bHMuU2V0Rmlyc3QocF9fLFNjaGVtZU1vZHVsYTNUeXBlcy5Ub1NjaGVtZV9URVhUKGZvcm1hbF9u >YW1lKSk7CiAgICAgICAgRVZBTCBOZXh0KCk7CiAgICAgICAgRVZBTCBTY2hlbWVVdGlscy5TZXRG >aXJzdChwX18sVG9TY2hlbWVfRmlsZV9TdGF0dXMoZm9ybWFsX3N0YXQpKTsKICAgICAgICBFVkFM >IE5leHQoKTsKCiAgICAgICAgKCogcmV0dXJuIHByb2NlZHVyZSByZXN1bHQgKikKICAgICAgICBS >RVRVUk4gcmVzCiAgICAgICAgRU5ECiAgICAgIEVORCgqV0lUSCopCiAgICBFWENFUFQKICAgICAg >fCBPU0Vycm9yLkUoeGFyZykgPT4gRVZBTCBTY2hlbWVBcHBseS5PbmVBcmcoaW50ZXJwLGV4Y0hh >bmRsZXIsU2NoZW1lVXRpbHMuTGlzdDIoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJxdW90ZSIpLFNj >aGVtZVV0aWxzLkNvbnMoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJPU0Vycm9yLkUiKSwgVG9TY2hl >bWVfQXRvbUxpc3RfVCh4YXJnKSkpKQogICAgRU5EOwogICAgPCpOT1dBUk4qPlJFVFVSTiBTY2hl >bWVCb29sZWFuLkZhbHNlKCkKICBFTkQgTWV0aG9kU3R1Yl9GU19JdGVyYXRvcl9uZXh0V2l0aFN0 >YXR1czsKUFJPQ0VEVVJFIE5ld19GU19QdWJsaWNJdGVyYXRvcihpbnRlcnAgOiBTY2hlbWUuVDsg >aW5pdHMgOiBTY2hlbWVPYmplY3QuVCkgOiBTY2hlbWVPYmplY3QuVCBSQUlTRVMgeyBTY2hlbWUu >RSB9ID0KICBWQVIKICAgIHAgOj0gU2NoZW1lUGFpci5QYWlyKGluaXRzKTsKICAgIGdvYmJsZWQg >OiBCT09MRUFOOwogIEJFR0lOCiAgICBXSVRIIHJlcyA9IE5FVyhGU19QdWJsaWNJdGVyYXRvcl9T >dXJyb2dhdGUsIGludGVycCA6PSBpbnRlcnApIERPCiAgICAgIFdISUxFIHAgIyBOSUwgRE8KICAg >ICAgICBXSVRIIHIgPSBTY2hlbWVQYWlyLlBhaXIocC5maXJzdCkgRE8KICAgICAgICAgIGdvYmJs >ZWQgOj0gRkFMU0U7CiAgICAgICAgICBJRiByICMgTklMIFRIRU4KICAgICAgICAgICAgSUYgci5m >aXJzdCA9IFNjaGVtZVN5bWJvbC5Gcm9tVGV4dCgibmV4dCIpIFRIRU4KICAgICAgICAgICAgICAg >cmVzLm5leHRfc2xvdCA6PSByLnJlc3Q7IGdvYmJsZWQgOj0gVFJVRQogICAgICAgICAgICBFTkQ7 >CiAgICAgICAgICAgIElGIHIuZmlyc3QgPSBTY2hlbWVTeW1ib2wuRnJvbVRleHQoImNsb3NlIikg >VEhFTgogICAgICAgICAgICAgICByZXMuY2xvc2Vfc2xvdCA6PSByLnJlc3Q7IGdvYmJsZWQgOj0g >VFJVRQogICAgICAgICAgICBFTkQ7CiAgICAgICAgICAgIElGIHIuZmlyc3QgPSBTY2hlbWVTeW1i >b2wuRnJvbVRleHQoIm5leHRXaXRoU3RhdHVzIikgVEhFTgogICAgICAgICAgICAgICByZXMubmV4 >dFdpdGhTdGF0dXNfc2xvdCA6PSByLnJlc3Q7IGdvYmJsZWQgOj0gVFJVRQogICAgICAgICAgICBF >TkQ7CiAgICAgICAgICBFTkQ7CiAgICAgICAgICBJRiBOT1QgZ29iYmxlZCBUSEVOCiAgICAgICAg >ICAgIFJBSVNFIFNjaGVtZS5FKCJGU19QdWJsaWNJdGVyYXRvcjogVW5rbm93biBmaWVsZC9tZXRo >b2QgIiAmIFNjaGVtZVV0aWxzLlN0cmluZ2lmeShyLmZpcnN0KSAmICIgaW4gIiAmIFNjaGVtZVV0 >aWxzLlN0cmluZ2lmeShpbml0cykpCiAgICAgICAgICBFTkQKICAgICAgICBFTkQ7CiAgICAgICAg >cCA6PSBTY2hlbWVQYWlyLlBhaXIocC5yZXN0KQogICAgICBFTkQ7CiAgICAgIFJFVFVSTiByZXMK >ICAgIEVORAogIEVORCBOZXdfRlNfUHVibGljSXRlcmF0b3I7CgpQUk9DRURVUkUgR2VuTmV3X0ZT >X1B1YmxpY0l0ZXJhdG9yKGludGVycCA6IFNjaGVtZS5UOyA8KlVOVVNFRCo+b2JqIDogU2NoZW1l >T2JqZWN0LlQ7IGluaXRzIDogU2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VT >IHsgU2NoZW1lLkUgfSA9CiAgQkVHSU4gUkVUVVJOIE5ld19GU19QdWJsaWNJdGVyYXRvcihpbnRl >cnAsaW5pdHMpIEVORCBHZW5OZXdfRlNfUHVibGljSXRlcmF0b3I7CgpUWVBFIEZTX1B1YmxpY0l0 >ZXJhdG9yX1N1cnJvZ2F0ZSA9IEZTLlB1YmxpY0l0ZXJhdG9yIE9CSkVDVCAKICAgIGludGVycCA6 >IFNjaGVtZS5UOwogICAgbmV4dF9zbG90IDogU2NoZW1lT2JqZWN0LlQgOj0gTklMOyAKICAgIGNs >b3NlX3Nsb3QgOiBTY2hlbWVPYmplY3QuVCA6PSBOSUw7IAogICAgbmV4dFdpdGhTdGF0dXNfc2xv >dCA6IFNjaGVtZU9iamVjdC5UIDo9IE5JTDsgCiAgT1ZFUlJJREVTCiAgICBuZXh0IDo9IEZTX1B1 >YmxpY0l0ZXJhdG9yX25leHRfZGVmYXVsdDsKICAgIGNsb3NlIDo9IEZTX1B1YmxpY0l0ZXJhdG9y >X2Nsb3NlX2RlZmF1bHQ7CiAgICBuZXh0V2l0aFN0YXR1cyA6PSBGU19QdWJsaWNJdGVyYXRvcl9u >ZXh0V2l0aFN0YXR1c19kZWZhdWx0OwogIEVORDsKClBST0NFRFVSRSBNZXRob2REaXNwYXRjaGVy >X0ZTX1B1YmxpY0l0ZXJhdG9yKGludGVycCA6IFNjaGVtZS5UOyBvYmogOiBTY2hlbWVPYmplY3Qu >VDsgYXJncyA6IFNjaGVtZU9iamVjdC5UKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IFNjaGVt >ZS5FIH0gPQogIFZBUgogICAgbWV0aE5hbWUgOj0gU2NoZW1lLlN5bWJvbENoZWNrKFNjaGVtZVV0 >aWxzLkZpcnN0KGFyZ3MpKTsKICAgIG1ldGhBcmdzIDo9IFNjaGVtZVV0aWxzLkNvbnMob2JqLFNj >aGVtZVV0aWxzLlNlY29uZChhcmdzKSk7CiAgICBtZXRoRXhjSGFuZGxlciA6PSBTY2hlbWVVdGls >cy5UaGlyZChhcmdzKTsKICBCRUdJTgogICAgSUYgRkFMU0UgVEhFTiA8KkFTU0VSVCBGQUxTRSo+ >CiAgICBFTFNJRiBtZXRoTmFtZSA9IFNjaGVtZVN5bWJvbC5Gcm9tVGV4dCgibmV4dCIpIFRIRU4K >ICAgICAgUkVUVVJOIE1ldGhvZFN0dWJfRlNfUHVibGljSXRlcmF0b3JfbmV4dChpbnRlcnAsbWV0 >aEFyZ3MsbWV0aEV4Y0hhbmRsZXIpCiAgICBFTFNJRiBtZXRoTmFtZSA9IFNjaGVtZVN5bWJvbC5G >cm9tVGV4dCgiY2xvc2UiKSBUSEVOCiAgICAgIFJFVFVSTiBNZXRob2RTdHViX0ZTX1B1YmxpY0l0 >ZXJhdG9yX2Nsb3NlKGludGVycCxtZXRoQXJncyxtZXRoRXhjSGFuZGxlcikKICAgIEVMU0lGIG1l >dGhOYW1lID0gU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJuZXh0V2l0aFN0YXR1cyIpIFRIRU4KICAg >ICAgUkVUVVJOIE1ldGhvZFN0dWJfRlNfUHVibGljSXRlcmF0b3JfbmV4dFdpdGhTdGF0dXMoaW50 >ZXJwLG1ldGhBcmdzLG1ldGhFeGNIYW5kbGVyKQogICAgRUxTRQogICAgICBSQUlTRSBTY2hlbWUu >RSgidW5rbm93biBtZXRob2QgIiZTY2hlbWVTeW1ib2wuVG9UZXh0KG1ldGhOYW1lKSYiIGZvciB0 >eXBlIEZTLlB1YmxpY0l0ZXJhdG9yIik7CiAgICBFTkQKICBFTkQgTWV0aG9kRGlzcGF0Y2hlcl9G >U19QdWJsaWNJdGVyYXRvcjsKClBST0NFRFVSRSBGU19QdWJsaWNJdGVyYXRvcl9uZXh0X2RlZmF1 >bHQob2JqZWN0X18gOiBGU19QdWJsaWNJdGVyYXRvcl9TdXJyb2dhdGU7IFZBUiBmb3JtYWxfbmFt >ZSA6ICBURVhUICkgOiAgQk9PTEVBTiAgPSAKICBCRUdJTgogICAgSUYgb2JqZWN0X18ubmV4dF9z >bG90ID0gTklMIFRIRU4KICAgICAgKCogcHVudCB0byBNb2R1bGEtMyBvYmplY3QgdHlwZSBkZWZu >ICopCiAgICAgIFJFVFVSTiBGUy5QdWJsaWNJdGVyYXRvci5uZXh0KG9iamVjdF9fLCBmb3JtYWxf >bmFtZSkKICAgIEVMU0UKICAgICAgKCogbWV0aG9kIG92ZXJyaWRlbiBieSBTY2hlbWUgY29kZSAq >KQogICAgICBWQVIKICAgICAgICBhcmdzX18gOiBTY2hlbWVQYWlyLlQgOj0gTkVXKFNjaGVtZVBh >aXIuVCwgZmlyc3QgOj0gb2JqZWN0X18sIHJlc3QgOj0gTklMKTsKICAgICAgQkVHSU4KICAgICAg >ICBhcmdzX18gOj0gU2NoZW1lVXRpbHMuQ29ucyhTY2hlbWVNb2R1bGEzVHlwZXMuVG9TY2hlbWVf >VEVYVChmb3JtYWxfbmFtZSksYXJnc19fKTsKICAgICAgICBhcmdzX18gOj0gU2NoZW1lVXRpbHMu >UmV2ZXJzZShhcmdzX18pOwogICAgICAgIFJFVFVSTiBTY2hlbWVNb2R1bGEzVHlwZXMuVG9Nb2R1 >bGFfQk9PTEVBTihTY2hlbWVQcm9jZWR1cmVTdHVicy5DYWxsU2NoZW1lKG9iamVjdF9fLmludGVy >cCwgb2JqZWN0X18ubmV4dF9zbG90LCBhcmdzX18pKQogICAgICAgICgqIGFuZCB0aGlzIGlzIHdo >ZXJlIHdlIG5lZWQgdG8gdW5wYWNrIFZBUiBwYXJhbXMgKikKICAgICAgRU5ECiAgICBFTkQKICBF >TkQgRlNfUHVibGljSXRlcmF0b3JfbmV4dF9kZWZhdWx0OwoKUFJPQ0VEVVJFIEZTX1B1YmxpY0l0 >ZXJhdG9yX2Nsb3NlX2RlZmF1bHQob2JqZWN0X18gOiBGU19QdWJsaWNJdGVyYXRvcl9TdXJyb2dh >dGUpID0gCiAgQkVHSU4KICAgIElGIG9iamVjdF9fLmNsb3NlX3Nsb3QgPSBOSUwgVEhFTgogICAg >ICAoKiBwdW50IHRvIE1vZHVsYS0zIG9iamVjdCB0eXBlIGRlZm4gKikKICAgICAgRlMuUHVibGlj >SXRlcmF0b3IuY2xvc2Uob2JqZWN0X18pCiAgICBFTFNFCiAgICAgICgqIG1ldGhvZCBvdmVycmlk >ZW4gYnkgU2NoZW1lIGNvZGUgKikKICAgICAgVkFSCiAgICAgICAgYXJnc19fIDogU2NoZW1lUGFp >ci5UIDo9IE5FVyhTY2hlbWVQYWlyLlQsIGZpcnN0IDo9IG9iamVjdF9fLCByZXN0IDo9IE5JTCk7 >CiAgICAgIEJFR0lOCiAgICAgICAgYXJnc19fIDo9IFNjaGVtZVV0aWxzLlJldmVyc2UoYXJnc19f >KTsKICAgICAgICBFVkFMIChTY2hlbWVQcm9jZWR1cmVTdHVicy5DYWxsU2NoZW1lKG9iamVjdF9f >LmludGVycCwgb2JqZWN0X18uY2xvc2Vfc2xvdCwgYXJnc19fKSkKICAgICAgICAoKiBhbmQgdGhp >cyBpcyB3aGVyZSB3ZSBuZWVkIHRvIHVucGFjayBWQVIgcGFyYW1zICopCiAgICAgIEVORAogICAg >RU5ECiAgRU5EIEZTX1B1YmxpY0l0ZXJhdG9yX2Nsb3NlX2RlZmF1bHQ7CgpQUk9DRURVUkUgRlNf >UHVibGljSXRlcmF0b3JfbmV4dFdpdGhTdGF0dXNfZGVmYXVsdChvYmplY3RfXyA6IEZTX1B1Ymxp >Y0l0ZXJhdG9yX1N1cnJvZ2F0ZTsgVkFSIGZvcm1hbF9uYW1lIDogIFRFWFQgOyBWQVIgZm9ybWFs >X3N0YXQgOiBGaWxlLlN0YXR1cykgOiAgQk9PTEVBTiAgUkFJU0VTIHsgT1NFcnJvci5FIH0gPSAK >ICBCRUdJTgogICAgSUYgb2JqZWN0X18ubmV4dFdpdGhTdGF0dXNfc2xvdCA9IE5JTCBUSEVOCiAg >ICAgICgqIHB1bnQgdG8gTW9kdWxhLTMgb2JqZWN0IHR5cGUgZGVmbiAqKQogICAgICBSRVRVUk4g >RlMuUHVibGljSXRlcmF0b3IubmV4dFdpdGhTdGF0dXMob2JqZWN0X18sIGZvcm1hbF9uYW1lLCBm >b3JtYWxfc3RhdCkKICAgIEVMU0UKICAgICAgKCogbWV0aG9kIG92ZXJyaWRlbiBieSBTY2hlbWUg >Y29kZSAqKQogICAgICBWQVIKICAgICAgICBhcmdzX18gOiBTY2hlbWVQYWlyLlQgOj0gTkVXKFNj >aGVtZVBhaXIuVCwgZmlyc3QgOj0gb2JqZWN0X18sIHJlc3QgOj0gTklMKTsKICAgICAgQkVHSU4K >ICAgICAgICBhcmdzX18gOj0gU2NoZW1lVXRpbHMuQ29ucyhTY2hlbWVNb2R1bGEzVHlwZXMuVG9T >Y2hlbWVfVEVYVChmb3JtYWxfbmFtZSksYXJnc19fKTsKICAgICAgICBhcmdzX18gOj0gU2NoZW1l >VXRpbHMuQ29ucyhUb1NjaGVtZV9GaWxlX1N0YXR1cyhmb3JtYWxfc3RhdCksYXJnc19fKTsKICAg >ICAgICBhcmdzX18gOj0gU2NoZW1lVXRpbHMuUmV2ZXJzZShhcmdzX18pOwogICAgICAgIFJFVFVS >TiBTY2hlbWVNb2R1bGEzVHlwZXMuVG9Nb2R1bGFfQk9PTEVBTihTY2hlbWVQcm9jZWR1cmVTdHVi >cy5DYWxsU2NoZW1lKG9iamVjdF9fLmludGVycCwgb2JqZWN0X18ubmV4dFdpdGhTdGF0dXNfc2xv >dCwgYXJnc19fKSkKICAgICAgICAoKiBhbmQgdGhpcyBpcyB3aGVyZSB3ZSBuZWVkIHRvIHVucGFj >ayBWQVIgcGFyYW1zICopCiAgICAgIEVORAogICAgRU5ECiAgRU5EIEZTX1B1YmxpY0l0ZXJhdG9y >X25leHRXaXRoU3RhdHVzX2RlZmF1bHQ7CgpQUk9DRURVUkUgTWV0aG9kU3R1Yl9GU19QdWJsaWNJ >dGVyYXRvcl9uZXh0KGludGVycCA6IFNjaGVtZS5UOwogICAgICAgICAgICAgICAgICAgICAgYXJn >cyA6IFNjaGVtZU9iamVjdC5UOwogICAgICAgICAgICAgICAgICAgICAgZXhjSGFuZGxlciA6IFNj >aGVtZU9iamVjdC5UKSA6IFNjaGVtZU9iamVjdC5UCiAgUkFJU0VTIHsgU2NoZW1lLkUgfSA9IAog >CiAgUFJPQ0VEVVJFIE5leHQoKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IFNjaGVtZS5FIH0g >PSAKICAgIEJFR0lOCiAgICAgIFRSWSBSRVRVUk4gU2NoZW1lVXRpbHMuRmlyc3QocF9fKSBGSU5B >TExZIHBfXyA6PSBTY2hlbWVQYWlyLlBhaXIoU2NoZW1lVXRpbHMuUmVzdChwX18pKSBFTkQKICAg >IEVORCBOZXh0OwogCiAgVkFSIHBfXyA6PSBTY2hlbWVQYWlyLlBhaXIoYXJncyk7CiAgQkVHSU4K >ICAgIFRSWQogICAgICAoKiB1bnBhY2sgZm9ybWFscyAqKQogICAgICBWQVIgPCpOT1dBUk4qPmp1 >bmtfXyA6PSAwOwogICAgICAgICAgIHRoaXMgOj0gVG9Nb2R1bGFfRlNfUHVibGljSXRlcmF0b3Io >TmV4dCgpKTsKICAgICAgICAgICBmb3JtYWxfbmFtZSA6PSBTY2hlbWVNb2R1bGEzVHlwZXMuVG9N >b2R1bGFfVEVYVChOZXh0KCkpOyBCRUdJTgogICAgICAgICgqIGNhcnJ5IG91dCBOSUwgY2hlY2tz >IGZvciBvcGVuIGFycmF5cyAqKQoKICAgICAgICAoKiBtYWtlIHByb2NlZHVyZSBjYWxsICopCiAg >ICAgICAgV0lUSCByZXMgPSBTY2hlbWVNb2R1bGEzVHlwZXMuVG9TY2hlbWVfQk9PTEVBTih0aGlz >Lm5leHQoZm9ybWFsX25hbWUpKSBETwogICAgICAgICgqIHVucGFjayBWQVIgcGFyYW1zICopCiAg >ICAgICAgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICAgICAgICBFVkFMIE5leHQoKTsK >ICAgICAgICBFVkFMIFNjaGVtZVV0aWxzLlNldEZpcnN0KHBfXyxTY2hlbWVNb2R1bGEzVHlwZXMu >VG9TY2hlbWVfVEVYVChmb3JtYWxfbmFtZSkpOwogICAgICAgIEVWQUwgTmV4dCgpOwoKICAgICAg >ICAoKiByZXR1cm4gcHJvY2VkdXJlIHJlc3VsdCAqKQogICAgICAgIFJFVFVSTiByZXMKICAgICAg >ICBFTkQKICAgICAgRU5EKCpXSVRIKikKICAgIEVYQ0VQVAogICAgRU5EOwogICAgPCpOT1dBUk4q >PlJFVFVSTiBTY2hlbWVCb29sZWFuLkZhbHNlKCkKICBFTkQgTWV0aG9kU3R1Yl9GU19QdWJsaWNJ >dGVyYXRvcl9uZXh0OwpQUk9DRURVUkUgTWV0aG9kU3R1Yl9GU19QdWJsaWNJdGVyYXRvcl9jbG9z >ZShpbnRlcnAgOiBTY2hlbWUuVDsKICAgICAgICAgICAgICAgICAgICAgIGFyZ3MgOiBTY2hlbWVP >YmplY3QuVDsKICAgICAgICAgICAgICAgICAgICAgIGV4Y0hhbmRsZXIgOiBTY2hlbWVPYmplY3Qu >VCkgOiBTY2hlbWVPYmplY3QuVAogIFJBSVNFUyB7IFNjaGVtZS5FIH0gPSAKIAogIFBST0NFRFVS >RSBOZXh0KCkgOiBTY2hlbWVPYmplY3QuVCBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAgICBCRUdJ >TgogICAgICBUUlkgUkVUVVJOIFNjaGVtZVV0aWxzLkZpcnN0KHBfXykgRklOQUxMWSBwX18gOj0g >U2NoZW1lUGFpci5QYWlyKFNjaGVtZVV0aWxzLlJlc3QocF9fKSkgRU5ECiAgICBFTkQgTmV4dDsK >IAogIFZBUiBwX18gOj0gU2NoZW1lUGFpci5QYWlyKGFyZ3MpOwogIEJFR0lOCiAgICBUUlkKICAg >ICAgKCogdW5wYWNrIGZvcm1hbHMgKikKICAgICAgVkFSIDwqTk9XQVJOKj5qdW5rX18gOj0gMDsK >ICAgICAgICAgICB0aGlzIDo9IFRvTW9kdWxhX0ZTX1B1YmxpY0l0ZXJhdG9yKE5leHQoKSk7IEJF >R0lOCiAgICAgICAgKCogY2Fycnkgb3V0IE5JTCBjaGVja3MgZm9yIG9wZW4gYXJyYXlzICopCgog >ICAgICAgICgqIG1ha2UgcHJvY2VkdXJlIGNhbGwgKikKICAgICAgICB0aGlzLmNsb3NlKCk7CiAg >ICAgICAgKCogdW5wYWNrIFZBUiBwYXJhbXMgKikKICAgICAgICBwX18gOj0gU2NoZW1lUGFpci5Q >YWlyKGFyZ3MpOwogICAgICAgIEVWQUwgTmV4dCgpOwoKICAgICAgICAoKiBwcm9wZXIgcHJvY2Vk >dXJlIDogcmV0dXJuIFRSVUUgKikKICAgICAgICBSRVRVUk4gU2NoZW1lQm9vbGVhbi5UcnVlKCkK >ICAgICAgRU5EKCpXSVRIKikKICAgIEVYQ0VQVAogICAgRU5EOwogICAgPCpOT1dBUk4qPlJFVFVS >TiBTY2hlbWVCb29sZWFuLkZhbHNlKCkKICBFTkQgTWV0aG9kU3R1Yl9GU19QdWJsaWNJdGVyYXRv >cl9jbG9zZTsKUFJPQ0VEVVJFIE1ldGhvZFN0dWJfRlNfUHVibGljSXRlcmF0b3JfbmV4dFdpdGhT >dGF0dXMoaW50ZXJwIDogU2NoZW1lLlQ7CiAgICAgICAgICAgICAgICAgICAgICBhcmdzIDogU2No >ZW1lT2JqZWN0LlQ7CiAgICAgICAgICAgICAgICAgICAgICBleGNIYW5kbGVyIDogU2NoZW1lT2Jq >ZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQKICBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAKICBQUk9D >RURVUkUgTmV4dCgpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUgfSA9IAogICAg >QkVHSU4KICAgICAgVFJZIFJFVFVSTiBTY2hlbWVVdGlscy5GaXJzdChwX18pIEZJTkFMTFkgcF9f >IDo9IFNjaGVtZVBhaXIuUGFpcihTY2hlbWVVdGlscy5SZXN0KHBfXykpIEVORAogICAgRU5EIE5l >eHQ7CiAKICBWQVIgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICBCRUdJTgogICAgVFJZ >CiAgICAgICgqIHVucGFjayBmb3JtYWxzICopCiAgICAgIFZBUiA8Kk5PV0FSTio+anVua19fIDo9 >IDA7CiAgICAgICAgICAgdGhpcyA6PSBUb01vZHVsYV9GU19QdWJsaWNJdGVyYXRvcihOZXh0KCkp >OwogICAgICAgICAgIGZvcm1hbF9uYW1lIDo9IFNjaGVtZU1vZHVsYTNUeXBlcy5Ub01vZHVsYV9U >RVhUKE5leHQoKSk7CiAgICAgICAgICAgZm9ybWFsX3N0YXQgOj0gVG9Nb2R1bGFfRmlsZV9TdGF0 >dXMoTmV4dCgpKTsgQkVHSU4KICAgICAgICAoKiBjYXJyeSBvdXQgTklMIGNoZWNrcyBmb3Igb3Bl >biBhcnJheXMgKikKCiAgICAgICAgKCogbWFrZSBwcm9jZWR1cmUgY2FsbCAqKQogICAgICAgIFdJ >VEggcmVzID0gU2NoZW1lTW9kdWxhM1R5cGVzLlRvU2NoZW1lX0JPT0xFQU4odGhpcy5uZXh0V2l0 >aFN0YXR1cyhmb3JtYWxfbmFtZSwgZm9ybWFsX3N0YXQpKSBETwogICAgICAgICgqIHVucGFjayBW >QVIgcGFyYW1zICopCiAgICAgICAgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICAgICAg >ICBFVkFMIE5leHQoKTsKICAgICAgICBFVkFMIFNjaGVtZVV0aWxzLlNldEZpcnN0KHBfXyxTY2hl >bWVNb2R1bGEzVHlwZXMuVG9TY2hlbWVfVEVYVChmb3JtYWxfbmFtZSkpOwogICAgICAgIEVWQUwg >TmV4dCgpOwogICAgICAgIEVWQUwgU2NoZW1lVXRpbHMuU2V0Rmlyc3QocF9fLFRvU2NoZW1lX0Zp >bGVfU3RhdHVzKGZvcm1hbF9zdGF0KSk7CiAgICAgICAgRVZBTCBOZXh0KCk7CgogICAgICAgICgq >IHJldHVybiBwcm9jZWR1cmUgcmVzdWx0ICopCiAgICAgICAgUkVUVVJOIHJlcwogICAgICAgIEVO >RAogICAgICBFTkQoKldJVEgqKQogICAgRVhDRVBUCiAgICAgIHwgT1NFcnJvci5FKHhhcmcpID0+ >IEVWQUwgU2NoZW1lQXBwbHkuT25lQXJnKGludGVycCxleGNIYW5kbGVyLFNjaGVtZVV0aWxzLkxp >c3QyKFNjaGVtZVN5bWJvbC5Gcm9tVGV4dCgicXVvdGUiKSxTY2hlbWVVdGlscy5Db25zKFNjaGVt >ZVN5bWJvbC5Gcm9tVGV4dCgiT1NFcnJvci5FIiksIFRvU2NoZW1lX0F0b21MaXN0X1QoeGFyZykp >KSkKICAgIEVORDsKICAgIDwqTk9XQVJOKj5SRVRVUk4gU2NoZW1lQm9vbGVhbi5GYWxzZSgpCiAg >RU5EIE1ldGhvZFN0dWJfRlNfUHVibGljSXRlcmF0b3JfbmV4dFdpdGhTdGF0dXM7CgpQUk9DRURV >UkUgRmllbGRHZXRfRlNfSXRlcmF0b3IoaW50ZXJwIDogU2NoZW1lLlQ7IG9iaiA6IFNjaGVtZU9i >amVjdC5UOyBhcmdzIDogU2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsg >U2NoZW1lLkUgfSA9CiAgVkFSCiAgICBmaWVsZCAgIDo9IFNjaGVtZVV0aWxzLkZpcnN0KGFyZ3Mp >OwogICAgbmFycm93IDogRlMuSXRlcmF0b3I7CiAgQkVHSU4KICAgIElGIE5PVCBJU1RZUEUob2Jq >LEZTLkl0ZXJhdG9yKSBPUiBvYmo9TklMIFRIRU4KICAgICAgUkFJU0UgU2NoZW1lLkUoIk5vdCBv >ZiB0eXBlIEZTLkl0ZXJhdG9yIDogIiAmIFNjaGVtZVV0aWxzLlN0cmluZ2lmeShvYmopKQogICAg >RU5EOwogICAgbmFycm93IDo9IE5BUlJPVyhvYmosRlMuSXRlcmF0b3IpOwogICAgSUYgRkFMU0Ug >VEhFTiA8KkFTU0VSVCBGQUxTRSo+CiAgICBFTFNFIFJBSVNFIFNjaGVtZS5FKCJVbmtub3duIGZp >ZWxkICIgJiBTY2hlbWVVdGlscy5TdHJpbmdpZnkoZmllbGQpKQogICAgRU5ECiAgRU5EIEZpZWxk >R2V0X0ZTX0l0ZXJhdG9yOwoKUFJPQ0VEVVJFIEZpZWxkU2V0X0ZTX0l0ZXJhdG9yKGludGVycCA6 >IFNjaGVtZS5UOyBvYmogOiBTY2hlbWVPYmplY3QuVDsgYXJncyA6IFNjaGVtZU9iamVjdC5UKSA6 >IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IFNjaGVtZS5FIH0gPQogIFZBUgogICAgZmllbGQgICA6 >PSBTY2hlbWVVdGlscy5GaXJzdChhcmdzKTsKICAgIHZhbHVlICAgOj0gU2NoZW1lVXRpbHMuRmly >c3QoU2NoZW1lVXRpbHMuUmVzdChhcmdzKSk7CiAgICBuYXJyb3cgOiBGUy5JdGVyYXRvcjsKICAg >IHJlcyA6IFNjaGVtZU9iamVjdC5UOwogIEJFR0lOCiAgICBJRiBOT1QgSVNUWVBFKG9iaixGUy5J >dGVyYXRvcikgT1Igb2JqPU5JTCBUSEVOCiAgICAgIFJBSVNFIFNjaGVtZS5FKCJOb3Qgb2YgdHlw >ZSBGUy5JdGVyYXRvciA6ICIgJiBTY2hlbWVVdGlscy5TdHJpbmdpZnkob2JqKSkKICAgIEVORDsK >ICAgIG5hcnJvdyA6PSBOQVJST1cob2JqLEZTLkl0ZXJhdG9yKTsKICAgIElGIEZBTFNFIFRIRU4g >PCpBU1NFUlQgRkFMU0UqPgogICAgRUxTRSBSQUlTRSBTY2hlbWUuRSgiVW5rbm93biBmaWVsZCAi >ICYgU2NoZW1lVXRpbHMuU3RyaW5naWZ5KGZpZWxkKSkKICAgIEVORDsKICAgIFJFVFVSTiByZXMK >ICBFTkQgRmllbGRTZXRfRlNfSXRlcmF0b3I7CgpQUk9DRURVUkUgRmllbGRHZXRfRlNfUHVibGlj >SXRlcmF0b3IoaW50ZXJwIDogU2NoZW1lLlQ7IG9iaiA6IFNjaGVtZU9iamVjdC5UOyBhcmdzIDog >U2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUgfSA9CiAg >VkFSCiAgICBmaWVsZCAgIDo9IFNjaGVtZVV0aWxzLkZpcnN0KGFyZ3MpOwogICAgbmFycm93IDog >RlMuUHVibGljSXRlcmF0b3I7CiAgQkVHSU4KICAgIElGIE5PVCBJU1RZUEUob2JqLEZTLlB1Ymxp >Y0l0ZXJhdG9yKSBPUiBvYmo9TklMIFRIRU4KICAgICAgUkFJU0UgU2NoZW1lLkUoIk5vdCBvZiB0 >eXBlIEZTLlB1YmxpY0l0ZXJhdG9yIDogIiAmIFNjaGVtZVV0aWxzLlN0cmluZ2lmeShvYmopKQog >ICAgRU5EOwogICAgbmFycm93IDo9IE5BUlJPVyhvYmosRlMuUHVibGljSXRlcmF0b3IpOwogICAg >SUYgRkFMU0UgVEhFTiA8KkFTU0VSVCBGQUxTRSo+CiAgICBFTFNFIFJBSVNFIFNjaGVtZS5FKCJV >bmtub3duIGZpZWxkICIgJiBTY2hlbWVVdGlscy5TdHJpbmdpZnkoZmllbGQpKQogICAgRU5ECiAg >RU5EIEZpZWxkR2V0X0ZTX1B1YmxpY0l0ZXJhdG9yOwoKUFJPQ0VEVVJFIEZpZWxkU2V0X0ZTX1B1 >YmxpY0l0ZXJhdG9yKGludGVycCA6IFNjaGVtZS5UOyBvYmogOiBTY2hlbWVPYmplY3QuVDsgYXJn >cyA6IFNjaGVtZU9iamVjdC5UKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IFNjaGVtZS5FIH0g >PQogIFZBUgogICAgZmllbGQgICA6PSBTY2hlbWVVdGlscy5GaXJzdChhcmdzKTsKICAgIHZhbHVl >ICAgOj0gU2NoZW1lVXRpbHMuRmlyc3QoU2NoZW1lVXRpbHMuUmVzdChhcmdzKSk7CiAgICBuYXJy >b3cgOiBGUy5QdWJsaWNJdGVyYXRvcjsKICAgIHJlcyA6IFNjaGVtZU9iamVjdC5UOwogIEJFR0lO >CiAgICBJRiBOT1QgSVNUWVBFKG9iaixGUy5QdWJsaWNJdGVyYXRvcikgT1Igb2JqPU5JTCBUSEVO >CiAgICAgIFJBSVNFIFNjaGVtZS5FKCJOb3Qgb2YgdHlwZSBGUy5QdWJsaWNJdGVyYXRvciA6ICIg >JiBTY2hlbWVVdGlscy5TdHJpbmdpZnkob2JqKSkKICAgIEVORDsKICAgIG5hcnJvdyA6PSBOQVJS >T1cob2JqLEZTLlB1YmxpY0l0ZXJhdG9yKTsKICAgIElGIEZBTFNFIFRIRU4gPCpBU1NFUlQgRkFM >U0UqPgogICAgRUxTRSBSQUlTRSBTY2hlbWUuRSgiVW5rbm93biBmaWVsZCAiICYgU2NoZW1lVXRp >bHMuU3RyaW5naWZ5KGZpZWxkKSkKICAgIEVORDsKICAgIFJFVFVSTiByZXMKICBFTkQgRmllbGRT >ZXRfRlNfUHVibGljSXRlcmF0b3I7CgoKCgoKClBST0NFRFVSRSBUb1NjaGVtZV9BdG9tTGlzdF9U >KFJFQURPTkxZIHggOiBBdG9tTGlzdC5UKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IH0gPSAK >ICBCRUdJTgogICAgUkVUVVJOIHgKICBFTkQgVG9TY2hlbWVfQXRvbUxpc3RfVDsKCgpQUk9DRURV >UkUgVG9TY2hlbWVfRlNfSXRlcmF0b3IoUkVBRE9OTFkgeCA6IEZTLkl0ZXJhdG9yKSA6IFNjaGVt >ZU9iamVjdC5UIFJBSVNFUyB7IH0gPSAKICBCRUdJTgogICAgUkVUVVJOIHgKICBFTkQgVG9TY2hl >bWVfRlNfSXRlcmF0b3I7CgoKUFJPQ0VEVVJFIFRvU2NoZW1lX0ZpbGVfVChSRUFET05MWSB4IDog >RmlsZS5UKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IH0gPSAKICBCRUdJTgogICAgUkVUVVJO >IHgKICBFTkQgVG9TY2hlbWVfRmlsZV9UOwoKClBST0NFRFVSRSBUb1NjaGVtZV9GaWxlX1N0YXR1 >cyhSRUFET05MWSB4IDogRmlsZS5TdGF0dXMpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2No >ZW1lLkUgfSA9IAogIEJFR0lOCiAgICBWQVIgcmVzIDogU2NoZW1lUGFpci5UOj1OSUw7IEJFR0lO >CiAgICAgIHJlcyA6PSBTY2hlbWVVdGlscy5Db25zKFNjaGVtZVV0aWxzLkNvbnMoU2NoZW1lU3lt >Ym9sLkZyb21UZXh0KCJ0eXBlIiksVG9TY2hlbWVfQXRvbV9UKHgudHlwZSkpLHJlcyk7CiAgICAg >IHJlcyA6PSBTY2hlbWVVdGlscy5Db25zKFNjaGVtZVV0aWxzLkNvbnMoU2NoZW1lU3ltYm9sLkZy >b21UZXh0KCJtb2RpZmljYXRpb25UaW1lIiksU2NoZW1lTW9kdWxhM1R5cGVzLlRvU2NoZW1lX0xP >TkdSRUFMKHgubW9kaWZpY2F0aW9uVGltZSkpLHJlcyk7CiAgICAgIHJlcyA6PSBTY2hlbWVVdGls >cy5Db25zKFNjaGVtZVV0aWxzLkNvbnMoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJzaXplIiksVG9T >Y2hlbWVfVkFMMExPTkdJTlRfX1ZBTDEwNzM3NDUxMTJMT05HSU5UKHguc2l6ZSkpLHJlcyk7CiAg >ICAgIFJFVFVSTiByZXMKICAgIEVORAogIEVORCBUb1NjaGVtZV9GaWxlX1N0YXR1czsKCgpQUk9D >RURVUkUgVG9Nb2R1bGFfRlNfQ3JlYXRlT3B0aW9uKHggOiBTY2hlbWVPYmplY3QuVCkgOiAoRlMu >Q3JlYXRlT3B0aW9uKSBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAgQkVHSU4KQ09OU1QKICAgICAg >TmFtZSA9IEFSUkFZIEZTLkNyZWF0ZU9wdGlvbiBPRiBURVhUIHsgIk5ldmVyIiwgIk9rIiwgIkFs >d2F5cyIgfTsgCiAgICBCRUdJTgogICAgICBGT1IgaSA6PSBGSVJTVChOYW1lKSBUTyBMQVNUKE5h >bWUpIERPCiAgICAgICAgSUYgU2NoZW1lU3ltYm9sLkZyb21UZXh0KE5hbWVbaV0pID0geCBUSEVO >CiAgICAgICAgICBSRVRVUk4gaQogICAgICAgIEVORAogICAgICBFTkQ7CiAgICAgIFJBSVNFIFNj >aGVtZS5FKCJOb3QgYSB2YWx1ZSBvZiBGUy5DcmVhdGVPcHRpb24gOiAiICYgU2NoZW1lVXRpbHMu >U3RyaW5naWZ5KHgpKQogICAgRU5ECiAgRU5EIFRvTW9kdWxhX0ZTX0NyZWF0ZU9wdGlvbjsKCgpQ >Uk9DRURVUkUgVG9Nb2R1bGFfRlNfQWNjZXNzT3B0aW9uKHggOiBTY2hlbWVPYmplY3QuVCkgOiAo >RlMuQWNjZXNzT3B0aW9uKSBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAgQkVHSU4KQ09OU1QKICAg >ICAgTmFtZSA9IEFSUkFZIEZTLkFjY2Vzc09wdGlvbiBPRiBURVhUIHsgIk9ubHlPd25lckNhblJl >YWQiLCAiUmVhZE9ubHkiLCAiRGVmYXVsdCIgfTsgCiAgICBCRUdJTgogICAgICBGT1IgaSA6PSBG >SVJTVChOYW1lKSBUTyBMQVNUKE5hbWUpIERPCiAgICAgICAgSUYgU2NoZW1lU3ltYm9sLkZyb21U >ZXh0KE5hbWVbaV0pID0geCBUSEVOCiAgICAgICAgICBSRVRVUk4gaQogICAgICAgIEVORAogICAg >ICBFTkQ7CiAgICAgIFJBSVNFIFNjaGVtZS5FKCJOb3QgYSB2YWx1ZSBvZiBGUy5BY2Nlc3NPcHRp >b24gOiAiICYgU2NoZW1lVXRpbHMuU3RyaW5naWZ5KHgpKQogICAgRU5ECiAgRU5EIFRvTW9kdWxh >X0ZTX0FjY2Vzc09wdGlvbjsKCgpQUk9DRURVUkUgVG9Nb2R1bGFfRmlsZV9UKHggOiBTY2hlbWVP >YmplY3QuVCkgOiAoRmlsZS5UKSBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAgQkVHSU4KICAgIElG >IE5PVCBJU1RZUEUoeCxGaWxlLlQpIFRIRU4KICAgICAgUkFJU0UgU2NoZW1lLkUoIk5vdCBvZiB0 >eXBlIEZpbGUuVCA6ICIgJiBTY2hlbWVVdGlscy5TdHJpbmdpZnkoeCkpCiAgICBFTkQ7CiAgICBS >RVRVUk4geAogIEVORCBUb01vZHVsYV9GaWxlX1Q7CgoKUFJPQ0VEVVJFIFRvU2NoZW1lX1ZBTDBM >T05HSU5UX19WQUwxMDczNzQ1MTEyTE9OR0lOVChSRUFET05MWSB4IDogWyBWQUwoMCwgTE9OR0lO >VCApLi5WQUwoLTEwNzM3NDUxMTIsIExPTkdJTlQgKSBdKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNF >UyB7IFNjaGVtZS5FIH0gPSAKICBCRUdJTgogICAgUkVUVVJOIFRvU2NoZW1lX0xPTkdJTlQoeCkK >ICBFTkQgVG9TY2hlbWVfVkFMMExPTkdJTlRfX1ZBTDEwNzM3NDUxMTJMT05HSU5UOwoKClBST0NF >RFVSRSBUb1NjaGVtZV9BdG9tX1QoUkVBRE9OTFkgeCA6IEF0b20uVCkgOiBTY2hlbWVPYmplY3Qu >VCBSQUlTRVMgeyB9ID0gCiAgQkVHSU4KICAgIFJFVFVSTiB4CiAgRU5EIFRvU2NoZW1lX0F0b21f >VDsKCgpQUk9DRURVUkUgVG9TY2hlbWVfTE9OR0lOVChSRUFET05MWSB4IDogIExPTkdJTlQgKSA6 >IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IFNjaGVtZS5FIH0gPSAKICBCRUdJTgogICAgV0lUSCBy >ZWYgPSBORVcoUkVGIExPTkdJTlQpIERPCiAgICAgIHJlZl4gOj0geDsKICAgICAgUkVUVVJOIFNj >aGVtZU1vZHVsYTNUeXBlcy5Ub1NjaGVtZV9MT05HSU5UKHJlZikKICAgIEVORAogIEVORCBUb1Nj >aGVtZV9MT05HSU5UOwoKUFJPQ0VEVVJFIFRvTW9kdWxhX0ZTX1B1YmxpY0l0ZXJhdG9yKHggOiBT >Y2hlbWVPYmplY3QuVCkgOiAoRlMuUHVibGljSXRlcmF0b3IpIFJBSVNFUyB7IFNjaGVtZS5FIH0g >PSAKICBCRUdJTgogICAgSUYgTk9UIElTVFlQRSh4LEZTLlB1YmxpY0l0ZXJhdG9yKSBUSEVOCiAg >ICAgIFJBSVNFIFNjaGVtZS5FKCJOb3Qgb2YgdHlwZSBGUy5QdWJsaWNJdGVyYXRvciA6ICIgJiBT >Y2hlbWVVdGlscy5TdHJpbmdpZnkoeCkpCiAgICBFTkQ7CiAgICBSRVRVUk4geAogIEVORCBUb01v >ZHVsYV9GU19QdWJsaWNJdGVyYXRvcjsKCgpQUk9DRURVUkUgVG9Nb2R1bGFfRlNfSXRlcmF0b3Io >eCA6IFNjaGVtZU9iamVjdC5UKSA6IChGUy5JdGVyYXRvcikgUkFJU0VTIHsgU2NoZW1lLkUgfSA9 >IAogIEJFR0lOCiAgICBJRiBOT1QgSVNUWVBFKHgsRlMuSXRlcmF0b3IpIFRIRU4KICAgICAgUkFJ >U0UgU2NoZW1lLkUoIk5vdCBvZiB0eXBlIEZTLkl0ZXJhdG9yIDogIiAmIFNjaGVtZVV0aWxzLlN0 >cmluZ2lmeSh4KSkKICAgIEVORDsKICAgIFJFVFVSTiB4CiAgRU5EIFRvTW9kdWxhX0ZTX0l0ZXJh >dG9yOwoKClBST0NFRFVSRSBUb01vZHVsYV9GaWxlX1N0YXR1cyh4IDogU2NoZW1lT2JqZWN0LlQp >IDogKEZpbGUuU3RhdHVzKSBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAgQkVHSU4KICAgIFZBUiBy >ZXMgOiBGaWxlLlN0YXR1czsKICAgICAgICBwIDo9IFNjaGVtZVBhaXIuUGFpcih4KTsKICAgIEJF >R0lOCiAgICAgIFdISUxFIHAgIyBOSUwgRE8KICAgICAgICBJRiBGQUxTRSBUSEVOCiAgICAgICAg >RUxTSUYgU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJ0eXBlIikgPSBTY2hlbWVVdGlscy5GaXJzdChw >LmZpcnN0KSBUSEVOCiAgICAgICAgICByZXMudHlwZSA6PSBUb01vZHVsYV9BdG9tX1QoU2NoZW1l >VXRpbHMuUmVzdChwLmZpcnN0KSkKICAgICAgICBFTFNJRiBTY2hlbWVTeW1ib2wuRnJvbVRleHQo >Im1vZGlmaWNhdGlvblRpbWUiKSA9IFNjaGVtZVV0aWxzLkZpcnN0KHAuZmlyc3QpIFRIRU4KICAg >ICAgICAgIHJlcy5tb2RpZmljYXRpb25UaW1lIDo9IFNjaGVtZU1vZHVsYTNUeXBlcy5Ub01vZHVs >YV9MT05HUkVBTChTY2hlbWVVdGlscy5SZXN0KHAuZmlyc3QpKQogICAgICAgIEVMU0lGIFNjaGVt >ZVN5bWJvbC5Gcm9tVGV4dCgic2l6ZSIpID0gU2NoZW1lVXRpbHMuRmlyc3QocC5maXJzdCkgVEhF >TgogICAgICAgICAgcmVzLnNpemUgOj0gVG9Nb2R1bGFfVkFMMExPTkdJTlRfX1ZBTDEwNzM3NDUz >MzZMT05HSU5UKFNjaGVtZVV0aWxzLlJlc3QocC5maXJzdCkpCiAgICAgICAgRU5EOwogICAgICAg >IHAgOj0gU2NoZW1lUGFpci5QYWlyKHAucmVzdCkKICAgICAgRU5EOwogICAgICBSRVRVUk4gcmVz >CiAgICBFTkQKICBFTkQgVG9Nb2R1bGFfRmlsZV9TdGF0dXM7CgoKUFJPQ0VEVVJFIFRvTW9kdWxh >X1ZBTDBMT05HSU5UX19WQUwxMDczNzQ1MzM2TE9OR0lOVCh4IDogU2NoZW1lT2JqZWN0LlQpIDog >KFsgVkFMKDAsIExPTkdJTlQgKS4uVkFMKC0xMDczNzQ1MzM2LCBMT05HSU5UICkgXSkgUkFJU0VT >IHsgU2NoZW1lLkUgfSA9IAogIEJFR0lOCiAgICBXSVRIIGJhc2VWYWwgPSBUb01vZHVsYV9MT05H >SU5UKHgpIERPCiAgICAgIElGIGJhc2VWYWwgPCBGSVJTVChbIFZBTCgwLCBMT05HSU5UICkuLlZB >TCgtMTA3Mzc0NTMzNiwgTE9OR0lOVCApIF0pIE9SIGJhc2VWYWwgPiBMQVNUKFsgVkFMKDAsIExP >TkdJTlQgKS4uVkFMKC0xMDczNzQ1MzM2LCBMT05HSU5UICkgXSkgVEhFTgogICAgICAgIFJBSVNF >IFNjaGVtZS5FKCJWYWx1ZSBvdXQgb2YgcmFuZ2UgZm9yIFsgVkFMKDAsIExPTkdJTlQgKS4uVkFM >KC0xMDczNzQ1MzM2LCBMT05HSU5UICkgXSA6IiAmIFNjaGVtZVV0aWxzLlN0cmluZ2lmeSh4KSkK >ICAgICAgRU5EOwogICAgICBSRVRVUk4gYmFzZVZhbAogICAgRU5ECiAgRU5EIFRvTW9kdWxhX1ZB >TDBMT05HSU5UX19WQUwxMDczNzQ1MzM2TE9OR0lOVDsKCgpQUk9DRURVUkUgVG9Nb2R1bGFfQXRv >bV9UKHggOiBTY2hlbWVPYmplY3QuVCkgOiAoQXRvbS5UKSBSQUlTRVMgeyBTY2hlbWUuRSB9ID0g >CiAgQkVHSU4KICAgIElGIE5PVCBJU1RZUEUoeCxBdG9tLlQpIFRIRU4KICAgICAgUkFJU0UgU2No >ZW1lLkUoIk5vdCBvZiB0eXBlIEF0b20uVCA6ICIgJiBTY2hlbWVVdGlscy5TdHJpbmdpZnkoeCkp >CiAgICBFTkQ7CiAgICBSRVRVUk4geAogIEVORCBUb01vZHVsYV9BdG9tX1Q7CgoKUFJPQ0VEVVJF >IFRvTW9kdWxhX0xPTkdJTlQoeCA6IFNjaGVtZU9iamVjdC5UKSA6ICBMT05HSU5UICBSQUlTRVMg >eyBTY2hlbWUuRSB9ID0gCiAgQkVHSU4KICAgIFdJVEggcmVmID0gU2NoZW1lTW9kdWxhM1R5cGVz >LlRvTW9kdWxhX0xPTkdJTlQoeCkgRE8KICAgICAgUkVUVVJOIE5BUlJPVyhyZWYsIFJFRiBMT05H >SU5UKV4KICAgIEVORAogIEVORCBUb01vZHVsYV9MT05HSU5UOwoKQkVHSU4gRU5EIEZTU2NoZW1l >U3R1YnMuCg== > >--_2d6969dc-a0fa-42e3-85e1-71600a2e9b7d_-- From hosking at cs.purdue.edu Fri Dec 31 23:01:27 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 31 Dec 2010 17:01:27 -0500 Subject: [M3devel] CM3 status In-Reply-To: References: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com> Message-ID: <9EF449E4-72AB-4461-AC0C-1B0A79341E44@cs.purdue.edu> I didn't OK dropping SPARC stack walking, just agreeing that we should move all platforms to gcc-supported stack walking. On Dec 30, 2010, at 7:01 AM, Jay K wrote: > Tony ok'ed this for Solaris/sparc32 a few months ago. I couldn't get it working with gcc 4.5, not even without optimization. > That was the last step in moving off of gcc 4.3 backend. I wasn't real happy about dropping stack walking for Solaris. It should not be difficult to retain. I thought you were going to try to fix m3cg 4.5 to handle it. My preference would be to retain the stack walking code on Solaris/SPARC (since it is so easy to do...) modulo making sure that m3cg 4.5 could cope with it. > Alpha/OSF also doesn't work. I didn't look much into it, and I really don't think it matters. > It is an extremely little used platform. This year I saw it work on 4.0 and 5.1 but otherwise > it had been unused for several years I believe, and I don't see its use continuing much. Last time I ran M3 on Alpha/OSF it did work. > Upgrade of Solaris/sparc32 from gcc 4.3 to 4.5: > > 2010-10-13 11:18 jkrell > > * m3-sys/cminstall/src/config-no-install/SPARC32_SOLARIS.common, > m3-sys/m3cc/gcc/gcc/m3cg/parse.c, m3-sys/m3cc/src/clean_marker.txt, > m3-sys/m3cc/src/m3makefile, m3-libs/m3core/src/runtime/m3makefile, > m3-sys/m3middle/src/Target.m3, > m3-libs/m3core/src/runtime/SOLgnu/m3makefile, > m3-libs/m3core/src/runtime/SOLgnu/m3makefile-old, > m3-libs/m3core/src/runtime/SOLsun/m3makefile, > m3-libs/m3core/src/runtime/SOLsun/m3makefile-old: > > disable Solaris/sparc32 stack walker > switch Solaris/sparc32 to gcc 4.5 backend > function.c: make failure to volatilize when setjmp/vfork present an error > instead of a warning > add missing volatilization > pin Solaris/sparc32 at -O1 in the config file as -O2/-O3 were > seen to hit internal compiler errors (assertion failures) > remove the "all volatile" paths from parse.c (since they > were only for Solaris/sparc32's stack walker) > > > Tony ok'ing (in my interpretation) the abandonment of our stack walker: > > https://mail.elegosoft.com/pipermail/m3devel/2010-October/008019.html > > > At least that was my interpretation. > Using gcc's exception handling support and *its* stack walker (libgcc/libunwind) > should provide the better and more portable functionality on many platforms. > I'm not certain what'd it look like on systems where gcc isn't the usual C compiler (e.g. Solaris) > but it's bound to work well on Linux, NetBSD, FreeBSD, OpenBSD, and Solaris using gcc. > "more portable" as in, across all architectures. > > > Perhaps I should have stuck back with 4.3 until implementing this however. > > > It is definitely a step backward to not have the stack walker on Solaris/sparc32, > but that is the only platform in years that has had one, and it is not terrible > to have every platform on gcc 4.5.2 and not sprinkling volatile around. > There are some backward steps but definitely a lot forward. > I tried using 5.4.0 tonight and I didn't get far. > > > > o possibly unsafe OS calls in new C code (this may be a wrong deduction > > from my side) > > > I don't know what this is referring to. > The Enable/DisableScheduling? I all but undid that. > It should be in a few functions, e.g. malloc/free/realloc/calloc/opendir/readdir/closedir/fopen/fclose. > Some of those it already is in. With OpenBSD moving to pthreads it matters less. > It only matters for user threads. > > > > o GUI input not working for BadBricks and other games (only on Darwin?) > > > Yes this is still a problem, and occurs in 5.8.6 release, on Darwin local X Server. > Doesn't reproduce when remoted to Cygwin/X. Other X apps do work locally. > Not understood. > It'd be good to get confirmation if/when they ever worked. > > > > o no clean way for exception handling with current gcc > > > This is how things have *always* been, *except* on Alpha/OSF and Solaris/sparc32. > Those two platforms have "regressed", but for Solaris/sparc32 it was discussed and > Alpha/OSF I really don't think is important. > > > Exception handling has always been very inefficient on all but approx. those two platforms. > It has always been desirable to fix. > > The inefficiency has a few parts. Mainly that "try" costs pthread_getspecific and setjmp. > The inefficiency of the actual throw/catch is not as worrisome. > > > > o still alignment issues > > > Details? > > > > I'm concerned that things get tried out, don't work properly for all > > our target platforms, but are left then and not cleaned up and something > > else gets tried. I'm not sure this is correct, it is just me feeling > > unwell after reading all those mails. > > > Not really. > > > > > Hudson and Tinderbox status seem to be mostly OK though, but I haven't > > checked in detail (FreeBSD failing was a disk failure on my system > > recently). But the tests don't cover all the things we should check. > > > Yep I try to remember to check Hudson fairly regularly. > I never look at Tinderbox though. > > > > I think it would be good to have an overview of the projects/work that > > is in progress or pending and its status. For example, we've imported > > a new gcc version, but that doesn't seem to work well on all targets, > > or does it? If not, how are we going to address this? Use older versions > > on some platforms? Can I read up on that somewhere? > > All platforms (except NT386) use gcc 4.5.2 for the backend. > (I did the upgrade after the release was made but before it was announced; > they delay announcement while it propagates to mirrors.) > > > Ok, also ARM_DARWIN hypothetically uses 4.2. > Apple forks gcc fairly aggressively. > Perhaps we should merge the two forks. Perhaps. > ARM_DARWIN isn't really supported currently. Probably that should be worked on. > It'd also be interesting to see what Apple did to 4.2 for ppc/x86... > > > > I'd like to suggest to simply use our Trac WiKi to document the ongoing > > > Agreed but I'm lazy. > I just throw "bombs" around.. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Fri Dec 31 23:26:50 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Fri, 31 Dec 2010 17:26:50 -0500 Subject: [M3devel] emac Message-ID: <20101231222650.GB2428@topoi.pooq.com> I may be acquiring an emac, which is a small (but heavy -- 50 pounds) power-PC-based Apple Mac, if I've been informed correctly, running a somewhat obsolete OS. If I end up with it, would there be anything I can usefully test on it that's not being adequately tested already? -- hendrik From jay.krell at cornell.edu Fri Dec 31 23:47:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Dec 2010 22:47:02 +0000 Subject: [M3devel] CM3 status In-Reply-To: <9EF449E4-72AB-4461-AC0C-1B0A79341E44@cs.purdue.edu> References: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com>, , <9EF449E4-72AB-4461-AC0C-1B0A79341E44@cs.purdue.edu> Message-ID: Oops, you can see the ambiguity? So you'd rather leave Solaris/sparc32 back on gcc-4.3 for now, if the gcc-supported stack walking isn't imminent? And possibly volatile on load/store a lot. (That was more out of laziness maybe, I remember if I tried removing it.) I don't like that, but I can do it. Or is it imminent, by someone other than me? gcc-4.5 even without any optimizations and volatile everywhere didn't work with the Solaris/sparc32 stack walker. I tried a fair amount to debug it but gave up at the time. I continue to assume that Alpha/OSF is even much less interesting, given that it has extremely few users. The code continues to sit unused in CVS, same as it mostly ever did. > Last time I ran M3 on Alpha/OSF it did work. I ran it in 2010 and it didn't work. I don't remember though if that was with gcc 4.3 or 4.5. I could try again with 4.3, but I don't know what the result would be -- we'd leave it back with 4.3 also? > I wasn't real happy about dropping stack walking for Solaris. It should not be difficult to retain. I thought you were going to try to fix m3cg 4.5 to handle it > ...modulo making sure that m3cg 4.5 could cope with it. This was looking to be difficult. Even volatile everywhere and no optimization didn't work. I could give it another try perhaps. Or maybe someone else can? Getting it to work without any optimization and volatile on every load/store should be useful and easy, but it wasn't proving even easy. I figure moving to 4.5 has a fair amount of value, and optimizing one platform Solaris/sparc32 uniquely beyond all others, is less so. Or maybe I should look again more closely at the gcc stuff. Maybe it could be done imminently.. That would nicely remove a lot of target-dependent-ness out of the front/middle end!. - Jay From: hosking at cs.purdue.edu Date: Fri, 31 Dec 2010 17:01:27 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] CM3 status I didn't OK dropping SPARC stack walking, just agreeing that we should move all platforms to gcc-supported stack walking. On Dec 30, 2010, at 7:01 AM, Jay K wrote:Tony ok'ed this for Solaris/sparc32 a few months ago. I couldn't get it working with gcc 4.5, not even without optimization. That was the last step in moving off of gcc 4.3 backend. I wasn't real happy about dropping stack walking for Solaris. It should not be difficult to retain. I thought you were going to try to fix m3cg 4.5 to handle it. My preference would be to retain the stack walking code on Solaris/SPARC (since it is so easy to do...) modulo making sure that m3cg 4.5 could cope with it. Alpha/OSF also doesn't work. I didn't look much into it, and I really don't think it matters. It is an extremely little used platform. This year I saw it work on 4.0 and 5.1 but otherwise it had been unused for several years I believe, and I don't see its use continuing much. Last time I ran M3 on Alpha/OSF it did work. Upgrade of Solaris/sparc32 from gcc 4.3 to 4.5: 2010-10-13 11:18 jkrell * m3-sys/cminstall/src/config-no-install/SPARC32_SOLARIS.common, m3-sys/m3cc/gcc/gcc/m3cg/parse.c, m3-sys/m3cc/src/clean_marker.txt, m3-sys/m3cc/src/m3makefile, m3-libs/m3core/src/runtime/m3makefile, m3-sys/m3middle/src/Target.m3, m3-libs/m3core/src/runtime/SOLgnu/m3makefile, m3-libs/m3core/src/runtime/SOLgnu/m3makefile-old, m3-libs/m3core/src/runtime/SOLsun/m3makefile, m3-libs/m3core/src/runtime/SOLsun/m3makefile-old: disable Solaris/sparc32 stack walker switch Solaris/sparc32 to gcc 4.5 backend function.c: make failure to volatilize when setjmp/vfork present an error instead of a warning add missing volatilization pin Solaris/sparc32 at -O1 in the config file as -O2/-O3 were seen to hit internal compiler errors (assertion failures) remove the "all volatile" paths from parse.c (since they were only for Solaris/sparc32's stack walker) Tony ok'ing (in my interpretation) the abandonment of our stack walker: https://mail.elegosoft.com/pipermail/m3devel/2010-October/008019.html At least that was my interpretation. Using gcc's exception handling support and *its* stack walker (libgcc/libunwind) should provide the better and more portable functionality on many platforms. I'm not certain what'd it look like on systems where gcc isn't the usual C compiler (e.g. Solaris) but it's bound to work well on Linux, NetBSD, FreeBSD, OpenBSD, and Solaris using gcc. "more portable" as in, across all architectures. Perhaps I should have stuck back with 4.3 until implementing this however. It is definitely a step backward to not have the stack walker on Solaris/sparc32, but that is the only platform in years that has had one, and it is not terrible to have every platform on gcc 4.5.2 and not sprinkling volatile around. There are some backward steps but definitely a lot forward. I tried using 5.4.0 tonight and I didn't get far. > o possibly unsafe OS calls in new C code (this may be a wrong deduction > from my side) I don't know what this is referring to. The Enable/DisableScheduling? I all but undid that. It should be in a few functions, e.g. malloc/free/realloc/calloc/opendir/readdir/closedir/fopen/fclose. Some of those it already is in. With OpenBSD moving to pthreads it matters less. It only matters for user threads. > o GUI input not working for BadBricks and other games (only on Darwin?) Yes this is still a problem, and occurs in 5.8.6 release, on Darwin local X Server. Doesn't reproduce when remoted to Cygwin/X. Other X apps do work locally. Not understood. It'd be good to get confirmation if/when they ever worked. > o no clean way for exception handling with current gcc This is how things have *always* been, *except* on Alpha/OSF and Solaris/sparc32. Those two platforms have "regressed", but for Solaris/sparc32 it was discussed and Alpha/OSF I really don't think is important. Exception handling has always been very inefficient on all but approx. those two platforms. It has always been desirable to fix. The inefficiency has a few parts. Mainly that "try" costs pthread_getspecific and setjmp. The inefficiency of the actual throw/catch is not as worrisome. > o still alignment issues Details? > I'm concerned that things get tried out, don't work properly for all > our target platforms, but are left then and not cleaned up and something > else gets tried. I'm not sure this is correct, it is just me feeling > unwell after reading all those mails. Not really. > Hudson and Tinderbox status seem to be mostly OK though, but I haven't > checked in detail (FreeBSD failing was a disk failure on my system > recently). But the tests don't cover all the things we should check. Yep I try to remember to check Hudson fairly regularly. I never look at Tinderbox though. > I think it would be good to have an overview of the projects/work that > is in progress or pending and its status. For example, we've imported > a new gcc version, but that doesn't seem to work well on all targets, > or does it? If not, how are we going to address this? Use older versions > on some platforms? Can I read up on that somewhere? All platforms (except NT386) use gcc 4.5.2 for the backend. (I did the upgrade after the release was made but before it was announced; they delay announcement while it propagates to mirrors.) Ok, also ARM_DARWIN hypothetically uses 4.2. Apple forks gcc fairly aggressively. Perhaps we should merge the two forks. Perhaps. ARM_DARWIN isn't really supported currently. Probably that should be worked on. It'd also be interesting to see what Apple did to 4.2 for ppc/x86... > I'd like to suggest to simply use our Trac WiKi to document the ongoing Agreed but I'm lazy. I just throw "bombs" around.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From ttmrichter at gmail.com Wed Dec 1 06:45:34 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Wed, 1 Dec 2010 13:45:34 +0800 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> <20101130150418.GB11084@topoi.pooq.com> Message-ID: On 1 December 2010 01:18, Jay K wrote: > In the case of templates leading to some meta programming, it was an > accident. > But in the case of operator overloading it seems just goodness. > I am badly conflicted in the case of operator overloading. In its favour we have: - more succinct code that clearly states intent (when overloaded properly) - opportunities to optimize calculations (like your example with intermediate forms for matrix manipulations) Countering that favour, however, we have: - idiots redefining operators in ways that are emphatically *not* proper in terms of semantics (operator<< and operator>> being obvious cases, but also operator+ for concatenation and some of the ... utterly painful uses for operator,) - the inability to define *new* operators (which leads to the first problem of idiots redefining the semantics of operators) - unexpected costs to operations making the eyeballing of execution complexity (time-wise and memory-wise) literally impossible - painful interaction with templates that makes a perfect storm of eye-damaging syntax -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 1 07:49:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Dec 2010 06:49:36 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, , , <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, <20101130150418.GB11084@topoi.pooq.com>, , Message-ID: opportunities to optimize calculations (like your example with intermediate forms for matrix manipulations) Just to be clear, that power is not easily created, and would not be do-able in the constrained form I suggested, where it is always, e.g. T +(T,T) > not proper in terms of semantics (operator<< and operator>> being obvious cases) This would not be allowed in my constrained proposal. > but also operator+ for concatenation This is very reasonable. > utterly painful uses for operator,) I'm surprised that is overloadable, but indeed it appears it is. I don't think I have *ever* seen anyone overload it, and I have seen a lot. > the inability to define new operators (which leads to the first problem of idiots redefining the semantics of operators) Stroupstroup rejected this as too complex. (See the Design&Evolution book). I don't see people pine for this often and I suspect he did the right thing. It creates a layering problem I believe in the typical structure. The lexical analysis would have to get information from higher layers. > unexpected costs to operations making the eyeballing of execution complexity (time-wise and memory-wise) literally impossible This is already the case. As I said. So let's say that every single function call is shown. It is hard to know which functions have which cost. There are also hidden function calls e.g. for "try" and every pointer derereference (right?) Please consider floating point. Historically floating point was "soft float". Sometimes these days it still us. Yet we still have operators for floating point. Why? Because it is just so convenient and idiomatic. Why stop there? A primary design point of C++ is to give user defined types all the powers of built in types. No longer does it require a compiler change to introduce a type with the "power" of int. And so on. > painful interaction with templates that makes a perfect storm of eye-damaging syntax Huh? Specifically? The one vague reason I don't fully understand is: C doesn't have it. Does C represent a good example of a sort of minimalism? Maybe. It isn't clear to me the value of C. It has been *very* widely abandoned in favor of C++. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Wed Dec 1 08:55:49 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 30 Nov 2010 23:55:49 -0800 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, , , <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, <20101130150418.GB11084@topoi.pooq.com>, , Message-ID: <20101201075549.426511A208F@async.async.caltech.edu> I think if you want overloaded operators, you code in Scheme or your own invented language and write a little compiler/translator (to C or Modula-3, for example), for the particular expressions you want to convert. You can have whatever crazy syntax and features you want if you do it that way, and it doesn't gum up everyone else's day... Mika P.S. People were listing things they liked about Modula-3 a few days ago. I'm surprised no one mentioned my favorite properties: -- no possibility of breaking existing code by adding new symbols to an interface, no matter how public -- no possibility of breaking existing code by adding new methods to an object type, no matter how widely exported or how widely used or "subclassed" about how many other programming languages can you say that? (Note also that these features are on a quite different level from Jay's list...) Jay K writes: >--_25139682-7cce-49b1-ae17-6a4dff3488ee_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > >opportunities to optimize calculations (like your example with intermediate= > forms for matrix manipulations) >Just to be clear=2C that power is not easily created=2C and would not be do= >-able in the constrained form I suggested=2C where it is always=2C e.g. T += >(T=2CT) > > > not proper in terms of semantics (operator<< and operator>> being obvio= >us cases) > >This would not be allowed in my constrained proposal. > >> but also operator+ for concatenation > >This is very reasonable. > > > utterly painful uses for operator=2C) > > >I'm surprised that is overloadable=2C but indeed it appears it is. I don't = >think I have *ever* seen anyone overload it=2C and I have seen a lot. > > > > > the inability to define new operators (which leads to the first problem = >of idiots redefining the semantics of operators) > > >Stroupstroup rejected this as too complex. (See the Design&Evolution book). >I don't see people pine for this often and I suspect he did the right thing= >. >It creates a layering problem I believe in the typical structure. >The lexical analysis would have to get information from higher layers. > > > > unexpected costs to operations making the eyeballing of execution comple= >xity (time-wise and memory-wise) literally impossible > > >This is already the case. As I said. So let's say that every single functio= >n call is shown. It is hard to know which functions have which cost. >There are also hidden function calls e.g. for "try" and every pointer derer= >eference (right?) > > >Please consider floating point. Historically floating point was "soft float= >". Sometimes these days it still us. Yet we still have operators for floati= >ng point. >Why? Because it is just so convenient and idiomatic. Why stop there? > > >A primary design point of C++ is to give user defined types all the powers = >of built in types. >No longer does it require a compiler change to introduce a type with the "p= >ower" of int. And so on. > > > >> painful interaction with templates that makes a perfect storm of eye-dama= >ging syntax >Huh? Specifically? > >The one vague reason I don't fully understand is: C doesn't have it. >Does C represent a good example of a sort of minimalism? Maybe. >It isn't clear to me the value of C. It has been *very* widely abandoned in= > favor of C++. > > - Jay > = > >--_25139682-7cce-49b1-ae17-6a4dff3488ee_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >
  • opportunities to optimize calculations (like your example with = >intermediate forms for matrix manipulations)

Just to be clear= >=2C that power is not easily created=2C and would not be do-able in the con= >strained form I suggested=2C where it is always=2C e.g. T +(T=2CT)

<= >div class=3D"ecxgmail_quote"> =3B>=3B =3B not =3Bprope= >r in terms of semantics (e=3D"'courier new'=2C monospace">operator<=3B<=3B and e=3D"" class=3D"ecxApple-style-span" face=3D"'courier new'=2C monospace">op= >erator>=3B>=3B being obvious cases)

This would not be all= >owed in my constrained proposal.

>=3B but also ass=3D"ecxApple-style-span" face=3D"'courier new'=2C monospace">operator+font> for concatenation

This is very reasonable.

 =3B>= >=3B utterly painful uses for face=3D"'courier new'=2C monospace">operator=2C)


I'm sur= >prised that is overloadable=2C but indeed it appears it is. I don't think I= > have *ever* seen anyone overload it=2C and I have seen a lot.
>

 =3B>=3B the inability to define new =3Boperators = >(which leads to the first problem of idiots redefining the semantics of ope= >rators)


Stroupstroup rejected this as too complex. (See the Desi= >gn&=3BEvolution book).
I don't see people pine for this often and I s= >uspect he did the right thing.
It creates a layering problem I believe i= >n the typical structure.
The lexical analysis would have to get informat= >ion from higher layers.


 =3B>=3B unexpected costs to opera= >tions making the eyeballing of execution complexity (time-wise and memory-w= >ise) literally impossible


This is already the case. As I said. S= >o let's say that every single function call is shown. It is hard to know wh= >ich functions have which cost.
There are also hidden function calls e.g.= > for "try" and every pointer derereference (right?)


Please consi= >der floating point. Historically floating point was "soft float". Sometimes= > these days it still us. Yet we still have operators for floating point.>Why? Because it is just so convenient and idiomatic. Why stop there?
r>
A primary design point of C++ is to give user defined types all the p= >owers of built in types.
No longer does it require a compiler change to = >introduce a type with the "power" of int. And so on.


>>=3B painful interaction with templates that makes a perfect storm of eye= >-damaging syntax

Huh? Specifically?

The one vague reason I = >don't fully understand is: C doesn't have it.
Does C represent a good ex= >ample of a sort of minimalism? Maybe.
It isn't clear to me the value of = >C. It has been *very* widely abandoned in favor of C++.

 =3B- Ja= >y
>= > >--_25139682-7cce-49b1-ae17-6a4dff3488ee_-- From dragisha at m3w.org Wed Dec 1 09:18:55 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 1 Dec 2010 09:18:55 +0100 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, , , <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, <20101130150418.GB11084@topoi.pooq.com>, , Message-ID: <4C27C8EE-5A26-456A-A0D7-EC176113CCB5@m3w.org> Look for Modula-2 R10 and how they spec'd it. On Dec 1, 2010, at 7:49 AM, Jay K wrote: > A primary design point of C++ is to give user defined types all the powers of built in types. > No longer does it require a compiler change to introduce a type with the "power" of int. And so on. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed Dec 1 17:00:10 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 01 Dec 2010 10:00:10 -0600 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: , , <4CF42AEE.3000807@lcwb.coop>, , <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> Message-ID: <4CF6710A.4010907@lcwb.coop> Jay K wrote: >> generics are good, but not as good as C++ templates On the contrary, Modula-3 generics are overall, *far* superior to C++ templates, which are a language complexity nightmare, about as bad as user-defined overloading. Modula-3 generics are vastly simpler, yet more flexible. (Modula-3 generics do achieve this at the cost of a small inconvenience.) Here is a comparison I wrote some time ago of the generic/template facilities of Ada, C++, and Modula-3: ----------------------------------------------------------------------- Some comparisons of generics/templates in Ada, C++, and Modula-3 C++'s template facility is *vastly* more complicated than Modula-3's. C++(2003) has a 58-page chapter on templates, more that the entire Modula-3 reference. Additionally, C++ has a lot of additional material on templates woven throughout the rest of the language. Modula-3 devotes 2 pages to its generics and defines them with a translation to equivalent, generic-free code, so that they need not be mentioned elsewhere. Ada's generics are a bit less complicated than C++'s, but not a whole lot. Here are some of the sources of the gratuitous complexity: Confused identifier resolution Probably the worst source of C++'s template complexity derives from interaction with the identifier resolution rules it inherits from C. They were already cobbled-up in C and got worse in C++. In a single scope, the same identifier can be declared with different meanings, most importantly, two different ways of naming types (typedef names, class names), neither of which is sufficient by itself, and ordinary identifiers (variables and functions). The rules for deciding what an identifier reference actually means are highly dependent on the context of the reference. Moreover, the very syntax depends on the surrounding declarations. The template facility makes this immeasurably worse, because, in a template, the needed context is not there. So this is fixed by new and different syntactic and semantic rules for making the distinction. In contexts where the syntax does not determine whether a type or ordinary meaning is needed, the presence or absence of 'typename' (or a class key) makes the needed distinction. But there are several contexts where the syntax does imply that a type is needed, and these are full of inconsistency. In some, 'typename' is required, in others, it is optional, and in yet others, it is not allowed. So a programmer cannot just establish a habit of always doing it a certain way. None of this conveys any useful function to the language. In Modula-3 and Ada, all identifiers in a scope are really in the same scope, and both the syntax and rules for looking up identifiers are independent of the referencing context. A drastic simplification. Many kinds of template/generic units Another source is the ability to have several kinds of template units (functions, classes, member functions, member templates, etc.) and template parameters. Moreover, these are not necessarily tied to separate compilation units. Like C++, Ada also allows several kinds of units, not necessarily separately compiled, to be generic, instantiated, and in the case of procedures, generic parameters. In Modula-3, only interfaces and modules can be generic, and only interfaces can be generic parameters. But since an interface or module can contain any declarable entity, the result is every bit as flexible, probably even more so. Yet this greatly simplifies generics. It does come at a price of minor inconvenience by requiring more very small, separately compiled interfaces and modules as instantiations and more small interfaces as generic actuals. As an aside, the ability to create instantiations using the build system is only an added convenience, not mandated by the language. You can always write Modula-3 code for all instantiations and generic actuals, with no more burden added to the build system or its use by than ordinary, non-generic interfaces and modules. The Quake commands we have in the implementations of Modula-3 merely generate common cases of these almost trivial compilation units, as a quicker alternative. All instantiations are anonymous Yet another source of complexity in C++ is the lack of named instantiations. Everywhere you want to refer to an instantiation, you have to repeat is full structural definition, complete with repeats of the template actuals. This makes some code awfully pedantic. It gets worse when there are nested instantiations. And, of course, it complicates the language itself. Aside from language complexity, this also creates a very difficult problem for an implementation, because it must locate and combine all the structurally-equivalent instantiations, even from separate compilations. This the worst source of very highly mangled linker names. In both Ada and Modula-3, you always declare a name for an instantiation, attached to its definition, providing the generic actuals exactly once here. Then you use the name (a single identifier) everywhere else. If you don't want multiple copies of structurally-equivalent instantiations to be compiled, you just take care to code it this way, as is the case in virtually all other constructs in all languages. The implementation doesn't need to find the duplicates. Static checkability of template/generic units One source of complexity in Ada's generics is Ada's policy that a generic can be fully statically checked in the absence of any instantiation. The instantiations have some semantic rules that must still be applied, but they don't involve anything but the normal kinds of interface properties of the generic unit. An instantiation cannot cause internal semantic errors to pop up inside the generic. (In Ada 83, there was one language bug in this property. It was fixed in the next version, Ada 99.) This is a very nice property. Unfortunately, it complicates the language greatly. On the one hand, there has to be an elaborate set of rules about what kinds of generic parameters are allowed at all and how different generic parameters of a single generic unit can be interrelated. The programmer then has to specify these relationships. Inevitably, while this system of rules is complicated, it is also incomplete. C++ and Modula-3 postpone semantic checking until instantiation time, which removes these limitations, at the cost that an instantiation could mysteriously fail to compile if the actuals don't have the right properties. The compile errors will likely be deep inside the body of the generic--where the instantiator would ideally not need to venture. Modula-3 at least informally encourages the writers of generics to write comments spelling out the necessary properties of the generic actuals. AFAIK, C++ does not. This postponement sacrifices a very nice property for static checking. In Modula-3, the sacrifice buys a lot of simplicity and some increased flexibility. C++ gives the worst of both worlds, as the same static checking is lost, with no simplicity benefit. Interaction with overloading Both C++ and Ada allow user-defined overloading of both operators and procedure/function identifiers. This creates massive language complexity in many ways. A template/generic facility provides more things to interact with overloading, heaping on more complexity. ----------------------------------------------------------------------- From ttmrichter at gmail.com Thu Dec 2 07:36:05 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Thu, 2 Dec 2010 14:36:05 +0800 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> <20101130150418.GB11084@topoi.pooq.com> Message-ID: On 1 December 2010 14:49, Jay K wrote: > > *not* proper in terms of semantics (operator<< and operator>> being > obvious cases) > > This would not be allowed in my constrained proposal. > How would you stop it? How would you enforce a rule that says "<<" means that you are somehow shifting something to the left, even if the representation isn't a binary integer? How would you enforce a rule that says "+" must add, not concatenate, subtract, multiply or reset the computer? > > but also operator+ for concatenation > > This is very reasonable. > No, it is not. The semantics of concatenation are hugely different from the semantics of addition. Consider 3+4 vs. 4+3. Now consider "three"+"four" vs. "four"+"three". If you want to do concatenation, have an operator for concatenation. (++, say, as a random example.) Do not overload addition with an operation that isn't even vaguely analogous. > > utterly painful uses for operator,) > > I'm surprised that is overloadable, but indeed it appears it is. I don't > think I have *ever* seen anyone overload it, and I have seen a lot. > I would tell you how I used it, but I'm utterly ashamed of that portion of my life. ;) (It was in a type-safe SQL query builder.) > > the inability to define *new* operators (which leads to the first > problem of idiots redefining the semantics of operators) > > Stroupstroup rejected this as too complex. (See the Design&Evolution book). > Stroustrup is, not to put too fine a point on this, a gibbering lunatic. He rejected defining new operators as "too complex" -- yet created a language that to this day is nigh-impossible to implement according to specification (a situation that will be made even worse with the never-arriving C++1x). In the meantime languages far simpler than C++ (syntactically, at least) have had the ability to define new operators at will for ages. Haskell, for example, as a top of my head instance. Prolog too, if memory serves. Personally, I'd much rather try to implement a parser for Haskell or Prolog or languages in that vein than I would a C++ parser. > I don't see people pine for this often and I suspect he did the right > thing. > People don't pine for it often because people don't pine for capabilities they don't know exist. Most people don't pine for hygenic macro systems either -- until they use them in languages that provide that kind of capability. People didn't pine for RTTI in C++ either ... until it became available in some compilers and other compilers seemed far more constrained. People didn't pine for automated memory management ... until Java came along and made it mainstream. People didn't pine for multi-threading ... until everybody and their dog supported it. Hell, people didn't pine, by and large, for *operator overloading *until C++ made it mainstream! What people pine for vs. what people need or at least can truly use are such radically disjoint sets that I often use what people pine for as a hint for what to *avoid*. > It creates a layering problem I believe in the typical structure. > The lexical analysis would have to get information from higher layers. > Or you could go the Haskell route. Any token that consists of purely "special symbols" is an operator that can be used directly as an operator. To use it as a regular function you need to wrap it in parens. This means I can define, say, a "UFO operator" like <=+=+=+=> (made deliberately gonzo for fun) and use it as-is--e.g.: Expr1 <=+=+=+=> Expr2--or as a two-parameter function call--(<=+=+=+=>) Expr1 Expr2. Further you can go more down the Haskell route and make any function usable as an operator: myFunc Expr1 Expr2 is equally usable as Expr1 `myFunc` Expr2. Can you see how lexical analysis can trivially identify your operator definitions and usage here? > > unexpected costs to operations making the eyeballing of execution > complexity (time-wise and memory-wise) literally impossible > > This is already the case. As I said. So let's say that every single > function call is shown. It is hard to know which functions have which cost. > There are also hidden function calls e.g. for "try" and every pointer > derereference (right?) > Operator overloading can multiply these by orders of magnitude and have the added problem of being, in effect, "COME FROM" statements. I mean they're not as bad in this regard as, say, Aspect-Oriented Programming, but they're still pretty nasty. The fact that features X and Y have hidden costs is not really a good argument for adding feature Z that has all those hidden costs and an order of magnitude more all concealed in such a way that it is almost impossible to keep track of where things are really going. > Please consider floating point. Historically floating point was "soft > float". Sometimes these days it still us. Yet we still have operators for > floating point. > Why? Because it is just so convenient and idiomatic. Why stop there? > Because at some point the costs outweigh the benefits. Operator overloading is at just that cusp point for me to be torn. It has some major benefits, but it has major costs and right now I actually lean slightly in the direction of thinking the costs outweigh the benefits. (A few years ago I leaned slightly in the other direction, mind, so it, as a feature is not something I'm going to reject a language for.) > A primary design point of C++ is to give user defined types all the powers > of built in types. > No longer does it require a compiler change to introduce a type with the > "power" of int. And so on. > Instead it allows you to introduce a type that looks like an int but has such wildly varying semantics that it will confuse the ever living daylights out of people using it. Like using "+" for concatenation. > > painful interaction with templates that makes a perfect storm of > eye-damaging syntax > > Huh? Specifically? > My C++ days are a decade behind me so I no longer have any source that illustrates this. I just recall that any time we had a templated class with overloaded operators that it turned into an asinine stew of unreadable code. > The one vague reason I don't fully understand is: C doesn't have it. > Does C represent a good example of a sort of minimalism? Maybe. > It isn't clear to me the value of C. It has been *very* widely abandoned in > favor of C++. > What is the FFI lingua franca again? C or C++? (Hint: one of those two languages has syntax to make it compatible with the other, but not vice versa.) -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 2 07:53:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 2 Dec 2010 06:53:37 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, , , <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, <20101130150418.GB11084@topoi.pooq.com>, , , , Message-ID: > What is the FFI lingua franca again? C or C++? C is fairly lingua franca, but how do I *efficiently* *portably* implement exception handling? NT, Tru64, VMS all extend C slightly to allow it. I don't believe C on any other system does. C also doesn't offer "good idioms" for operator overloading. Easy enough for a target language, but as we are discussing here, not for a source language. + for String really is ok. Java, C++, C#. I realize it has completely different meaning than for integers, but even float vs. int are quite different in what + means. You know, big + small float == big. At this point, probably millions of programmers are comfortable with + being concat. At least in statically typed systems, where 3 and "3" are clearly different. > Any token that consists of purely "special symbols" is an operator that > can be used directly as an operator This changes the meaning of existing code in both C/C++ and Modula-3. e.g.: a:=+b; a:=-b; a:=--b; a:=---b; Maybe this can be resolved though. Still, I think there is plenty value in overloading existing operators. As well, one might just go ahead and define new rules for "unused" characters, if we have any. e.g. tilde, percent? > What people pine for vs. what people need or at least can truly use are > such radically disjoint sets that I often use what people pine for as a > hint for what to avoid. True. > How would you enforce a rule that says "<<" means that you are somehow > shifting something to the left My proposal was, like, that + is always T +(T,T). Similar for *, -, DIV. For << I think it'd always be T <<(T, integer). := would also be, like, := (T designator?, T) Granted, the semantic could still be arbitrary. But you wouldn't be able to define the family: <<(stream, integer) <<(stream, text) <<(stream, float) so that'd probably stop you from <<(stream, integer) meaning to print an integer. This limited form of operator overloading supports many scenarios. It does not however support the Blitz++ construct that optimizes all temporaries out of matrix/vector math. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Dec 2 08:59:35 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 2 Dec 2010 08:59:35 +0100 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, , , <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, <20101130150418.GB11084@topoi.pooq.com>, , , , Message-ID: <0E7D490B-41B9-4B90-B689-A280B2B2E0C8@m3w.org> Then obviously you are hitting blind alley there. Go other route. For example, LLVM route. On Dec 2, 2010, at 7:53 AM, Jay K wrote: > > What is the FFI lingua franca again? C or C++? > > > C is fairly lingua franca, but how do I *efficiently* *portably* > implement exception handling? NT, Tru64, VMS all extend C slightly > to allow it. I don't believe C on any other system does. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 2 10:17:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 2 Dec 2010 09:17:32 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: <0E7D490B-41B9-4B90-B689-A280B2B2E0C8@m3w.org> References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, , , , , , <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, , <20101130150418.GB11084@topoi.pooq.com>, , , , , , , , , , <0E7D490B-41B9-4B90-B689-A280B2B2E0C8@m3w.org> Message-ID: The gcc intermediate form does support exception handling. Efficient exception handling doesn't motivate gcc to llvm switch. As well, generating C++ is a good option for this reason. At least on non-NT/Tru64/VMS systems. As well, since this is multiple axes, an initial C backend could generate code like we do today -- pthread_getspecific/setjmp. Switching to LLVM is a big task. - Jay From: dragisha at m3w.org Date: Thu, 2 Dec 2010 08:59:35 +0100 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Enumeration or subrange value out of range Then obviously you are hitting blind alley there. Go other route. For example, LLVM route. On Dec 2, 2010, at 7:53 AM, Jay K wrote:> What is the FFI lingua franca again? C or C++? C is fairly lingua franca, but how do I *efficiently* *portably* implement exception handling? NT, Tru64, VMS all extend C slightly to allow it. I don't believe C on any other system does. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Dec 2 10:29:24 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 2 Dec 2010 10:29:24 +0100 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, , , , , , <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, , <20101130150418.GB11084@topoi.pooq.com>, , , , , , , , , , <0E7D490B-41B9-4B90-B689-A280B2B2E0C8@m3w.org> Message-ID: On Dec 2, 2010, at 10:17 AM, Jay K wrote: > The gcc intermediate form does support exception handling. > Efficient exception handling doesn't motivate gcc to llvm switch. > As well, generating C++ is a good option for this reason. > At least on non-NT/Tru64/VMS systems. > As well, since this is multiple axes, an initial C backend could generate code > like we do today -- pthread_getspecific/setjmp. > > Switching to LLVM is a big task. As big as making C++ backend? I don't see it as a switch. Just as another backend. And yes, I know it's easier from audience. It is your call, but anything C, C++, GCC is pain long term. We will probably all reap benefits of that C backend, as good intermediate solution if nothing else, but sooner we settle on LLVM, and forget GCC's wriggling backend, better. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 2 10:41:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 2 Dec 2010 09:41:13 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, ,,, ,,, ,,<16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, ,,<20101130150418.GB11084@topoi.pooq.com>, ,,, ,,, ,,, , , , , , , <0E7D490B-41B9-4B90-B689-A280B2B2E0C8@m3w.org>, , Message-ID: A C/C++ backend is definitely easier than anything else. It requires no learning of the target form! I know C and C++ very well, very little of C++ is relevant, mainly exception handling (*), and surely there is far more familiarity in the world of C and C++ than LLVM or gcc trees. * -- other parts of C++ might be interesting, such as putting module initializers in statics with constructors. This feature of C++ doesn't work well, but this would possibly help e.g. LoadLibrary/dlopen(mod3.dll) run the module initializers. Though here again, there is a way to do in C for NT and probably C in general, with platform-specific code. - Jay From: dragisha at m3w.org Date: Thu, 2 Dec 2010 10:29:24 +0100 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Enumeration or subrange value out of range On Dec 2, 2010, at 10:17 AM, Jay K wrote:The gcc intermediate form does support exception handling. Efficient exception handling doesn't motivate gcc to llvm switch. As well, generating C++ is a good option for this reason. At least on non-NT/Tru64/VMS systems. As well, since this is multiple axes, an initial C backend could generate code like we do today -- pthread_getspecific/setjmp. Switching to LLVM is a big task. As big as making C++ backend? I don't see it as a switch. Just as another backend. And yes, I know it's easier from audience. It is your call, but anything C, C++, GCC is pain long term. We will probably all reap benefits of that C backend, as good intermediate solution if nothing else, but sooner we settle on LLVM, and forget GCC's wriggling backend, better. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ttmrichter at gmail.com Thu Dec 2 13:51:08 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Thu, 2 Dec 2010 20:51:08 +0800 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> <20101130150418.GB11084@topoi.pooq.com> Message-ID: On 2 December 2010 14:53, Jay K wrote: > + for String really is ok. > We will have to agree to disagree here. I really cannot stand having addition and concatenation using the same operator. It bugs me at a very profound level, even more than using left- and right-shift operators for output and input. > At this point, probably millions of programmers are comfortable > with + being concat. At least in statically typed systems, > where 3 and "3" are clearly different. > At this point millions of programmers are comfortable programming without a clean separation between interface and implementation. I still prefer the Modula series of languages and would not want them to change into an abortion like C++. > > Any token that consists of purely "special symbols" is an operator that > > can be used directly as an operator > > This changes the meaning of existing code in both C/C++ and Modula-3. > > e.g.: > a:=+b; > a:=-b; > a:=--b; > a:=---b; > I wasn't actually suggesting that we directly use Haskell's system. I was just pointing out that it's trivial to allow operators to be defined by the programmer without having the lexer communicating outside of the lexing process. It's a matter of language design. Were I to retrofit a "define new operator" mechanism into an established language like Modula-3, I'd probably insist that user-added operators be wrapped in something like backquotes. So a hypothetical concatenation operator might become `++`. Basically user-defined operators would have to have some way to uniquely identify themselves as such to the lexer in the absence of a language built from scratch to support them. > Still, I think there is plenty value in overloading existing operators. > There can be, yes. It's just that I've seen more abuse of operator overloading than I have good uses. This makes me nervous of having them, even though they *really are* damned convenient when used correctly. -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Dec 2 15:12:56 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 2 Dec 2010 09:12:56 -0500 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> <20101130150418.GB11084@topoi.pooq.com> Message-ID: <20101202141256.GA17591@topoi.pooq.com> On Thu, Dec 02, 2010 at 02:36:05PM +0800, Michael Richter wrote: > On 1 December 2010 14:49, Jay K wrote: > > No, it is not. The semantics of concatenation are hugely different from the > semantics of addition. Consider 3+4 vs. 4+3. > Now consider "three"+"four" > vs. "four"+"three". If you want to do concatenation, have an operator for > concatenation. (++, say, as a random example.) Do not overload addition > with an operation that isn't even vaguely analogous. The semantics of matrix multiplication are hugely different from those of integer multiplication. Consider A*B vs B*A. By this this doesn't mean that we necessarily need a different operator symbol. For string concatenation, there's even a homomorphism (length) mapping it to natural number addition. Just like determinant for matrices. > > > > > utterly painful uses for operator,) > > > > > > I'm surprised that is overloadable, but indeed it appears it is. I don't > > think I have *ever* seen anyone overload it, and I have seen a lot. > > > > I would tell you how I used it, but I'm utterly ashamed of that portion of > my life. ;) (It was in a type-safe SQL query builder.) That sounds as if you were defining . to be a reasonable approximation to SQL's . That sounds like a reasonable thing to do -- except if any of its uses would have to be disambiguated with C++'s hopelessly complicated disambiguation rules. > > Operator overloading can multiply these by orders of magnitude and have the > added problem of being, in effect, "COME FROM" statements. Those were fun. Good thing no one took hem seriously. > My C++ days are a decade behind me so I no longer have any source that > illustrates this. I just recall that any time we had a templated class with > overloaded operators that it turned into an asinine stew of unreadable code. > > > > The one vague reason I don't fully understand is: C doesn't have it. > > Does C represent a good example of a sort of minimalism? Maybe. > > It isn't clear to me the value of C. It has been *very* widely abandoned in > > favor of C++. I use the subset of C++ that's more or less equivalent to C. It gives me slightly better type-checking, but that's the main benefit. Very rarely I use single inheritance. If I do anything that involves a lot of that, I prefer Modula 3. > > What is the FFI lingua franca again? C or C++? (Hint: one of those two > languages has syntax to make it compatible with the other, but not vice > versa.) C has interfacing specs that are more or less consistent from machine to machine. C++ doesn't seem to. > > -- > "Perhaps people don't believe this, but throughout all of the discussions of > entering China our focus has really been what's best for the Chinese people. > It's not been about our revenue or profit or whatnot." > --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. More demonstrating how difficult some ethical decisions, even with the best of intentions. - hendrik From hendrik at topoi.pooq.com Thu Dec 2 15:22:03 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 2 Dec 2010 09:22:03 -0500 Subject: [M3devel] Code generation (was: Enumeration or subrange value out of range) In-Reply-To: References: <0E7D490B-41B9-4B90-B689-A280B2B2E0C8@m3w.org> Message-ID: <20101202142203.GB17591@topoi.pooq.com> On Thu, Dec 02, 2010 at 09:17:32AM +0000, Jay K wrote: > > The gcc intermediate form does support exception handling. > Efficient exception handling doesn't motivate gcc to llvm switch. > As well, generating C++ is a good option for this reason. > At least on non-NT/Tru64/VMS systems. > As well, since this is multiple axes, an initial C backend could generate code > like we do today -- pthread_getspecific/setjmp. > > Switching to LLVM is a big task. > > - Jay We seem to have switched from language design to Modula 3 implementatin decisions. Are either LLVN or gcc-intermediate as well-documented as C--, C, or C++? Too bad C-- seems to be somewhat lacking in implementatins of multiple kinds of hardware. It's otherwise excellent. -- hendrik From ttmrichter at gmail.com Thu Dec 2 15:36:59 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Thu, 2 Dec 2010 22:36:59 +0800 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: <20101202141256.GA17591@topoi.pooq.com> References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> <20101130150418.GB11084@topoi.pooq.com> <20101202141256.GA17591@topoi.pooq.com> Message-ID: On 2 December 2010 22:12, Hendrik Boom wrote: > > The semantics of concatenation are hugely different from the > > semantics of addition. Consider 3+4 vs. 4+3. > > Now consider "three"+"four" > > vs. "four"+"three". If you want to do concatenation, have an operator > for > > concatenation. (++, say, as a random example.) Do not overload addition > > with an operation that isn't even vaguely analogous. > > The semantics of matrix multiplication are hugely different from those > of integer multiplication. Consider A*B vs B*A. > This is why, if memory serves, there's two different "multiplication" operations and operators for matrices? > > > I'm surprised that is overloadable, but indeed it appears it is. I > don't > > > think I have *ever* seen anyone overload it, and I have seen a lot. > > > I would tell you how I used it, but I'm utterly ashamed of that portion > of > > my life. ;) (It was in a type-safe SQL query builder.) > > That sounds as if you were defining . to be a reasonable approximation > to SQL's . That sounds like a reasonable thing to do -- except if any of > its uses would have to be disambiguated with C++'s hopelessly > complicated disambiguation rules. > Yeah, that was a problem. It also required some utterly retarded constructs like function calls that had double-parentheses because the comma is used differently in argument lists than in expressions and so forth. The final product was marginally better to use than the traditional format string-style SQL statement builders, but only marginally so and at a huge expense in implementation comprehension (and thus testing and debugging). > > Operator overloading can multiply these by orders of magnitude and have > the > > added problem of being, in effect, "COME FROM" statements. > > Those were fun. Good thing no one took hem seriously. > Sure they did. It's called "Aspect-Oriented Programming". ;) > I use the subset of C++ that's more or less equivalent to C. It gives > me slightly better type-checking, but that's the main benefit. > I think this plus limited use of inheritance is the majority use of C++. > > What is the FFI lingua franca again? C or C++? (Hint: one of those two > > languages has syntax to make it compatible with the other, but not vice > > versa.) > > C has interfacing specs that are more or less consistent from machine to > machine. > > C++ doesn't seem to. > C++ doesn't even have interfacing specs that are consistent and compatible from compiler to compiler. Or, often, compiler version to compiler version in the same family. > > "Perhaps people don't believe this, but throughout all of the discussions > of > entering China our focus has really been what's best for the Chinese > people. > It's not been about our revenue or profit or whatnot." > --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. More demonstrating how difficult some ethical decisions, even with the best of intentions. This presumes you actually believe what Brin says. I don't. I think revenue and profit was their only concern in moving into China and a lack thereof on both fronts was their motive to leave. -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 2 15:48:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 2 Dec 2010 14:48:35 +0000 Subject: [M3devel] Code generation (was: Enumeration or subrange value out of range) In-Reply-To: <20101202142203.GB17591@topoi.pooq.com> References: <0E7D490B-41B9-4B90-B689-A280B2B2E0C8@m3w.org>, , <20101202142203.GB17591@topoi.pooq.com> Message-ID: > Are either LLVN or gcc-intermediate as well-documented as C--, C, or > C++? > Too bad C-- seems to be somewhat lacking in implementatins of multiple > kinds of hardware. It's otherwise excellent. gcc-intermediate isn't necessarily poorly documented or changes much, but C and C++ are clearly the better documented forms. Just go to a bookstore. And even if they weren't better documented, there is much broader experience with them, by me and the wider world. It's a numbers thing. I have written thousands of lines of C and C++ and overall millions or billions have been written. Most of mine have been compiled by one line of compilers, but not all, and, in reality, I don't believe a backend would use the language(s) very intensely. The main reason I advocate C++ as a target vs. C is for portable efficient exception handling. (As well, Visual C++ I think is closer to the standard in terms of lack of extensions than gcc; I have also compiled some code with its /Za switch that disables extensions.) I should point out that nested functions will probably pose a small problem. Using "this" in C++ might help some, esp. to get the extra parameter efficiently passed on 32bit x86. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Dec 2 19:08:41 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 2 Dec 2010 13:08:41 -0500 Subject: [M3devel] Code generation (was: Enumeration or subrange value out of range) In-Reply-To: References: <20101202142203.GB17591@topoi.pooq.com> Message-ID: <20101202180841.GA2541@topoi.pooq.com> On Thu, Dec 02, 2010 at 02:48:35PM +0000, Jay K wrote: > > > Are either LLVN or gcc-intermediate as well-documented as C--, C, or > > C++? > > Too bad C-- seems to be somewhat lacking in implementatins of multiple > > kinds of hardware. It's otherwise excellent. > > > gcc-intermediate isn't necessarily poorly documented or changes much, > but C and C++ are clearly the better documented forms. > Just go to a bookstore. > > > And even if they weren't better documented, there is much broader > experience with them, by me and the wider world. > > > It's a numbers thing. I have written thousands of lines of C and C++ > and overall millions or billions have been written. > > > Most of mine have been compiled by one line of compilers, but not all, > and, in reality, I don't believe a backend would use the language(s) > very intensely. The main reason I advocate C++ as a target vs. C > is for portable efficient exception handling. > (As well, Visual C++ I think is closer to the standard in terms > of lack of extensions than gcc; I have also compiled some code > with its /Za switch that disables extensions.) > > > I should point out that nested functions will probably pose a small problem. > Using "this" in C++ might help some, esp. to get the extra parameter efficiently > passed on 32bit x86. I've used "this" trick for environments in a language in which almost every source line resulted in multiple functions, each with its own environment. I ended up with a huge number of classes and enormous link times. I'm not at all sure that the many classes were the cause of the link times. That was about 20 years ago. -- hendrik From mika at async.async.caltech.edu Thu Dec 2 20:29:19 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Thu, 02 Dec 2010 11:29:19 -0800 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: <20101202141256.GA17591@topoi.pooq.com> References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> <20101130150418.GB11084@topoi.pooq.com> <20101202141256.GA17591@topoi.pooq.com> Message-ID: <20101202192919.AFAE01A209B@async.async.caltech.edu> Hendrik Boom writes: >On Thu, Dec 02, 2010 at 02:36:05PM +0800, Michael Richter wrote: >> On 1 December 2010 14:49, Jay K wrote: >> >> No, it is not. The semantics of concatenation are hugely different from the >> semantics of addition. Consider 3+4 vs. 4+3. >> Now consider "three"+"four" >> vs. "four"+"three". If you want to do concatenation, have an operator for >> concatenation. (++, say, as a random example.) Do not overload addition >> with an operation that isn't even vaguely analogous. > >The semantics of matrix multiplication are hugely different from those >of integer multiplication. Consider A*B vs B*A. Ummm... integer multiplication is a special case of matrix multiplication.... Mika From jay.krell at cornell.edu Tue Dec 7 23:45:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 7 Dec 2010 22:45:36 +0000 Subject: [M3devel] ongoing hardware clearance -- anyone want a working Alpha, Sparcs? Message-ID: ongoing hardware clearance.. The hardware clearance is ongoing. In particular, with mixed feelings, my only HPPA/HP-UX/Linux machine is gone. On the other hand, last night I installed Linux/alpha and it can soon be in Hudson (albeit with a 9GB hard drive, which has proven challenging on Linux/sparc). This is the first I've had an Alpha locally up and running. I'm torn: keep the machine, running Linux Linux has the advantage of having Java across all architectures, so easily put into Hudson keep the machine, try NetBSD, OpenBSD, FreeBSD (6.4), VMS, Tru64. *BSD generally lack Java except on x86/AMD64. VMS would be nice to get working. It was on the machine originally. Tru64 probably redundant with Mika's machine, which we should try to get into Hudson. Get rid of the machine. I have 2 other Alphas, physically smaller, don't know yet if they work. Fourth Alpha already gone, not sure it worked. Machine is like: alphaev5 266MHz ? 256MB ? 9GB CD-ROM drive noticably slow but working ok no video out -- using serial console -- a fun rare little exercise :) (the other hand is easily implemented as Windows XP laptop running Hyperterm, using a USB to serial device, they run about $20; someday I might try a dedicated serial terminal device) Linux/sparc might be on the chopping block soon too. Someone to host that would be nice. Shipping outside the US is generally too expensive. The current Hudson node has no takers on ebay yet. http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=120657135772 I do have some other Sparcs I haven't used yet, might try them, or might get rid of them. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Dec 11 13:09:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 11 Dec 2010 12:09:48 +0000 Subject: [M3devel] Linux/Alpha working, uploaded archives Message-ID: Alpha/Linux works, builds itself, Juno comes up. There are builds here: http://modula3.elegosoft.com/cm3/uploaded-archives/ built on Debian 5.0. Debian 6.0 drops support for Alpha. It was easy as usual: setup the machine workaround one small gcc bug get the jmpbuf size, and the ucontext field My intention is to: not keep the machine up and running, not in Hudson go through and get OpenBSD, FreeBSD, NetBSD, VMS to work, however: so far I haven't been able to boot OpenBSD, NetBSD on my DS10L, FreeBSD doesn't see the hard drive, Linux works fine, and the I seem to have toasted the machine I was using so: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=120659104744 If anyone knows how to fix that, please let me know, thanks. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sat Dec 11 23:19:02 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 11 Dec 2010 14:19:02 -0800 Subject: [M3devel] cm3 on snow leopard? Message-ID: <20101211221902.B71F81A207C@async.async.caltech.edu> Hello m3devel, I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook Air, but it seems I have the wrong assembler? I had to force dpkg to override the architecture on install (it was expecting i386, I think, and my machine identified itself as being "i386-darwin"?) Here are some details... [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version Critical Mass Modula-3 version 5.8.6 last updated: 2010-04-11 compiled: 2010-07-14 21:27:23 configuration: /usr/local/cm3/bin/cm3.cfg host: I386_DARWIN target: I386_DARWIN compiling an empty Main.m3 yields: [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands --- building in ../I386_DARWIN --- cd ../I386_DARWIN rm .M3SHIP rm .M3OVERRIDES inhale prog.mx inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a new source -> compiling Main.m3 m3front ../src/Main.m3 -w1 /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno-reorde r-blocks Main.mc -o Main.ms echo "rep movsl" | as -o /dev/null 2> /dev/null as Main.ms -o Main.mo Main.ms:15:suffix or operands invalid for `push' assemble => 1 assembler failed assembling: Main.ms rm Main.mo exhale prog.mx rm prog.manifest compilation failed => not building program "prog" Fatal Error: package build failed [HAL:~/test/src] mika% uname -a Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 [HAL:~/test/src] mika% as -v Apple Inc version cctools-782~33, GNU assembler version 1.38 I have XCode installed. [HAL:~/test/src] mika% gcc -v Using built-in specs. Target: i686-apple-darwin10 Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Apple Inc. build 5664) [HAL:~/test/src] mika% which gcc /usr/bin/gcc I must be doing something very obviously wrong (obviously to someone on this list, right??) Mika From jay.krell at cornell.edu Sun Dec 12 01:59:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 12 Dec 2010 00:59:18 +0000 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: <20101211221902.B71F81A207C@async.async.caltech.edu> References: <20101211221902.B71F81A207C@async.async.caltech.edu> Message-ID: I admit I'm still using Leopard. - Jay > To: m3devel at elegosoft.com > Date: Sat, 11 Dec 2010 14:19:02 -0800 > From: mika at async.caltech.edu > Subject: [M3devel] cm3 on snow leopard? > > Hello m3devel, > > I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook > Air, but it seems I have the wrong assembler? > > I had to force dpkg to override the architecture on install (it was expecting > i386, I think, and my machine identified itself as being "i386-darwin"?) > > Here are some details... > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-14 21:27:23 > configuration: /usr/local/cm3/bin/cm3.cfg > host: I386_DARWIN > target: I386_DARWIN > > compiling an empty Main.m3 yields: > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands > --- building in ../I386_DARWIN --- > > cd ../I386_DARWIN > rm .M3SHIP > rm .M3OVERRIDES > inhale prog.mx > inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a > inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a > > new source -> compiling Main.m3 > m3front ../src/Main.m3 -w1 > /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno-reorde > r-blocks Main.mc -o Main.ms > echo "rep movsl" | as -o /dev/null 2> /dev/null > as Main.ms -o Main.mo > Main.ms:15:suffix or operands invalid for `push' > assemble => 1 > assembler failed assembling: Main.ms > rm Main.mo > exhale prog.mx > rm prog.manifest > > compilation failed => not building program "prog" > Fatal Error: package build failed > > [HAL:~/test/src] mika% uname -a > Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 > [HAL:~/test/src] mika% as -v > Apple Inc version cctools-782~33, GNU assembler version 1.38 > > > I have XCode installed. > > [HAL:~/test/src] mika% gcc -v > Using built-in specs. > Target: i686-apple-darwin10 > Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 > Thread model: posix > gcc version 4.2.1 (Apple Inc. build 5664) > [HAL:~/test/src] mika% which gcc > /usr/bin/gcc > > > I must be doing something very obviously wrong (obviously to someone on this list, right??) > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 12 06:26:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 12 Dec 2010 05:26:37 +0000 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: References: <20101211221902.B71F81A207C@async.async.caltech.edu>, Message-ID: I'm rudely (but helpfully) ignoring your details and giving some of mine. I though what is supposed to happen, specifically on Darwin, is the assembly code is supposed to indicate an architecture. jbook2:m3core jay$ CM3_TARGET=I386_DARWIN M3CONFIG=/cm3/bin/config/I386_DARWIN cm3 -keep ^C jbook2:m3core jay$ CM3_TARGET=AMD64_DARWIN M3CONFIG=/cm3/bin/config/AMD64_DARWIN cm3 -keep ^C head */RTHooks.ms but no. But then this: jbook2:m3core jay$ CM3_TARGET=AMD64_DARWIN M3CONFIG=/cm3/bin/config/AMD64_DARWIN cm3 -keep -commands --- building in AMD64_DARWIN --- .. /usr/libexec/gcc/darwin/x86_64/as RTAllocator.ms -o RTAllocator.mo CM3_TARGET=I386_DARWIN M3CONFIG=/cm3/bin/config/I386_DARWIN cm3 -keep -commands ... /usr/libexec/gcc/darwin/i386/as Ctypes.is -o Ctypes.io i386 vs. x86_64. Darwin.common: proc configure_assembler() is if defined("SYSTEM_ASM") return end SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" if not FileExists(SYSTEM_ASM) SYSTEM_ASM = "as" end end jbook2:m3core jay$ grep DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-install/* /dev2/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN:DarwinArch = "x86_64" /dev2/cm3/m3-sys/cminstall/src/config-no-install/ARM_DARWIN:DarwinArch = "armv6" % ? /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: local arch = " -arch " & DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: arch = " -arch_only " & DarwinArch & " " /dev2/cm3/m3-sys/cminstall/src/config-no-install/I386_DARWIN:DarwinArch = "i386" /dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC64_DARWIN:DarwinArch = "ppc64" /dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC_DARWIN:DarwinArch = "ppc" ? cm3 -commands? find /usr/lib | grep /as$ find /usr/libexec | grep /as$ Maybe the path changed? Has a version? or is there is only i686-apple-darwin9, powerpc-apple-darwin9? I should look into getting the architecture into the assembly code though and just running "as", esp. on newer hosts. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; m3devel at elegosoft.com Date: Sun, 12 Dec 2010 00:59:18 +0000 Subject: Re: [M3devel] cm3 on snow leopard? I admit I'm still using Leopard. - Jay > To: m3devel at elegosoft.com > Date: Sat, 11 Dec 2010 14:19:02 -0800 > From: mika at async.caltech.edu > Subject: [M3devel] cm3 on snow leopard? > > Hello m3devel, > > I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook > Air, but it seems I have the wrong assembler? > > I had to force dpkg to override the architecture on install (it was expecting > i386, I think, and my machine identified itself as being "i386-darwin"?) > > Here are some details... > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-14 21:27:23 > configuration: /usr/local/cm3/bin/cm3.cfg > host: I386_DARWIN > target: I386_DARWIN > > compiling an empty Main.m3 yields: > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands > --- building in ../I386_DARWIN --- > > cd ../I386_DARWIN > rm .M3SHIP > rm .M3OVERRIDES > inhale prog.mx > inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a > inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a > > new source -> compiling Main.m3 > m3front ../src/Main.m3 -w1 > /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno-reorde > r-blocks Main.mc -o Main.ms > echo "rep movsl" | as -o /dev/null 2> /dev/null > as Main.ms -o Main.mo > Main.ms:15:suffix or operands invalid for `push' > assemble => 1 > assembler failed assembling: Main.ms > rm Main.mo > exhale prog.mx > rm prog.manifest > > compilation failed => not building program "prog" > Fatal Error: package build failed > > [HAL:~/test/src] mika% uname -a > Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 > [HAL:~/test/src] mika% as -v > Apple Inc version cctools-782~33, GNU assembler version 1.38 > > > I have XCode installed. > > [HAL:~/test/src] mika% gcc -v > Using built-in specs. > Target: i686-apple-darwin10 > Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 > Thread model: posix > gcc version 4.2.1 (Apple Inc. build 5664) > [HAL:~/test/src] mika% which gcc > /usr/bin/gcc > > > I must be doing something very obviously wrong (obviously to someone on this list, right??) > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 12 06:36:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 12 Dec 2010 05:36:02 +0000 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: References: <20101211221902.B71F81A207C@async.async.caltech.edu>, , , Message-ID: Please experiment a bit with this and let me know. Notice how I only get .machine for ppc. jbook2:~ jay$ cat 1.c void F1() {} jbook2:~ jay$ gcc -arch ppc64 -c 1.c -S && grep machine 1.s .machine ppc64 jbook2:~ jay$ gcc -arch ppc -c 1.c -S && grep machine 1.s .machine ppc7400 jbook2:~ jay$ gcc -arch i386 -c 1.c -S && grep machine 1.s jbook2:~ jay$ gcc -arch x86_64 -c 1.c -S && grep machine 1.s Oh, here: gcc-4.2 -arch ppc64 -c 1.c -v gcc-4.2 -arch x86_64 -c 1.c -v /usr/libexec/gcc/i686-apple-darwin9/4.2.1/as -arch x86_64 -force_cpusubtype_ALL -o 1.o /var/folders/QG/Q Ok, I think we should use the C compiler on Darwin to assemble. It costs an extra fork/exec. This is probably a reasonable idea on all systems, and cheap enough except on Cygwin. I'll try to get around to this fairly soon. It'll require per-target. More generally we *might* be able to extract enough from the gcc driver in m3-sys/m3cc and use it. I might might might might pursue that. Might. In particular, we could build both cm3cg and gcc driver (renamed -- m3gcc?) and trigger gcc to run both cm3cg (m3cgc1) and as. This seems very very reasonable. gcc driver (renamed) merely has to know that .is/.ms map to cm3cg or m3cgc1. This is a good idea. But more work. Thanks, - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; m3devel at elegosoft.com Date: Sun, 12 Dec 2010 05:26:37 +0000 Subject: Re: [M3devel] cm3 on snow leopard? I'm rudely (but helpfully) ignoring your details and giving some of mine. I though what is supposed to happen, specifically on Darwin, is the assembly code is supposed to indicate an architecture. jbook2:m3core jay$ CM3_TARGET=I386_DARWIN M3CONFIG=/cm3/bin/config/I386_DARWIN cm3 -keep ^C jbook2:m3core jay$ CM3_TARGET=AMD64_DARWIN M3CONFIG=/cm3/bin/config/AMD64_DARWIN cm3 -keep ^C head */RTHooks.ms but no. But then this: jbook2:m3core jay$ CM3_TARGET=AMD64_DARWIN M3CONFIG=/cm3/bin/config/AMD64_DARWIN cm3 -keep -commands --- building in AMD64_DARWIN --- .. /usr/libexec/gcc/darwin/x86_64/as RTAllocator.ms -o RTAllocator.mo CM3_TARGET=I386_DARWIN M3CONFIG=/cm3/bin/config/I386_DARWIN cm3 -keep -commands ... /usr/libexec/gcc/darwin/i386/as Ctypes.is -o Ctypes.io i386 vs. x86_64. Darwin.common: proc configure_assembler() is if defined("SYSTEM_ASM") return end SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" if not FileExists(SYSTEM_ASM) SYSTEM_ASM = "as" end end jbook2:m3core jay$ grep DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-install/* /dev2/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN:DarwinArch = "x86_64" /dev2/cm3/m3-sys/cminstall/src/config-no-install/ARM_DARWIN:DarwinArch = "armv6" % ? /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: local arch = " -arch " & DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: arch = " -arch_only " & DarwinArch & " " /dev2/cm3/m3-sys/cminstall/src/config-no-install/I386_DARWIN:DarwinArch = "i386" /dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC64_DARWIN:DarwinArch = "ppc64" /dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC_DARWIN:DarwinArch = "ppc" ? cm3 -commands? find /usr/lib | grep /as$ find /usr/libexec | grep /as$ Maybe the path changed? Has a version? or is there is only i686-apple-darwin9, powerpc-apple-darwin9? I should look into getting the architecture into the assembly code though and just running "as", esp. on newer hosts. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; m3devel at elegosoft.com Date: Sun, 12 Dec 2010 00:59:18 +0000 Subject: Re: [M3devel] cm3 on snow leopard? I admit I'm still using Leopard. - Jay > To: m3devel at elegosoft.com > Date: Sat, 11 Dec 2010 14:19:02 -0800 > From: mika at async.caltech.edu > Subject: [M3devel] cm3 on snow leopard? > > Hello m3devel, > > I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook > Air, but it seems I have the wrong assembler? > > I had to force dpkg to override the architecture on install (it was expecting > i386, I think, and my machine identified itself as being "i386-darwin"?) > > Here are some details... > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-14 21:27:23 > configuration: /usr/local/cm3/bin/cm3.cfg > host: I386_DARWIN > target: I386_DARWIN > > compiling an empty Main.m3 yields: > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands > --- building in ../I386_DARWIN --- > > cd ../I386_DARWIN > rm .M3SHIP > rm .M3OVERRIDES > inhale prog.mx > inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a > inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a > > new source -> compiling Main.m3 > m3front ../src/Main.m3 -w1 > /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno-reorde > r-blocks Main.mc -o Main.ms > echo "rep movsl" | as -o /dev/null 2> /dev/null > as Main.ms -o Main.mo > Main.ms:15:suffix or operands invalid for `push' > assemble => 1 > assembler failed assembling: Main.ms > rm Main.mo > exhale prog.mx > rm prog.manifest > > compilation failed => not building program "prog" > Fatal Error: package build failed > > [HAL:~/test/src] mika% uname -a > Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 > [HAL:~/test/src] mika% as -v > Apple Inc version cctools-782~33, GNU assembler version 1.38 > > > I have XCode installed. > > [HAL:~/test/src] mika% gcc -v > Using built-in specs. > Target: i686-apple-darwin10 > Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 > Thread model: posix > gcc version 4.2.1 (Apple Inc. build 5664) > [HAL:~/test/src] mika% which gcc > /usr/bin/gcc > > > I must be doing something very obviously wrong (obviously to someone on this list, right??) > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 12 06:49:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 12 Dec 2010 05:49:29 +0000 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: References: <20101211221902.B71F81A207C@async.async.caltech.edu>, , , Message-ID: I'm more sympathetic to using the already installed C compiler to drive the assembler, than to build the current gcc driver. You can see on Darwin we already probe around fairly aggressively for a C compiler that can be told the target: Darwin.common: proc configure_c_compiler() is if defined("SYSTEM_CC") return end % % older compiler doesn't like -m32 or -arch % % gcc -c -m32 -x c /dev/null % cc1: error: invalid option ?m32? % % fPIC is not usually needed here. % It is the default for Apple gcc and left % here in case user is using a self-built FSF gcc. % SYSTEM_CC = "gcc -gstabs+ -fPIC" local m = " -m" & {"32BITS":"32","64BITS":"64"}{WORD_SIZE} local arch = " -arch " & DarwinArch if not equal(try_exec("@" & SYSTEM_CC & m & " -c -x c /dev/null -o /dev/null 2>&1 | fgrep \"cc1: error: invalid option \\\`32'\" >/dev/null"), 0) SYSTEM_CC = SYSTEM_CC & m end if not equal(try_exec("@" & SYSTEM_CC & arch & " -c -x c /dev/null -o /dev/null 2>&1 | fgrep \"cc1: error: unrecognized command line option \\\\\"-arch\\\\\"\" >/dev/null"), 0) SYSTEM_CC = SYSTEM_CC & arch end %write("SYSTEM_CC is " & SYSTEM_CC) end Most likely if we merely set SYSTEM_ASM = SYSTEM_CC & "-x assembler" it'll work well. Maybe only in this else case: proc configure_assembler() is if defined("SYSTEM_ASM") return end SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" if not FileExists(SYSTEM_ASM) SYSTEM_ASM = "as" <<== here end end All this is addressed by autoconf and/or a C-generating backend..... - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; m3devel at elegosoft.com Date: Sun, 12 Dec 2010 05:26:37 +0000 Subject: Re: [M3devel] cm3 on snow leopard? I'm rudely (but helpfully) ignoring your details and giving some of mine. I though what is supposed to happen, specifically on Darwin, is the assembly code is supposed to indicate an architecture. jbook2:m3core jay$ CM3_TARGET=I386_DARWIN M3CONFIG=/cm3/bin/config/I386_DARWIN cm3 -keep ^C jbook2:m3core jay$ CM3_TARGET=AMD64_DARWIN M3CONFIG=/cm3/bin/config/AMD64_DARWIN cm3 -keep ^C head */RTHooks.ms but no. But then this: jbook2:m3core jay$ CM3_TARGET=AMD64_DARWIN M3CONFIG=/cm3/bin/config/AMD64_DARWIN cm3 -keep -commands --- building in AMD64_DARWIN --- .. /usr/libexec/gcc/darwin/x86_64/as RTAllocator.ms -o RTAllocator.mo CM3_TARGET=I386_DARWIN M3CONFIG=/cm3/bin/config/I386_DARWIN cm3 -keep -commands ... /usr/libexec/gcc/darwin/i386/as Ctypes.is -o Ctypes.io i386 vs. x86_64. Darwin.common: proc configure_assembler() is if defined("SYSTEM_ASM") return end SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" if not FileExists(SYSTEM_ASM) SYSTEM_ASM = "as" end end jbook2:m3core jay$ grep DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-install/* /dev2/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN:DarwinArch = "x86_64" /dev2/cm3/m3-sys/cminstall/src/config-no-install/ARM_DARWIN:DarwinArch = "armv6" % ? /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: local arch = " -arch " & DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: arch = " -arch_only " & DarwinArch & " " /dev2/cm3/m3-sys/cminstall/src/config-no-install/I386_DARWIN:DarwinArch = "i386" /dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC64_DARWIN:DarwinArch = "ppc64" /dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC_DARWIN:DarwinArch = "ppc" ? cm3 -commands? find /usr/lib | grep /as$ find /usr/libexec | grep /as$ Maybe the path changed? Has a version? or is there is only i686-apple-darwin9, powerpc-apple-darwin9? I should look into getting the architecture into the assembly code though and just running "as", esp. on newer hosts. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; m3devel at elegosoft.com Date: Sun, 12 Dec 2010 00:59:18 +0000 Subject: Re: [M3devel] cm3 on snow leopard? I admit I'm still using Leopard. - Jay > To: m3devel at elegosoft.com > Date: Sat, 11 Dec 2010 14:19:02 -0800 > From: mika at async.caltech.edu > Subject: [M3devel] cm3 on snow leopard? > > Hello m3devel, > > I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook > Air, but it seems I have the wrong assembler? > > I had to force dpkg to override the architecture on install (it was expecting > i386, I think, and my machine identified itself as being "i386-darwin"?) > > Here are some details... > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-14 21:27:23 > configuration: /usr/local/cm3/bin/cm3.cfg > host: I386_DARWIN > target: I386_DARWIN > > compiling an empty Main.m3 yields: > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands > --- building in ../I386_DARWIN --- > > cd ../I386_DARWIN > rm .M3SHIP > rm .M3OVERRIDES > inhale prog.mx > inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a > inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a > > new source -> compiling Main.m3 > m3front ../src/Main.m3 -w1 > /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno-reorde > r-blocks Main.mc -o Main.ms > echo "rep movsl" | as -o /dev/null 2> /dev/null > as Main.ms -o Main.mo > Main.ms:15:suffix or operands invalid for `push' > assemble => 1 > assembler failed assembling: Main.ms > rm Main.mo > exhale prog.mx > rm prog.manifest > > compilation failed => not building program "prog" > Fatal Error: package build failed > > [HAL:~/test/src] mika% uname -a > Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 > [HAL:~/test/src] mika% as -v > Apple Inc version cctools-782~33, GNU assembler version 1.38 > > > I have XCode installed. > > [HAL:~/test/src] mika% gcc -v > Using built-in specs. > Target: i686-apple-darwin10 > Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 > Thread model: posix > gcc version 4.2.1 (Apple Inc. build 5664) > [HAL:~/test/src] mika% which gcc > /usr/bin/gcc > > > I must be doing something very obviously wrong (obviously to someone on this list, right??) > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 12 07:01:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 12 Dec 2010 06:01:21 +0000 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: References: <20101211221902.B71F81A207C@async.async.caltech.edu>, , , , , , Message-ID: Please try my updated Darwin.common. IsX86 = equal(TARGET, "I386_DARWIN") or equal(TARGET, "AMD64_DARWIN") proc configure_assembler() is if defined("SYSTEM_ASM") return end SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" if not FileExists(SYSTEM_ASM) if IsX86 configure_c_compiler () SYSTEM_ASM = SYSTEM_CC_ASM & " -c -x assembler" else SYSTEM_ASM = "as" end end %SYSTEM_ASM = SYSTEM_CC_ASM & " -v -c -x assembler" end proc configure_c_compiler() is if defined("SYSTEM_CC") return end % % older compiler doesn't like -m32 or -arch % % gcc -c -m32 -x c /dev/null % cc1: error: invalid option ?m32? % % fPIC is not usually needed here. % It is the default for Apple gcc and left % here in case user is using a self-built FSF gcc. % SYSTEM_CC = "gcc -gstabs+ -fPIC" SYSTEM_CC_ASM = "gcc -fPIC" local m = " -m" & {"32BITS":"32","64BITS":"64"}{WORD_SIZE} local arch = " -arch " & DarwinArch if not equal(try_exec("@" & SYSTEM_CC & m & " -c -x c /dev/null -o /dev/null 2>&1 | fgrep \"cc1: error: invalid option \\\`32'\" >/dev/null"), 0) SYSTEM_CC = SYSTEM_CC & m SYSTEM_CC_ASM = SYSTEM_CC_ASM & m end if not equal(try_exec("@" & SYSTEM_CC & arch & " -c -x c /dev/null -o /dev/null 2>&1 | fgrep \"cc1: error: unrecognized command line option \\\\\"-arch\\\\\"\" >/dev/null"), 0) SYSTEM_CC = SYSTEM_CC & arch SYSTEM_CC_ASM = SYSTEM_CC_ASM & arch end %write("SYSTEM_CC is " & SYSTEM_CC) end - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; m3devel at elegosoft.com Date: Sun, 12 Dec 2010 05:49:29 +0000 Subject: Re: [M3devel] cm3 on snow leopard? I'm more sympathetic to using the already installed C compiler to drive the assembler, than to build the current gcc driver. You can see on Darwin we already probe around fairly aggressively for a C compiler that can be told the target: Darwin.common: proc configure_c_compiler() is if defined("SYSTEM_CC") return end % % older compiler doesn't like -m32 or -arch % % gcc -c -m32 -x c /dev/null % cc1: error: invalid option ?m32? % % fPIC is not usually needed here. % It is the default for Apple gcc and left % here in case user is using a self-built FSF gcc. % SYSTEM_CC = "gcc -gstabs+ -fPIC" local m = " -m" & {"32BITS":"32","64BITS":"64"}{WORD_SIZE} local arch = " -arch " & DarwinArch if not equal(try_exec("@" & SYSTEM_CC & m & " -c -x c /dev/null -o /dev/null 2>&1 | fgrep \"cc1: error: invalid option \\\`32'\" >/dev/null"), 0) SYSTEM_CC = SYSTEM_CC & m end if not equal(try_exec("@" & SYSTEM_CC & arch & " -c -x c /dev/null -o /dev/null 2>&1 | fgrep \"cc1: error: unrecognized command line option \\\\\"-arch\\\\\"\" >/dev/null"), 0) SYSTEM_CC = SYSTEM_CC & arch end %write("SYSTEM_CC is " & SYSTEM_CC) end Most likely if we merely set SYSTEM_ASM = SYSTEM_CC & "-x assembler" it'll work well. Maybe only in this else case: proc configure_assembler() is if defined("SYSTEM_ASM") return end SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" if not FileExists(SYSTEM_ASM) SYSTEM_ASM = "as" <<== here end end All this is addressed by autoconf and/or a C-generating backend..... - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; m3devel at elegosoft.com Date: Sun, 12 Dec 2010 05:26:37 +0000 Subject: Re: [M3devel] cm3 on snow leopard? I'm rudely (but helpfully) ignoring your details and giving some of mine. I though what is supposed to happen, specifically on Darwin, is the assembly code is supposed to indicate an architecture. jbook2:m3core jay$ CM3_TARGET=I386_DARWIN M3CONFIG=/cm3/bin/config/I386_DARWIN cm3 -keep ^C jbook2:m3core jay$ CM3_TARGET=AMD64_DARWIN M3CONFIG=/cm3/bin/config/AMD64_DARWIN cm3 -keep ^C head */RTHooks.ms but no. But then this: jbook2:m3core jay$ CM3_TARGET=AMD64_DARWIN M3CONFIG=/cm3/bin/config/AMD64_DARWIN cm3 -keep -commands --- building in AMD64_DARWIN --- .. /usr/libexec/gcc/darwin/x86_64/as RTAllocator.ms -o RTAllocator.mo CM3_TARGET=I386_DARWIN M3CONFIG=/cm3/bin/config/I386_DARWIN cm3 -keep -commands ... /usr/libexec/gcc/darwin/i386/as Ctypes.is -o Ctypes.io i386 vs. x86_64. Darwin.common: proc configure_assembler() is if defined("SYSTEM_ASM") return end SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" if not FileExists(SYSTEM_ASM) SYSTEM_ASM = "as" end end jbook2:m3core jay$ grep DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-install/* /dev2/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN:DarwinArch = "x86_64" /dev2/cm3/m3-sys/cminstall/src/config-no-install/ARM_DARWIN:DarwinArch = "armv6" % ? /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: local arch = " -arch " & DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: arch = " -arch_only " & DarwinArch & " " /dev2/cm3/m3-sys/cminstall/src/config-no-install/I386_DARWIN:DarwinArch = "i386" /dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC64_DARWIN:DarwinArch = "ppc64" /dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC_DARWIN:DarwinArch = "ppc" ? cm3 -commands? find /usr/lib | grep /as$ find /usr/libexec | grep /as$ Maybe the path changed? Has a version? or is there is only i686-apple-darwin9, powerpc-apple-darwin9? I should look into getting the architecture into the assembly code though and just running "as", esp. on newer hosts. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; m3devel at elegosoft.com Date: Sun, 12 Dec 2010 00:59:18 +0000 Subject: Re: [M3devel] cm3 on snow leopard? I admit I'm still using Leopard. - Jay > To: m3devel at elegosoft.com > Date: Sat, 11 Dec 2010 14:19:02 -0800 > From: mika at async.caltech.edu > Subject: [M3devel] cm3 on snow leopard? > > Hello m3devel, > > I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook > Air, but it seems I have the wrong assembler? > > I had to force dpkg to override the architecture on install (it was expecting > i386, I think, and my machine identified itself as being "i386-darwin"?) > > Here are some details... > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-14 21:27:23 > configuration: /usr/local/cm3/bin/cm3.cfg > host: I386_DARWIN > target: I386_DARWIN > > compiling an empty Main.m3 yields: > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands > --- building in ../I386_DARWIN --- > > cd ../I386_DARWIN > rm .M3SHIP > rm .M3OVERRIDES > inhale prog.mx > inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a > inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a > > new source -> compiling Main.m3 > m3front ../src/Main.m3 -w1 > /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno-reorde > r-blocks Main.mc -o Main.ms > echo "rep movsl" | as -o /dev/null 2> /dev/null > as Main.ms -o Main.mo > Main.ms:15:suffix or operands invalid for `push' > assemble => 1 > assembler failed assembling: Main.ms > rm Main.mo > exhale prog.mx > rm prog.manifest > > compilation failed => not building program "prog" > Fatal Error: package build failed > > [HAL:~/test/src] mika% uname -a > Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 > [HAL:~/test/src] mika% as -v > Apple Inc version cctools-782~33, GNU assembler version 1.38 > > > I have XCode installed. > > [HAL:~/test/src] mika% gcc -v > Using built-in specs. > Target: i686-apple-darwin10 > Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 > Thread model: posix > gcc version 4.2.1 (Apple Inc. build 5664) > [HAL:~/test/src] mika% which gcc > /usr/bin/gcc > > > I must be doing something very obviously wrong (obviously to someone on this list, right??) > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Dec 12 10:35:35 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 12 Dec 2010 01:35:35 -0800 Subject: [M3devel] cm3 on snow leopard? Message-ID: <20101212093535.155ED1A207C@async.async.caltech.edu> Thanks, Jay. I wasn't able to use your Darwin.config (remember, I'm installing from the release .deb)---there seem to have been too many changes to these files for me to be able to sort it all out. However, I figured out how to do a "quick and dirty" from your email. This fixed it for me: if not defined("SYSTEM_ASM") SYSTEM_ASM="/usr/libexec/gcc/darwin/i386/as" end Now to check on all the other problems. Mika Jay K writes: >--_1377ed26-bb42-4722-b430-c9bf3b1b287d_ >Content-Type: text/plain; charset="Windows-1252" >Content-Transfer-Encoding: quoted-printable > > >I'm more sympathetic to using the already installed C compiler >to drive the assembler=2C than to build the current gcc driver. > > >You can see on Darwin we already probe around fairly aggressively >for a C compiler that can be told the target: > >Darwin.common: > > >proc configure_c_compiler() is > > if defined("SYSTEM_CC") > return > end > > % > % older compiler doesn't like -m32 or -arch > % > % gcc -c -m32 -x c /dev/null > % cc1: error: invalid option =91m32=92 > % > % fPIC is not usually needed here. > % It is the default for Apple gcc and left > % here in case user is using a self-built FSF gcc. > % > > SYSTEM_CC =3D "gcc -gstabs+ -fPIC" > local m =3D " -m" & {"32BITS":"32"=2C"64BITS":"64"}{WORD_SIZE} > local arch =3D " -arch " & DarwinArch > if not equal(try_exec("@" & SYSTEM_CC & m & " -c -x c /dev/null -o /dev/n= >ull 2>&1 | fgrep \"cc1: error: invalid option \\\`32'\" >/dev/null")=2C 0) > SYSTEM_CC =3D SYSTEM_CC & m > end > if not equal(try_exec("@" & SYSTEM_CC & arch & " -c -x c /dev/null -o /de= >v/null 2>&1 | fgrep \"cc1: error: unrecognized command line option \\\\\"-a= >rch\\\\\"\" >/dev/null")=2C 0) > SYSTEM_CC =3D SYSTEM_CC & arch > end > %write("SYSTEM_CC is " & SYSTEM_CC) >end > ... From jay.krell at cornell.edu Sun Dec 12 10:51:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 12 Dec 2010 09:51:06 +0000 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: References: <20101211221902.B71F81A207C@async.async.caltech.edu>, , , , , , , <20101212093436.813921A207A@async.async.caltech.edu>, Message-ID: oh, oops, I didn't realize release was so far behind, duh. :) It reads, AMD64_DARWIN: SYSTEM_ASM = "/usr/libexec/gcc/darwin/x86_64/as" if not FileExists(SYSTEM_ASM) SYSTEM_ASM = "as" end I386_DARWIN: proc configure_assembler() is if defined("SYSTEM_ASM") return end local a = try_exec("@echo \"rep movsl\" | as -o /dev/null 2> /dev/null") % write("a is " & a & CR) if equal(a, 0) SYSTEM_ASM = "as" % write(SYSTEM_ASM & " works" & CR) return end % write("as does not work" & CR) if FileExists("/cctools-698.1/usr/bin/as") SYSTEM_ASM = "/cctools-698.1/usr/bin/as" % write("using " & SYSTEM_ASM & ", which is presumed to work" & CR) return end error("as does not work (does not recognize \"rep movsl\"), please upgrade to " & "cctools-698.1 or newer and install to /cctools-698.1") % % another good option is probably to put an assembler next to cm3cg % end I have since changed m3cc to work with the older assembler. :) (The gcc folks might have also, but I did so differently.) - Jay > To: jay.krell at cornell.edu > CC: m3devel at async.caltech.edu > Subject: Re: [M3devel] cm3 on snow leopard? > Date: Sun, 12 Dec 2010 01:34:36 -0800 > From: mika at async.caltech.edu > > Thanks, Jay. > > I wasn't able to use your Darwin.config (remember, I'm installing > from the release .deb)---there seem to have been too many changes to > these files for me to be able to sort it all out. However, I figured > out how to do a "quick and dirty" from your email. > > This fixed it for me: > > if not defined("SYSTEM_ASM") > SYSTEM_ASM="/usr/libexec/gcc/darwin/i386/as" > end > > Now to check on all the other problems. > > Mika > > Jay K writes: > >--_1377ed26-bb42-4722-b430-c9bf3b1b287d_ > >Content-Type: text/plain; charset="Windows-1252" > >Content-Transfer-Encoding: quoted-printable > > > > > >I'm more sympathetic to using the already installed C compiler > >to drive the assembler=2C than to build the current gcc driver. > > > > > >You can see on Darwin we already probe around fairly aggressively > >for a C compiler that can be told the target: > > > >Darwin.common: > > > > > >proc configure_c_compiler() is > > > > if defined("SYSTEM_CC") > > return > > end > > > > % > > % older compiler doesn't like -m32 or -arch > > % > > % gcc -c -m32 -x c /dev/null > > % cc1: error: invalid option =91m32=92 > > % > > % fPIC is not usually needed here. > > % It is the default for Apple gcc and left > > % here in case user is using a self-built FSF gcc. > > % > > > > SYSTEM_CC =3D "gcc -gstabs+ -fPIC" > > local m =3D " -m" & {"32BITS":"32"=2C"64BITS":"64"}{WORD_SIZE} > > local arch =3D " -arch " & DarwinArch > > if not equal(try_exec("@" & SYSTEM_CC & m & " -c -x c /dev/null -o /dev/n= > >ull 2>&1 | fgrep \"cc1: error: invalid option \\\`32'\" >/dev/null")=2C 0) > > SYSTEM_CC =3D SYSTEM_CC & m > > end > > if not equal(try_exec("@" & SYSTEM_CC & arch & " -c -x c /dev/null -o /de= > >v/null 2>&1 | fgrep \"cc1: error: unrecognized command line option \\\\\"-a= > >rch\\\\\"\" >/dev/null")=2C 0) > > SYSTEM_CC =3D SYSTEM_CC & arch > > end > > %write("SYSTEM_CC is " & SYSTEM_CC) > >end > > > > > >Most likely if we merely set SYSTEM_ASM =3D SYSTEM_CC & "-x assembler" > >it'll work well. > >Maybe only in this else case: > > > > > >proc configure_assembler() is > > if defined("SYSTEM_ASM") > > return > > end > > SYSTEM_ASM =3D "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" > > if not FileExists(SYSTEM_ASM) > > SYSTEM_ASM =3D "as" <<=3D=3D here > > end > >end > > > > > >All this is addressed by autoconf and/or a C-generating backend..... > > > > > > - Jay > > > > > > > > > > > > > >From: jay.krell at cornell.edu > >To: mika at async.caltech.edu=3B m3devel at elegosoft.com > >Date: Sun=2C 12 Dec 2010 05:26:37 +0000 > >Subject: Re: [M3devel] cm3 on snow leopard? > > > > > > > > > > > > > > > > > >I'm rudely (but helpfully) ignoring your details and giving some of mine. > > > >I though what is supposed to happen=2C specifically on Darwin=2C is the ass= > >embly code is supposed to indicate an architecture. > > > >jbook2:m3core jay$ CM3_TARGET=3DI386_DARWIN M3CONFIG=3D/cm3/bin/config/I386= > >_DARWIN cm3 -keep > >^C > > > >jbook2:m3core jay$ CM3_TARGET=3DAMD64_DARWIN M3CONFIG=3D/cm3/bin/config/AMD= > >64_DARWIN cm3 -keep > >^C > > > >head */RTHooks.ms > > > >but no. > > > >But then this: > > > >jbook2:m3core jay$ CM3_TARGET=3DAMD64_DARWIN M3CONFIG=3D/cm3/bin/config/AMD= > >64_DARWIN cm3 -keep -commands > >--- building in AMD64_DARWIN --- > > > >.. > >/usr/libexec/gcc/darwin/x86_64/as RTAllocator.ms -o RTAllocator.mo > > > >CM3_TARGET=3DI386_DARWIN M3CONFIG=3D/cm3/bin/config/I386_DARWIN cm3 -keep -= > >commands > > > >... > >/usr/libexec/gcc/darwin/i386/as Ctypes.is -o Ctypes.io > > > >i386 vs. x86_64. > > > >Darwin.common: > >proc configure_assembler() is > > if defined("SYSTEM_ASM") > > return > > end > > SYSTEM_ASM =3D "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" > > if not FileExists(SYSTEM_ASM) > > SYSTEM_ASM =3D "as" > > end > >end > > > > > >jbook2:m3core jay$ grep DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no= > >-install/* > >/dev2/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN:DarwinArch = > >=3D "x86_64" > >/dev2/cm3/m3-sys/cminstall/src/config-no-install/ARM_DARWIN:DarwinArch =3D = > >"armv6" % ? > >/dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: SYSTEM_ASM= > > =3D "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" > >/dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: local arch= > > =3D " -arch " & DarwinArch > >/dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: arch = > >=3D " -arch_only " & DarwinArch & " " > >/dev2/cm3/m3-sys/cminstall/src/config-no-install/I386_DARWIN:DarwinArch =3D= > > "i386" > >/dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC64_DARWIN:DarwinArch = > >=3D "ppc64" > >/dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC_DARWIN:DarwinArch =3D = > >"ppc" > > > >? > >cm3 -commands? > > > >find /usr/lib | grep /as$ > >find /usr/libexec | grep /as$ > > > > > >Maybe the path changed? Has a version? or is there is only i686-apple-darwi= > >n9=2C powerpc-apple-darwin9? > > > >I should look into getting the architecture into the assembly code though a= > >nd just running "as"=2C esp. on newer hosts. > > > > - Jay > > > > > >From: jay.krell at cornell.edu > >To: mika at async.caltech.edu=3B m3devel at elegosoft.com > >Date: Sun=2C 12 Dec 2010 00:59:18 +0000 > >Subject: Re: [M3devel] cm3 on snow leopard? > > > > > > > > > > > > > > > > > >I admit I'm still using Leopard. > > > > - Jay > > > > > > > >> To: m3devel at elegosoft.com > >> Date: Sat=2C 11 Dec 2010 14:19:02 -0800 > >> From: mika at async.caltech.edu > >> Subject: [M3devel] cm3 on snow leopard? > >>=20 > >> Hello m3devel=2C > >>=20 > >> I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook > >> Air=2C but it seems I have the wrong assembler? > >>=20 > >> I had to force dpkg to override the architecture on install (it was expec= > >ting > >> i386=2C I think=2C and my machine identified itself as being "i386-darwin= > >"?) > >>=20 > >> Here are some details... > >>=20 > >> [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version > >> Critical Mass Modula-3 version 5.8.6 > >> last updated: 2010-04-11 > >> compiled: 2010-07-14 21:27:23 > >> configuration: /usr/local/cm3/bin/cm3.cfg > >> host: I386_DARWIN > >> target: I386_DARWIN > >>=20 > >> compiling an empty Main.m3 yields: > >>=20 > >> [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands > >> --- building in ../I386_DARWIN --- > >>=20 > >> cd ../I386_DARWIN > >> rm .M3SHIP > >> rm .M3OVERRIDES > >> inhale prog.mx > >> inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a > >> inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a > >>=20 > >> new source -> compiling Main.m3 > >> m3front ../src/Main.m3 -w1 > >> /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno= > >-reorde > >> r-blocks Main.mc -o Main.ms > >> echo "rep movsl" | as -o /dev/null 2> /dev/null > >> as Main.ms -o Main.mo > >> Main.ms:15:suffix or operands invalid for `push' > >> assemble =3D> 1 > >> assembler failed assembling: Main.ms > >> rm Main.mo > >> exhale prog.mx > >> rm prog.manifest > >>=20 > >> compilation failed =3D> not building program "prog" > >> Fatal Error: package build failed > >>=20 > >> [HAL:~/test/src] mika% uname -a > >> Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39= > > PDT 2010=3B root:xnu-1504.9.17~1/RELEASE_I386 i386 > >> [HAL:~/test/src] mika% as -v > >> Apple Inc version cctools-782~33=2C GNU assembler version 1.38 > >>=20 > >>=20 > >> I have XCode installed. > >>=20 > >> [HAL:~/test/src] mika% gcc -v > >> Using built-in specs. > >> Target: i686-apple-darwin10 > >> Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checkin= > >g --enable-werror --prefix=3D/usr --mandir=3D/share/man --enable-languages= > >=3Dc=2Cobjc=2Cc++=2Cobj-c++ --program-transform-name=3D/^[cg][^.-]*$/s/$/-4= > >.2/ --with-slibdir=3D/usr/lib --build=3Di686-apple-darwin10 --program-prefi= > >x=3Di686-apple-darwin10- --host=3Dx86_64-apple-darwin10 --target=3Di686-app= > >le-darwin10 --with-gxx-include-dir=3D/include/c++/4.2.1 > >> Thread model: posix > >> gcc version 4.2.1 (Apple Inc. build 5664) > >> [HAL:~/test/src] mika% which gcc > >> /usr/bin/gcc > >>=20 > >>=20 > >> I must be doing something very obviously wrong (obviously to someone on t= > >his list=2C right??) > >>=20 > >> Mika > > = > > > >--_1377ed26-bb42-4722-b430-c9bf3b1b287d_ > >Content-Type: text/html; charset="Windows-1252" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >I'm more sympathetic to using the already installed C compiler
to drive = > >the assembler=2C than to build the current gcc driver.


You can s= > >ee on Darwin we already probe around fairly aggressively
for a C compile= > >r that can be told the target:

Darwin.common:


proc config= > >ure_c_compiler() is

 =3B if defined("SYSTEM_CC")
 =3B&nbs= > >p=3B =3B return
 =3B end

 =3B %
 =3B % older c= > >ompiler doesn't like -m32 or -arch
 =3B %
 =3B % gcc -c -m32 = > >-x c /dev/null
 =3B % cc1: error: invalid option =91m32=92
 = > >=3B %
 =3B % fPIC is not usually needed here.
 =3B % It is th= > >e default for Apple gcc and left
 =3B % here in case user is using a= > > self-built FSF gcc.
 =3B %

 =3B SYSTEM_CC =3D "gcc -gsta= > >bs+ -fPIC"
 =3B local m =3D " -m" &=3B {"32BITS":"32"=2C"64BITS":= > >"64"}{WORD_SIZE}
 =3B local arch =3D " -arch " &=3B DarwinArch >> =3B if not equal(try_exec("@" &=3B SYSTEM_CC &=3B m &=3B " -= > >c -x c /dev/null -o /dev/null 2>=3B&=3B1 | fgrep \"cc1: error: invalid= > > option \\\`32'\" >=3B/dev/null")=2C 0)
 =3B =3B =3B SYSTE= > >M_CC =3D SYSTEM_CC &=3B m
 =3B end
 =3B if not equal(try_e= > >xec("@" &=3B SYSTEM_CC &=3B arch &=3B " -c -x c /dev/null -o /dev/= > >null 2>=3B&=3B1 | fgrep \"cc1: error: unrecognized command line option= > > \\\\\"-arch\\\\\"\" >=3B/dev/null")=2C 0)
 =3B =3B =3B SY= > >STEM_CC =3D SYSTEM_CC &=3B arch
 =3B end
 =3B %write("SYST= > >EM_CC is " &=3B SYSTEM_CC)
end


Most likely if we merely se= > >t SYSTEM_ASM =3D SYSTEM_CC &=3B "-x assembler"
it'll work well.
Ma= > >ybe only in this else case:


proc configure_assembler() is
&nb= > >sp=3B if defined("SYSTEM_ASM")
 =3B =3B =3B return
 = > >=3B end
 =3B SYSTEM_ASM =3D "/usr/libexec/gcc/darwin/" &=3B Darwi= > >nArch &=3B "/as"
 =3B if not FileExists(SYSTEM_ASM)
 =3B&n= > >bsp=3B =3B =3B =3B SYSTEM_ASM =3D "as" <=3B<=3B=3D=3D here<= > >br> =3B end
end


All this is addressed by autoconf and/or = > >a C-generating backend.....


 =3B- Jay




>>
From: jay.krell at cornell.edu
To: mika at async.= > >caltech.edu=3B m3devel at elegosoft.com
Date: Sun=2C 12 Dec 2010 05:26:37 += > >0000
Subject: Re: [M3devel] cm3 on snow leopard?

> > > > >"> > > > > > > > > > >I'm rudely (but helpfully) ignoring your details and giving some of mine. >r>
I though what is supposed to happen=2C specifically on Darwin=2C is t= > >he assembly code is supposed to indicate an architecture.

jbook2:m3c= > >ore jay$ CM3_TARGET=3DI386_DARWIN M3CONFIG=3D/cm3/bin/config/I386_DARWIN cm= > >3 -keep
^C

jbook2:m3core jay$ CM3_TARGET=3DAMD64_DARWIN M3CONFIG= > >=3D/cm3/bin/config/AMD64_DARWIN cm3 -keep
^C

head */RTHooks.ms >>
but no.

But then this:

jbook2:m3core jay$ CM3_TARGET=3DA= > >MD64_DARWIN M3CONFIG=3D/cm3/bin/config/AMD64_DARWIN cm3 -keep -commands
= > >--- building in AMD64_DARWIN ---

..
/usr/libexec/gcc/darwin/x86_6= > >4/as RTAllocator.ms -o RTAllocator.mo

CM3_TARGET=3DI386_DARWIN M3CON= > >FIG=3D/cm3/bin/config/I386_DARWIN cm3 -keep -commands

...
/usr/li= > >bexec/gcc/darwin/i386/as Ctypes.is -o Ctypes.io

i386 vs. x86_64.
= > >
Darwin.common:
proc configure_assembler() is
 =3B if defined(= > >"SYSTEM_ASM")
 =3B =3B =3B return
 =3B end
 = > >=3B SYSTEM_ASM =3D "/usr/libexec/gcc/darwin/" &=3B DarwinArch &=3B "/= > >as"
 =3B if not FileExists(SYSTEM_ASM)
 =3B =3B =3B&n= > >bsp=3B =3B SYSTEM_ASM =3D "as"
 =3B end
end


jbook2= > >:m3core jay$ grep DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-insta= > >ll/*
/dev2/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN:Darwi= > >nArch =3D "x86_64"
/dev2/cm3/m3-sys/cminstall/src/config-no-install/ARM_= > >DARWIN:DarwinArch =3D "armv6" % ?
/dev2/cm3/m3-sys/cminstall/src/config-= > >no-install/Darwin.common: =3B SYSTEM_ASM =3D "/usr/libexec/gcc/darwin/"= > > &=3B DarwinArch &=3B "/as"
/dev2/cm3/m3-sys/cminstall/src/config-= > >no-install/Darwin.common: =3B local arch =3D " -arch " &=3B DarwinAr= > >ch
/dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: = > >=3B =3B =3B =3B =3B arch =3D " -arch_only " &=3B DarwinA= > >rch &=3B " "
/dev2/cm3/m3-sys/cminstall/src/config-no-install/I386_DA= > >RWIN:DarwinArch =3D "i386"
/dev2/cm3/m3-sys/cminstall/src/config-no-inst= > >all/PPC64_DARWIN:DarwinArch =3D "ppc64"
/dev2/cm3/m3-sys/cminstall/src/c= > >onfig-no-install/PPC_DARWIN:DarwinArch =3D "ppc"

?
cm3 -commands?= > >

find /usr/lib | grep /as$
find /usr/libexec | grep /as$
> >
Maybe the path changed? Has a version? or is there is only i686-apple-d= > >arwin9=2C powerpc-apple-darwin9?

I should look into getting the arch= > >itecture into the assembly code though and just running "as"=2C esp. on new= > >er hosts.

 =3B- Jay


From: = > >jay.krell at cornell.edu
To: mika at async.caltech.edu=3B m3devel at elegosoft.co= > >m
Date: Sun=2C 12 Dec 2010 00:59:18 +0000
Subject: Re: [M3devel] cm3 = > >on snow leopard?

> > > > > > > > > > > > > >I admit I'm still using Leopard.

 =3B- Jay



>=3B= > > To: m3devel at elegosoft.com
>=3B Date: Sat=2C 11 Dec 2010 14:19:02 -080= > >0
>=3B From: mika at async.caltech.edu
>=3B Subject: [M3devel] cm3 o= > >n snow leopard?
>=3B
>=3B Hello m3devel=2C
>=3B
>=3B = > >I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook >r>>=3B Air=2C but it seems I have the wrong assembler?
>=3B
>= > >=3B I had to force dpkg to override the architecture on install (it was exp= > >ecting
>=3B i386=2C I think=2C and my machine identified itself as bei= > >ng "i386-darwin"?)
>=3B
>=3B Here are some details...
>=3B = > >
>=3B [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version
>=3B= > > Critical Mass Modula-3 version 5.8.6
>=3B last updated: 2010-04-11<= > >br>>=3B compiled: 2010-07-14 21:27:23
>=3B configuration: /usr/l= > >ocal/cm3/bin/cm3.cfg
>=3B host: I386_DARWIN
>=3B target: I386= > >_DARWIN
>=3B
>=3B compiling an empty Main.m3 yields:
>=3B <= > >br>>=3B [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands
= > >>=3B --- building in ../I386_DARWIN ---
>=3B
>=3B cd ../I386_D= > >ARWIN
>=3B rm .M3SHIP
>=3B rm .M3OVERRIDES
>=3B inhale prog.= > >mx
>=3B inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a
&g= > >t=3B inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a
>=3B
>= > >=3B new source ->=3B compiling Main.m3
>=3B m3front ../src/Main.m3 -= > >w1
>=3B /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 = > >-quiet -fno-reorde
>=3B r-blocks Main.mc -o Main.ms
>=3B echo "re= > >p movsl" | as -o /dev/null 2>=3B /dev/null
>=3B as Main.ms -o Main.m= > >o
>=3B Main.ms:15:suffix or operands invalid for `push'
>=3B as= > >semble =3D>=3B 1
>=3B assembler failed assembling: Main.ms
>=3B= > > rm Main.mo
>=3B exhale prog.mx
>=3B rm prog.manifest
>=3B <= > >br>>=3B compilation failed =3D>=3B not building program "prog"
>= > >=3B Fatal Error: package build failed
>=3B
>=3B [HAL:~/test/src]= > > mika% uname -a
>=3B Darwin HAL.local 10.5.0 Darwin Kernel Version 10.= > >5.0: Fri Nov 5 23:20:39 PDT 2010=3B root:xnu-1504.9.17~1/RELEASE_I386 i386= > >
>=3B [HAL:~/test/src] mika% as -v
>=3B Apple Inc version cctools= > >-782~33=2C GNU assembler version 1.38
>=3B
>=3B
>=3B I hav= > >e XCode installed.
>=3B
>=3B [HAL:~/test/src] mika% gcc -v
&g= > >t=3B Using built-in specs.
>=3B Target: i686-apple-darwin10
>=3B = > >Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking = > >--enable-werror --prefix=3D/usr --mandir=3D/share/man --enable-languages=3D= > >c=2Cobjc=2Cc++=2Cobj-c++ --program-transform-name=3D/^[cg][^.-]*$/s/$/-4.2/= > > --with-slibdir=3D/usr/lib --build=3Di686-apple-darwin10 --program-prefix= > >=3Di686-apple-darwin10- --host=3Dx86_64-apple-darwin10 --target=3Di686-appl= > >e-darwin10 --with-gxx-include-dir=3D/include/c++/4.2.1
>=3B Thread mod= > >el: posix
>=3B gcc version 4.2.1 (Apple Inc. build 5664)
>=3B [HA= > >L:~/test/src] mika% which gcc
>=3B /usr/bin/gcc
>=3B
>=3B <= > >br>>=3B I must be doing something very obviously wrong (obviously to some= > >one on this list=2C right??)
>=3B
>=3B Mika
> > = > > > >= > > > >--_1377ed26-bb42-4722-b430-c9bf3b1b287d_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Dec 12 21:14:58 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 12 Dec 2010 12:14:58 -0800 Subject: [M3devel] compiler problems on Snow Leopard Message-ID: <20101212201458.BEFA41A2079@async.async.caltech.edu> Hi everyone, Well I was able to get past all my linking issues (mostly questions of dynamic vs. static linking and how to do it, which seems to change from version to version...) But now I did hit a real problem. "../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** unaligned store type=6 s/o/a=32/0/32 "../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** unaligned load_indirect type=6 s/a=32/32 Here is the code, but it's not likely to be of much help... PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.T RAISES { Scheme.E } = BEGIN VAR res : SchemePair.T:=NIL; BEGIN res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),ToScheme_Atom_T(x.type)),res); res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modificationTime"),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),ToScheme_VAL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) RETURN res END END ToScheme_File_Status; ... PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0, LONGINT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = BEGIN RETURN ToScheme_LONGINT(x) (* line 981 *) END ToScheme_VAL0LONGINT__VAL16778080LONGINT; for reference, ToScheme_LONGINT is: PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISES { Scheme.E } = BEGIN WITH ref = NEW(REF LONGINT) DO ref^ := x; RETURN SchemeModula3Types.ToScheme_LONGINT(ref) END END ToScheme_LONGINT; Mika From hosking at cs.purdue.edu Sun Dec 12 21:19:15 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Dec 2010 15:19:15 -0500 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: <20101211221902.B71F81A207C@async.async.caltech.edu> References: <20101211221902.B71F81A207C@async.async.caltech.edu> Message-ID: My config file has: SYSTEM_ASM="as" ... return try_exec ("@" & SYSTEM_ASM, "-arch", "i386", "-q", source, "-o", object Works fine for me on Snow Leopard. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 11, 2010, at 5:19 PM, Mika Nystrom wrote: > Hello m3devel, > > I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook > Air, but it seems I have the wrong assembler? > > I had to force dpkg to override the architecture on install (it was expecting > i386, I think, and my machine identified itself as being "i386-darwin"?) > > Here are some details... > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-14 21:27:23 > configuration: /usr/local/cm3/bin/cm3.cfg > host: I386_DARWIN > target: I386_DARWIN > > compiling an empty Main.m3 yields: > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands > --- building in ../I386_DARWIN --- > > cd ../I386_DARWIN > rm .M3SHIP > rm .M3OVERRIDES > inhale prog.mx > inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a > inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a > > new source -> compiling Main.m3 > m3front ../src/Main.m3 -w1 > /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno-reorde > r-blocks Main.mc -o Main.ms > echo "rep movsl" | as -o /dev/null 2> /dev/null > as Main.ms -o Main.mo > Main.ms:15:suffix or operands invalid for `push' > assemble => 1 > assembler failed assembling: Main.ms > rm Main.mo > exhale prog.mx > rm prog.manifest > > compilation failed => not building program "prog" > Fatal Error: package build failed > > [HAL:~/test/src] mika% uname -a > Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 > [HAL:~/test/src] mika% as -v > Apple Inc version cctools-782~33, GNU assembler version 1.38 > > > I have XCode installed. > > [HAL:~/test/src] mika% gcc -v > Using built-in specs. > Target: i686-apple-darwin10 > Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 > Thread model: posix > gcc version 4.2.1 (Apple Inc. build 5664) > [HAL:~/test/src] mika% which gcc > /usr/bin/gcc > > > I must be doing something very obviously wrong (obviously to someone on this list, right??) > > Mika From hosking at cs.purdue.edu Sun Dec 12 21:20:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Dec 2010 15:20:20 -0500 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: <20101212093535.155ED1A207C@async.async.caltech.edu> References: <20101212093535.155ED1A207C@async.async.caltech.edu> Message-ID: <6545A943-6879-4B23-B3C4-17E5BDEB83C4@cs.purdue.edu> PS My "as" shows version: Apple Inc version cctools-782~37, GNU assembler version 1.38 Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 12, 2010, at 4:35 AM, Mika Nystrom wrote: > Thanks, Jay. > > I wasn't able to use your Darwin.config (remember, I'm installing > from the release .deb)---there seem to have been too many changes to > these files for me to be able to sort it all out. However, I figured > out how to do a "quick and dirty" from your email. > > This fixed it for me: > > if not defined("SYSTEM_ASM") > SYSTEM_ASM="/usr/libexec/gcc/darwin/i386/as" > end > > Now to check on all the other problems. > > Mika > > Jay K writes: >> --_1377ed26-bb42-4722-b430-c9bf3b1b287d_ >> Content-Type: text/plain; charset="Windows-1252" >> Content-Transfer-Encoding: quoted-printable >> >> >> I'm more sympathetic to using the already installed C compiler >> to drive the assembler=2C than to build the current gcc driver. >> >> >> You can see on Darwin we already probe around fairly aggressively >> for a C compiler that can be told the target: >> >> Darwin.common: >> >> >> proc configure_c_compiler() is >> >> if defined("SYSTEM_CC") >> return >> end >> >> % >> % older compiler doesn't like -m32 or -arch >> % >> % gcc -c -m32 -x c /dev/null >> % cc1: error: invalid option =91m32=92 >> % >> % fPIC is not usually needed here. >> % It is the default for Apple gcc and left >> % here in case user is using a self-built FSF gcc. >> % >> >> SYSTEM_CC =3D "gcc -gstabs+ -fPIC" >> local m =3D " -m" & {"32BITS":"32"=2C"64BITS":"64"}{WORD_SIZE} >> local arch =3D " -arch " & DarwinArch >> if not equal(try_exec("@" & SYSTEM_CC & m & " -c -x c /dev/null -o /dev/n= >> ull 2>&1 | fgrep \"cc1: error: invalid option \\\`32'\" >/dev/null")=2C 0) >> SYSTEM_CC =3D SYSTEM_CC & m >> end >> if not equal(try_exec("@" & SYSTEM_CC & arch & " -c -x c /dev/null -o /de= >> v/null 2>&1 | fgrep \"cc1: error: unrecognized command line option \\\\\"-a= >> rch\\\\\"\" >/dev/null")=2C 0) >> SYSTEM_CC =3D SYSTEM_CC & arch >> end >> %write("SYSTEM_CC is " & SYSTEM_CC) >> end >> > ... From hosking at cs.purdue.edu Sun Dec 12 21:25:13 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Dec 2010 15:25:13 -0500 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <20101212201458.BEFA41A2079@async.async.caltech.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu> Message-ID: <8A823CE8-A4A2-4280-8558-39D494F87160@cs.purdue.edu> That's an alignment problem alright. Perhaps the alignment information for VAL is wrong? Or for LONGINT? Jay, any ideas? On Dec 12, 2010, at 3:14 PM, Mika Nystrom wrote: > Hi everyone, > > Well I was able to get past all my linking issues (mostly questions > of dynamic vs. static linking and how to do it, which seems to change from > version to version...) > > But now I did hit a real problem. > > "../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** unaligned store type=6 s/o/a=32/0/32 > "../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** unaligned load_indirect type=6 s/a=32/32 > > Here is the code, but it's not likely to be of much help... > > PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.T RAISES { Scheme.E } = > BEGIN > VAR res : SchemePair.T:=NIL; BEGIN > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),ToScheme_Atom_T(x.type)),res); > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modificationTime"),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),ToScheme_VAL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) > RETURN res > END > END ToScheme_File_Status; > > > ... > > PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0, LONGINT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = > BEGIN > RETURN ToScheme_LONGINT(x) (* line 981 *) > END ToScheme_VAL0LONGINT__VAL16778080LONGINT; > > > for reference, ToScheme_LONGINT is: > > PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISES { Scheme.E } = > BEGIN > WITH ref = NEW(REF LONGINT) DO > ref^ := x; > RETURN SchemeModula3Types.ToScheme_LONGINT(ref) > END > END ToScheme_LONGINT; > > Mika From hosking at cs.purdue.edu Sun Dec 12 21:26:06 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Dec 2010 15:26:06 -0500 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <20101212201458.BEFA41A2079@async.async.caltech.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu> Message-ID: <8E56EB70-2DF9-40F8-8842-0D782A46EC7B@cs.purdue.edu> Mika, Did this LONGINT code work previously? I'm trying to figure out when the problem was introduced. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 12, 2010, at 3:14 PM, Mika Nystrom wrote: > Hi everyone, > > Well I was able to get past all my linking issues (mostly questions > of dynamic vs. static linking and how to do it, which seems to change from > version to version...) > > But now I did hit a real problem. > > "../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** unaligned store type=6 s/o/a=32/0/32 > "../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** unaligned load_indirect type=6 s/a=32/32 > > Here is the code, but it's not likely to be of much help... > > PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.T RAISES { Scheme.E } = > BEGIN > VAR res : SchemePair.T:=NIL; BEGIN > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),ToScheme_Atom_T(x.type)),res); > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modificationTime"),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),ToScheme_VAL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) > RETURN res > END > END ToScheme_File_Status; > > > ... > > PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0, LONGINT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = > BEGIN > RETURN ToScheme_LONGINT(x) (* line 981 *) > END ToScheme_VAL0LONGINT__VAL16778080LONGINT; > > > for reference, ToScheme_LONGINT is: > > PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISES { Scheme.E } = > BEGIN > WITH ref = NEW(REF LONGINT) DO > ref^ := x; > RETURN SchemeModula3Types.ToScheme_LONGINT(ref) > END > END ToScheme_LONGINT; > > Mika From mika at async.caltech.edu Sun Dec 12 21:49:02 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 12 Dec 2010 12:49:02 -0800 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <8E56EB70-2DF9-40F8-8842-0D782A46EC7B@cs.purdue.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu> <8E56EB70-2DF9-40F8-8842-0D782A46EC7B@cs.purdue.edu> Message-ID: <20101212204902.D68291A2079@async.async.caltech.edu> Tony, It's been a long, long time since I last compiled anything on I386_DARWIN, so I'm not sure. It did/does work on AMD64_LINUX and _FREEBSD, as far as I know. Mika Tony Hosking writes: >Mika, > >Did this LONGINT code work previously? I'm trying to figure out when = >the problem was introduced. > >Antony Hosking | Associate Professor | Computer Science | Purdue = >University >305 N. University Street | West Lafayette | IN 47907 | USA >Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > >On Dec 12, 2010, at 3:14 PM, Mika Nystrom wrote: > >> Hi everyone, >>=20 >> Well I was able to get past all my linking issues (mostly questions >> of dynamic vs. static linking and how to do it, which seems to change = >from >> version to version...) >>=20 >> But now I did hit a real problem. >>=20 >> "../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** = >unaligned store type=3D6 s/o/a=3D32/0/32 >> "../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** = >unaligned load_indirect type=3D6 s/a=3D32/32 >>=20 >> Here is the code, but it's not likely to be of much help... >>=20 >> PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : = >SchemeObject.T RAISES { Scheme.E } =3D >> BEGIN >> VAR res : SchemePair.T:=3DNIL; BEGIN >> res :=3D = >SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),ToScheme_A= >tom_T(x.type)),res); >> res :=3D = >SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modificationTime"= >),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); >> res :=3D = >SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),ToScheme_V= >AL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) >> RETURN res >> END >> END ToScheme_File_Status; >>=20 >>=20 >> ... >>=20 >> PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ = >VAL(0, LONGINT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { = >Scheme.E } =3D >> BEGIN >> RETURN ToScheme_LONGINT(x) (* line 981 *) >> END ToScheme_VAL0LONGINT__VAL16778080LONGINT; >>=20 >>=20 >> for reference, ToScheme_LONGINT is: >>=20 >> PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T = >RAISES { Scheme.E } =3D >> BEGIN >> WITH ref =3D NEW(REF LONGINT) DO >> ref^ :=3D x; >> RETURN SchemeModula3Types.ToScheme_LONGINT(ref) >> END >> END ToScheme_LONGINT; >>=20 >> Mika From jay.krell at cornell.edu Mon Dec 13 09:23:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Dec 2010 08:23:31 +0000 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: References: <20101211221902.B71F81A207C@async.async.caltech.edu>, Message-ID: Do all Darwin/x86 assemblers accept -arch flag? I don't know. e.g. 10.4? I might bring such a system back online.... Do all Darwin assemblers accept -arch? I doubt it. - Jay > From: hosking at cs.purdue.edu > Date: Sun, 12 Dec 2010 15:19:15 -0500 > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] cm3 on snow leopard? > > My config file has: > > SYSTEM_ASM="as" > ... > return try_exec ("@" & SYSTEM_ASM, "-arch", "i386", "-q", source, "-o", object > > Works fine for me on Snow Leopard. > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On Dec 11, 2010, at 5:19 PM, Mika Nystrom wrote: > > > Hello m3devel, > > > > I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook > > Air, but it seems I have the wrong assembler? > > > > I had to force dpkg to override the architecture on install (it was expecting > > i386, I think, and my machine identified itself as being "i386-darwin"?) > > > > Here are some details... > > > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version > > Critical Mass Modula-3 version 5.8.6 > > last updated: 2010-04-11 > > compiled: 2010-07-14 21:27:23 > > configuration: /usr/local/cm3/bin/cm3.cfg > > host: I386_DARWIN > > target: I386_DARWIN > > > > compiling an empty Main.m3 yields: > > > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands > > --- building in ../I386_DARWIN --- > > > > cd ../I386_DARWIN > > rm .M3SHIP > > rm .M3OVERRIDES > > inhale prog.mx > > inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a > > inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a > > > > new source -> compiling Main.m3 > > m3front ../src/Main.m3 -w1 > > /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno-reorde > > r-blocks Main.mc -o Main.ms > > echo "rep movsl" | as -o /dev/null 2> /dev/null > > as Main.ms -o Main.mo > > Main.ms:15:suffix or operands invalid for `push' > > assemble => 1 > > assembler failed assembling: Main.ms > > rm Main.mo > > exhale prog.mx > > rm prog.manifest > > > > compilation failed => not building program "prog" > > Fatal Error: package build failed > > > > [HAL:~/test/src] mika% uname -a > > Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 > > [HAL:~/test/src] mika% as -v > > Apple Inc version cctools-782~33, GNU assembler version 1.38 > > > > > > I have XCode installed. > > > > [HAL:~/test/src] mika% gcc -v > > Using built-in specs. > > Target: i686-apple-darwin10 > > Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 > > Thread model: posix > > gcc version 4.2.1 (Apple Inc. build 5664) > > [HAL:~/test/src] mika% which gcc > > /usr/bin/gcc > > > > > > I must be doing something very obviously wrong (obviously to someone on this list, right??) > > > > Mika > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 13 09:49:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Dec 2010 08:49:21 +0000 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <8A823CE8-A4A2-4280-8558-39D494F87160@cs.purdue.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, <8A823CE8-A4A2-4280-8558-39D494F87160@cs.purdue.edu> Message-ID: Head looks much better than release here. I'm not "just" saying that. release has stuff like m3front/src/misc/CG.m3: ELSIF (t = Target.Word.cg_type) OR (t = Target.Integer.cg_type) THEN ... ELSE Err("unaligned..." where head has: ELSIF (t = Target.Word.cg_type) OR (t = Target.Integer.cg_type) OR (t = Target.Long.cg_type) OR (t = Target.Longint.cg_type) THEN ... ELSE Err("unaligned..." several instances. Please try head. - Jay > From: hosking at cs.purdue.edu > Date: Sun, 12 Dec 2010 15:25:13 -0500 > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] compiler problems on Snow Leopard > > That's an alignment problem alright. Perhaps the alignment information for VAL is wrong? Or for LONGINT? Jay, any ideas? > > On Dec 12, 2010, at 3:14 PM, Mika Nystrom wrote: > > > Hi everyone, > > > > Well I was able to get past all my linking issues (mostly questions > > of dynamic vs. static linking and how to do it, which seems to change from > > version to version...) > > > > But now I did hit a real problem. > > > > "../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** unaligned store type=6 s/o/a=32/0/32 > > "../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** unaligned load_indirect type=6 s/a=32/32 > > > > Here is the code, but it's not likely to be of much help... > > > > PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.T RAISES { Scheme.E } = > > BEGIN > > VAR res : SchemePair.T:=NIL; BEGIN > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),ToScheme_Atom_T(x.type)),res); > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modificationTime"),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),ToScheme_VAL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) > > RETURN res > > END > > END ToScheme_File_Status; > > > > > > ... > > > > PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0, LONGINT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = > > BEGIN > > RETURN ToScheme_LONGINT(x) (* line 981 *) > > END ToScheme_VAL0LONGINT__VAL16778080LONGINT; > > > > > > for reference, ToScheme_LONGINT is: > > > > PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISES { Scheme.E } = > > BEGIN > > WITH ref = NEW(REF LONGINT) DO > > ref^ := x; > > RETURN SchemeModula3Types.ToScheme_LONGINT(ref) > > END > > END ToScheme_LONGINT; > > > > Mika > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 13 23:32:41 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Dec 2010 22:32:41 +0000 Subject: [M3devel] hardware woes (sort of).. Message-ID: Oops. Anyone in USA want an Itanium, no strings attached (but some suggested)? eBay item 290507974646 http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rt=nc&nma=true&item=290507974646 Thanks, - Jay From mika at async.caltech.edu Mon Dec 13 23:40:56 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 13 Dec 2010 14:40:56 -0800 Subject: [M3devel] file descriptor confusion? Message-ID: <20101213224056.18B341A2078@async.async.caltech.edu> Hi m3devel, Still fiddling with I386_DARWIN. I've been able to get everything that I need compiling with the release compiler so I haven't upgraded to the head yet. I'm trying hard to get a new product ready and am already behind, was hoping I could debug my own code on this new laptop... Maybe soon (actually I have already found a bug in my own code under the compiler so I shouldn't complain). But I've run into a mystery that I think may be due to some change in CM3, but it might also be a bug of mine, so please just let me know if there *might* have been some changes that could have had the following effect. My code uses a pretty elaborate debugging framework with a "Debug" module that prints debug messages and conditionally can turn on and off various input streams (types of debug messages) and output streams (targets: terminal, files, etc.) I have a program that connects over TCP to a server, using Wr and Rd on ConnFD.T, TCP.T, and such objects. I am now finding that my debug output is going to the server! It's supposed to be a completely separate stream. It looks like the file descriptors have gotten confused. Maybe. Does this ring a bell for anyone? Sometime in the last year I would guess. Code works perfectly under PM3 (as always). If it does ring a bell anywhere, what are the chances it's different in the head? Mika From jay.krell at cornell.edu Mon Dec 13 23:52:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Dec 2010 22:52:35 +0000 Subject: [M3devel] file descriptor confusion? In-Reply-To: <20101213224056.18B341A2078@async.async.caltech.edu> References: <20101213224056.18B341A2078@async.async.caltech.edu> Message-ID: Maybe some detail of fork? Does problem occur on other systems? Are you interfacing with C at all, besides what m3core/libm3 does for you? - Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Mon, 13 Dec 2010 14:40:56 -0800 > From: mika at async.caltech.edu > Subject: [M3devel] file descriptor confusion? > > Hi m3devel, > > Still fiddling with I386_DARWIN. > > I've been able to get everything that I need compiling with the release > compiler so I haven't upgraded to the head yet. I'm trying hard to > get a new product ready and am already behind, was hoping I could debug > my own code on this new laptop... Maybe soon (actually I have already > found a bug in my own code under the compiler so I shouldn't complain). > > But I've run into a mystery that I think may be due to some change in CM3, > but it might also be a bug of mine, so please just let me know if there > *might* have been some changes that could have had the following effect. > > My code uses a pretty elaborate debugging framework with a "Debug" > module that prints debug messages and conditionally can turn on and > off various input streams (types of debug messages) and output streams > (targets: terminal, files, etc.) > > I have a program that connects over TCP to a server, using Wr and Rd on > ConnFD.T, TCP.T, and such objects. I am now finding that my debug > output is going to the server! It's supposed to be a completely separate > stream. It looks like the file descriptors have gotten confused. Maybe. > > Does this ring a bell for anyone? Sometime in the last year I would guess. > Code works perfectly under PM3 (as always). If it does ring a bell > anywhere, what are the chances it's different in the head? > > Mika From wagner at elegosoft.com Tue Dec 14 11:03:08 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 14 Dec 2010 11:03:08 +0100 Subject: [M3devel] file descriptor confusion? In-Reply-To: <20101213224056.18B341A2078@async.async.caltech.edu> References: <20101213224056.18B341A2078@async.async.caltech.edu> Message-ID: <20101214110308.5q5cl8v484o8844g@mail.elegosoft.com> Quoting Mika Nystrom : > Hi m3devel, > > Still fiddling with I386_DARWIN. > > I've been able to get everything that I need compiling with the release > compiler so I haven't upgraded to the head yet. I'm trying hard to > get a new product ready and am already behind, was hoping I could debug > my own code on this new laptop... Maybe soon (actually I have already > found a bug in my own code under the compiler so I shouldn't complain). > > But I've run into a mystery that I think may be due to some change in CM3, > but it might also be a bug of mine, so please just let me know if there > *might* have been some changes that could have had the following effect. > > My code uses a pretty elaborate debugging framework with a "Debug" > module that prints debug messages and conditionally can turn on and > off various input streams (types of debug messages) and output streams > (targets: terminal, files, etc.) > > I have a program that connects over TCP to a server, using Wr and Rd on > ConnFD.T, TCP.T, and such objects. I am now finding that my debug > output is going to the server! It's supposed to be a completely separate > stream. It looks like the file descriptors have gotten confused. Maybe. > > Does this ring a bell for anyone? Sometime in the last year I would guess. > Code works perfectly under PM3 (as always). If it does ring a bell > anywhere, what are the chances it's different in the head? I think the main differences that one should look at are these two: o CM3 now uses a different threading implementation on most platforms (operating system (p)threads), and not self-implemented user threads any more. o Process.Create has been changed in order to cope with the change above, IIRC. All user threads used to be duplicated by fork, whereas the pthreads now need to be restarted in the child process. Please correct me if I remember this wrong, Jay. There's nothing more specific I can think of though that would explain the behaviour. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Dec 15 23:37:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Dec 2010 22:37:33 +0000 Subject: [M3devel] bit field operations for insert/extract In-Reply-To: References: , , <4FC6CE6F-FE19-461E-ACCC-41D6762CA3BC@cs.purdue.edu>, , , , , , Message-ID: I'm a bit nervous, like, that the semantics are the same esp. at the edge or past-the-edge cases -- extracting 0, 1, 31, 32, 33 bits, etc. I guess testing should show one way or the other -- assuming there aren't "undefined" things in gcc that vary per target (not sure if I have the patience or not to look at all the assembly for all the targets for all of the particular test case where I combinatorially generate everything, I probably should bite that bullet though, maybe split it into 4 easier to digest cases (32bit, 64bit, big endian, little endian). - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] bit field operations for insert/extract > Date: Tue, 23 Nov 2010 22:53:25 +0000 > > > Fair enough, easy enough. > I'd want to double check that the existing use is wanting that interpretation. > > > Obviously for that matter, we can leave the code asis for big endian. > And just take your code as it was, but under if (target_is_little_endian). > Big endian is the minority anyway. > :) > (no, I won't do that) > > > It would be cool if the frontend never checked target endianness. > It does it very little as it is. But ok either way. > (I want to move the Target.m3 stuff to the config files -- endianness, > setjmp name, jmpbuf size/align, etc., though that's about all that is left) > > > > - Jay > > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Tue, 23 Nov 2010 17:46:06 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] bit field operations for insert/extract > > > > If that's the case then I would argue for adjusting the offset accordingly in parse.c. > > extract_mn and insert_mn are defined as equivalent to Word.Extract/Word.Insert, respectively. > > > > On Nov 23, 2010, at 4:46 PM, Jay K wrote: > > > > > > > > Let me clarify. > > > Remember when you used bit field operations for extract_mn? > > > And they didn't work on any big endian system? > > > And I had to undo it? With your approval. > > > > > > > > > I believe the way to go: > > > the change you did in parse.c; it was correct, highly likely > > > removing those endian checks in m3front, which you didn't do at the time > > > > > > > > > Removing the endian checks will only affect big endian. > > > The code reads something like: > > > if little_endian extract_mn(offset, count) > > > else extract_mn(size - offset, size - count) > > > > > > > > > So just change it to: > > > extract_mn(offset, count) > > > > > > > > > And I strongly suspect it will affect it "in the right way". > > > But I'm going to try diffing assembly before/after to be sure. > > > And then watch the sparc and ppc hudson builds. :) > > > (and fix PPC_DARWIN beforehand as well) > > > > > > > > > > > > This is perhaps an interface change in m3cg, but there are no other big endian backends > > > and there are no other uses of extract_mn in the frontend, I think. > > > i.e. the meaning of extract_mn will have been changed to match gcc's interpretation, which it already did for little endian. Either that, or very reasonably in gcc we can check what the target endian is and adjust the count/offset. Either way. But one way involves target-specifieity in two places, the other zero. I like removing target-specificity. Though it is probably kind of implied in the next layer down, in gcc. > > > > > > > > > Anyway, still speculation at this point. > > > But this is pretty high on my list, low hanging fruit granted, probably no affect in the optimized code or perhaps unoptimized code, but I do like the idea to keep parse.c "thin" here if possible. > > > (ie: if this goes well, the next thing to look at is rotate, however in all of these bit operations, > > > I do worry that our definition of count/offset = 0, = type_precision, > type_precision may not match the gcc backend; > > > perhaps it is best to just leave everything asis...?) > > > > > > > > > and then I'll try to focus again on the type stuff, which is currently disabled because there was some problem, and then I decided I needed multiple passes, so I needed an in-memory form besides locals, so I wanted structs, declaratively declared (!) and depersisted, so I wanted C++, so I spent a week fixing that, oops...and there was also an m3cg/ir change which we found Hudson wasn't dealing with properly...and then configure enable-checking which I also have wanted...[i.e. I think have good excuses lately!] > > > > > > > > > (and then the later part of the type stuff is array/component_refs, and *then* enabling all optimizations, *including* not taking the address of so many things....(we're actually pretty good now and only disable one optimization, but taking the address probably is still a big downer)) > > > > > > > > > - Jay > > > > > > > > > ________________________________ > > >> Subject: Re: [M3devel] bit field operations for insert/extract > > >> From: hosking at cs.purdue.edu > > >> Date: Tue, 23 Nov 2010 16:34:25 -0500 > > >> CC: m3devel at elegosoft.com > > >> To: jay.krell at cornell.edu > > >> > > >> Are they wrong? Seems strange that they worked previously! > > >> > > >> On Nov 23, 2010, at 1:46 PM, Jay K wrote: > > >> > > >> None yet. But notice the endian checks around the insert_mn or > > >> extract_mn uses in cg.m3. > > >> The change would be to remove those. > > >> > > >> - Jay > > >> > > >> > > >> ________________________________ > > >> Subject: Re: [M3devel] bit field operations for insert/extract > > >> From: hosking at cs.purdue.edu > > >> Date: Tue, 23 Nov 2010 09:37:00 -0500 > > >> CC: m3devel at elegosoft.com > > >> To: jay.krell at cornell.edu > > >> > > >> Refresh my memory. What m3front change did you make? > > >> > > >> > > >> On Nov 23, 2010, at 3:33 AM, Jay K wrote: > > >> > > >> Tony, I'm going to try again to use bitfield operations for extract_mn. > > >> And insert_mn. > > >> I think I know what went wrong before for extract_mn: just remove the > > >> endian check in m3front. > > >> But I'm going to be sure test p240 covers it well. > > >> > > >> The easy part, duh, your original extract_mn was correct I think, just, > > >> again, missing the m3front change. > > >> > > >> Insert_mn is less obvious. > > >> I started writing it... bitfield_ref..modify_expr...uh, seems > > >> suspicious, to be modifying an existing value. > > >> > > >> I guess it's more like, that, but with a temp that starts with the full > > >> value of x: > > >> create temp > > >> modify(temp, x) > > >> modify(bitfield_ref(temp, count, offset), y); > > >> m3_load(temp) > > >> > > >> ? > > >> > > >> I'll try something like that. > > >> It seems unfortunate. > > >> Maybe we can know if x is already a value and not a variable? > > >> > > >> > > >> - Jay > > >> > > >> > > >> > > From dragisha at m3w.org Fri Dec 17 10:25:32 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 17 Dec 2010 10:25:32 +0100 Subject: [M3devel] swig Message-ID: Hi, GNU Modula-2 has this: http://www.nongnu.org/gm2/gm2.html#SEC23, and it's probably interesting for us too. Fancy approach there - instead of including a language parser into SWIG proper, a compiler emits .i files. SWIG is then used to process it to "client" platforms. d From jay.krell at cornell.edu Sat Dec 18 11:43:46 2010 From: jay.krell at cornell.edu (Jay) Date: Sat, 18 Dec 2010 02:43:46 -0800 Subject: [M3devel] TCardinal Message-ID: > CARDINAL is only ever used for values that should be in range on all > architectures. really? - Jay From hosking at cs.purdue.edu Sat Dec 18 16:45:42 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 18 Dec 2010 10:45:42 -0500 Subject: [M3devel] TCardinal In-Reply-To: References: Message-ID: <8530EEC4-872F-490B-94BB-3254834593B6@cs.purdue.edu> Yep. As far as I can tell. On Dec 18, 2010, at 5:43 AM, Jay wrote: >> CARDINAL is only ever used for values that should be in range on all >> architectures. > > really? > > - Jay From mika at async.caltech.edu Mon Dec 20 13:43:13 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 20 Dec 2010 04:43:13 -0800 Subject: [M3devel] swig In-Reply-To: References: Message-ID: <20101220124313.E25011A2061@async.async.caltech.edu> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >Hi, > >GNU Modula-2 has this: http://www.nongnu.org/gm2/gm2.html#SEC23, and = >it's probably interesting for us too. Fancy approach there - instead of = >including a language parser into SWIG proper, a compiler emits .i files. = >SWIG is then used to process it to "client" platforms. > >d One could also use m3tk for this. That's the approach I take for my Scheme environment, which I in principle have no objections to releasing, but haven't had the time to clean up properly.. (like so many other things). Of course since my Scheme interpreter is written in Modula-3, my code is (in principle) independent of implementation decisions in the Modula-3 compiler. (The code that the compiler sees is pure Modula-3.) Mika From dragisha at m3w.org Thu Dec 23 17:12:44 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 23 Dec 2010 17:12:44 +0100 Subject: [M3devel] still alive? Message-ID: <1293120764.8612.1.camel@boromir.m3w.org> Holiday season started already? -- Dragi?a Duri? From dabenavidesd at yahoo.es Fri Dec 24 15:13:38 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 24 Dec 2010 14:13:38 +0000 (GMT) Subject: [M3devel] still alive? In-Reply-To: <1293120764.8612.1.camel@boromir.m3w.org> Message-ID: <441851.14864.qm@web29708.mail.ird.yahoo.com> Hi all: I hope you had started, merry Christmas and let's wait this thing has very interesting things for us: https://groups.google.com/group/comp.std.c++/tree/browse_frm/month/1994-03/3dbb4bad549f75d4?rnum=51&_done=/group/comp.std.c%2B%2B/browse_frm/month/1994-03?&hl=pt&pli=1 check for the post for he third message: There is someone who was the mentioned OS sources, he was wondering in there what would mean CAMEL (the Application Manager at some time in that not commercialized project told me that it might be Compiler for Acorn Modula-2 Extended Language), it seems those guys there liked a lot to use exceptions, but the Application Manager said that there were in Xerox/Alto machines program crashes a lot times with run-time message uncaught exception. Hope it helps to awareness of this things --- El jue, 23/12/10, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: [M3devel] still alive? > Para: "m3devel" > Fecha: jueves, 23 de diciembre, 2010 11:12 > Holiday season started already? > -- > Dragi?a Duri? > > From dragisha at m3w.org Sat Dec 25 22:22:34 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 25 Dec 2010 22:22:34 +0100 Subject: [M3devel] Out-of-place error? Message-ID: I am getting this message *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "../src/types/XLTypeList.m3", line 235 *** And code is: 235 RETURN RefSeq.Sub(o1, from-1, XLTypeNumber.FromInt(range.get(1))); In this environment (just to get an idea): IF range.get(1) = NIL THEN RETURN RefSeq.Sub(o1, from-1); ELSE RETURN RefSeq.Sub(o1, from-1, XLTypeNumber.FromInt(range.get(1))); END; Same crash, same line :), happened when I inserted <* DEBUG range.get(1) *> before RETURN statement in ELSE branch.. Why this happens? TIA, dd p.s. Merry Christmass, of course :) From jay.krell at cornell.edu Sun Dec 26 00:41:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Dec 2010 23:41:28 +0000 Subject: [M3devel] Out-of-place error? In-Reply-To: References: Message-ID: I don't understand the question. > From: dragisha at m3w.org > Date: Sat, 25 Dec 2010 22:22:34 +0100 > To: m3devel at elegosoft.com > Subject: [M3devel] Out-of-place error? > > I am getting this message > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/types/XLTypeList.m3", line 235 > *** > > And code is: > 235 RETURN RefSeq.Sub(o1, from-1, XLTypeNumber.FromInt(range.get(1))); > > In this environment (just to get an idea): > IF range.get(1) = NIL THEN > RETURN RefSeq.Sub(o1, from-1); > ELSE > RETURN RefSeq.Sub(o1, from-1, XLTypeNumber.FromInt(range.get(1))); > END; > > Same crash, same line :), happened when I inserted > <* DEBUG range.get(1) *> > > before RETURN statement in ELSE branch.. > > Why this happens? > > TIA, > dd > > p.s. Merry Christmass, of course :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 26 11:02:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Dec 2010 10:02:12 +0000 Subject: [M3devel] assertion failure in compiler Message-ID: MODULE bug1; PROCEDURE F1()= CONST a=ARRAY OF INTEGER{0}; VAR b := SUBARRAY(0,1,a); BEGIN END F1; BEGIN END bug1. new source -> compiling bug1.m3 "../src/bug1.m3", line 5: SUBARRAY: first argument must be an array *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/exprs/Expr.m3", line 337 *** -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 26 11:28:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Dec 2010 10:28:40 +0000 Subject: [M3devel] offsetof, et. al? Message-ID: construction various data? So, I have this C: typedef struct _enum_t { const char* name; uint64_t value; } enum_t; typedef struct _field_t { char name[16]; uchar offset; uchar size; uchar element_size; uchar str; uchar macho_string; uchar enum_table_count; const enum_t* enum_table; } field_t; #define FIELD(t, f) {STRINGIZE(f), offsetof(t, f), sizeof((((t*)0)->f))} #define FIELD_ARRAY(t, f) {STRINGIZE(f), offsetof(t, f), sizeof((((t*)0)->f)), sizeof((((t*)0)->f)[0]) } #define FIELD_STRING(t, f) {STRINGIZE(f), offsetof(t, f), sizeof((((t*)0)->f)), sizeof((((t*)0)->f)[0]), 1 } #define FIELD_ENUM(t, f, e) {STRINGIZE(f), offsetof(t, f), sizeof((((t*)0)->f)), 0, 0, 0, sizeof(e)/sizeof((e)[0]), e } #define FIELD_MACHO_STRING(t, f) {STRINGIZE(f), offsetof(t, f), sizeof((((t*)0)->f)), 0, 0, 1 } typedef struct _struct_t { const char* name; uint size; uint nfields; const field_t* fields; int widest_field; } struct_t; #define STRUCT(a) {STRINGIZE(a), sizeof(a), NUMBER_OF(PASTE(a,_fields)), PASTE(a,_fields)} extern_const enum_t macho_magic_names[] = { { "magic32", macho_magic32 }, { "magic64", macho_magic64 } }; extern_const enum_t macho_cputype_names[] = { { "x86", macho_cpu_type_x86 }, { "amd64", macho_cpu_type_amd64 }, { "powerpc", macho_cpu_type_powerpc }, { "powerpc64", macho_cpu_type_powerpc64 } }; extern_const enum_t macho_cpusubtype_names[] = { { "powerpc_all", macho_cpu_subtype_powerpc_all }, { "x86_all", macho_cpu_subtype_x86_all } }; extern_const enum_t macho_filetype_names[] = { { "object", macho_type_object }, { "execute", macho_type_execute }, { "fixed_vm_library", macho_type_fixed_vm_library }, { "core", macho_type_core }, { "preload", macho_type_preload }, { "dylib", macho_type_dylib }, { "dylinker", macho_type_dylinker }, { "bundle", macho_type_bundle }, { "dylib_stub", macho_type_dylib_stub }, { "dsym", macho_type_dsym } }; extern_const field_t macho_header32_t_fields[] = { FIELD_ENUM(macho_header32_t, magic, macho_magic_names), FIELD_ENUM(macho_header32_t, cputype, macho_cputype_names), FIELD_ENUM(macho_header32_t, cpusubtype, macho_cpusubtype_names), FIELD_ENUM(macho_header32_t, filetype, macho_filetype_names), FIELD(macho_header32_t, ncmds), FIELD(macho_header32_t, sizeofcmds), FIELD(macho_header32_t, flags) }; how do I "best" convert this to Modula-3? I don't see a good analog to offsetof. I don't see a good analog of variably sized non-copying arrays, esp. constants. I have something kind of close, but I have to use VAR in places instead of CONST, and I have to make copies of the arrays, and I have to compute the offsets/sizes myself, which isn't difficult. I understand that using offset of is necesssarily unsafe. What I have, C and Modula-3, is checked in, in scratch/macho. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 26 21:15:37 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Dec 2010 15:15:37 -0500 Subject: [M3devel] Out-of-place error? In-Reply-To: References: Message-ID: <00F41A55-5306-4C7D-8E7C-1BE206AAF47C@cs.purdue.edu> Weird. What does the signature of range.get look like? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 25, 2010, at 6:41 PM, Jay K wrote: > I don't understand the question. > > > From: dragisha at m3w.org > > Date: Sat, 25 Dec 2010 22:22:34 +0100 > > To: m3devel at elegosoft.com > > Subject: [M3devel] Out-of-place error? > > > > I am getting this message > > > > *** > > *** runtime error: > > *** An enumeration or subrange value was out of range. > > *** file "../src/types/XLTypeList.m3", line 235 > > *** > > > > And code is: > > 235 RETURN RefSeq.Sub(o1, from-1, XLTypeNumber.FromInt(range.get(1))); > > > > In this environment (just to get an idea): > > IF range.get(1) = NIL THEN > > RETURN RefSeq.Sub(o1, from-1); > > ELSE > > RETURN RefSeq.Sub(o1, from-1, XLTypeNumber.FromInt(range.get(1))); > > END; > > > > Same crash, same line :), happened when I inserted > > <* DEBUG range.get(1) *> > > > > before RETURN statement in ELSE branch.. > > > > Why this happens? > > > > TIA, > > dd > > > > p.s. Merry Christmass, of course :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 26 21:25:42 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Dec 2010 15:25:42 -0500 Subject: [M3devel] assertion failure in compiler In-Reply-To: References: Message-ID: I think this is a known bug, related to one we already have a testcase for. On Dec 26, 2010, at 5:02 AM, Jay K wrote: > MODULE bug1; > > PROCEDURE F1()= > CONST a=ARRAY OF INTEGER{0}; > VAR b := SUBARRAY(0,1,a); > BEGIN > END F1; > > BEGIN > END bug1. > > > new source -> compiling bug1.m3 > "../src/bug1.m3", line 5: SUBARRAY: first argument must be an array > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/exprs/Expr.m3", line 337 > *** > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 27 03:11:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 02:11:28 +0000 Subject: [M3devel] pointers/arrays? Message-ID: a: UNTRACED REF T; i: INTEGER; a[i] ? (a + i)^ ? Or I'm really stuck with LOOPEHOLE(a + i * BYTESIZE(a^), UNTRACED REF T) Seems kind of stinky. I've got some nice efficient readable safe-enough C and it doesn't seem to translate well easily efficiently to Modula-3. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 27 05:37:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 04:37:07 +0000 Subject: [M3devel] pointers/arrays? In-Reply-To: References: Message-ID: I'm still wrestling with this. I have found a few options that work and they all have glaring problems. VAR macho_header32_t_fields := ARRAY [0..6] OF field_t{ field_t{ "magic", 0, 4, enum_table := EnumTable(macho_magic_names)}, ... field_t{ "flags", 24, 4}}; 1) I shouldn't have to give the size of the array. 2) I shouldn't have to copy the enum table to make it an indexable array. Disappointing.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 27 Dec 2010 02:11:28 +0000 Subject: [M3devel] pointers/arrays? a: UNTRACED REF T; i: INTEGER; a[i] ? (a + i)^ ? Or I'm really stuck with LOOPEHOLE(a + i * BYTESIZE(a^), UNTRACED REF T) Seems kind of stinky. I've got some nice efficient readable safe-enough C and it doesn't seem to translate well easily efficiently to Modula-3. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 27 08:15:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 07:15:26 +0000 Subject: [M3devel] constants/offsetof? Message-ID: Is it unreasonble to expect more/all of these to be constant? UNSAFE MODULE bug1; TYPE T1 = RECORD i,j:INTEGER END; <*NOWARN*>VAR a:T1; <*NOWARN*>CONST b: UNTRACED REF T1 = NIL; <*NOWARN*>CONST c: ADDRESS = ADR(a); (* line 7 *) <*NOWARN*>CONST d: ADDRESS = ADR(a.i); <*NOWARN*>CONST e: ADDRESS = ADR(a.j); <*NOWARN*>CONST f: INTEGER = ADR(a.j) - NIL; <*NOWARN*>CONST g: ADDRESS = ADR(b.i); <*NOWARN*>CONST h: ADDRESS = ADR(b.j); <*NOWARN*>CONST i: INTEGER = ADR(b.j) - NIL; <*NOWARN*>VAR vc: ADDRESS := ADR(a); <*NOWARN*>VAR vd: ADDRESS := ADR(a.i); <*NOWARN*>VAR ve: ADDRESS := ADR(a.j); <*NOWARN*>VAR vf: INTEGER := ADR(a.j) - NIL; (* oops, didn't mean this one *) <*NOWARN*>VAR vg: ADDRESS := ADR(b.i); <*NOWARN*>VAR vh: ADDRESS := ADR(b.j); <*NOWARN*>VAR vi: INTEGER := ADR(b.j) - NIL; BEGIN END bug1. "../src/bug1.m3", line 7: value is not constant "../src/bug1.m3", line 8: value is not constant "../src/bug1.m3", line 9: value is not constant "../src/bug1.m3", line 10: value is not constant "../src/bug1.m3", line 11: value is not constant "../src/bug1.m3", line 12: value is not constant "../src/bug1.m3", line 13: value is not constant It works in C... #include typedef struct { ptrdiff_t i, j;}T1; T1 a; #define b ((T1*)0) T1* const c = &a; ptrdiff_t* const d = &a.i; ptrdiff_t* const e = &a.j; ptrdiff_t const f = offsetof(T1,j); ptrdiff_t* const g = &b->i; ptrdiff_t* const h = &b->j; ptrdiff_t const i = &b->j - (ptrdiff_t*)0; Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Dec 27 11:14:21 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Dec 2010 02:14:21 -0800 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <20101212201458.BEFA41A2079@async.async.caltech.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu> Message-ID: <20101227101421.38A6A1A205B@async.async.caltech.edu> I upgraded to the CVS head and now I get the following: ... "../I386_DARWIN/FSSchemeStubs.m3", line 872: warning: unreachable statement "../I386_DARWIN/FSSchemeStubs.m3", line 903: warning: unreachable statement "../I386_DARWIN/FSSchemeStubs.m3", line 434: 2 code generation errors 1 error and 23 warnings encountered new exporters -> recompiling FSSchemeStubs.i3 ... The source code is: TYPE FS_Iterator_Surrogate = FS.Iterator OBJECT (* line 434 *) interp : Scheme.T; next_slot : SchemeObject.T := NIL; close_slot : SchemeObject.T := NIL; nextWithStatus_slot : SchemeObject.T := NIL; OVERRIDES next := FS_Iterator_next_default; close := FS_Iterator_close_default; nextWithStatus := FS_Iterator_nextWithStatus_default; END; Mika Mika Nystrom writes: >Hi everyone, > >Well I was able to get past all my linking issues (mostly questions >of dynamic vs. static linking and how to do it, which seems to change from >version to version...) > >But now I did hit a real problem. > >"../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** unaligne >d store type=6 s/o/a=32/0/32 >"../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** unaligne >d load_indirect type=6 s/a=32/32 > >Here is the code, but it's not likely to be of much help... > >PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.T RAIS >ES { Scheme.E } = > BEGIN > VAR res : SchemePair.T:=NIL; BEGIN > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),T >oScheme_Atom_T(x.type)),res); > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modifica >tionTime"),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),T >oScheme_VAL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) > RETURN res > END > END ToScheme_File_Status; > > >... > >PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0, LONGI >NT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = > BEGIN > RETURN ToScheme_LONGINT(x) (* line 981 *) > END ToScheme_VAL0LONGINT__VAL16778080LONGINT; > > >for reference, ToScheme_LONGINT is: > >PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISES { S >cheme.E } = > BEGIN > WITH ref = NEW(REF LONGINT) DO > ref^ := x; > RETURN SchemeModula3Types.ToScheme_LONGINT(ref) > END > END ToScheme_LONGINT; > > Mika From mika at async.caltech.edu Mon Dec 27 11:16:53 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Dec 2010 02:16:53 -0800 Subject: [M3devel] another Snow Leopard compiler crash Message-ID: <20101227101653.307241A205B@async.async.caltech.edu> ===> calarm/regress/ximport --- building in I386_DARWIN --- new source -> compiling Main.m3 "../src/Main.m3", line 258: warning: potentially unhandled exception: Main.ParamErr "../src/Main.m3", line 260: warning: potentially unhandled exception: Main.ParamErr "../src/Main.m3", line 261: warning: potentially unhandled exception: Main.ParamErr 3 warnings encountered ../src/Main.m3: In function 'Main__DumpMatching__DumpOne': ../src/Main.m3:225:0: error: unable to find a register to spill in class 'CREG' ../src/Main.m3:225:0: error: this is the insn: (insn 5 4 6 2 ../src/Main.m3:204 (parallel [ (set (reg:SI 0 ax [130]) (const_int 0 [0x0])) (set (reg:SI 1 dx [128]) (plus:SI (ashift:SI (reg:SI 0 ax [130]) (const_int 2 [0x2])) (reg:SI 1 dx [128]))) (set (reg:SI 4 si [129]) (plus:SI (ashift:SI (reg:SI 0 ax [130]) (const_int 2 [0x2])) (reg:SI 4 si [129]))) (set (mem/s/c:BLK (reg:SI 1 dx [128]) [0 trade+0 S24 A64]) (mem/s/c:BLK (reg:SI 4 si [129]) [0 trade+0 S24 A32])) (use (reg:SI 0 ax [130])) ]) 838 {*rep_movsi} (expr_list:REG_UNUSED (reg:SI 0 ax [130]) (expr_list:REG_UNUSED (reg:SI 4 si [129]) (expr_list:REG_UNUSED (reg:SI 1 dx [128]) (nil))))) ../src/Main.m3:225:0: internal compiler error: in spill_failure, at reload1.c:2163 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: Main.mc compilation failed => not building program "ximport" Fatal Error: package build failed Here is the code: PROCEDURE DumpMatching(tr : TickerRef; trades, bids, asks : HFDataSSeq.T) RAISES { Wr.Failure } = PROCEDURE DumpOne(trade, bid, ask : HFData.S) RAISES { Wr.Failure } = BEGIN <* ASSERT trade.time = bid.time AND bid.time = ask.time *> Wr.PutText(wr, Fmt.LongReal(trade.time)); Wr.PutChar(wr, ' '); Wr.PutText(wr, Fmt.LongReal(aFactor*trade.pv.price)); Wr.PutChar(wr, ' '); Wr.PutText(wr, Fmt.LongReal(FLOAT(trade.pv.volume,LONGREAL)/aFactor)); Wr.PutChar(wr, ' '); Wr.PutText(wr, Fmt.LongReal(aFactor*bid.pv.price)); Wr.PutChar(wr, ' '); Wr.PutText(wr, Fmt.LongReal(FLOAT(bid.pv.volume,LONGREAL)/aFactor)); Wr.PutChar(wr, ' '); Wr.PutText(wr, Fmt.LongReal(aFactor*ask.pv.price)); Wr.PutChar(wr, ' '); Wr.PutText(wr, Fmt.LongReal(FLOAT(ask.pv.volume,LONGREAL)/aFactor)); Wr.PutChar(wr, '\n') END DumpOne; CONST NoTime = FIRST(Time.T); VAR wr := FileWr.Open(odir & "/" & tr.ticker); tp, bp, ap := 0; ttime, btime, atime := NoTime; aFactor : LONGREAL := 1.0d0; BEGIN WHILE tp < trades.size() AND bp < bids.size() AND ap < asks.size() DO IF ttime = NoTime THEN ttime := trades.get(tp).time END; IF btime = NoTime THEN btime := bids.get(bp).time END; IF atime = NoTime THEN atime := asks.get(ap).time END; IF ttime = btime AND btime = atime THEN DumpOne(trades.get(tp),bids.get(bp),asks.get(ap)); INC(tp); INC(bp); INC(ap); ttime := NoTime; btime := NoTime; atime := NoTime ELSIF ttime < btime OR ttime < atime THEN INC(tp); ttime := NoTime ELSIF btime < atime OR btime < ttime THEN INC(bp); btime := NoTime ELSIF atime < btime OR atime < ttime THEN INC(ap); atime := NoTime END END; Wr.Close(wr) END DumpMatching; Miika From jay.krell at cornell.edu Mon Dec 27 11:17:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 10:17:51 +0000 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <20101227101421.38A6A1A205B@async.async.caltech.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, <20101227101421.38A6A1A205B@async.async.caltech.edu> Message-ID: Can you put all your code in our CVS repository? > "../I386_DARWIN/FSSchemeStubs.m3", line 434: 2 code generation errors There is a way to get that to show more information.. Or does it already? - Jay > To: m3devel at elegosoft.com > Date: Mon, 27 Dec 2010 02:14:21 -0800 > From: mika at async.caltech.edu > Subject: Re: [M3devel] compiler problems on Snow Leopard > > I upgraded to the CVS head and now I get the following: > > ... > "../I386_DARWIN/FSSchemeStubs.m3", line 872: warning: unreachable statement > "../I386_DARWIN/FSSchemeStubs.m3", line 903: warning: unreachable statement > "../I386_DARWIN/FSSchemeStubs.m3", line 434: 2 code generation errors > 1 error and 23 warnings encountered > new exporters -> recompiling FSSchemeStubs.i3 > ... > > The source code is: > > TYPE FS_Iterator_Surrogate = FS.Iterator OBJECT (* line 434 *) > interp : Scheme.T; > next_slot : SchemeObject.T := NIL; > close_slot : SchemeObject.T := NIL; > nextWithStatus_slot : SchemeObject.T := NIL; > OVERRIDES > next := FS_Iterator_next_default; > close := FS_Iterator_close_default; > nextWithStatus := FS_Iterator_nextWithStatus_default; > END; > > Mika > > Mika Nystrom writes: > >Hi everyone, > > > >Well I was able to get past all my linking issues (mostly questions > >of dynamic vs. static linking and how to do it, which seems to change from > >version to version...) > > > >But now I did hit a real problem. > > > >"../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** unaligne > >d store type=6 s/o/a=32/0/32 > >"../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** unaligne > >d load_indirect type=6 s/a=32/32 > > > >Here is the code, but it's not likely to be of much help... > > > >PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.T RAIS > >ES { Scheme.E } = > > BEGIN > > VAR res : SchemePair.T:=NIL; BEGIN > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),T > >oScheme_Atom_T(x.type)),res); > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modifica > >tionTime"),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),T > >oScheme_VAL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) > > RETURN res > > END > > END ToScheme_File_Status; > > > > > >... > > > >PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0, LONGI > >NT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = > > BEGIN > > RETURN ToScheme_LONGINT(x) (* line 981 *) > > END ToScheme_VAL0LONGINT__VAL16778080LONGINT; > > > > > >for reference, ToScheme_LONGINT is: > > > >PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISES { S > >cheme.E } = > > BEGIN > > WITH ref = NEW(REF LONGINT) DO > > ref^ := x; > > RETURN SchemeModula3Types.ToScheme_LONGINT(ref) > > END > > END ToScheme_LONGINT; > > > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Dec 27 11:38:10 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Dec 2010 02:38:10 -0800 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, <20101227101421.38A6A1A205B@async.async.caltech.edu> Message-ID: <20101227103810.94DF21A205B@async.async.caltech.edu> Jay K writes: >--_6f82bcb2-663f-4046-87f2-073a1528a819_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Can you put all your code in our CVS repository? > I can't put all the code I work with in m3devel's repository: some of it is proprietary. The Scheme code however I have no restrictions on distributing (that's what's got problems in this case). It is however large and unwieldy and I'd like to have other people's suggestions for how to submit/incorporate it with CM3 before I just dump it in the repository. It also overlaps a bit with "caltech-parser", so there should probably be a "caltech-common" package for the overlaps? If you run the following commands in a fresh directory, you should get to the error I emailed: setenv CM3 1 cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -d . make regress # GNU make : 'gmake regress' on BSD cd mscheme/sstubgen/example cm3 -x Mika From jay.krell at cornell.edu Mon Dec 27 11:35:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 10:35:24 +0000 Subject: [M3devel] enable/disableswitching around external calls? Message-ID: I noticed calls to free in M3toC missing Enable/DisableSwitching. I'm going to generalize this, somewhat, in m3core.h, but that still leaves a fair number of custom wrappers. This area seems extremely error prone and extremely difficult to get test coverage on. These functions only do anything for user threads. Which we only use by default on OpenBSD. How about the frontend emit the calls around any external calls? Theory being: external calls are rare? Perhaps frontend/m3middle would know if user threads are in use and only emit the calls in that case. Perhaps. I don't like sprinking much target-specific information around. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 27 11:46:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 10:46:55 +0000 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <20101227103810.94DF21A205B@async.async.caltech.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , <20101227103810.94DF21A205B@async.async.caltech.edu> Message-ID: aside: overlap with caltech_parser: if you can come up with a merged version that works with both, good If you can't, I think you have to rename one or the other. Maybe someday we can support some sort of hierarchy that automatically maps to/from the file system hierarchy... I'll try to reproduce the problem. All targets? Workaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) - Jay > To: jay.krell at cornell.edu > Date: Mon, 27 Dec 2010 02:38:10 -0800 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] compiler problems on Snow Leopard > > Jay K writes: > >--_6f82bcb2-663f-4046-87f2-073a1528a819_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Can you put all your code in our CVS repository? > > > > I can't put all the code I work with in m3devel's repository: some of > it is proprietary. > > The Scheme code however I have no restrictions on distributing (that's > what's got problems in this case). It is however large and unwieldy and > I'd like to have other people's suggestions for how to submit/incorporate > it with CM3 before I just dump it in the repository. It also overlaps a bit > with "caltech-parser", so there should probably be a "caltech-common" > package for the overlaps? > > If you run the following commands in a fresh directory, you should get > to the error I emailed: > > setenv CM3 1 > cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -d . > make regress # GNU make : 'gmake regress' on BSD > cd mscheme/sstubgen/example > cm3 -x > > Mika > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 27 11:51:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 10:51:10 +0000 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , , , <20101227103810.94DF21A205B@async.async.caltech.edu>, Message-ID: I can't quite reproduce it, but I can compile a bunch of your code. new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-lib.a" -> archiving libsstubgen.a ===> mscheme/sstubgen/program --- building in I386_DARWIN --- -> linking sstubgen i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/libmscheme.a: No such file or directory m3_link => 1 linker failed linking: sstubgen Fatal Error: package build failed jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example jbook2:example jay$ c,3 -bash: c,3: command not found jbook2:example jay$ cm3 --- building in I386_DARWIN --- ignoring ../src/m3overrides "/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3makefile", line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/I386_DARWIN/.M3EXPORTS" for reading --procedure-- -line- -file--- import -- include_dir 3 /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3makefile - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu Date: Mon, 27 Dec 2010 10:46:55 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] compiler problems on Snow Leopard aside: overlap with caltech_parser: if you can come up with a merged version that works with both, good If you can't, I think you have to rename one or the other. Maybe someday we can support some sort of hierarchy that automatically maps to/from the file system hierarchy... I'll try to reproduce the problem. All targets? Workaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) - Jay > To: jay.krell at cornell.edu > Date: Mon, 27 Dec 2010 02:38:10 -0800 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] compiler problems on Snow Leopard > > Jay K writes: > >--_6f82bcb2-663f-4046-87f2-073a1528a819_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Can you put all your code in our CVS repository? > > > > I can't put all the code I work with in m3devel's repository: some of > it is proprietary. > > The Scheme code however I have no restrictions on distributing (that's > what's got problems in this case). It is however large and unwieldy and > I'd like to have other people's suggestions for how to submit/incorporate > it with CM3 before I just dump it in the repository. It also overlaps a bit > with "caltech-parser", so there should probably be a "caltech-common" > package for the overlaps? > > If you run the following commands in a fresh directory, you should get > to the error I emailed: > > setenv CM3 1 > cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -d . > make regress # GNU make : 'gmake regress' on BSD > cd mscheme/sstubgen/example > cm3 -x > > Mika > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Dec 27 11:53:17 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Dec 2010 02:53:17 -0800 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , <20101227103810.94DF21A205B@async.async.caltech.edu> Message-ID: <20101227105317.52A861A205B@async.async.caltech.edu> I'mu sure a merged version is possible. I still have a separate version of caltech-parser in "my" repository that works with "my" Debug.i3, etc. I have only tried Snow Leopard (I386_DARWIN). I use PM3 on FreeBSD... I haven't tried workarounds here because I don't desperately need this code to work (at least not yet). The problem I reported a couple of weeks ago with "file descriptors" turned out to have something to do with closing a file through C somehow.. not sure exactly what was going on since I am using a helper C process to do terminal I/O using GNU readline. Mika Jay K writes: >--_f9584f16-e235-418f-823d-1c2a51c6bc9b_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >aside: overlap with caltech_parser: >if you can come up with a merged version that works with both=2C good >If you can't=2C I think you have to rename one or the other. > >Maybe someday we can support some sort of hierarchy that automatically maps= > to/from the file system hierarchy... > >I'll try to reproduce the problem. > >All targets? >Workaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) > > - Jay > > >> To: jay.krell at cornell.edu >> Date: Mon=2C 27 Dec 2010 02:38:10 -0800 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] compiler problems on Snow Leopard >>=20 >> Jay K writes: >> >--_6f82bcb2-663f-4046-87f2-073a1528a819_ >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> >Can you put all your code in our CVS repository? >> > >>=20 >> I can't put all the code I work with in m3devel's repository: some of=20 >> it is proprietary. >>=20 >> The Scheme code however I have no restrictions on distributing (that's >> what's got problems in this case). It is however large and unwieldy and >> I'd like to have other people's suggestions for how to submit/incorporate >> it with CM3 before I just dump it in the repository. It also overlaps a = >bit >> with "caltech-parser"=2C so there should probably be a "caltech-common" >> package for the overlaps? >>=20 >> If you run the following commands in a fresh directory=2C you should get >> to the error I emailed: >>=20 >> setenv CM3 1 >> cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -d . >> make regress # GNU make : 'gmake regress' on BSD >> cd mscheme/sstubgen/example >> cm3 -x >>=20 >> Mika >>=20 >>=20 > = > >--_f9584f16-e235-418f-823d-1c2a51c6bc9b_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >aside: overlap with caltech_parser:
if you can come up with a merged ver= >sion that works with both=2C good
If you can't=2C I think you have to re= >name one or the other.

Maybe someday we can support some sort of hie= >rarchy that automatically maps to/from the file system hierarchy...

= >I'll try to reproduce the problem.

All targets?
Workaround with d= >ifferent cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?)

 =3B- Jay>

>=3B To: jay.krell at cornell.edu
>=3B Date: Mon=2C 27 Dec 201= >0 02:38:10 -0800
>=3B From: mika at async.caltech.edu
>=3B CC: m3dev= >el at elegosoft.com
>=3B Subject: Re: [M3devel] compiler problems on Snow= > Leopard
>=3B
>=3B Jay K writes:
>=3B >=3B--_6f82bcb2-663= >f-4046-87f2-073a1528a819_
>=3B >=3BContent-Type: text/plain=3B chars= >et=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encoding: quoted-printab= >le
>=3B >=3B
>=3B >=3B
>=3B >=3BCan you put all your c= >ode in our CVS repository?
>=3B >=3B
>=3B
>=3B I can't pu= >t all the code I work with in m3devel's repository: some of
>=3B it i= >s proprietary.
>=3B
>=3B The Scheme code however I have no restr= >ictions on distributing (that's
>=3B what's got problems in this case)= >. It is however large and unwieldy and
>=3B I'd like to have other pe= >ople's suggestions for how to submit/incorporate
>=3B it with CM3 befo= >re I just dump it in the repository. It also overlaps a bit
>=3B with= > "caltech-parser"=2C so there should probably be a "caltech-common"
>= >=3B package for the overlaps?
>=3B
>=3B If you run the following= > commands in a fresh directory=2C you should get
>=3B to the error I e= >mailed:
>=3B
>=3B setenv CM3 1
>=3B cvs -d :pserver:anonymo= >us at pluto.gcapltd.com:/home/gcap-public-cvs up -d .
>=3B make regress = > # GNU make : 'gmake regress' on BSD
>=3B cd mscheme/sstubgen/example= >
>=3B cm3 -x
>=3B
>=3B Mika
>=3B
>=3B
= > >= > >--_f9584f16-e235-418f-823d-1c2a51c6bc9b_-- From mika at async.caltech.edu Mon Dec 27 11:58:59 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Dec 2010 02:58:59 -0800 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , , , <20101227103810.94DF21A205B@async.async.caltech.edu>, Message-ID: <20101227105859.8E1F21A205B@async.async.caltech.edu> Run cm3 -x instead of just cm3. Did you get an error compiling package "mscheme"? I certainly have a libmscheme.a in there. /m3overrides has build_standalone() in it. I normally didn't use build_standalone() but something has changed in how the system searches for shared libs when building with overrides and this was the easiest solution (at least for now). Mika Jay K writes: >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >I can't quite reproduce it=2C but I can compile a bunch of your code. > > >new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-lib.a" = >-> archiving libsstubgen.a > >=3D=3D=3D> mscheme/sstubgen/program >--- building in I386_DARWIN --- > > -> linking sstubgen >i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/lib= >mscheme.a: No such file or directory > m3_link =3D> 1 >linker failed linking: sstubgen >Fatal Error: package build failed > >jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example >jbook2:example jay$ c=2C3 >-bash: c=2C3: command not found >jbook2:example jay$ cm3 >--- building in I386_DARWIN --- > >ignoring ../src/m3overrides > >"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3makefile"= >=2C line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/I386_DARW= >IN/.M3EXPORTS" for reading > >--procedure-- -line- -file--- >import -- >include_dir 3 /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/exa= >mple/src/m3makefile > > > - Jay > > > > > > >From: jay.krell at cornell.edu >To: mika at async.caltech.edu >Date: Mon=2C 27 Dec 2010 10:46:55 +0000 >CC: m3devel at elegosoft.com >Subject: Re: [M3devel] compiler problems on Snow Leopard > > > > > > > > >aside: overlap with caltech_parser: >if you can come up with a merged version that works with both=2C good >If you can't=2C I think you have to rename one or the other. > >Maybe someday we can support some sort of hierarchy that automatically maps= > to/from the file system hierarchy... > >I'll try to reproduce the problem. > >All targets? >Workaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) > > - Jay > > >> To: jay.krell at cornell.edu >> Date: Mon=2C 27 Dec 2010 02:38:10 -0800 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] compiler problems on Snow Leopard >>=20 >> Jay K writes: >> >--_6f82bcb2-663f-4046-87f2-073a1528a819_ >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> >Can you put all your code in our CVS repository? >> > >>=20 >> I can't put all the code I work with in m3devel's repository: some of=20 >> it is proprietary. >>=20 >> The Scheme code however I have no restrictions on distributing (that's >> what's got problems in this case). It is however large and unwieldy and >> I'd like to have other people's suggestions for how to submit/incorporate >> it with CM3 before I just dump it in the repository. It also overlaps a = >bit >> with "caltech-parser"=2C so there should probably be a "caltech-common" >> package for the overlaps? >>=20 >> If you run the following commands in a fresh directory=2C you should get >> to the error I emailed: >>=20 >> setenv CM3 1 >> cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -d . >> make regress # GNU make : 'gmake regress' on BSD >> cd mscheme/sstubgen/example >> cm3 -x >>=20 >> Mika >>=20 >>=20 > = > >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >I can't quite reproduce it=2C but I can compile a bunch of your code.
r>
new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-l= >ib.a" ->=3B archiving libsstubgen.a

=3D=3D=3D>=3B mscheme/sstubg= >en/program
--- building in I386_DARWIN ---

 =3B->=3B linkin= >g sstubgen
i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I= >386_DARWIN/libmscheme.a: No such file or directory
 =3B m3_link =3D&= >gt=3B 1
linker failed linking: sstubgen
Fatal Error: package build fa= >iled

jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example
jboo= >k2:example jay$ c=2C3
-bash: c=2C3: command not found
jbook2:example = >jay$ cm3
--- building in I386_DARWIN ---

ignoring ../src/m3overri= >des

"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3= >makefile"=2C line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/= >I386_DARWIN/.M3EXPORTS" for reading

--procedure-- =3B -line-&nbs= >p=3B -file---
import =3B =3B =3B =3B =3B =3B&nbs= >p=3B =3B =3B =3B =3B =3B -- =3B <=3Bbuiltin>=3B= >
include_dir =3B =3B =3B =3B =3B =3B =3B&nbs= >p=3B 3 =3B /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src= >/m3makefile


 =3B- Jay






topSpelling">From: jay.krell at cornell.edu
To: mika at async.caltech.edu
D= >ate: Mon=2C 27 Dec 2010 10:46:55 +0000
CC: m3devel at elegosoft.com
Subj= >ect: Re: [M3devel] compiler problems on Snow Leopard

> >"> > > > > >aside: overlap with caltech_parser:
if you can come up with a merged ver= >sion that works with both=2C good
If you can't=2C I think you have to re= >name one or the other.

Maybe someday we can support some sort of hie= >rarchy that automatically maps to/from the file system hierarchy...

= >I'll try to reproduce the problem.

All targets?
Workaround with d= >ifferent cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?)

 =3B- Jay>

>=3B To: jay.krell at cornell.edu
>=3B Date: Mon=2C 27 Dec 201= >0 02:38:10 -0800
>=3B From: mika at async.caltech.edu
>=3B CC: m3dev= >el at elegosoft.com
>=3B Subject: Re: [M3devel] compiler problems on Snow= > Leopard
>=3B
>=3B Jay K writes:
>=3B >=3B--_6f82bcb2-663= >f-4046-87f2-073a1528a819_
>=3B >=3BContent-Type: text/plain=3B chars= >et=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encoding: quoted-printab= >le
>=3B >=3B
>=3B >=3B
>=3B >=3BCan you put all your c= >ode in our CVS repository?
>=3B >=3B
>=3B
>=3B I can't pu= >t all the code I work with in m3devel's repository: some of
>=3B it i= >s proprietary.
>=3B
>=3B The Scheme code however I have no restr= >ictions on distributing (that's
>=3B what's got problems in this case)= >. It is however large and unwieldy and
>=3B I'd like to have other pe= >ople's suggestions for how to submit/incorporate
>=3B it with CM3 befo= >re I just dump it in the repository. It also overlaps a bit
>=3B with= > "caltech-parser"=2C so there should probably be a "caltech-common"
>= >=3B package for the overlaps?
>=3B
>=3B If you run the following= > commands in a fresh directory=2C you should get
>=3B to the error I e= >mailed:
>=3B
>=3B setenv CM3 1
>=3B cvs -d :pserver:anonymo= >us at pluto.gcapltd.com:/home/gcap-public-cvs up -d .
>=3B make regress = > # GNU make : 'gmake regress' on BSD
>=3B cd mscheme/sstubgen/example= >
>=3B cm3 -x
>=3B
>=3B Mika
>=3B
>=3B
= > >= > >--_9ece0c56-2524-4879-9a65-2407b1dbf664_-- From jay.krell at cornell.edu Mon Dec 27 12:04:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 11:04:11 +0000 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <20101227105859.8E1F21A205B@async.async.caltech.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , , , <20101227103810.94DF21A205B@async.async.caltech.edu>, , <20101227105859.8E1F21A205B@async.async.caltech.edu> Message-ID: Yes, overrides and standalone is a problem. Maybe I'll get around to addressing this for the next release. A proposed solution is: go back to mostly the old method: hard coded runpaths, with much overlap for global builds (to be shipped/installed), monstrously long paths for local builds (not to be shipped), AND link upon install Some systems allow for "slight relinking", including Solaris and Darwin, where just the paths get edited. That would be nicer. The old approach had problems too. If you build the system yourself, I think you automatically already today get what is described -- hardcoded run paths, with much overlap for global builds. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] compiler problems on Snow Leopard > Date: Mon, 27 Dec 2010 02:58:59 -0800 > From: mika at async.caltech.edu > > Run cm3 -x instead of just cm3. > > Did you get an error compiling package "mscheme"? I certainly have a > libmscheme.a in there. > > /m3overrides has build_standalone() in it. > > I normally didn't use build_standalone() but something has changed in > how the system searches for shared libs when building with overrides > and this was the easiest solution (at least for now). > > Mika > > Jay K writes: > >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >I can't quite reproduce it=2C but I can compile a bunch of your code. > > > > > >new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-lib.a" = > >-> archiving libsstubgen.a > > > >=3D=3D=3D> mscheme/sstubgen/program > >--- building in I386_DARWIN --- > > > > -> linking sstubgen > >i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/lib= > >mscheme.a: No such file or directory > > m3_link =3D> 1 > >linker failed linking: sstubgen > >Fatal Error: package build failed > > > >jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example > >jbook2:example jay$ c=2C3 > >-bash: c=2C3: command not found > >jbook2:example jay$ cm3 > >--- building in I386_DARWIN --- > > > >ignoring ../src/m3overrides > > > >"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3makefile"= > >=2C line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/I386_DARW= > >IN/.M3EXPORTS" for reading > > > >--procedure-- -line- -file--- > >import -- > >include_dir 3 /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/exa= > >mple/src/m3makefile > > > > > > - Jay > > > > > > > > > > > > > >From: jay.krell at cornell.edu > >To: mika at async.caltech.edu > >Date: Mon=2C 27 Dec 2010 10:46:55 +0000 > >CC: m3devel at elegosoft.com > >Subject: Re: [M3devel] compiler problems on Snow Leopard > > > > > > > > > > > > > > > > > >aside: overlap with caltech_parser: > >if you can come up with a merged version that works with both=2C good > >If you can't=2C I think you have to rename one or the other. > > > >Maybe someday we can support some sort of hierarchy that automatically maps= > > to/from the file system hierarchy... > > > >I'll try to reproduce the problem. > > > >All targets? > >Workaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) > > > > - Jay > > > > > >> To: jay.krell at cornell.edu > >> Date: Mon=2C 27 Dec 2010 02:38:10 -0800 > >> From: mika at async.caltech.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] compiler problems on Snow Leopard > >>=20 > >> Jay K writes: > >> >--_6f82bcb2-663f-4046-87f2-073a1528a819_ > >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> >Can you put all your code in our CVS repository? > >> > > >>=20 > >> I can't put all the code I work with in m3devel's repository: some of=20 > >> it is proprietary. > >>=20 > >> The Scheme code however I have no restrictions on distributing (that's > >> what's got problems in this case). It is however large and unwieldy and > >> I'd like to have other people's suggestions for how to submit/incorporate > >> it with CM3 before I just dump it in the repository. It also overlaps a = > >bit > >> with "caltech-parser"=2C so there should probably be a "caltech-common" > >> package for the overlaps? > >>=20 > >> If you run the following commands in a fresh directory=2C you should get > >> to the error I emailed: > >>=20 > >> setenv CM3 1 > >> cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -d . > >> make regress # GNU make : 'gmake regress' on BSD > >> cd mscheme/sstubgen/example > >> cm3 -x > >>=20 > >> Mika > >>=20 > >>=20 > > = > > > >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >I can't quite reproduce it=2C but I can compile a bunch of your code.
>r>
new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-l= > >ib.a" ->=3B archiving libsstubgen.a

=3D=3D=3D>=3B mscheme/sstubg= > >en/program
--- building in I386_DARWIN ---

 =3B->=3B linkin= > >g sstubgen
i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I= > >386_DARWIN/libmscheme.a: No such file or directory
 =3B m3_link =3D&= > >gt=3B 1
linker failed linking: sstubgen
Fatal Error: package build fa= > >iled

jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example
jboo= > >k2:example jay$ c=2C3
-bash: c=2C3: command not found
jbook2:example = > >jay$ cm3
--- building in I386_DARWIN ---

ignoring ../src/m3overri= > >des

"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3= > >makefile"=2C line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/= > >I386_DARWIN/.M3EXPORTS" for reading

--procedure-- =3B -line-&nbs= > >p=3B -file---
import =3B =3B =3B =3B =3B =3B&nbs= > >p=3B =3B =3B =3B =3B =3B -- =3B <=3Bbuiltin>=3B= > >
include_dir =3B =3B =3B =3B =3B =3B =3B&nbs= > >p=3B 3 =3B /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src= > >/m3makefile


 =3B- Jay






>topSpelling">From: jay.krell at cornell.edu
To: mika at async.caltech.edu
D= > >ate: Mon=2C 27 Dec 2010 10:46:55 +0000
CC: m3devel at elegosoft.com
Subj= > >ect: Re: [M3devel] compiler problems on Snow Leopard

> > > > >"> > > > > > > > > > >aside: overlap with caltech_parser:
if you can come up with a merged ver= > >sion that works with both=2C good
If you can't=2C I think you have to re= > >name one or the other.

Maybe someday we can support some sort of hie= > >rarchy that automatically maps to/from the file system hierarchy...

= > >I'll try to reproduce the problem.

All targets?
Workaround with d= > >ifferent cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?)

 =3B- Jay >>

>=3B To: jay.krell at cornell.edu
>=3B Date: Mon=2C 27 Dec 201= > >0 02:38:10 -0800
>=3B From: mika at async.caltech.edu
>=3B CC: m3dev= > >el at elegosoft.com
>=3B Subject: Re: [M3devel] compiler problems on Snow= > > Leopard
>=3B
>=3B Jay K writes:
>=3B >=3B--_6f82bcb2-663= > >f-4046-87f2-073a1528a819_
>=3B >=3BContent-Type: text/plain=3B chars= > >et=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encoding: quoted-printab= > >le
>=3B >=3B
>=3B >=3B
>=3B >=3BCan you put all your c= > >ode in our CVS repository?
>=3B >=3B
>=3B
>=3B I can't pu= > >t all the code I work with in m3devel's repository: some of
>=3B it i= > >s proprietary.
>=3B
>=3B The Scheme code however I have no restr= > >ictions on distributing (that's
>=3B what's got problems in this case)= > >. It is however large and unwieldy and
>=3B I'd like to have other pe= > >ople's suggestions for how to submit/incorporate
>=3B it with CM3 befo= > >re I just dump it in the repository. It also overlaps a bit
>=3B with= > > "caltech-parser"=2C so there should probably be a "caltech-common"
>= > >=3B package for the overlaps?
>=3B
>=3B If you run the following= > > commands in a fresh directory=2C you should get
>=3B to the error I e= > >mailed:
>=3B
>=3B setenv CM3 1
>=3B cvs -d :pserver:anonymo= > >us at pluto.gcapltd.com:/home/gcap-public-cvs up -d .
>=3B make regress = > > # GNU make : 'gmake regress' on BSD
>=3B cd mscheme/sstubgen/example= > >
>=3B cm3 -x
>=3B
>=3B Mika
>=3B
>=3B
= > > > >= > > > >--_9ece0c56-2524-4879-9a65-2407b1dbf664_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 27 12:16:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 11:16:00 +0000 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>,,, , <20101227101421.38A6A1A205B@async.async.caltech.edu>, ,,, , , <20101227103810.94DF21A205B@async.async.caltech.edu>, , , , , <20101227105859.8E1F21A205B@async.async.caltech.edu>, Message-ID: something wanted cit_util. --- building in AMD64_DARWIN --- ignoring ../src/m3overrides "/Users/jay/dev2/gcap-public-cvs/cit_util/src/texthack.tmpl", line 2: quake runtime error: undefined variable: TOP --procedure-- -line- -file--- template 2 /Users/jay/dev2/gcap-public-cvs/cit_util/src/texthack.tmpl include_dir 13 /Users/jay/dev2/gcap-public-cvs/cit_util/src/m3makefile 4 /Users/jay/dev2/gcap-public-cvs/cit_util/AMD64_DARWIN/m3make.args % $Id: texthack.tmpl,v 1.7 2002/12/13 22:20:12 kp Exp $ _M3TEXTHACK = TOP & "/m3texthack/" & BUILD_DIR & "/m3texthack" _DERIVGEN = TOP & "/m3texthack/src/derivgen.sh" I don't have m3texthack anywhere I think. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu Date: Mon, 27 Dec 2010 11:04:11 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] compiler problems on Snow Leopard Yes, overrides and standalone is a problem. Maybe I'll get around to addressing this for the next release. A proposed solution is: go back to mostly the old method: hard coded runpaths, with much overlap for global builds (to be shipped/installed), monstrously long paths for local builds (not to be shipped), AND link upon install Some systems allow for "slight relinking", including Solaris and Darwin, where just the paths get edited. That would be nicer. The old approach had problems too. If you build the system yourself, I think you automatically already today get what is described -- hardcoded run paths, with much overlap for global builds. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] compiler problems on Snow Leopard > Date: Mon, 27 Dec 2010 02:58:59 -0800 > From: mika at async.caltech.edu > > Run cm3 -x instead of just cm3. > > Did you get an error compiling package "mscheme"? I certainly have a > libmscheme.a in there. > > /m3overrides has build_standalone() in it. > > I normally didn't use build_standalone() but something has changed in > how the system searches for shared libs when building with overrides > and this was the easiest solution (at least for now). > > Mika > > Jay K writes: > >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >I can't quite reproduce it=2C but I can compile a bunch of your code. > > > > > >new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-lib.a" = > >-> archiving libsstubgen.a > > > >=3D=3D=3D> mscheme/sstubgen/program > >--- building in I386_DARWIN --- > > > > -> linking sstubgen > >i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/lib= > >mscheme.a: No such file or directory > > m3_link =3D> 1 > >linker failed linking: sstubgen > >Fatal Error: package build failed > > > >jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example > >jbook2:example jay$ c=2C3 > >-bash: c=2C3: command not found > >jbook2:example jay$ cm3 > >--- building in I386_DARWIN --- > > > >ignoring ../src/m3overrides > > > >"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3makefile"= > >=2C line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/I386_DARW= > >IN/.M3EXPORTS" for reading > > > >--procedure-- -line- -file--- > >import -- > >include_dir 3 /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/exa= > >mple/src/m3makefile > > > > > > - Jay > > > > > > > > > > > > > >From: jay.krell at cornell.edu > >To: mika at async.caltech.edu > >Date: Mon=2C 27 Dec 2010 10:46:55 +0000 > >CC: m3devel at elegosoft.com > >Subject: Re: [M3devel] compiler problems on Snow Leopard > > > > > > > > > > > > > > > > > >aside: overlap with caltech_parser: > >if you can come up with a merged version that works with both=2C good > >If you can't=2C I think you have to rename one or the other. > > > >Maybe someday we can support some sort of hierarchy that automatically maps= > > to/from the file system hierarchy... > > > >I'll try to reproduce the problem. > > > >All targets? > >Workaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) > > > > - Jay > > > > > >> To: jay.krell at cornell.edu > >> Date: Mon=2C 27 Dec 2010 02:38:10 -0800 > >> From: mika at async.caltech.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] compiler problems on Snow Leopard > >>=20 > >> Jay K writes: > >> >--_6f82bcb2-663f-4046-87f2-073a1528a819_ > >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> >Can you put all your code in our CVS repository? > >> > > >>=20 > >> I can't put all the code I work with in m3devel's repository: some of=20 > >> it is proprietary. > >>=20 > >> The Scheme code however I have no restrictions on distributing (that's > >> what's got problems in this case). It is however large and unwieldy and > >> I'd like to have other people's suggestions for how to submit/incorporate > >> it with CM3 before I just dump it in the repository. It also overlaps a = > >bit > >> with "caltech-parser"=2C so there should probably be a "caltech-common" > >> package for the overlaps? > >>=20 > >> If you run the following commands in a fresh directory=2C you should get > >> to the error I emailed: > >>=20 > >> setenv CM3 1 > >> cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -d . > >> make regress # GNU make : 'gmake regress' on BSD > >> cd mscheme/sstubgen/example > >> cm3 -x > >>=20 > >> Mika > >>=20 > >>=20 > > = > > > >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >I can't quite reproduce it=2C but I can compile a bunch of your code.
>r>
new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-l= > >ib.a" ->=3B archiving libsstubgen.a

=3D=3D=3D>=3B mscheme/sstubg= > >en/program
--- building in I386_DARWIN ---

 =3B->=3B linkin= > >g sstubgen
i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I= > >386_DARWIN/libmscheme.a: No such file or directory
 =3B m3_link =3D&= > >gt=3B 1
linker failed linking: sstubgen
Fatal Error: package build fa= > >iled

jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example
jboo= > >k2:example jay$ c=2C3
-bash: c=2C3: command not found
jbook2:example = > >jay$ cm3
--- building in I386_DARWIN ---

ignoring ../src/m3overri= > >des

"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3= > >makefile"=2C line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/= > >I386_DARWIN/.M3EXPORTS" for reading

--procedure-- =3B -line-&nbs= > >p=3B -file---
import =3B =3B =3B =3B =3B =3B&nbs= > >p=3B =3B =3B =3B =3B =3B -- =3B <=3Bbuiltin>=3B= > >
include_dir =3B =3B =3B =3B =3B =3B =3B&nbs= > >p=3B 3 =3B /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src= > >/m3makefile


 =3B- Jay






>topSpelling">From: jay.krell at cornell.edu
To: mika at async.caltech.edu
D= > >ate: Mon=2C 27 Dec 2010 10:46:55 +0000
CC: m3devel at elegosoft.com
Subj= > >ect: Re: [M3devel] compiler problems on Snow Leopard

> > > > >"> > > > > > > > > > >aside: overlap with caltech_parser:
if you can come up with a merged ver= > >sion that works with both=2C good
If you can't=2C I think you have to re= > >name one or the other.

Maybe someday we can support some sort of hie= > >rarchy that automatically maps to/from the file system hierarchy...

= > >I'll try to reproduce the problem.

All targets?
Workaround with d= > >ifferent cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?)

 =3B- Jay >>

>=3B To: jay.krell at cornell.edu
>=3B Date: Mon=2C 27 Dec 201= > >0 02:38:10 -0800
>=3B From: mika at async.caltech.edu
>=3B CC: m3dev= > >el at elegosoft.com
>=3B Subject: Re: [M3devel] compiler problems on Snow= > > Leopard
>=3B
>=3B Jay K writes:
>=3B >=3B--_6f82bcb2-663= > >f-4046-87f2-073a1528a819_
>=3B >=3BContent-Type: text/plain=3B chars= > >et=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encoding: quoted-printab= > >le
>=3B >=3B
>=3B >=3B
>=3B >=3BCan you put all your c= > >ode in our CVS repository?
>=3B >=3B
>=3B
>=3B I can't pu= > >t all the code I work with in m3devel's repository: some of
>=3B it i= > >s proprietary.
>=3B
>=3B The Scheme code however I have no restr= > >ictions on distributing (that's
>=3B what's got problems in this case)= > >. It is however large and unwieldy and
>=3B I'd like to have other pe= > >ople's suggestions for how to submit/incorporate
>=3B it with CM3 befo= > >re I just dump it in the repository. It also overlaps a bit
>=3B with= > > "caltech-parser"=2C so there should probably be a "caltech-common"
>= > >=3B package for the overlaps?
>=3B
>=3B If you run the following= > > commands in a fresh directory=2C you should get
>=3B to the error I e= > >mailed:
>=3B
>=3B setenv CM3 1
>=3B cvs -d :pserver:anonymo= > >us at pluto.gcapltd.com:/home/gcap-public-cvs up -d .
>=3B make regress = > > # GNU make : 'gmake regress' on BSD
>=3B cd mscheme/sstubgen/example= > >
>=3B cm3 -x
>=3B
>=3B Mika
>=3B
>=3B
= > > > >= > > > >--_9ece0c56-2524-4879-9a65-2407b1dbf664_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Dec 27 12:24:24 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Dec 2010 03:24:24 -0800 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , , , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , , , , , <20101227103810.94DF21A205B@async.async.caltech.edu>, , , , , <20101227105859.8E1F21A205B@async.async.caltech.edu>, Message-ID: <20101227112424.C13401A205B@async.async.caltech.edu> Don't think you need m3texthack. The first thing that happens when you run make ought to be that a file called ".top" is created at the top level of the repository, with a definition of TOP. This file is included by the top-level m3overrides, which is included by every m3overrides when you run with -x. Mika Jay K writes: >--_d61e805f-545e-4b3d-abe7-a20c582bec2e_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >something wanted cit_util. > > > >--- building in AMD64_DARWIN --- > > > >ignoring ../src/m3overrides > > > >"/Users/jay/dev2/gcap-public-cvs/cit_util/src/texthack.tmpl"=2C line 2: qua= >ke runtime error: undefined variable: TOP > > > >--procedure-- -line- -file--- > >template 2 /Users/jay/dev2/gcap-public-cvs/cit_util/src/texthac= >k.tmpl > >include_dir 13 /Users/jay/dev2/gcap-public-cvs/cit_util/src/m3makef= >ile > > 4 /Users/jay/dev2/gcap-public-cvs/cit_util/AMD64_DARWI= >N/m3make.args > > > > > >% $Id: texthack.tmpl=2Cv 1.7 2002/12/13 22:20:12 kp Exp $ > >_M3TEXTHACK =3D TOP & "/m3texthack/" & BUILD_DIR & "/m3texthack" > >_DERIVGEN =3D TOP & "/m3texthack/src/derivgen.sh" > > >I don't have m3texthack anywhere I think. > > - Jay > >From: jay.krell at cornell.edu >To: mika at async.caltech.edu >Date: Mon=2C 27 Dec 2010 11:04:11 +0000 >CC: m3devel at elegosoft.com >Subject: Re: [M3devel] compiler problems on Snow Leopard > > > > > > > > >Yes=2C overrides and standalone is a problem. > >Maybe I'll get around to addressing this for the next release. > >A proposed solution is: > go back to mostly the old method: hard coded runpaths=2C with much overla= >p for global builds (to be shipped/installed)=2C monstrously long paths for= > local builds (not to be shipped)=2C AND link upon install > Some systems allow for "slight relinking"=2C including Solaris and Darwin= >=2C where just the paths get edited. That would be nicer. > > The old approach had problems too. > > If you build the system yourself=2C I think you automatically already to= >day get what is described -- hardcoded run paths=2C with much overlap for g= >lobal builds. > > > - Jay > >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] compiler problems on Snow Leopard=20 >> Date: Mon=2C 27 Dec 2010 02:58:59 -0800 >> From: mika at async.caltech.edu >>=20 >> Run cm3 -x instead of just cm3. >>=20 >> Did you get an error compiling package "mscheme"? I certainly have a >> libmscheme.a in there. >>=20 >> /m3overrides has build_standalone() in it. >>=20 >> I normally didn't use build_standalone() but something has changed in >> how the system searches for shared libs when building with overrides >> and this was the easiest solution (at least for now). >>=20 >> Mika >>=20 >> Jay K writes: >> >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> >I can't quite reproduce it=3D2C but I can compile a bunch of your code. >> > >> > >> >new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-lib.= >a" =3D >> >-> archiving libsstubgen.a >> > >> >=3D3D=3D3D=3D3D> mscheme/sstubgen/program >> >--- building in I386_DARWIN --- >> > >> > -> linking sstubgen >> >i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/= >lib=3D >> >mscheme.a: No such file or directory >> > m3_link =3D3D> 1 >> >linker failed linking: sstubgen >> >Fatal Error: package build failed >> > >> >jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example >> >jbook2:example jay$ c=3D2C3 >> >-bash: c=3D2C3: command not found >> >jbook2:example jay$ cm3 >> >--- building in I386_DARWIN --- >> > >> >ignoring ../src/m3overrides >> > >> >"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3makefile= >"=3D >> >=3D2C line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/I386= >_DARW=3D >> >IN/.M3EXPORTS" for reading >> > >> >--procedure-- -line- -file--- >> >import -- >> >include_dir 3 /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/= >exa=3D >> >mple/src/m3makefile >> > >> > >> > - Jay >> > >> > >> > >> > >> > >> > >> >From: jay.krell at cornell.edu >> >To: mika at async.caltech.edu >> >Date: Mon=3D2C 27 Dec 2010 10:46:55 +0000 >> >CC: m3devel at elegosoft.com >> >Subject: Re: [M3devel] compiler problems on Snow Leopard >> > >> > >> > >> > >> > >> > >> > >> > >> >aside: overlap with caltech_parser: >> >if you can come up with a merged version that works with both=3D2C good >> >If you can't=3D2C I think you have to rename one or the other. >> > >> >Maybe someday we can support some sort of hierarchy that automatically m= >aps=3D >> > to/from the file system hierarchy... >> > >> >I'll try to reproduce the problem. >> > >> >All targets? >> >Workaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) >> > >> > - Jay >> > >> > >> >> To: jay.krell at cornell.edu >> >> Date: Mon=3D2C 27 Dec 2010 02:38:10 -0800 >> >> From: mika at async.caltech.edu >> >> CC: m3devel at elegosoft.com >> >> Subject: Re: [M3devel] compiler problems on Snow Leopard >> >>=3D20 >> >> Jay K writes: >> >> >--_6f82bcb2-663f-4046-87f2-073a1528a819_ >> >> >Content-Type: text/plain=3D3B charset=3D3D"iso-8859-1" >> >> >Content-Transfer-Encoding: quoted-printable >> >> > >> >> > >> >> >Can you put all your code in our CVS repository? >> >> > >> >>=3D20 >> >> I can't put all the code I work with in m3devel's repository: some of= >=3D20 >> >> it is proprietary. >> >>=3D20 >> >> The Scheme code however I have no restrictions on distributing (that's >> >> what's got problems in this case). It is however large and unwieldy a= >nd >> >> I'd like to have other people's suggestions for how to submit/incorpor= >ate >> >> it with CM3 before I just dump it in the repository. It also overlaps= > a =3D >> >bit >> >> with "caltech-parser"=3D2C so there should probably be a "caltech-comm= >on" >> >> package for the overlaps? >> >>=3D20 >> >> If you run the following commands in a fresh directory=3D2C you should= > get >> >> to the error I emailed: >> >>=3D20 >> >> setenv CM3 1 >> >> cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -= >d . >> >> make regress # GNU make : 'gmake regress' on BSD >> >> cd mscheme/sstubgen/example >> >> cm3 -x >> >>=3D20 >> >> Mika >> >>=3D20 >> >>=3D20 >> > =3D >> > >> >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ >> >Content-Type: text/html=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> > >> > >> > >> > >> >I can't quite reproduce it=3D2C but I can compile a bunch of your code.<= >br>> >r>
new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libschem= >e-l=3D >> >ib.a" ->=3D3B archiving libsstubgen.a

=3D3D=3D3D=3D3D>=3D3B m= >scheme/sstubg=3D >> >en/program
--- building in I386_DARWIN ---

 =3D3B->=3D3B= > linkin=3D >> >g sstubgen
i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mschem= >e/I=3D >> >386_DARWIN/libmscheme.a: No such file or directory
 =3D3B m3_link= > =3D3D&=3D >> >gt=3D3B 1
linker failed linking: sstubgen
Fatal Error: package bui= >ld fa=3D >> >iled

jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example
j= >boo=3D >> >k2:example jay$ c=3D2C3
-bash: c=3D2C3: command not found
jbook2:e= >xample =3D >> >jay$ cm3
--- building in I386_DARWIN ---

ignoring ../src/m3ove= >rri=3D >> >des

"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src= >/m3=3D >> >makefile"=3D2C line 3: quake runtime error: unable to open "/cm3/pkg/msc= >heme/=3D >> >I386_DARWIN/.M3EXPORTS" for reading

--procedure-- =3D3B -line= >-&nbs=3D >> >p=3D3B -file---
import =3D3B =3D3B =3D3B =3D3B = >=3D3B =3D3B&nbs=3D >> >p=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B -- =3D3B &l= >t=3D3Bbuiltin>=3D3B=3D >> >
include_dir =3D3B =3D3B =3D3B =3D3B =3D3B = >=3D3B =3D3B&nbs=3D >> >p=3D3B 3 =3D3B /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/exam= >ple/src=3D >> >/m3makefile


 =3D3B- Jay






=3D3D"s=3D >> >topSpelling">From: jay.krell at cornell.edu
To: mika at async.caltech.edur>D=3D >> >ate: Mon=3D2C 27 Dec 2010 10:46:55 +0000
CC: m3devel at elegosoft.com>Subj=3D >> >ect: Re: [M3devel] compiler problems on Snow Leopard

>> > >> >=3D3Dunicode=3D >> >"> >> > >> > >> > >> > >> >aside: overlap with caltech_parser:
if you can come up with a merged = >ver=3D >> >sion that works with both=3D2C good
If you can't=3D2C I think you hav= >e to re=3D >> >name one or the other.

Maybe someday we can support some sort of = >hie=3D >> >rarchy that automatically maps to/from the file system hierarchy...
<= >br>=3D >> >I'll try to reproduce the problem.

All targets?
Workaround wit= >h d=3D >> >ifferent cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?)

 =3D3B- J= >ay> >>

>=3D3B To: jay.krell at cornell.edu
>=3D3B Date: Mon=3D2C 2= >7 Dec 201=3D >> >0 02:38:10 -0800
>=3D3B From: mika at async.caltech.edu
>=3D3B CC= >: m3dev=3D >> >el at elegosoft.com
>=3D3B Subject: Re: [M3devel] compiler problems on= > Snow=3D >> > Leopard
>=3D3B
>=3D3B Jay K writes:
>=3D3B >=3D3B--_6= >f82bcb2-663=3D >> >f-4046-87f2-073a1528a819_
>=3D3B >=3D3BContent-Type: text/plain= >=3D3B chars=3D >> >et=3D3D"iso-8859-1"
>=3D3B >=3D3BContent-Transfer-Encoding: quote= >d-printab=3D >> >le
>=3D3B >=3D3B
>=3D3B >=3D3B
>=3D3B >=3D3BCan you= > put all your c=3D >> >ode in our CVS repository?
>=3D3B >=3D3B
>=3D3B
>=3D3B= > I can't pu=3D >> >t all the code I work with in m3devel's repository: some of
>=3D3B= > it i=3D >> >s proprietary.
>=3D3B
>=3D3B The Scheme code however I have n= >o restr=3D >> >ictions on distributing (that's
>=3D3B what's got problems in this = >case)=3D >> >. It is however large and unwieldy and
>=3D3B I'd like to have oth= >er pe=3D >> >ople's suggestions for how to submit/incorporate
>=3D3B it with CM3= > befo=3D >> >re I just dump it in the repository. It also overlaps a bit
>=3D3B= > with=3D >> > "caltech-parser"=3D2C so there should probably be a "caltech-common">>=3D >> >=3D3B package for the overlaps?
>=3D3B
>=3D3B If you run the = >following=3D >> > commands in a fresh directory=3D2C you should get
>=3D3B to the er= >ror I e=3D >> >mailed:
>=3D3B
>=3D3B setenv CM3 1
>=3D3B cvs -d :pserve= >r:anonymo=3D >> >us at pluto.gcapltd.com:/home/gcap-public-cvs up -d .
>=3D3B make regr= >ess =3D >> > # GNU make : 'gmake regress' on BSD
>=3D3B cd mscheme/sstubgen/ex= >ample=3D >> >
>=3D3B cm3 -x
>=3D3B
>=3D3B Mika
>=3D3B
&= >gt=3D3B
=3D >> > >> >=3D >> > >> >--_9ece0c56-2524-4879-9a65-2407b1dbf664_-- > = > >--_d61e805f-545e-4b3d-abe7-a20c582bec2e_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >something wanted cit_util.
>
>--- building in AMD64_DARWIN ---
>
>ignoring ../src/m3overrides
>
>"/Users/jay/dev2/gcap-public-cvs/cit_util/src/texthack.tmpl"=2C line 2: qua= >ke runtime error: undefined variable: TOP
>
>--procedure-- =3B -line- =3B -file---
>template =3B =3B =3B =3B =3B =3B =3B =3B&nb= >sp=3B =3B =3B 2 =3B /Users/jay/dev2/gcap-public-cvs/cit_util/sr= >c/texthack.tmpl
>include_dir =3B =3B =3B =3B =3B =3B =3B 13 = >=3B /Users/jay/dev2/gcap-public-cvs/cit_util/src/m3makefile
> =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= >sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = >=3B 4 =3B /Users/jay/dev2/gcap-public-cvs/cit_util/AMD64_DARWIN/m3make.= >args
>
>
>% $Id: texthack.tmpl=2Cv 1.7 2002/12/13 22:20:12 kp Exp $
>_M3TEXTHACK =3D TOP &=3B "/m3texthack/" &=3B BUILD_DIR &=3B "/m3te= >xthack"
>_DERIVGEN =3B =3B =3D TOP &=3B "/m3texthack/src/derivgen.sh"
>
I don't have m3texthack anywhere I think.

 =3B- Jay

<= >hr id=3D"stopSpelling">From: jay.krell at cornell.edu
To: mika at async.caltec= >h.edu
Date: Mon=2C 27 Dec 2010 11:04:11 +0000
CC: m3devel at elegosoft.c= >om
Subject: Re: [M3devel] compiler problems on Snow Leopard

> >"> > > > > >Yes=2C overrides and standalone is a problem.

Maybe I'll get around = >to addressing this for the next release.

A proposed solution is:
= > =3B go back to mostly the old method: hard coded runpaths=2C with much= > overlap for global builds (to be shipped/installed)=2C monstrously long pa= >ths for local builds (not to be shipped)=2C AND link upon install
 = >=3B Some systems allow for "slight relinking"=2C including Solaris and Darw= >in=2C where just the paths get edited. That would be nicer.

 =3B= > The old approach had problems too.

 =3B =3B If you build th= >e system yourself=2C I think you automatically already today get what is de= >scribed -- hardcoded run paths=2C with much overlap for global builds.
<= >br>
 =3B- Jay

>=3B To: jay.krell at cornell.edu
>=3B CC: = >m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] compiler problems on= > Snow Leopard
>=3B Date: Mon=2C 27 Dec 2010 02:58:59 -0800
>=3B = >From: mika at async.caltech.edu
>=3B
>=3B Run cm3 -x instead of jus= >t cm3.
>=3B
>=3B Did you get an error compiling package "mscheme= >"? I certainly have a
>=3B libmscheme.a in there.
>=3B
>= >=3B <=3Btop>=3B/m3overrides has build_standalone() in it.
>=3B >>=3B I normally didn't use build_standalone() but something has changed = >in
>=3B how the system searches for shared libs when building with ove= >rrides
>=3B and this was the easiest solution (at least for now).
&= >gt=3B
>=3B Mika
>=3B
>=3B Jay K writes:
>=3B >= >=3B--_9ece0c56-2524-4879-9a65-2407b1dbf664_
>=3B >=3BContent-Type: t= >ext/plain=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encodi= >ng: quoted-printable
>=3B >=3B
>=3B >=3B
>=3B >=3BI ca= >n't quite reproduce it=3D2C but I can compile a bunch of your code.
>= >=3B >=3B
>=3B >=3B
>=3B >=3Bnew "/dev2/gcap-public-cvs/msch= >eme/scheme-lib/I386_DARWIN/libscheme-lib.a" =3D
>=3B >=3B->=3B arc= >hiving libsstubgen.a
>=3B >=3B
>=3B >=3B=3D3D=3D3D=3D3D>=3B= > mscheme/sstubgen/program
>=3B >=3B--- building in I386_DARWIN ---r>>=3B >=3B
>=3B >=3B ->=3B linking sstubgen
>=3B >=3Bi= >686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/lib= >=3D
>=3B >=3Bmscheme.a: No such file or directory
>=3B >=3B = >m3_link =3D3D>=3B 1
>=3B >=3Blinker failed linking: sstubgen
&g= >t=3B >=3BFatal Error: package build failed
>=3B >=3B
>=3B >= >=3Bjbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example
>=3B >=3B= >jbook2:example jay$ c=3D2C3
>=3B >=3B-bash: c=3D2C3: command not fou= >nd
>=3B >=3Bjbook2:example jay$ cm3
>=3B >=3B--- building in = >I386_DARWIN ---
>=3B >=3B
>=3B >=3Bignoring ../src/m3override= >s
>=3B >=3B
>=3B >=3B"/Users/jay/dev2/gcap-public-cvs/mscheme= >/sstubgen/example/src/m3makefile"=3D
>=3B >=3B=3D2C line 3: quake ru= >ntime error: unable to open "/cm3/pkg/mscheme/I386_DARW=3D
>=3B >=3B= >IN/.M3EXPORTS" for reading
>=3B >=3B
>=3B >=3B--procedure-- = >-line- -file---
>=3B >=3Bimport -- <=3Bbuiltin>=3B= >
>=3B >=3Binclude_dir 3 /Users/jay/dev2/gcap-public-cvs/msc= >heme/sstubgen/exa=3D
>=3B >=3Bmple/src/m3makefile
>=3B >=3Br>>=3B >=3B
>=3B >=3B - Jay
>=3B >=3B
>=3B >=3B>>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B= > >=3BFrom: jay.krell at cornell.edu
>=3B >=3BTo: mika at async.caltech.e= >du
>=3B >=3BDate: Mon=3D2C 27 Dec 2010 10:46:55 +0000
>=3B >= >=3BCC: m3devel at elegosoft.com
>=3B >=3BSubject: Re: [M3devel] compile= >r problems on Snow Leopard
>=3B >=3B
>=3B >=3B
>=3B >= >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
= >>=3B >=3B
>=3B >=3Baside: overlap with caltech_parser:
>=3B= > >=3Bif you can come up with a merged version that works with both=3D2C g= >ood
>=3B >=3BIf you can't=3D2C I think you have to rename one or the= > other.
>=3B >=3B
>=3B >=3BMaybe someday we can support some = >sort of hierarchy that automatically maps=3D
>=3B >=3B to/from the f= >ile system hierarchy...
>=3B >=3B
>=3B >=3BI'll try to reprod= >uce the problem.
>=3B >=3B
>=3B >=3BAll targets?
>=3B &g= >t=3BWorkaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?)>>=3B >=3B
>=3B >=3B - Jay
>=3B >=3B
>=3B >=3B
= >>=3B >=3B>=3B To: jay.krell at cornell.edu
>=3B >=3B>=3B Date: = >Mon=3D2C 27 Dec 2010 02:38:10 -0800
>=3B >=3B>=3B From: mika at async= >.caltech.edu
>=3B >=3B>=3B CC: m3devel at elegosoft.com
>=3B >= >=3B>=3B Subject: Re: [M3devel] compiler problems on Snow Leopard
>= >=3B >=3B>=3B=3D20
>=3B >=3B>=3B Jay K writes:
>=3B >=3B= >>=3B >=3B--_6f82bcb2-663f-4046-87f2-073a1528a819_
>=3B >=3B>= >=3B >=3BContent-Type: text/plain=3D3B charset=3D3D"iso-8859-1"
>=3B = >>=3B>=3B >=3BContent-Transfer-Encoding: quoted-printable
>=3B &g= >t=3B>=3B >=3B
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= >=3BCan you put all your code in our CVS repository?
>=3B >=3B>=3B = >>=3B
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B I can't put all t= >he code I work with in m3devel's repository: some of=3D20
>=3B >=3B&= >gt=3B it is proprietary.
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B= > The Scheme code however I have no restrictions on distributing (that's
= >>=3B >=3B>=3B what's got problems in this case). It is however large= > and unwieldy and
>=3B >=3B>=3B I'd like to have other people's su= >ggestions for how to submit/incorporate
>=3B >=3B>=3B it with CM3 = >before I just dump it in the repository. It also overlaps a =3D
>=3B = >>=3Bbit
>=3B >=3B>=3B with "caltech-parser"=3D2C so there should= > probably be a "caltech-common"
>=3B >=3B>=3B package for the over= >laps?
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B If you run the fol= >lowing commands in a fresh directory=3D2C you should get
>=3B >=3B&g= >t=3B to the error I emailed:
>=3B >=3B>=3B=3D20
>=3B >=3B&g= >t=3B setenv CM3 1
>=3B >=3B>=3B cvs -d :pserver:anonymous at pluto.gc= >apltd.com:/home/gcap-public-cvs up -d .
>=3B >=3B>=3B make regress= > # GNU make : 'gmake regress' on BSD
>=3B >=3B>=3B cd mscheme/s= >stubgen/example
>=3B >=3B>=3B cm3 -x
>=3B >=3B>=3B=3D20r>>=3B >=3B>=3B Mika
>=3B >=3B>=3B=3D20
>=3B >= >=3B>=3B=3D20
>=3B >=3B =3Dr>>=3B >=3B
>=3B &= >gt=3B--_9ece0c56-2524-4879-9a65-2407b1dbf664_
>=3B >=3BContent-Type:= > text/html=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encod= >ing: quoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>=3B
= >>=3B >=3B<=3Bhead>=3B
>=3B >=3B<=3Bstyle>=3B<=3B!-->>=3B >=3B.hmmessage P
>=3B >=3B{
>=3B >=3Bmargin:0px=3D3= >B
>=3B >=3Bpadding:0px
>=3B >=3B}
>=3B >=3Bbody.hmmess= >age
>=3B >=3B{
>=3B >=3Bfont-size: 10pt=3D3B
>=3B >=3B= >font-family:Tahoma
>=3B >=3B}
>=3B >=3B-->=3B<=3B/style&g= >t=3B
>=3B >=3B<=3B/head>=3B
>=3B >=3B<=3Bbody class=3D3= >D'hmmessage'>=3B
>=3B >=3BI can't quite reproduce it=3D2C but I ca= >n compile a bunch of your code.<=3Bbr>=3B<=3Bb=3D
>=3B >=3Br&g= >t=3B<=3Bbr>=3Bnew "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN= >/libscheme-l=3D
>=3B >=3Bib.a" -&=3Bgt=3D3B archiving libsstubgen= >.a<=3Bbr>=3B<=3Bbr>=3B=3D3D=3D3D=3D3D&=3Bgt=3D3B mscheme/sstubg= >=3D
>=3B >=3Ben/program<=3Bbr>=3B--- building in I386_DARWIN ---= ><=3Bbr>=3B<=3Bbr>=3B&=3Bnbsp=3D3B-&=3Bgt=3D3B linkin=3D
&g= >t=3B >=3Bg sstubgen<=3Bbr>=3Bi686-apple-darwin9-gcc-4.0.1: /dev2/gcap= >-public-cvs/mscheme/I=3D
>=3B >=3B386_DARWIN/libmscheme.a: No such f= >ile or directory<=3Bbr>=3B&=3Bnbsp=3D3B m3_link =3D3D&=3B=3D
&= >gt=3B >=3Bgt=3D3B 1<=3Bbr>=3Blinker failed linking: sstubgen<=3Bbr&= >gt=3BFatal Error: package build fa=3D
>=3B >=3Biled<=3Bbr>=3B<= >=3Bbr>=3Bjbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example<=3Bbr&= >gt=3Bjboo=3D
>=3B >=3Bk2:example jay$ c=3D2C3<=3Bbr>=3B-bash: c= >=3D2C3: command not found<=3Bbr>=3Bjbook2:example =3D
>=3B >=3Bj= >ay$ cm3<=3Bbr>=3B--- building in I386_DARWIN ---<=3Bbr>=3B<=3Bbr&= >gt=3Bignoring ../src/m3overri=3D
>=3B >=3Bdes<=3Bbr>=3B<=3Bbr&= >gt=3B"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3=3D>>=3B >=3Bmakefile"=3D2C line 3: quake runtime error: unable to open "/= >cm3/pkg/mscheme/=3D
>=3B >=3BI386_DARWIN/.M3EXPORTS" for reading<= >=3Bbr>=3B<=3Bbr>=3B--procedure--&=3Bnbsp=3D3B -line-&=3Bnbs=3D<= >br>>=3B >=3Bp=3D3B -file---<=3Bbr>=3Bimport&=3Bnbsp=3D3B&=3Bn= >bsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&am= >p=3Bnbs=3D
>=3B >=3Bp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbs= >p=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B --&=3Bnbsp=3D3B &=3Blt=3D3Bbui= >ltin&=3Bgt=3D3B=3D
>=3B >=3B<=3Bbr>=3Binclude_dir&=3Bnbsp= >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&= >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbs=3D
>=3B >=3Bp=3D3B 3&=3Bnb= >sp=3D3B /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src=3D
= >>=3B >=3B/m3makefile<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B&=3Bnb= >sp=3D3B- Jay<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bb= >r>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bhr id=3D3D"s=3D
>=3B >=3Bto= >pSpelling">=3BFrom: jay.krell at cornell.edu<=3Bbr>=3BTo: mika at async.cal= >tech.edu<=3Bbr>=3BD=3D
>=3B >=3Bate: Mon=3D2C 27 Dec 2010 10:46:= >55 +0000<=3Bbr>=3BCC: m3devel at elegosoft.com<=3Bbr>=3BSubj=3D
>= >=3B >=3Bect: Re: [M3devel] compiler problems on Snow Leopard<=3Bbr>= >=3B<=3Bbr>=3B
>=3B >=3B
>=3B >=3B<=3Bmeta http-equiv=3D= >3D"Content-Type" content=3D3D"text/html=3D3B charset=3D3Dunicode=3D
>= >=3B >=3B">=3B
>=3B >=3B<=3Bmeta name=3D3D"Generator" content= >=3D3D"Microsoft SafeHTML">=3B
>=3B >=3B<=3Bstyle>=3B
>=3B= > >=3B.ExternalClass .ecxhmmessage P
>=3B >=3B{padding:0px=3D3B}>>=3B >=3B.ExternalClass body.ecxhmmessage
>=3B >=3B{font-size:1= >0pt=3D3Bfont-family:Tahoma=3D3B}
>=3B >=3B
>=3B >=3B<=3B/st= >yle>=3B
>=3B >=3B
>=3B >=3B
>=3B >=3Baside: overlap = >with caltech_parser:<=3Bbr>=3Bif you can come up with a merged ver=3Dr>>=3B >=3Bsion that works with both=3D2C good<=3Bbr>=3BIf you can'= >t=3D2C I think you have to re=3D
>=3B >=3Bname one or the other.<= >=3Bbr>=3B<=3Bbr>=3BMaybe someday we can support some sort of hie=3Dr>>=3B >=3Brarchy that automatically maps to/from the file system hiera= >rchy...<=3Bbr>=3B<=3Bbr>=3B=3D
>=3B >=3BI'll try to reproduc= >e the problem.<=3Bbr>=3B<=3Bbr>=3BAll targets?<=3Bbr>=3BWorkaro= >und with d=3D
>=3B >=3Bifferent cm3cg switches (e.g. -O0 vs. -O1 vs.= > -O2?)<=3Bbr>=3B<=3Bbr>=3B&=3Bnbsp=3D3B- Jay<=3Bbr=3D
>= >=3B >=3B>=3B<=3Bbr>=3B<=3Bbr>=3B&=3Bgt=3D3B To: jay.krell at co= >rnell.edu<=3Bbr>=3B&=3Bgt=3D3B Date: Mon=3D2C 27 Dec 201=3D
>= >=3B >=3B0 02:38:10 -0800<=3Bbr>=3B&=3Bgt=3D3B From: mika at async.cal= >tech.edu<=3Bbr>=3B&=3Bgt=3D3B CC: m3dev=3D
>=3B >=3Bel at elegos= >oft.com<=3Bbr>=3B&=3Bgt=3D3B Subject: Re: [M3devel] compiler problem= >s on Snow=3D
>=3B >=3B Leopard<=3Bbr>=3B&=3Bgt=3D3B <=3Bbr&= >gt=3B&=3Bgt=3D3B Jay K writes:<=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3= >B--_6f82bcb2-663=3D
>=3B >=3Bf-4046-87f2-073a1528a819_<=3Bbr>=3B= >&=3Bgt=3D3B &=3Bgt=3D3BContent-Type: text/plain=3D3B chars=3D
>= >=3B >=3Bet=3D3D"iso-8859-1"<=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3BCon= >tent-Transfer-Encoding: quoted-printab=3D
>=3B >=3Ble<=3Bbr>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3B<=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3B<= >=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3BCan you put all your c=3D
>=3B= > >=3Bode in our CVS repository?<=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3= >B<=3Bbr>=3B&=3Bgt=3D3B <=3Bbr>=3B&=3Bgt=3D3B I can't pu=3D>>=3B >=3Bt all the code I work with in m3devel's repository: some of &= >lt=3Bbr>=3B&=3Bgt=3D3B it i=3D
>=3B >=3Bs proprietary.<=3Bbr&= >gt=3B&=3Bgt=3D3B <=3Bbr>=3B&=3Bgt=3D3B The Scheme code however I = >have no restr=3D
>=3B >=3Bictions on distributing (that's<=3Bbr>= >=3B&=3Bgt=3D3B what's got problems in this case)=3D
>=3B >=3B. I= >t is however large and unwieldy and<=3Bbr>=3B&=3Bgt=3D3B I'd like to= > have other pe=3D
>=3B >=3Bople's suggestions for how to submit/inco= >rporate<=3Bbr>=3B&=3Bgt=3D3B it with CM3 befo=3D
>=3B >=3Bre = >I just dump it in the repository. It also overlaps a bit<=3Bbr>=3B&= >=3Bgt=3D3B with=3D
>=3B >=3B "caltech-parser"=3D2C so there should p= >robably be a "caltech-common"<=3Bbr>=3B&=3Bgt=3D
>=3B >=3B=3D= >3B package for the overlaps?<=3Bbr>=3B&=3Bgt=3D3B <=3Bbr>=3B&= >=3Bgt=3D3B If you run the following=3D
>=3B >=3B commands in a fresh= > directory=3D2C you should get<=3Bbr>=3B&=3Bgt=3D3B to the error I e= >=3D
>=3B >=3Bmailed:<=3Bbr>=3B&=3Bgt=3D3B <=3Bbr>=3B&= >=3Bgt=3D3B setenv CM3 1<=3Bbr>=3B&=3Bgt=3D3B cvs -d :pserver:anonymo= >=3D
>=3B >=3Bus at pluto.gcapltd.com:/home/gcap-public-cvs up -d .<= >=3Bbr>=3B&=3Bgt=3D3B make regress =3D
>=3B >=3B # GNU make : = >'gmake regress' on BSD<=3Bbr>=3B&=3Bgt=3D3B cd mscheme/sstubgen/exam= >ple=3D
>=3B >=3B<=3Bbr>=3B&=3Bgt=3D3B cm3 -x<=3Bbr>=3B&am= >p=3Bgt=3D3B <=3Bbr>=3B&=3Bgt=3D3B Mika<=3Bbr>=3B&=3Bgt= >=3D3B <=3Bbr>=3B&=3Bgt=3D3B <=3Bbr>=3B =3D
>=3B >=3B > = > <=3B/body>=3B
>=3B >=3B<=3B/html>=3B=3D
> >=3B >= >=3B
>=3B >=3B--_9ece0c56-2524-4879-9a65-2407b1dbf664_--
> = > >= > >--_d61e805f-545e-4b3d-abe7-a20c582bec2e_-- From jay.krell at cornell.edu Mon Dec 27 12:34:09 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 11:34:09 +0000 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <20101227112424.C13401A205B@async.async.caltech.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , , ,,<20101227101421.38A6A1A205B@async.async.caltech.edu>, , ,,, , ,,<20101227103810.94DF21A205B@async.async.caltech.edu>, , , , , , , , <20101227105859.8E1F21A205B@async.async.caltech.edu>, , , , <20101227112424.C13401A205B@async.async.caltech.edu> Message-ID: I started over. rm -rf various changed toolset to I386_DARWIN, hopefully correctly cvs -z3 upd -dAP export CM3=1 gnumake regress .. lots of stuf compiles .. .. and then: ===> mscheme/sstubgen/program --- building in I386_DARWIN --- new source -> compiling Main.m3 -> linking sstubgen i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/libmscheme.a: No such file or directory m3_link => 1 linker failed linking: sstubgen Fatal Error: package build failed jbook2:gcap-public-cvs jay$ cd mscheme/ jbook2:mscheme jay$ ls CVS doc interactive modula3scheme schemereadline src threads I386_DARWIN examples interactive_r scheme-lib schemesig sstubgen jbook2:mscheme jay$ cm3 --- building in I386_DARWIN --- ignoring ../src/m3overrides "/Users/jay/dev2/gcap-public-cvs/mscheme/src/sgenerics.tmpl", line 3: quake runtime error: undefined variable: TOP --procedure-- -line- -file--- template 3 /Users/jay/dev2/gcap-public-cvs/mscheme/src/sgenerics.tmpl include_dir 69 /Users/jay/dev2/gcap-public-cvs/mscheme/src/m3makefile 4 /Users/jay/dev2/gcap-public-cvs/mscheme/I386_DARWIN/m3make.args Fatal Error: package build failed jbook2:mscheme jay$ jbook2:mscheme jay$ cm3 -DTOP=/dev2/gcap-public-cvs --- building in I386_DARWIN --- ignoring ../src/m3overrides "/Users/jay/dev2/gcap-public-cvs/mscheme/src/m3makefile", line 73: quake runtime error: undefined variable: Netobj --procedure-- -line- -file--- include_dir 73 /Users/jay/dev2/gcap-public-cvs/mscheme/src/m3makefile 5 /Users/jay/dev2/gcap-public-cvs/mscheme/I386_DARWIN/m3make.args Fatal Error: package build failed j jbook2:mscheme jay$ cm3 -DTOP=/dev2/gcap-public-cvs -x --- building in I386_DARWIN --- ignoring override("mscheme", "/dev2/gcap-public-cvs") new source -> compiling SchemeEnvironment_Public_v1.m3 "../I386_DARWIN/SchemeEnvironment_Public_v1.m3", line 546: illegal INTEGER literal, zero used "../I386_DARWIN/SchemeEnvironment_Public_v1.m3", line 547: illegal INTEGER literal, zero used 2 errors encountered compilation failed => not building library "libmscheme.a" Fatal Error: package build failed jbook2:mscheme jay$ minArgs_arg := StubLib.InInteger(c, rep, 0, 9223372036854775807); maxArgs_arg := StubLib.InInteger(c, rep, 0, 9223372036854775807); > To: jay.krell at cornell.edu > Date: Mon, 27 Dec 2010 03:24:24 -0800 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] compiler problems on Snow Leopard > > Don't think you need m3texthack. > > The first thing that happens when you run make ought to be that a file > called ".top" is created at the top level of the repository, with a > definition of TOP. This file is included by the top-level m3overrides, > which is included by every m3overrides when you run with -x. > > Mika > > Jay K writes: > >--_d61e805f-545e-4b3d-abe7-a20c582bec2e_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >something wanted cit_util. > > > > > > > >--- building in AMD64_DARWIN --- > > > > > > > >ignoring ../src/m3overrides > > > > > > > >"/Users/jay/dev2/gcap-public-cvs/cit_util/src/texthack.tmpl"=2C line 2: qua= > >ke runtime error: undefined variable: TOP > > > > > > > >--procedure-- -line- -file--- > > > >template 2 /Users/jay/dev2/gcap-public-cvs/cit_util/src/texthac= > >k.tmpl > > > >include_dir 13 /Users/jay/dev2/gcap-public-cvs/cit_util/src/m3makef= > >ile > > > > 4 /Users/jay/dev2/gcap-public-cvs/cit_util/AMD64_DARWI= > >N/m3make.args > > > > > > > > > > > >% $Id: texthack.tmpl=2Cv 1.7 2002/12/13 22:20:12 kp Exp $ > > > >_M3TEXTHACK =3D TOP & "/m3texthack/" & BUILD_DIR & "/m3texthack" > > > >_DERIVGEN =3D TOP & "/m3texthack/src/derivgen.sh" > > > > > >I don't have m3texthack anywhere I think. > > > > - Jay > > > >From: jay.krell at cornell.edu > >To: mika at async.caltech.edu > >Date: Mon=2C 27 Dec 2010 11:04:11 +0000 > >CC: m3devel at elegosoft.com > >Subject: Re: [M3devel] compiler problems on Snow Leopard > > > > > > > > > > > > > > > > > >Yes=2C overrides and standalone is a problem. > > > >Maybe I'll get around to addressing this for the next release. > > > >A proposed solution is: > > go back to mostly the old method: hard coded runpaths=2C with much overla= > >p for global builds (to be shipped/installed)=2C monstrously long paths for= > > local builds (not to be shipped)=2C AND link upon install > > Some systems allow for "slight relinking"=2C including Solaris and Darwin= > >=2C where just the paths get edited. That would be nicer. > > > > The old approach had problems too. > > > > If you build the system yourself=2C I think you automatically already to= > >day get what is described -- hardcoded run paths=2C with much overlap for g= > >lobal builds. > > > > > > - Jay > > > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] compiler problems on Snow Leopard=20 > >> Date: Mon=2C 27 Dec 2010 02:58:59 -0800 > >> From: mika at async.caltech.edu > >>=20 > >> Run cm3 -x instead of just cm3. > >>=20 > >> Did you get an error compiling package "mscheme"? I certainly have a > >> libmscheme.a in there. > >>=20 > >> /m3overrides has build_standalone() in it. > >>=20 > >> I normally didn't use build_standalone() but something has changed in > >> how the system searches for shared libs when building with overrides > >> and this was the easiest solution (at least for now). > >>=20 > >> Mika > >>=20 > >> Jay K writes: > >> >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ > >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> >I can't quite reproduce it=3D2C but I can compile a bunch of your code. > >> > > >> > > >> >new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-lib.= > >a" =3D > >> >-> archiving libsstubgen.a > >> > > >> >=3D3D=3D3D=3D3D> mscheme/sstubgen/program > >> >--- building in I386_DARWIN --- > >> > > >> > -> linking sstubgen > >> >i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/= > >lib=3D > >> >mscheme.a: No such file or directory > >> > m3_link =3D3D> 1 > >> >linker failed linking: sstubgen > >> >Fatal Error: package build failed > >> > > >> >jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example > >> >jbook2:example jay$ c=3D2C3 > >> >-bash: c=3D2C3: command not found > >> >jbook2:example jay$ cm3 > >> >--- building in I386_DARWIN --- > >> > > >> >ignoring ../src/m3overrides > >> > > >> >"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3makefile= > >"=3D > >> >=3D2C line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/I386= > >_DARW=3D > >> >IN/.M3EXPORTS" for reading > >> > > >> >--procedure-- -line- -file--- > >> >import -- > >> >include_dir 3 /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/= > >exa=3D > >> >mple/src/m3makefile > >> > > >> > > >> > - Jay > >> > > >> > > >> > > >> > > >> > > >> > > >> >From: jay.krell at cornell.edu > >> >To: mika at async.caltech.edu > >> >Date: Mon=3D2C 27 Dec 2010 10:46:55 +0000 > >> >CC: m3devel at elegosoft.com > >> >Subject: Re: [M3devel] compiler problems on Snow Leopard > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> >aside: overlap with caltech_parser: > >> >if you can come up with a merged version that works with both=3D2C good > >> >If you can't=3D2C I think you have to rename one or the other. > >> > > >> >Maybe someday we can support some sort of hierarchy that automatically m= > >aps=3D > >> > to/from the file system hierarchy... > >> > > >> >I'll try to reproduce the problem. > >> > > >> >All targets? > >> >Workaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) > >> > > >> > - Jay > >> > > >> > > >> >> To: jay.krell at cornell.edu > >> >> Date: Mon=3D2C 27 Dec 2010 02:38:10 -0800 > >> >> From: mika at async.caltech.edu > >> >> CC: m3devel at elegosoft.com > >> >> Subject: Re: [M3devel] compiler problems on Snow Leopard > >> >>=3D20 > >> >> Jay K writes: > >> >> >--_6f82bcb2-663f-4046-87f2-073a1528a819_ > >> >> >Content-Type: text/plain=3D3B charset=3D3D"iso-8859-1" > >> >> >Content-Transfer-Encoding: quoted-printable > >> >> > > >> >> > > >> >> >Can you put all your code in our CVS repository? > >> >> > > >> >>=3D20 > >> >> I can't put all the code I work with in m3devel's repository: some of= > >=3D20 > >> >> it is proprietary. > >> >>=3D20 > >> >> The Scheme code however I have no restrictions on distributing (that's > >> >> what's got problems in this case). It is however large and unwieldy a= > >nd > >> >> I'd like to have other people's suggestions for how to submit/incorpor= > >ate > >> >> it with CM3 before I just dump it in the repository. It also overlaps= > > a =3D > >> >bit > >> >> with "caltech-parser"=3D2C so there should probably be a "caltech-comm= > >on" > >> >> package for the overlaps? > >> >>=3D20 > >> >> If you run the following commands in a fresh directory=3D2C you should= > > get > >> >> to the error I emailed: > >> >>=3D20 > >> >> setenv CM3 1 > >> >> cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -= > >d . > >> >> make regress # GNU make : 'gmake regress' on BSD > >> >> cd mscheme/sstubgen/example > >> >> cm3 -x > >> >>=3D20 > >> >> Mika > >> >>=3D20 > >> >>=3D20 > >> > =3D > >> > > >> >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ > >> >Content-Type: text/html=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> > > >> > > >> > > >> > > >> >I can't quite reproduce it=3D2C but I can compile a bunch of your code.<= > >br> >> >r>
new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libschem= > >e-l=3D > >> >ib.a" ->=3D3B archiving libsstubgen.a

=3D3D=3D3D=3D3D>=3D3B m= > >scheme/sstubg=3D > >> >en/program
--- building in I386_DARWIN ---

 =3D3B->=3D3B= > > linkin=3D > >> >g sstubgen
i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mschem= > >e/I=3D > >> >386_DARWIN/libmscheme.a: No such file or directory
 =3D3B m3_link= > > =3D3D&=3D > >> >gt=3D3B 1
linker failed linking: sstubgen
Fatal Error: package bui= > >ld fa=3D > >> >iled

jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example
j= > >boo=3D > >> >k2:example jay$ c=3D2C3
-bash: c=3D2C3: command not found
jbook2:e= > >xample =3D > >> >jay$ cm3
--- building in I386_DARWIN ---

ignoring ../src/m3ove= > >rri=3D > >> >des

"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src= > >/m3=3D > >> >makefile"=3D2C line 3: quake runtime error: unable to open "/cm3/pkg/msc= > >heme/=3D > >> >I386_DARWIN/.M3EXPORTS" for reading

--procedure-- =3D3B -line= > >-&nbs=3D > >> >p=3D3B -file---
import =3D3B =3D3B =3D3B =3D3B = > >=3D3B =3D3B&nbs=3D > >> >p=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B -- =3D3B &l= > >t=3D3Bbuiltin>=3D3B=3D > >> >
include_dir =3D3B =3D3B =3D3B =3D3B =3D3B = > >=3D3B =3D3B&nbs=3D > >> >p=3D3B 3 =3D3B /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/exam= > >ple/src=3D > >> >/m3makefile


 =3D3B- Jay






>=3D3D"s=3D > >> >topSpelling">From: jay.krell at cornell.edu
To: mika at async.caltech.edu >r>D=3D > >> >ate: Mon=3D2C 27 Dec 2010 10:46:55 +0000
CC: m3devel at elegosoft.com >>Subj=3D > >> >ect: Re: [M3devel] compiler problems on Snow Leopard

> >> > > >> > >=3D3Dunicode=3D > >> >"> > >> > > >> > > >> > > >> > > >> >aside: overlap with caltech_parser:
if you can come up with a merged = > >ver=3D > >> >sion that works with both=3D2C good
If you can't=3D2C I think you hav= > >e to re=3D > >> >name one or the other.

Maybe someday we can support some sort of = > >hie=3D > >> >rarchy that automatically maps to/from the file system hierarchy...
<= > >br>=3D > >> >I'll try to reproduce the problem.

All targets?
Workaround wit= > >h d=3D > >> >ifferent cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?)

 =3D3B- J= > >ay >> >>

>=3D3B To: jay.krell at cornell.edu
>=3D3B Date: Mon=3D2C 2= > >7 Dec 201=3D > >> >0 02:38:10 -0800
>=3D3B From: mika at async.caltech.edu
>=3D3B CC= > >: m3dev=3D > >> >el at elegosoft.com
>=3D3B Subject: Re: [M3devel] compiler problems on= > > Snow=3D > >> > Leopard
>=3D3B
>=3D3B Jay K writes:
>=3D3B >=3D3B--_6= > >f82bcb2-663=3D > >> >f-4046-87f2-073a1528a819_
>=3D3B >=3D3BContent-Type: text/plain= > >=3D3B chars=3D > >> >et=3D3D"iso-8859-1"
>=3D3B >=3D3BContent-Transfer-Encoding: quote= > >d-printab=3D > >> >le
>=3D3B >=3D3B
>=3D3B >=3D3B
>=3D3B >=3D3BCan you= > > put all your c=3D > >> >ode in our CVS repository?
>=3D3B >=3D3B
>=3D3B
>=3D3B= > > I can't pu=3D > >> >t all the code I work with in m3devel's repository: some of
>=3D3B= > > it i=3D > >> >s proprietary.
>=3D3B
>=3D3B The Scheme code however I have n= > >o restr=3D > >> >ictions on distributing (that's
>=3D3B what's got problems in this = > >case)=3D > >> >. It is however large and unwieldy and
>=3D3B I'd like to have oth= > >er pe=3D > >> >ople's suggestions for how to submit/incorporate
>=3D3B it with CM3= > > befo=3D > >> >re I just dump it in the repository. It also overlaps a bit
>=3D3B= > > with=3D > >> > "caltech-parser"=3D2C so there should probably be a "caltech-common" >>>=3D > >> >=3D3B package for the overlaps?
>=3D3B
>=3D3B If you run the = > >following=3D > >> > commands in a fresh directory=3D2C you should get
>=3D3B to the er= > >ror I e=3D > >> >mailed:
>=3D3B
>=3D3B setenv CM3 1
>=3D3B cvs -d :pserve= > >r:anonymo=3D > >> >us at pluto.gcapltd.com:/home/gcap-public-cvs up -d .
>=3D3B make regr= > >ess =3D > >> > # GNU make : 'gmake regress' on BSD
>=3D3B cd mscheme/sstubgen/ex= > >ample=3D > >> >
>=3D3B cm3 -x
>=3D3B
>=3D3B Mika
>=3D3B
&= > >gt=3D3B
=3D > >> > > >> >=3D > >> > > >> >--_9ece0c56-2524-4879-9a65-2407b1dbf664_-- > > = > > > >--_d61e805f-545e-4b3d-abe7-a20c582bec2e_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >something wanted cit_util.
> >
> >--- building in AMD64_DARWIN ---
> >
> >ignoring ../src/m3overrides
> >
> >"/Users/jay/dev2/gcap-public-cvs/cit_util/src/texthack.tmpl"=2C line 2: qua= > >ke runtime error: undefined variable: TOP
> >
> >--procedure-- =3B -line- =3B -file---
> >template =3B =3B =3B =3B =3B =3B =3B =3B&nb= > >sp=3B =3B =3B 2 =3B /Users/jay/dev2/gcap-public-cvs/cit_util/sr= > >c/texthack.tmpl
> >include_dir =3B =3B =3B =3B =3B =3B =3B 13 = > >=3B /Users/jay/dev2/gcap-public-cvs/cit_util/src/m3makefile
> > =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= > >sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = > >=3B 4 =3B /Users/jay/dev2/gcap-public-cvs/cit_util/AMD64_DARWIN/m3make.= > >args
> >
> >
> >% $Id: texthack.tmpl=2Cv 1.7 2002/12/13 22:20:12 kp Exp $
> >_M3TEXTHACK =3D TOP &=3B "/m3texthack/" &=3B BUILD_DIR &=3B "/m3te= > >xthack"
> >_DERIVGEN =3B =3B =3D TOP &=3B "/m3texthack/src/derivgen.sh"
> >
I don't have m3texthack anywhere I think.

 =3B- Jay

<= > >hr id=3D"stopSpelling">From: jay.krell at cornell.edu
To: mika at async.caltec= > >h.edu
Date: Mon=2C 27 Dec 2010 11:04:11 +0000
CC: m3devel at elegosoft.c= > >om
Subject: Re: [M3devel] compiler problems on Snow Leopard

> > > > >"> > > > > > > > > > >Yes=2C overrides and standalone is a problem.

Maybe I'll get around = > >to addressing this for the next release.

A proposed solution is:
= > > =3B go back to mostly the old method: hard coded runpaths=2C with much= > > overlap for global builds (to be shipped/installed)=2C monstrously long pa= > >ths for local builds (not to be shipped)=2C AND link upon install
 = > >=3B Some systems allow for "slight relinking"=2C including Solaris and Darw= > >in=2C where just the paths get edited. That would be nicer.

 =3B= > > The old approach had problems too.

 =3B =3B If you build th= > >e system yourself=2C I think you automatically already today get what is de= > >scribed -- hardcoded run paths=2C with much overlap for global builds.
<= > >br>
 =3B- Jay

>=3B To: jay.krell at cornell.edu
>=3B CC: = > >m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] compiler problems on= > > Snow Leopard
>=3B Date: Mon=2C 27 Dec 2010 02:58:59 -0800
>=3B = > >From: mika at async.caltech.edu
>=3B
>=3B Run cm3 -x instead of jus= > >t cm3.
>=3B
>=3B Did you get an error compiling package "mscheme= > >"? I certainly have a
>=3B libmscheme.a in there.
>=3B
>= > >=3B <=3Btop>=3B/m3overrides has build_standalone() in it.
>=3B >>>=3B I normally didn't use build_standalone() but something has changed = > >in
>=3B how the system searches for shared libs when building with ove= > >rrides
>=3B and this was the easiest solution (at least for now).
&= > >gt=3B
>=3B Mika
>=3B
>=3B Jay K writes:
>=3B >= > >=3B--_9ece0c56-2524-4879-9a65-2407b1dbf664_
>=3B >=3BContent-Type: t= > >ext/plain=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encodi= > >ng: quoted-printable
>=3B >=3B
>=3B >=3B
>=3B >=3BI ca= > >n't quite reproduce it=3D2C but I can compile a bunch of your code.
>= > >=3B >=3B
>=3B >=3B
>=3B >=3Bnew "/dev2/gcap-public-cvs/msch= > >eme/scheme-lib/I386_DARWIN/libscheme-lib.a" =3D
>=3B >=3B->=3B arc= > >hiving libsstubgen.a
>=3B >=3B
>=3B >=3B=3D3D=3D3D=3D3D>=3B= > > mscheme/sstubgen/program
>=3B >=3B--- building in I386_DARWIN --- >r>>=3B >=3B
>=3B >=3B ->=3B linking sstubgen
>=3B >=3Bi= > >686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/lib= > >=3D
>=3B >=3Bmscheme.a: No such file or directory
>=3B >=3B = > >m3_link =3D3D>=3B 1
>=3B >=3Blinker failed linking: sstubgen
&g= > >t=3B >=3BFatal Error: package build failed
>=3B >=3B
>=3B >= > >=3Bjbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example
>=3B >=3B= > >jbook2:example jay$ c=3D2C3
>=3B >=3B-bash: c=3D2C3: command not fou= > >nd
>=3B >=3Bjbook2:example jay$ cm3
>=3B >=3B--- building in = > >I386_DARWIN ---
>=3B >=3B
>=3B >=3Bignoring ../src/m3override= > >s
>=3B >=3B
>=3B >=3B"/Users/jay/dev2/gcap-public-cvs/mscheme= > >/sstubgen/example/src/m3makefile"=3D
>=3B >=3B=3D2C line 3: quake ru= > >ntime error: unable to open "/cm3/pkg/mscheme/I386_DARW=3D
>=3B >=3B= > >IN/.M3EXPORTS" for reading
>=3B >=3B
>=3B >=3B--procedure-- = > >-line- -file---
>=3B >=3Bimport -- <=3Bbuiltin>=3B= > >
>=3B >=3Binclude_dir 3 /Users/jay/dev2/gcap-public-cvs/msc= > >heme/sstubgen/exa=3D
>=3B >=3Bmple/src/m3makefile
>=3B >=3B >r>>=3B >=3B
>=3B >=3B - Jay
>=3B >=3B
>=3B >=3B >>>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B= > > >=3BFrom: jay.krell at cornell.edu
>=3B >=3BTo: mika at async.caltech.e= > >du
>=3B >=3BDate: Mon=3D2C 27 Dec 2010 10:46:55 +0000
>=3B >= > >=3BCC: m3devel at elegosoft.com
>=3B >=3BSubject: Re: [M3devel] compile= > >r problems on Snow Leopard
>=3B >=3B
>=3B >=3B
>=3B >= > >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
= > >>=3B >=3B
>=3B >=3Baside: overlap with caltech_parser:
>=3B= > > >=3Bif you can come up with a merged version that works with both=3D2C g= > >ood
>=3B >=3BIf you can't=3D2C I think you have to rename one or the= > > other.
>=3B >=3B
>=3B >=3BMaybe someday we can support some = > >sort of hierarchy that automatically maps=3D
>=3B >=3B to/from the f= > >ile system hierarchy...
>=3B >=3B
>=3B >=3BI'll try to reprod= > >uce the problem.
>=3B >=3B
>=3B >=3BAll targets?
>=3B &g= > >t=3BWorkaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) >>>=3B >=3B
>=3B >=3B - Jay
>=3B >=3B
>=3B >=3B
= > >>=3B >=3B>=3B To: jay.krell at cornell.edu
>=3B >=3B>=3B Date: = > >Mon=3D2C 27 Dec 2010 02:38:10 -0800
>=3B >=3B>=3B From: mika at async= > >.caltech.edu
>=3B >=3B>=3B CC: m3devel at elegosoft.com
>=3B >= > >=3B>=3B Subject: Re: [M3devel] compiler problems on Snow Leopard
>= > >=3B >=3B>=3B=3D20
>=3B >=3B>=3B Jay K writes:
>=3B >=3B= > >>=3B >=3B--_6f82bcb2-663f-4046-87f2-073a1528a819_
>=3B >=3B>= > >=3B >=3BContent-Type: text/plain=3D3B charset=3D3D"iso-8859-1"
>=3B = > >>=3B>=3B >=3BContent-Transfer-Encoding: quoted-printable
>=3B &g= > >t=3B>=3B >=3B
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= > >=3BCan you put all your code in our CVS repository?
>=3B >=3B>=3B = > >>=3B
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B I can't put all t= > >he code I work with in m3devel's repository: some of=3D20
>=3B >=3B&= > >gt=3B it is proprietary.
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B= > > The Scheme code however I have no restrictions on distributing (that's
= > >>=3B >=3B>=3B what's got problems in this case). It is however large= > > and unwieldy and
>=3B >=3B>=3B I'd like to have other people's su= > >ggestions for how to submit/incorporate
>=3B >=3B>=3B it with CM3 = > >before I just dump it in the repository. It also overlaps a =3D
>=3B = > >>=3Bbit
>=3B >=3B>=3B with "caltech-parser"=3D2C so there should= > > probably be a "caltech-common"
>=3B >=3B>=3B package for the over= > >laps?
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B If you run the fol= > >lowing commands in a fresh directory=3D2C you should get
>=3B >=3B&g= > >t=3B to the error I emailed:
>=3B >=3B>=3B=3D20
>=3B >=3B&g= > >t=3B setenv CM3 1
>=3B >=3B>=3B cvs -d :pserver:anonymous at pluto.gc= > >apltd.com:/home/gcap-public-cvs up -d .
>=3B >=3B>=3B make regress= > > # GNU make : 'gmake regress' on BSD
>=3B >=3B>=3B cd mscheme/s= > >stubgen/example
>=3B >=3B>=3B cm3 -x
>=3B >=3B>=3B=3D20 >r>>=3B >=3B>=3B Mika
>=3B >=3B>=3B=3D20
>=3B >= > >=3B>=3B=3D20
>=3B >=3B =3D >r>>=3B >=3B
>=3B &= > >gt=3B--_9ece0c56-2524-4879-9a65-2407b1dbf664_
>=3B >=3BContent-Type:= > > text/html=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encod= > >ing: quoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>=3B
= > >>=3B >=3B<=3Bhead>=3B
>=3B >=3B<=3Bstyle>=3B<=3B!-- >>>=3B >=3B.hmmessage P
>=3B >=3B{
>=3B >=3Bmargin:0px=3D3= > >B
>=3B >=3Bpadding:0px
>=3B >=3B}
>=3B >=3Bbody.hmmess= > >age
>=3B >=3B{
>=3B >=3Bfont-size: 10pt=3D3B
>=3B >=3B= > >font-family:Tahoma
>=3B >=3B}
>=3B >=3B-->=3B<=3B/style&g= > >t=3B
>=3B >=3B<=3B/head>=3B
>=3B >=3B<=3Bbody class=3D3= > >D'hmmessage'>=3B
>=3B >=3BI can't quite reproduce it=3D2C but I ca= > >n compile a bunch of your code.<=3Bbr>=3B<=3Bb=3D
>=3B >=3Br&g= > >t=3B<=3Bbr>=3Bnew "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN= > >/libscheme-l=3D
>=3B >=3Bib.a" -&=3Bgt=3D3B archiving libsstubgen= > >.a<=3Bbr>=3B<=3Bbr>=3B=3D3D=3D3D=3D3D&=3Bgt=3D3B mscheme/sstubg= > >=3D
>=3B >=3Ben/program<=3Bbr>=3B--- building in I386_DARWIN ---= > ><=3Bbr>=3B<=3Bbr>=3B&=3Bnbsp=3D3B-&=3Bgt=3D3B linkin=3D
&g= > >t=3B >=3Bg sstubgen<=3Bbr>=3Bi686-apple-darwin9-gcc-4.0.1: /dev2/gcap= > >-public-cvs/mscheme/I=3D
>=3B >=3B386_DARWIN/libmscheme.a: No such f= > >ile or directory<=3Bbr>=3B&=3Bnbsp=3D3B m3_link =3D3D&=3B=3D
&= > >gt=3B >=3Bgt=3D3B 1<=3Bbr>=3Blinker failed linking: sstubgen<=3Bbr&= > >gt=3BFatal Error: package build fa=3D
>=3B >=3Biled<=3Bbr>=3B<= > >=3Bbr>=3Bjbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example<=3Bbr&= > >gt=3Bjboo=3D
>=3B >=3Bk2:example jay$ c=3D2C3<=3Bbr>=3B-bash: c= > >=3D2C3: command not found<=3Bbr>=3Bjbook2:example =3D
>=3B >=3Bj= > >ay$ cm3<=3Bbr>=3B--- building in I386_DARWIN ---<=3Bbr>=3B<=3Bbr&= > >gt=3Bignoring ../src/m3overri=3D
>=3B >=3Bdes<=3Bbr>=3B<=3Bbr&= > >gt=3B"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3=3D >>>=3B >=3Bmakefile"=3D2C line 3: quake runtime error: unable to open "/= > >cm3/pkg/mscheme/=3D
>=3B >=3BI386_DARWIN/.M3EXPORTS" for reading<= > >=3Bbr>=3B<=3Bbr>=3B--procedure--&=3Bnbsp=3D3B -line-&=3Bnbs=3D<= > >br>>=3B >=3Bp=3D3B -file---<=3Bbr>=3Bimport&=3Bnbsp=3D3B&=3Bn= > >bsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&am= > >p=3Bnbs=3D
>=3B >=3Bp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbs= > >p=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B --&=3Bnbsp=3D3B &=3Blt=3D3Bbui= > >ltin&=3Bgt=3D3B=3D
>=3B >=3B<=3Bbr>=3Binclude_dir&=3Bnbsp= > >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&= > >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbs=3D
>=3B >=3Bp=3D3B 3&=3Bnb= > >sp=3D3B /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src=3D
= > >>=3B >=3B/m3makefile<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B&=3Bnb= > >sp=3D3B- Jay<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bb= > >r>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bhr id=3D3D"s=3D
>=3B >=3Bto= > >pSpelling">=3BFrom: jay.krell at cornell.edu<=3Bbr>=3BTo: mika at async.cal= > >tech.edu<=3Bbr>=3BD=3D
>=3B >=3Bate: Mon=3D2C 27 Dec 2010 10:46:= > >55 +0000<=3Bbr>=3BCC: m3devel at elegosoft.com<=3Bbr>=3BSubj=3D
>= > >=3B >=3Bect: Re: [M3devel] compiler problems on Snow Leopard<=3Bbr>= > >=3B<=3Bbr>=3B
>=3B >=3B
>=3B >=3B<=3Bmeta http-equiv=3D= > >3D"Content-Type" content=3D3D"text/html=3D3B charset=3D3Dunicode=3D
>= > >=3B >=3B">=3B
>=3B >=3B<=3Bmeta name=3D3D"Generator" content= > >=3D3D"Microsoft SafeHTML">=3B
>=3B >=3B<=3Bstyle>=3B
>=3B= > > >=3B.ExternalClass .ecxhmmessage P
>=3B >=3B{padding:0px=3D3B} >>>=3B >=3B.ExternalClass body.ecxhmmessage
>=3B >=3B{font-size:1= > >0pt=3D3Bfont-family:Tahoma=3D3B}
>=3B >=3B
>=3B >=3B<=3B/st= > >yle>=3B
>=3B >=3B
>=3B >=3B
>=3B >=3Baside: overlap = > >with caltech_parser:<=3Bbr>=3Bif you can come up with a merged ver=3D >r>>=3B >=3Bsion that works with both=3D2C good<=3Bbr>=3BIf you can'= > >t=3D2C I think you have to re=3D
>=3B >=3Bname one or the other.<= > >=3Bbr>=3B<=3Bbr>=3BMaybe someday we can support some sort of hie=3D >r>>=3B >=3Brarchy that automatically maps to/from the file system hiera= > >rchy...<=3Bbr>=3B<=3Bbr>=3B=3D
>=3B >=3BI'll try to reproduc= > >e the problem.<=3Bbr>=3B<=3Bbr>=3BAll targets?<=3Bbr>=3BWorkaro= > >und with d=3D
>=3B >=3Bifferent cm3cg switches (e.g. -O0 vs. -O1 vs.= > > -O2?)<=3Bbr>=3B<=3Bbr>=3B&=3Bnbsp=3D3B- Jay<=3Bbr=3D
>= > >=3B >=3B>=3B<=3Bbr>=3B<=3Bbr>=3B&=3Bgt=3D3B To: jay.krell at co= > >rnell.edu<=3Bbr>=3B&=3Bgt=3D3B Date: Mon=3D2C 27 Dec 201=3D
>= > >=3B >=3B0 02:38:10 -0800<=3Bbr>=3B&=3Bgt=3D3B From: mika at async.cal= > >tech.edu<=3Bbr>=3B&=3Bgt=3D3B CC: m3dev=3D
>=3B >=3Bel at elegos= > >oft.com<=3Bbr>=3B&=3Bgt=3D3B Subject: Re: [M3devel] compiler problem= > >s on Snow=3D
>=3B >=3B Leopard<=3Bbr>=3B&=3Bgt=3D3B <=3Bbr&= > >gt=3B&=3Bgt=3D3B Jay K writes:<=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3= > >B--_6f82bcb2-663=3D
>=3B >=3Bf-4046-87f2-073a1528a819_<=3Bbr>=3B= > >&=3Bgt=3D3B &=3Bgt=3D3BContent-Type: text/plain=3D3B chars=3D
>= > >=3B >=3Bet=3D3D"iso-8859-1"<=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3BCon= > >tent-Transfer-Encoding: quoted-printab=3D
>=3B >=3Ble<=3Bbr>=3B&= > >amp=3Bgt=3D3B &=3Bgt=3D3B<=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3B<= > >=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3BCan you put all your c=3D
>=3B= > > >=3Bode in our CVS repository?<=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3= > >B<=3Bbr>=3B&=3Bgt=3D3B <=3Bbr>=3B&=3Bgt=3D3B I can't pu=3D >>>=3B >=3Bt all the code I work with in m3devel's repository: some of &= > >lt=3Bbr>=3B&=3Bgt=3D3B it i=3D
>=3B >=3Bs proprietary.<=3Bbr&= > >gt=3B&=3Bgt=3D3B <=3Bbr>=3B&=3Bgt=3D3B The Scheme code however I = > >have no restr=3D
>=3B >=3Bictions on distributing (that's<=3Bbr>= > >=3B&=3Bgt=3D3B what's got problems in this case)=3D
>=3B >=3B. I= > >t is however large and unwieldy and<=3Bbr>=3B&=3Bgt=3D3B I'd like to= > > have other pe=3D
>=3B >=3Bople's suggestions for how to submit/inco= > >rporate<=3Bbr>=3B&=3Bgt=3D3B it with CM3 befo=3D
>=3B >=3Bre = > >I just dump it in the repository. It also overlaps a bit<=3Bbr>=3B&= > >=3Bgt=3D3B with=3D
>=3B >=3B "caltech-parser"=3D2C so there should p= > >robably be a "caltech-common"<=3Bbr>=3B&=3Bgt=3D
>=3B >=3B=3D= > >3B package for the overlaps?<=3Bbr>=3B&=3Bgt=3D3B <=3Bbr>=3B&= > >=3Bgt=3D3B If you run the following=3D
>=3B >=3B commands in a fresh= > > directory=3D2C you should get<=3Bbr>=3B&=3Bgt=3D3B to the error I e= > >=3D
>=3B >=3Bmailed:<=3Bbr>=3B&=3Bgt=3D3B <=3Bbr>=3B&= > >=3Bgt=3D3B setenv CM3 1<=3Bbr>=3B&=3Bgt=3D3B cvs -d :pserver:anonymo= > >=3D
>=3B >=3Bus at pluto.gcapltd.com:/home/gcap-public-cvs up -d .<= > >=3Bbr>=3B&=3Bgt=3D3B make regress =3D
>=3B >=3B # GNU make : = > >'gmake regress' on BSD<=3Bbr>=3B&=3Bgt=3D3B cd mscheme/sstubgen/exam= > >ple=3D
>=3B >=3B<=3Bbr>=3B&=3Bgt=3D3B cm3 -x<=3Bbr>=3B&am= > >p=3Bgt=3D3B <=3Bbr>=3B&=3Bgt=3D3B Mika<=3Bbr>=3B&=3Bgt= > >=3D3B <=3Bbr>=3B&=3Bgt=3D3B <=3Bbr>=3B =3D
>=3B >=3B > > = > > <=3B/body>=3B
>=3B >=3B<=3B/html>=3B=3D
> > >=3B >= > >=3B
>=3B >=3B--_9ece0c56-2524-4879-9a65-2407b1dbf664_--
> > = > > > >= > > > >--_d61e805f-545e-4b3d-abe7-a20c582bec2e_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 27 18:19:24 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Dec 2010 12:19:24 -0500 Subject: [M3devel] pointers/arrays? In-Reply-To: References: Message-ID: Have you played around with SUBARRAY? On Dec 26, 2010, at 11:37 PM, Jay K wrote: > I'm still wrestling with this. I have found a few options that work and they all have glaring problems. > > > VAR macho_header32_t_fields := ARRAY [0..6] OF field_t{ > field_t{ "magic", 0, 4, enum_table := EnumTable(macho_magic_names)}, > ... > field_t{ "flags", 24, 4}}; > > > 1) I shouldn't have to give the size of the array. > 2) I shouldn't have to copy the enum table to make it an indexable array. > > > Disappointing.. > > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 27 Dec 2010 02:11:28 +0000 > Subject: [M3devel] pointers/arrays? > > a: UNTRACED REF T; > i: INTEGER; > > > a[i] ? > (a + i)^ ? > > > Or I'm really stuck with > LOOPEHOLE(a + i * BYTESIZE(a^), UNTRACED REF T) > > > Seems kind of stinky. > I've got some nice efficient readable safe-enough C and it doesn't seem to translate well easily efficiently to Modula-3. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 27 18:20:25 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Dec 2010 12:20:25 -0500 Subject: [M3devel] constants/offsetof? In-Reply-To: References: Message-ID: <69FCE67E-DA1E-46EA-BD6C-6A0F680E8628@cs.purdue.edu> I really don't understand yet what you are trying to achieve. Do you have a distilled example? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 27, 2010, at 2:15 AM, Jay K wrote: > Is it unreasonble to expect more/all of these to be constant? > > > UNSAFE MODULE bug1; > > > TYPE T1 = RECORD i,j:INTEGER END; > > > <*NOWARN*>VAR a:T1; > <*NOWARN*>CONST b: UNTRACED REF T1 = NIL; > <*NOWARN*>CONST c: ADDRESS = ADR(a); (* line 7 *) > <*NOWARN*>CONST d: ADDRESS = ADR(a.i); > <*NOWARN*>CONST e: ADDRESS = ADR(a.j); > <*NOWARN*>CONST f: INTEGER = ADR(a.j) - NIL; > <*NOWARN*>CONST g: ADDRESS = ADR(b.i); > <*NOWARN*>CONST h: ADDRESS = ADR(b.j); > <*NOWARN*>CONST i: INTEGER = ADR(b.j) - NIL; > > <*NOWARN*>VAR vc: ADDRESS := ADR(a); > <*NOWARN*>VAR vd: ADDRESS := ADR(a.i); > <*NOWARN*>VAR ve: ADDRESS := ADR(a.j); > <*NOWARN*>VAR vf: INTEGER := ADR(a.j) - NIL; (* oops, didn't mean this one *) > <*NOWARN*>VAR vg: ADDRESS := ADR(b.i); > <*NOWARN*>VAR vh: ADDRESS := ADR(b.j); > <*NOWARN*>VAR vi: INTEGER := ADR(b.j) - NIL; > > BEGIN > END bug1. > > > "../src/bug1.m3", line 7: value is not constant > "../src/bug1.m3", line 8: value is not constant > "../src/bug1.m3", line 9: value is not constant > "../src/bug1.m3", line 10: value is not constant > "../src/bug1.m3", line 11: value is not constant > "../src/bug1.m3", line 12: value is not constant > "../src/bug1.m3", line 13: value is not constant > > It works in C... > > #include > > typedef struct { ptrdiff_t i, j;}T1; > > T1 a; > #define b ((T1*)0) > T1* const c = &a; > ptrdiff_t* const d = &a.i; > ptrdiff_t* const e = &a.j; > ptrdiff_t const f = offsetof(T1,j); > ptrdiff_t* const g = &b->i; > ptrdiff_t* const h = &b->j; > ptrdiff_t const i = &b->j - (ptrdiff_t*)0; > > > Thanks, > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 27 18:21:12 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Dec 2010 12:21:12 -0500 Subject: [M3devel] another Snow Leopard compiler crash In-Reply-To: <20101227101653.307241A205B@async.async.caltech.edu> References: <20101227101653.307241A205B@async.async.caltech.edu> Message-ID: Which version of the backend are you using? Release? There has been so much churn in the trunk lately that I have lost track of things. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 27, 2010, at 5:16 AM, Mika Nystrom wrote: > > ===> calarm/regress/ximport > --- building in I386_DARWIN --- > > new source -> compiling Main.m3 > "../src/Main.m3", line 258: warning: potentially unhandled exception: Main.ParamErr > "../src/Main.m3", line 260: warning: potentially unhandled exception: Main.ParamErr > "../src/Main.m3", line 261: warning: potentially unhandled exception: Main.ParamErr > 3 warnings encountered > ../src/Main.m3: In function 'Main__DumpMatching__DumpOne': > ../src/Main.m3:225:0: error: unable to find a register to spill in class 'CREG' > ../src/Main.m3:225:0: error: this is the insn: > (insn 5 4 6 2 ../src/Main.m3:204 (parallel [ > (set (reg:SI 0 ax [130]) > (const_int 0 [0x0])) > (set (reg:SI 1 dx [128]) > (plus:SI (ashift:SI (reg:SI 0 ax [130]) > (const_int 2 [0x2])) > (reg:SI 1 dx [128]))) > (set (reg:SI 4 si [129]) > (plus:SI (ashift:SI (reg:SI 0 ax [130]) > (const_int 2 [0x2])) > (reg:SI 4 si [129]))) > (set (mem/s/c:BLK (reg:SI 1 dx [128]) [0 trade+0 S24 A64]) > (mem/s/c:BLK (reg:SI 4 si [129]) [0 trade+0 S24 A32])) > (use (reg:SI 0 ax [130])) > ]) 838 {*rep_movsi} (expr_list:REG_UNUSED (reg:SI 0 ax [130]) > (expr_list:REG_UNUSED (reg:SI 4 si [129]) > (expr_list:REG_UNUSED (reg:SI 1 dx [128]) > (nil))))) > ../src/Main.m3:225:0: internal compiler error: in spill_failure, at reload1.c:2163 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: Main.mc > compilation failed => not building program "ximport" > Fatal Error: package build failed > > Here is the code: > > PROCEDURE DumpMatching(tr : TickerRef; > trades, bids, asks : HFDataSSeq.T) RAISES { Wr.Failure } = > > PROCEDURE DumpOne(trade, bid, ask : HFData.S) RAISES { Wr.Failure } = > BEGIN > <* ASSERT trade.time = bid.time AND bid.time = ask.time *> > Wr.PutText(wr, Fmt.LongReal(trade.time)); > > Wr.PutChar(wr, ' '); > Wr.PutText(wr, Fmt.LongReal(aFactor*trade.pv.price)); > Wr.PutChar(wr, ' '); > Wr.PutText(wr, Fmt.LongReal(FLOAT(trade.pv.volume,LONGREAL)/aFactor)); > > Wr.PutChar(wr, ' '); > Wr.PutText(wr, Fmt.LongReal(aFactor*bid.pv.price)); > Wr.PutChar(wr, ' '); > Wr.PutText(wr, Fmt.LongReal(FLOAT(bid.pv.volume,LONGREAL)/aFactor)); > > Wr.PutChar(wr, ' '); > Wr.PutText(wr, Fmt.LongReal(aFactor*ask.pv.price)); > Wr.PutChar(wr, ' '); > Wr.PutText(wr, Fmt.LongReal(FLOAT(ask.pv.volume,LONGREAL)/aFactor)); > > Wr.PutChar(wr, '\n') > END DumpOne; > > CONST > NoTime = FIRST(Time.T); > VAR > wr := FileWr.Open(odir & "/" & tr.ticker); > tp, bp, ap := 0; > ttime, btime, atime := NoTime; > aFactor : LONGREAL := 1.0d0; > BEGIN > WHILE tp < trades.size() AND bp < bids.size() AND ap < asks.size() DO > IF ttime = NoTime THEN ttime := trades.get(tp).time END; > IF btime = NoTime THEN btime := bids.get(bp).time END; > IF atime = NoTime THEN atime := asks.get(ap).time END; > > IF ttime = btime AND btime = atime THEN > DumpOne(trades.get(tp),bids.get(bp),asks.get(ap)); > INC(tp); INC(bp); INC(ap); > ttime := NoTime; btime := NoTime; atime := NoTime > ELSIF ttime < btime OR ttime < atime THEN > INC(tp); ttime := NoTime > ELSIF btime < atime OR btime < ttime THEN > INC(bp); btime := NoTime > ELSIF atime < btime OR atime < ttime THEN > INC(ap); atime := NoTime > END > END; > Wr.Close(wr) > END DumpMatching; > > Miika From hosking at cs.purdue.edu Mon Dec 27 18:22:28 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Dec 2010 12:22:28 -0500 Subject: [M3devel] enable/disableswitching around external calls? In-Reply-To: References: Message-ID: No way! I don't understand your problem. Are you saying you have thread-unsafe C code? What is the problem. Please don't do damage here! On Dec 27, 2010, at 5:35 AM, Jay K wrote: > I noticed calls to free in M3toC missing Enable/DisableSwitching. > > I'm going to generalize this, somewhat, in m3core.h, but that still leaves a fair number of custom wrappers. > > This area seems extremely error prone and extremely difficult to get test coverage on. > > These functions only do anything for user threads. > Which we only use by default on OpenBSD. > > How about the frontend emit the calls around any external calls? > > Theory being: external calls are rare? > > Perhaps frontend/m3middle would know if user threads are in use and only emit the calls in that case. Perhaps. > I don't like sprinking much target-specific information around. > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 27 18:23:35 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Dec 2010 12:23:35 -0500 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, <20101227101421.38A6A1A205B@async.async.caltech.edu> Message-ID: Rather than cluttering up CVS, why not put it in the bug-tracker? That's what it is for! Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 27, 2010, at 5:17 AM, Jay K wrote: > Can you put all your code in our CVS repository? > > > "../I386_DARWIN/FSSchemeStubs.m3", line 434: 2 code generation errors > > There is a way to get that to show more information.. > Or does it already? > > - Jay > > > To: m3devel at elegosoft.com > > Date: Mon, 27 Dec 2010 02:14:21 -0800 > > From: mika at async.caltech.edu > > Subject: Re: [M3devel] compiler problems on Snow Leopard > > > > I upgraded to the CVS head and now I get the following: > > > > ... > > "../I386_DARWIN/FSSchemeStubs.m3", line 872: warning: unreachable statement > > "../I386_DARWIN/FSSchemeStubs.m3", line 903: warning: unreachable statement > > "../I386_DARWIN/FSSchemeStubs.m3", line 434: 2 code generation errors > > 1 error and 23 warnings encountered > > new exporters -> recompiling FSSchemeStubs.i3 > > ... > > > > The source code is: > > > > TYPE FS_Iterator_Surrogate = FS.Iterator OBJECT (* line 434 *) > > interp : Scheme.T; > > next_slot : SchemeObject.T := NIL; > > close_slot : SchemeObject.T := NIL; > > nextWithStatus_slot : SchemeObject.T := NIL; > > OVERRIDES > > next := FS_Iterator_next_default; > > close := FS_Iterator_close_default; > > nextWithStatus := FS_Iterator_nextWithStatus_default; > > END; > > > > Mika > > > > Mika Nystrom writes: > > >Hi everyone, > > > > > >Well I was able to get past all my linking issues (mostly questions > > >of dynamic vs. static linking and how to do it, which seems to change from > > >version to version...) > > > > > >But now I did hit a real problem. > > > > > >"../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** unaligne > > >d store type=6 s/o/a=32/0/32 > > >"../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** unaligne > > >d load_indirect type=6 s/a=32/32 > > > > > >Here is the code, but it's not likely to be of much help... > > > > > >PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.T RAIS > > >ES { Scheme.E } = > > > BEGIN > > > VAR res : SchemePair.T:=NIL; BEGIN > > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),T > > >oScheme_Atom_T(x.type)),res); > > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modifica > > >tionTime"),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); > > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),T > > >oScheme_VAL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) > > > RETURN res > > > END > > > END ToScheme_File_Status; > > > > > > > > >... > > > > > >PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0, LONGI > > >NT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = > > > BEGIN > > > RETURN ToScheme_LONGINT(x) (* line 981 *) > > > END ToScheme_VAL0LONGINT__VAL16778080LONGINT; > > > > > > > > >for reference, ToScheme_LONGINT is: > > > > > >PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISES { S > > >cheme.E } = > > > BEGIN > > > WITH ref = NEW(REF LONGINT) DO > > > ref^ := x; > > > RETURN SchemeModula3Types.ToScheme_LONGINT(ref) > > > END > > > END ToScheme_LONGINT; > > > > > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Dec 27 19:54:53 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Dec 2010 10:54:53 -0800 Subject: [M3devel] another Snow Leopard compiler crash In-Reply-To: References: <20101227101653.307241A205B@async.async.caltech.edu> Message-ID: <20101227185453.97CE51A205B@async.async.caltech.edu> No I had to upgrade the backend to get it to work at all, it's at head too (as of 4-5 days ago). Tony Hosking writes: >Which version of the backend are you using? Release? There has been so = >much churn in the trunk lately that I have lost track of things. > > > >Antony Hosking | Associate Professor | Computer Science | Purdue = From hosking at cs.purdue.edu Mon Dec 27 20:36:14 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Dec 2010 14:36:14 -0500 Subject: [M3devel] another Snow Leopard compiler crash In-Reply-To: <20101227185453.97CE51A205B@async.async.caltech.edu> References: <20101227101653.307241A205B@async.async.caltech.edu> <20101227185453.97CE51A205B@async.async.caltech.edu> Message-ID: OK. Jay? On Dec 27, 2010, at 1:54 PM, Mika Nystrom wrote: > No I had to upgrade the backend to get it to work at all, it's at head > too (as of 4-5 days ago). > > Tony Hosking writes: >> Which version of the backend are you using? Release? There has been so = >> much churn in the trunk lately that I have lost track of things. >> >> >> >> Antony Hosking | Associate Professor | Computer Science | Purdue = From jay.krell at cornell.edu Mon Dec 27 22:41:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 21:41:31 +0000 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , Message-ID: > Rather than cluttering up CVS, why not put it in the bug-tracker? That's what it is for! It is large. It is more code that could be repeatedly tested, by building the entire "system", for a gradually growing definition of "system". We have had a number of problems that only appear in one or two or a few pieces of code. e.g. the removal of referenced nested functions. e.g. optimizations causing compilation to fail (which this appears to be as well). A smaller example would be nice, but that is more work to get. - Jay From: hosking at cs.purdue.edu Date: Mon, 27 Dec 2010 12:23:35 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] compiler problems on Snow Leopard Rather than cluttering up CVS, why not put it in the bug-tracker? That's what it is for! Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 27, 2010, at 5:17 AM, Jay K wrote:Can you put all your code in our CVS repository? > "../I386_DARWIN/FSSchemeStubs.m3", line 434: 2 code generation errors There is a way to get that to show more information.. Or does it already? - Jay > To: m3devel at elegosoft.com > Date: Mon, 27 Dec 2010 02:14:21 -0800 > From: mika at async.caltech.edu > Subject: Re: [M3devel] compiler problems on Snow Leopard > > I upgraded to the CVS head and now I get the following: > > ... > "../I386_DARWIN/FSSchemeStubs.m3", line 872: warning: unreachable statement > "../I386_DARWIN/FSSchemeStubs.m3", line 903: warning: unreachable statement > "../I386_DARWIN/FSSchemeStubs.m3", line 434: 2 code generation errors > 1 error and 23 warnings encountered > new exporters -> recompiling FSSchemeStubs.i3 > ... > > The source code is: > > TYPE FS_Iterator_Surrogate = FS.Iterator OBJECT (* line 434 *) > interp : Scheme.T; > next_slot : SchemeObject.T := NIL; > close_slot : SchemeObject.T := NIL; > nextWithStatus_slot : SchemeObject.T := NIL; > OVERRIDES > next := FS_Iterator_next_default; > close := FS_Iterator_close_default; > nextWithStatus := FS_Iterator_nextWithStatus_default; > END; > > Mika > > Mika Nystrom writes: > >Hi everyone, > > > >Well I was able to get past all my linking issues (mostly questions > >of dynamic vs. static linking and how to do it, which seems to change from > >version to version...) > > > >But now I did hit a real problem. > > > >"../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** unaligne > >d store type=6 s/o/a=32/0/32 > >"../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** unaligne > >d load_indirect type=6 s/a=32/32 > > > >Here is the code, but it's not likely to be of much help... > > > >PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.T RAIS > >ES { Scheme.E } = > > BEGIN > > VAR res : SchemePair.T:=NIL; BEGIN > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),T > >oScheme_Atom_T(x.type)),res); > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modifica > >tionTime"),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),T > >oScheme_VAL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) > > RETURN res > > END > > END ToScheme_File_Status; > > > > > >... > > > >PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0, LONGI > >NT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = > > BEGIN > > RETURN ToScheme_LONGINT(x) (* line 981 *) > > END ToScheme_VAL0LONGINT__VAL16778080LONGINT; > > > > > >for reference, ToScheme_LONGINT is: > > > >PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISES { S > >cheme.E } = > > BEGIN > > WITH ref = NEW(REF LONGINT) DO > > ref^ := x; > > RETURN SchemeModula3Types.ToScheme_LONGINT(ref) > > END > > END ToScheme_LONGINT; > > > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 28 11:48:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Dec 2010 10:48:58 +0000 Subject: [M3devel] C/Modula-3 interop with smaller than word/register parameters? In-Reply-To: References: Message-ID: (same question for return values -- use INTEGER/ptrdiff_t instead of int?) - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: C/Modula-3 interop with smaller than word/register parameters? Date: Tue, 28 Dec 2010 10:47:16 +0000 Are we super confident that passing an "int" (Ctypes.int) from Modula-3 to C will handle the upper bits correctly, for systems with 64bit registers, register-passing calling conventions? That is, zero or sign extended, if the ABI mandates it? I realize, on the C side, the upper bits may or may not be ignored, depending on the ABI. Maybe I'm being too paranoid. Maybe I should stick to ptrdiff_t/INTEGER parameters? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 28 11:47:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Dec 2010 10:47:16 +0000 Subject: [M3devel] C/Modula-3 interop with smaller than word/register parameters? Message-ID: Are we super confident that passing an "int" (Ctypes.int) from Modula-3 to C will handle the upper bits correctly, for systems with 64bit registers, register-passing calling conventions? That is, zero or sign extended, if the ABI mandates it? I realize, on the C side, the upper bits may or may not be ignored, depending on the ABI. Maybe I'm being too paranoid. Maybe I should stick to ptrdiff_t/INTEGER parameters? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 29 10:53:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Dec 2010 09:53:27 +0000 Subject: [M3devel] gui problems? BadBricks? columns? Message-ID: Could anyone look into BadBricks and columns? They see very broken -- don't seem to accept input. BadBricks occasionally does. tetris and Juno seem ok. mentor probably also though I didn't try today. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 29 13:45:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Dec 2010 12:45:58 +0000 Subject: [M3devel] ternary operator Message-ID: C code: m.swap32 = swapped ? swap32 : no_swap32; m.swap64 = swapped ? swap64 : no_swap64; m.macho_header_size = m64 ? sizeof(macho_header64_t) : sizeof(macho_header32_t); Modula-3? file.swap32 := no_swap32; file.swap64 := no_swap64; IF swapped THEN file.swap32 := swap32; file.swap64 := swap64; END; file.header_size := (ORD(m64) * BYTESIZE(header64_t)) + (ORD(NOT m64) * BYTESIZE(header32_t)); I don't like either of those forms nor IF swapped THEN file.swap32 := swap32; file.swap64 := swap64; ELSE file.swap32 := no_swap32; file.swap64 := no_swap64; END; If static type inference was more prevalent, I wouldn't mind like: m.swap32 = {no_swap32, swap32}[ORD(swapped)]; m.swap64 = {no_swap64, swap64}[ORD(swapped)]; m.macho_header_size = {sizeof(macho_header32_t), sizeof(macho_header64_t)}[ORD m64]; but I assume {no_swap32, swap32} has to be a typed constant... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Wed Dec 29 16:38:16 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 29 Dec 2010 10:38:16 -0500 Subject: [M3devel] ternary operator In-Reply-To: References: Message-ID: <20101229153816.GA17912@topoi.pooq.com> On Wed, Dec 29, 2010 at 12:45:58PM +0000, Jay K wrote: > > C code: > > m.swap32 = swapped ? swap32 : no_swap32; > m.swap64 = swapped ? swap64 : no_swap64; > m.macho_header_size = m64 ? sizeof(macho_header64_t) : sizeof(macho_header32_t); Algol 60 code: m.swap32 := IF swapped THEN swap32 ELSE no_swap32; m.swap64 := IF swapped THEN swap64 ELSE no_swap64; ...(but no such thing as sizeof)... Algol 68 code: m.swap32 := IF swapped THEN swap32 ELSE no_swap32 FI; m.swap64 := IF swapped THEN swap64 ELSE no_swap64 FI; ...(but no such thing as sizeof)... > > > Modula-3? > > > file.swap32 := no_swap32; > file.swap64 := no_swap64; > IF swapped THEN > file.swap32 := swap32; > file.swap64 := swap64; > END; > file.header_size := (ORD(m64) * BYTESIZE(header64_t)) + (ORD(NOT m64) * BYTESIZE(header32_t)); > > > > I don't like either of those forms nor > > > IF swapped THEN > > file.swap32 := swap32; > > file.swap64 := swap64; > > ELSE > > file.swap32 := no_swap32; > > > file.swap64 := no_swap64; > > > END; > > > > If static type inference was more prevalent, I wouldn't mind like: > > > m.swap32 = {no_swap32, swap32}[ORD(swapped)]; > > m.swap64 = {no_swap64, swap64}[ORD(swapped)]; > > m.macho_header_size = {sizeof(macho_header32_t), sizeof(macho_header64_t)}[ORD m64]; > > > > but I assume {no_swap32, swap32} has to be a typed constant... Abd if it no_awap32 and swap32 were como,licated expressions, it would waste time evaluating things never used. > > > - Jay > From hosking at cs.purdue.edu Wed Dec 29 17:36:40 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 29 Dec 2010 11:36:40 -0500 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: References: Message-ID: These used to work perfectly well. This is a regression. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 29, 2010, at 4:53 AM, Jay K wrote: > Could anyone look into BadBricks and columns? > They see very broken -- don't seem to accept input. > BadBricks occasionally does. > > > tetris and Juno seem ok. > mentor probably also though I didn't try today. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Dec 29 20:06:57 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 29 Dec 2010 19:06:57 +0000 (GMT) Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: Message-ID: <472423.41361.qm@web29708.mail.ird.yahoo.com> Hi all: It seemes to me they should, but currently are not in the standard build package list? Besides could be a problem in the threading? That's why I still like the traditional package, the scheduler might need adjustments, but still it has some nice things like @M3nopreemption, it seems John Polstra wrote something about using it on Digital Unix to run cvsup, see: Are there any cases of test no this runtime parameter? http://www.mavetju.org/mail/view_message.php?list=freebsd-hubs&id=551523 Thanks in advance --- El mi?, 29/12/10, Tony Hosking escribi?: De: Tony Hosking Asunto: Re: [M3devel] gui problems? BadBricks? columns? Para: "Jay K" CC: "m3devel" Fecha: mi?rcoles, 29 de diciembre, 2010 11:36 These used to work perfectly well. ?This is a regression. Antony Hosking?|?Associate Professor?| Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice?+1 765 494 6001 |?Mobile?+1 765 427 5484 On Dec 29, 2010, at 4:53 AM, Jay K wrote: Could anyone look into BadBricks and columns? They see very broken -- don't seem to accept input. BadBricks occasionally does. tetris and Juno seem ok. mentor probably also though I didn't try today. ?- Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Thu Dec 30 00:51:35 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 29 Dec 2010 23:51:35 +0000 (GMT) Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: <472423.41361.qm@web29708.mail.ird.yahoo.com> Message-ID: <60437.40903.qm@web29717.mail.ird.yahoo.com> Hi all: this reminds me that we need anyway to proof the system on errors like locking and anything else, I guess we can try again of the folks in the HP research lab if they would have the sources of the ESC/Modula-3 checker compile them for us and if they agree like before they did with the ESC/Java to make a release for us. I think they planned to do it, just that, nobody gave any new version DEC SRC M3, and it was one of the last things to be scheduled to be released. The original post explaining this same reason is here inside DEC: http://groups.google.com/group/comp.lang.modula3/browse_thread/thread/246542d2609608c7/6e9f7b0a0dd35ce9?hl=en&ie=UTF-8&q=modula3+release+3.6#6e9f7b0a0dd35ce9 Perhaps if we enough petitions we will have some day, what do you think? Perhaps is worth the time, the most difficult thing is finding it, but I guess it would be in the same part they worked or a file server over there, if they allow someone a permission to seek in their files, is just that, we can try to find it. I hope so. I mean what is the reason for keeping it if they did it to use it and explore it, and just because of time they didn't published. Have a nice and happy new year folks! --- El mi?, 29/12/10, Daniel Alejandro Benavides D. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] gui problems? BadBricks? columns? Para: "Jay K" , "Tony Hosking" CC: "m3devel" Fecha: mi?rcoles, 29 de diciembre, 2010 14:06 Hi all: It seemes to me they should, but currently are not in the standard build package list? Besides could be a problem in the threading? That's why I still like the traditional package, the scheduler might need adjustments, but still it has some nice things like @M3nopreemption, it seems John Polstra wrote something about using it on Digital Unix to run cvsup, see: Are there any cases of test no this runtime parameter? http://www.mavetju.org/mail/view_message.php?list=freebsd-hubs&id=551523 Thanks in advance --- El mi?, 29/12/10, Tony Hosking escribi?: De: Tony Hosking Asunto: Re: [M3devel] gui problems? BadBricks? columns? Para: "Jay K" CC: "m3devel" Fecha: mi?rcoles, 29 de diciembre, 2010 11:36 These used to work perfectly well. ?This is a regression. Antony Hosking?|?Associate Professor?| Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice?+1 765 494 6001 |?Mobile?+1 765 427 5484 On Dec 29, 2010, at 4:53 AM, Jay K wrote: Could anyone look into BadBricks and columns? They see very broken -- don't seem to accept input. BadBricks occasionally does. tetris and Juno seem ok. mentor probably also though I didn't try today. ?- Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 30 01:27:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 00:27:43 +0000 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: <60437.40903.qm@web29717.mail.ird.yahoo.com> References: <472423.41361.qm@web29708.mail.ird.yahoo.com>, <60437.40903.qm@web29717.mail.ird.yahoo.com> Message-ID: >These used to work perfectly well. This is a regression. I think not in a long time. Can anyone dig around? > It seemes to me they should, but currently are not in the standard build package list? Yes they are. > @M3nopreemption Probably something to do with user threads and not possible these days. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Thu Dec 30 02:23:12 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 29 Dec 2010 20:23:12 -0500 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: <60437.40903.qm@web29717.mail.ird.yahoo.com> References: <472423.41361.qm@web29708.mail.ird.yahoo.com> <60437.40903.qm@web29717.mail.ird.yahoo.com> Message-ID: Daniel et al: I tried a year or so ago to pursue getting the sources for the ESC. I'd have to dig up my old emails, but my recollection is that I ran into a dead end getting the sources and the permission to put them in our repository. I don't think the Modula-3 edition was kept up when the project moved on to other languages. Regards, Randy Coleburn From: Daniel Alejandro Benavides D. [mailto:dabenavidesd at yahoo.es] Sent: Wednesday, December 29, 2010 6:52 PM To: Jay K; Tony Hosking Cc: m3devel Subject: Re: [M3devel] gui problems? BadBricks? columns? Hi all: this reminds me that we need anyway to proof the system on errors like locking and anything else, I guess we can try again of the folks in the HP research lab if they would have the sources of the ESC/Modula-3 checker compile them for us and if they agree like before they did with the ESC/Java to make a release for us. I think they planned to do it, just that, nobody gave any new version DEC SRC M3, and it was one of the last things to be scheduled to be released. The original post explaining this same reason is here inside DEC: http://groups.google.com/group/comp.lang.modula3/browse_thread/thread/246542d2609608c7/6e9f7b0a0dd35ce9?hl=en&ie=UTF-8&q=modula3+release+3.6#6e9f7b0a0dd35ce9 Perhaps if we enough petitions we will have some day, what do you think? Perhaps is worth the time, the most difficult thing is finding it, but I guess it would be in the same part they worked or a file server over there, if they allow someone a permission to seek in their files, is just that, we can try to find it. I hope so. I mean what is the reason for keeping it if they did it to use it and explore it, and just because of time they didn't published. Have a nice and happy new year folks! --- El mi?, 29/12/10, Daniel Alejandro Benavides D. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] gui problems? BadBricks? columns? Para: "Jay K" , "Tony Hosking" CC: "m3devel" Fecha: mi?rcoles, 29 de diciembre, 2010 14:06 Hi all: It seemes to me they should, but currently are not in the standard build package list? Besides could be a problem in the threading? That's why I still like the traditional package, the scheduler might need adjustments, but still it has some nice things like @M3nopreemption, it seems John Polstra wrote something about using it on Digital Unix to run cvsup, see: Are there any cases of test no this runtime parameter? http://www.mavetju.org/mail/view_message.php?list=freebsd-hubs&id=551523 Thanks in advance --- El mi?, 29/12/10, Tony Hosking escribi?: De: Tony Hosking Asunto: Re: [M3devel] gui problems? BadBricks? columns? Para: "Jay K" CC: "m3devel" Fecha: mi?rcoles, 29 de diciembre, 2010 11:36 These used to work perfectly well. This is a regression. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 29, 2010, at 4:53 AM, Jay K wrote: Could anyone look into BadBricks and columns? They see very broken -- don't seem to accept input. BadBricks occasionally does. tetris and Juno seem ok. mentor probably also though I didn't try today. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Thu Dec 30 02:26:38 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 29 Dec 2010 20:26:38 -0500 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: References: <472423.41361.qm@web29708.mail.ird.yahoo.com>, <60437.40903.qm@web29717.mail.ird.yahoo.com> Message-ID: Both badbricks and columns seem to be working for me on Windows 7. Regards, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Wednesday, December 29, 2010 7:28 PM To: dabenavidesd at yahoo.es; Tony Cc: m3devel Subject: Re: [M3devel] gui problems? BadBricks? columns? >These used to work perfectly well. This is a regression. I think not in a long time. Can anyone dig around? > It seemes to me they should, but currently are not in the standard build package list? Yes they are. > @M3nopreemption Probably something to do with user threads and not possible these days. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Dec 30 04:26:37 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 29 Dec 2010 22:26:37 -0500 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: References: <472423.41361.qm@web29708.mail.ird.yahoo.com> <60437.40903.qm@web29717.mail.ird.yahoo.com> Message-ID: <20101230032636.GA31254@topoi.pooq.com> On Wed, Dec 29, 2010 at 08:23:12PM -0500, Coleburn, Randy wrote: > Daniel et al: > > I tried a year or so ago to pursue getting the sources for the ESC. > I'd have to dig up my old emails, but my recollection is that I ran into a dead end getting the sources and the permission to put them in our repository. > I don't think the Modula-3 edition was kept up when the project moved on to other languages. What does the ESC do that's relevant to threading? I mean, not just an answer like "deadlock and race detection", but what algorithms does it use to accomplish it? Does the Modula 3 compiler construct the proper data structures that could provide the raw data those algorithms would need? How much work would it be to reimplement this from scratch? -- hendrik From hosking at cs.purdue.edu Thu Dec 30 07:39:16 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Dec 2010 01:39:16 -0500 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: References: <472423.41361.qm@web29708.mail.ird.yahoo.com>, <60437.40903.qm@web29717.mail.ird.yahoo.com> Message-ID: <40D2C08F-4A14-43DE-B3DF-660BC2266001@cs.purdue.edu> I know I have used them in the last year or so. On Dec 29, 2010, at 7:27 PM, Jay K wrote: > >These used to work perfectly well. This is a regression. > > I think not in a long time. Can anyone dig around? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 30 10:45:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 09:45:51 +0000 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: <40D2C08F-4A14-43DE-B3DF-660BC2266001@cs.purdue.edu> References: <472423.41361.qm@web29708.mail.ird.yahoo.com>, , <60437.40903.qm@web29717.mail.ird.yahoo.com>, , <40D2C08F-4A14-43DE-B3DF-660BC2266001@cs.purdue.edu> Message-ID: Release 5.8.6 I386_DARWIN BadBricks and columns run locally don't work on MacOSX 10.5. They come up and draw reasonably, but they don't accept any mouse or keyboard input. I'll try some other versions, platforms, X servers, though I know several current don't work remotely to MacOSX 10.5. I'd be curious to hear from others. - Jay From: hosking at cs.purdue.edu Date: Thu, 30 Dec 2010 01:39:16 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] gui problems? BadBricks? columns? I know I have used them in the last year or so. On Dec 29, 2010, at 7:27 PM, Jay K wrote: >These used to work perfectly well. This is a regression. I think not in a long time. Can anyone dig around? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 30 11:13:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 10:13:47 +0000 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: References: <472423.41361.qm@web29708.mail.ird.yahoo.com>, , , <60437.40903.qm@web29717.mail.ird.yahoo.com>, , , , <40D2C08F-4A14-43DE-B3DF-660BC2266001@cs.purdue.edu>, Message-ID: LINUXLIBC6 5.4.0 just doesn't work -- its m3bundle segfaults right away.. cm3-min-POSIX-FreeBSD4-5.4.0.tgz on FreeBSD 4 the cminstall and cm3 right away hit bad syscall.. I might try bootstrapping the modern tree to FreeBSD 4 and try building 5.4.0 there... - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Thu, 30 Dec 2010 09:45:51 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] gui problems? BadBricks? columns? Release 5.8.6 I386_DARWIN BadBricks and columns run locally don't work on MacOSX 10.5. They come up and draw reasonably, but they don't accept any mouse or keyboard input. I'll try some other versions, platforms, X servers, though I know several current don't work remotely to MacOSX 10.5. I'd be curious to hear from others. - Jay From: hosking at cs.purdue.edu Date: Thu, 30 Dec 2010 01:39:16 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] gui problems? BadBricks? columns? I know I have used them in the last year or so. On Dec 29, 2010, at 7:27 PM, Jay K wrote: >These used to work perfectly well. This is a regression. I think not in a long time. Can anyone dig around? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Dec 30 12:23:14 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Dec 2010 12:23:14 +0100 Subject: [M3devel] CM3 status Message-ID: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com> Hi all, after reading a couple of Modula-3 mails again after some time of 'abstinence' I'm a little bit confused about the state of the code and the direction of development. I see that several different failures and ideas are discussed, but don't seem to get resolved; none of them is documented in our Trac instance as far as I know. Some things I remember offhand: o at least 2 different compiler/assembler problems on Darwin/Snow Leopard o current gcc not working on Solaris (?!) o stack walker code abandoned o possibly unsafe OS calls in new C code (this may be a wrong deduction from my side) o GUI input not working for BadBricks and other games (only on Darwin?) o no clean way for exception handling with current gcc o still alignment issues I'm concerned that things get tried out, don't work properly for all our target platforms, but are left then and not cleaned up and something else gets tried. I'm not sure this is correct, it is just me feeling unwell after reading all those mails. Hudson and Tinderbox status seem to be mostly OK though, but I haven't checked in detail (FreeBSD failing was a disk failure on my system recently). But the tests don't cover all the things we should check. I think it would be good to have an overview of the projects/work that is in progress or pending and its status. For example, we've imported a new gcc version, but that doesn't seem to work well on all targets, or does it? If not, how are we going to address this? Use older versions on some platforms? Can I read up on that somewhere? I'd like to suggest to simply use our Trac WiKi to document the ongoing work (everybody can get write access to that on request) and to record all errors, failures and major tasks there as issues. This should help everybody to participate and make me much more relaxed if I consider the M3 emails (if anybody should care about my personal discomfort at all :-) Just for reference: the trac instance can be found at https://projects.elego.de/cm3 Several of the committers should already have access, and using the WiKi and the issue tracker should not be much more work than writing emails. But the information will be easier to access then. I hope to have offended nobody by this; I just wanted to make a suggestion how to improve collaboration and discussion. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Dec 30 12:42:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 11:42:13 +0000 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: References: <472423.41361.qm@web29708.mail.ird.yahoo.com>,,, , <60437.40903.qm@web29717.mail.ird.yahoo.com>, ,,, , , <40D2C08F-4A14-43DE-B3DF-660BC2266001@cs.purdue.edu>, , , Message-ID: ok, well, I386_DARWIN head remoted to Cygwin/X works. Something about Mac X Server maybe. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Thu, 30 Dec 2010 10:13:47 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] gui problems? BadBricks? columns? LINUXLIBC6 5.4.0 just doesn't work -- its m3bundle segfaults right away.. cm3-min-POSIX-FreeBSD4-5.4.0.tgz on FreeBSD 4 the cminstall and cm3 right away hit bad syscall.. I might try bootstrapping the modern tree to FreeBSD 4 and try building 5.4.0 there... - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Thu, 30 Dec 2010 09:45:51 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] gui problems? BadBricks? columns? Release 5.8.6 I386_DARWIN BadBricks and columns run locally don't work on MacOSX 10.5. They come up and draw reasonably, but they don't accept any mouse or keyboard input. I'll try some other versions, platforms, X servers, though I know several current don't work remotely to MacOSX 10.5. I'd be curious to hear from others. - Jay From: hosking at cs.purdue.edu Date: Thu, 30 Dec 2010 01:39:16 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] gui problems? BadBricks? columns? I know I have used them in the last year or so. On Dec 29, 2010, at 7:27 PM, Jay K wrote: >These used to work perfectly well. This is a regression. I think not in a long time. Can anyone dig around? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Dec 30 13:04:11 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Dec 2010 13:04:11 +0100 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: References: <472423.41361.qm@web29708.mail.ird.yahoo.com>,,, , <60437.40903.qm@web29717.mail.ird.yahoo.com>, ,,, , , <40D2C08F-4A14-43DE-B3DF-660BC2266001@cs.purdue.edu>, , , Message-ID: <20101230130411.mgdi3tjdioocg40g@mail.elegosoft.com> Quoting Jay K : > > ok, well, I386_DARWIN head remoted to Cygwin/X works. > Something about Mac X Server maybe. My 2 cent (tries): % ll /usr/local/cm3/bin/BadBricks -rwxrwxr-x 1 wagner m3 3380338 19 Nov 20:37 /usr/local/cm3/bin/BadBricks* works OK. % ll /ad0e/home/hudson/work/cm3-inst/luthien/current--all-pkgs/bin/BadBricks -rwxr-xr-x 1 hudson hudson 90590 29 Dec 13:46 /ad0e/home/hudson/work/cm3-inst/luthien/current--all-pkgs/bin/BadBricks* runs, but incorrectly displays 0 for all bricks :-( Olaf > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Thu, 30 Dec 2010 10:13:47 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] gui problems? BadBricks? columns? > > > > > > > > > LINUXLIBC6 5.4.0 just doesn't work -- its m3bundle segfaults right away.. > cm3-min-POSIX-FreeBSD4-5.4.0.tgz on FreeBSD 4 the cminstall and cm3 > right away hit bad syscall.. > I might try bootstrapping the modern tree to FreeBSD 4 and try > building 5.4.0 there... > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Thu, 30 Dec 2010 09:45:51 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] gui problems? BadBricks? columns? > > > > > > > > > Release 5.8.6 I386_DARWIN BadBricks and columns run locally don't > work on MacOSX 10.5. > They come up and draw reasonably, but they don't accept any mouse or > keyboard input. > I'll try some other versions, platforms, X servers, though I know > several current don't work remotely to MacOSX 10.5. > I'd be curious to hear from others. > > - Jay > > From: hosking at cs.purdue.edu > Date: Thu, 30 Dec 2010 01:39:16 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] gui problems? BadBricks? columns? > > > > I know I have used them in the last year or so. > > > On Dec 29, 2010, at 7:27 PM, Jay K wrote: >These used to work > perfectly well. This is a regression. > > I think not in a long time. Can anyone dig around? > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Dec 30 13:01:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 12:01:39 +0000 Subject: [M3devel] CM3 status In-Reply-To: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com> References: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com> Message-ID: > o at least 2 different compiler/assembler problems on Darwin/Snow Leopard Needs more investigation. Occurs in code not in our tree, with optimization. The error message fyi is one that people occasionally see with mainline gcc also, though hopefully not in recent releases. Something about a shortage of registers. A significant codebase, not easily built, no small reproduction case yet presented or in hand. Some of the problems are in release 5.8.6 but fixed in head. But not all understood. I suggest the code be added to our CVS and be made buildable and regularly built there. > o current gcc not working on Solaris (?!) I don't know what this is referring to. Do you mean 4.5 vs. 4.3? Well, sort of but really. Keep reading. > o stack walker code abandoned Tony ok'ed this for Solaris/sparc32 a few months ago. I couldn't get it working with gcc 4.5, not even without optimization. That was the last step in moving off of gcc 4.3 backend. Alpha/OSF also doesn't work. I didn't look much into it, and I really don't think it matters. It is an extremely little used platform. This year I saw it work on 4.0 and 5.1 but otherwise it had been unused for several years I believe, and I don't see its use continuing much. Upgrade of Solaris/sparc32 from gcc 4.3 to 4.5: 2010-10-13 11:18 jkrell * m3-sys/cminstall/src/config-no-install/SPARC32_SOLARIS.common, m3-sys/m3cc/gcc/gcc/m3cg/parse.c, m3-sys/m3cc/src/clean_marker.txt, m3-sys/m3cc/src/m3makefile, m3-libs/m3core/src/runtime/m3makefile, m3-sys/m3middle/src/Target.m3, m3-libs/m3core/src/runtime/SOLgnu/m3makefile, m3-libs/m3core/src/runtime/SOLgnu/m3makefile-old, m3-libs/m3core/src/runtime/SOLsun/m3makefile, m3-libs/m3core/src/runtime/SOLsun/m3makefile-old: disable Solaris/sparc32 stack walker switch Solaris/sparc32 to gcc 4.5 backend function.c: make failure to volatilize when setjmp/vfork present an error instead of a warning add missing volatilization pin Solaris/sparc32 at -O1 in the config file as -O2/-O3 were seen to hit internal compiler errors (assertion failures) remove the "all volatile" paths from parse.c (since they were only for Solaris/sparc32's stack walker) Tony ok'ing (in my interpretation) the abandonment of our stack walker: https://mail.elegosoft.com/pipermail/m3devel/2010-October/008019.html At least that was my interpretation. Using gcc's exception handling support and *its* stack walker (libgcc/libunwind) should provide the better and more portable functionality on many platforms. I'm not certain what'd it look like on systems where gcc isn't the usual C compiler (e.g. Solaris) but it's bound to work well on Linux, NetBSD, FreeBSD, OpenBSD, and Solaris using gcc. "more portable" as in, across all architectures. Perhaps I should have stuck back with 4.3 until implementing this however. It is definitely a step backward to not have the stack walker on Solaris/sparc32, but that is the only platform in years that has had one, and it is not terrible to have every platform on gcc 4.5.2 and not sprinkling volatile around. There are some backward steps but definitely a lot forward. I tried using 5.4.0 tonight and I didn't get far. > o possibly unsafe OS calls in new C code (this may be a wrong deduction > from my side) I don't know what this is referring to. The Enable/DisableScheduling? I all but undid that. It should be in a few functions, e.g. malloc/free/realloc/calloc/opendir/readdir/closedir/fopen/fclose. Some of those it already is in. With OpenBSD moving to pthreads it matters less. It only matters for user threads. > o GUI input not working for BadBricks and other games (only on Darwin?) Yes this is still a problem, and occurs in 5.8.6 release, on Darwin local X Server. Doesn't reproduce when remoted to Cygwin/X. Other X apps do work locally. Not understood. It'd be good to get confirmation if/when they ever worked. > o no clean way for exception handling with current gcc This is how things have *always* been, *except* on Alpha/OSF and Solaris/sparc32. Those two platforms have "regressed", but for Solaris/sparc32 it was discussed and Alpha/OSF I really don't think is important. Exception handling has always been very inefficient on all but approx. those two platforms. It has always been desirable to fix. The inefficiency has a few parts. Mainly that "try" costs pthread_getspecific and setjmp. The inefficiency of the actual throw/catch is not as worrisome. > o still alignment issues Details? > I'm concerned that things get tried out, don't work properly for all > our target platforms, but are left then and not cleaned up and something > else gets tried. I'm not sure this is correct, it is just me feeling > unwell after reading all those mails. Not really. > Hudson and Tinderbox status seem to be mostly OK though, but I haven't > checked in detail (FreeBSD failing was a disk failure on my system > recently). But the tests don't cover all the things we should check. Yep I try to remember to check Hudson fairly regularly. I never look at Tinderbox though. > I think it would be good to have an overview of the projects/work that > is in progress or pending and its status. For example, we've imported > a new gcc version, but that doesn't seem to work well on all targets, > or does it? If not, how are we going to address this? Use older versions > on some platforms? Can I read up on that somewhere? All platforms (except NT386) use gcc 4.5.2 for the backend. (I did the upgrade after the release was made but before it was announced; they delay announcement while it propagates to mirrors.) Ok, also ARM_DARWIN hypothetically uses 4.2. Apple forks gcc fairly aggressively. Perhaps we should merge the two forks. Perhaps. ARM_DARWIN isn't really supported currently. Probably that should be worked on. It'd also be interesting to see what Apple did to 4.2 for ppc/x86... > I'd like to suggest to simply use our Trac WiKi to document the ongoing Agreed but I'm lazy. I just throw "bombs" around.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 30 13:19:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 12:19:08 +0000 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: <20101230130411.mgdi3tjdioocg40g@mail.elegosoft.com> References: <472423.41361.qm@web29708.mail.ird.yahoo.com>,,, , , <60437.40903.qm@web29717.mail.ird.yahoo.com>, , , , , , ,,<40D2C08F-4A14-43DE-B3DF-660BC2266001@cs.purdue.edu>, , , , , , , <20101230130411.mgdi3tjdioocg40g@mail.elegosoft.com> Message-ID: > % ll /usr/local/cm3/bin/BadBricks > -rwxrwxr-x 1 wagner m3 3380338 19 Nov 20:37 /usr/local/cm3/bin/BadBricks* > > works OK. > > % ll /ad0e/home/hudson/work/cm3-inst/luthien/current--all-pkgs/bin/BadBricks > -rwxr-xr-x 1 hudson hudson 90590 29 Dec 13:46 > /ad0e/home/hudson/work/cm3-inst/luthien/current--all-pkgs/bin/BadBricks* > > runs, but incorrectly displays 0 for all bricks :-( > Thanks. uname -a ? AMD64_FREEBSD I assume? Huh, wierd, a different seemingly recent regression. That doesn't occur for me I386_DARWIN remoted to Cygwin/X. Need to isolate it...try other platforms...? Maybe I turned optimization off on my system (lately I've been doing everything with -O3 via a local edit, but occasionally I undo that). Imho the problem I'm seeing might have been there forever. Definitely not fully understood yet. I'll try PPC_DARWIN 10.4 as that is handy... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 30 13:14:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 12:14:21 +0000 Subject: [M3devel] m3-libs/m3core/src/runtime/common/Compiler.tmpl? Message-ID: So..I spent a few minutes tonight trying to use/build an old release: 5.4.0. One of the problems I hit was building the 5.4.0 release with a current "I386_FREEBSD" compiler. One of the problems in the system, just a small number of occurences, is m3makefiles having lists of platforms, that don't have current platforms. In some ways this might be inevitable. I have however reduced the problem by using lists of OS (Linux, FreeBSD, etc.) and processor architecture (x86, AMD64, SPARC32, etc.). So new combinations thereof don't require visiting so many places. However this reminded me of something that has bugged me a bit. In m3core: INTERFACE Compiler; (* this is generated by quake code *) enum OS = { POSIX, WIN32} not so bad, hasn't changed in over 10 years enum Platform = { big list of all targets } changes whenever a target is added, fairly often CONST ThisOS = OS.POSIX or OS.WIN32 not so bad CONST ThisPlatform:Platform = ... a small problem, the subject here CONST ThisPlatform_String:TEXT = "..."; not a problem I'd like to remove the enum Platform and ThisPlatform. This increases portability in terms of the ability of older/newer cm3 to build newer/older cm3. i.e...I guess...just...for a cm3 hosted on a renamed platform (I386_LINUX vs. LINUXLIBC6, etc.) It also is one less file to edit when adding a new target. Ideally that number is just one file, though currently it is a few. I'll try it out, see if anything in our tree uses it. Any uses are probably suspicious anyway. Perhaps we should provide the two smaller "composed" enums rename ThisOS to ThisOSType then ThisOS in {Linux, OpenBSD, FreeBSD, Solaris, etc.} and ThisProcessorArchitecture in {x86, AMD64, sparc32, etc.} (possibly x86, sparc, powerpc, and then can check BITSIZE(INTEGER) to get 32/64). The one place I knew of that used this stuff I changed to do something else -- use quake code to produce true/false. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 30 13:26:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 12:26:26 +0000 Subject: [M3devel] CM3 status In-Reply-To: References: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com>, Message-ID: > Alpha/OSF also doesn't work Clarification -- the target works, but not its stack walker. I moved it back to setjmp/longjmp a few months ago when an Alpha/OSF machine was presented to me, when the stack walker didn't work on the first try. This stuff is fairly difficult to debug, reading the Alpha or Sparc assembly to find the mistakes in it, and the payoff is very small... - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Thu, 30 Dec 2010 12:01:39 +0000 Subject: Re: [M3devel] CM3 status > o at least 2 different compiler/assembler problems on Darwin/Snow Leopard Needs more investigation. Occurs in code not in our tree, with optimization. The error message fyi is one that people occasionally see with mainline gcc also, though hopefully not in recent releases. Something about a shortage of registers. A significant codebase, not easily built, no small reproduction case yet presented or in hand. Some of the problems are in release 5.8.6 but fixed in head. But not all understood. I suggest the code be added to our CVS and be made buildable and regularly built there. > o current gcc not working on Solaris (?!) I don't know what this is referring to. Do you mean 4.5 vs. 4.3? Well, sort of but really. Keep reading. > o stack walker code abandoned Tony ok'ed this for Solaris/sparc32 a few months ago. I couldn't get it working with gcc 4.5, not even without optimization. That was the last step in moving off of gcc 4.3 backend. Alpha/OSF also doesn't work. I didn't look much into it, and I really don't think it matters. It is an extremely little used platform. This year I saw it work on 4.0 and 5.1 but otherwise it had been unused for several years I believe, and I don't see its use continuing much. Upgrade of Solaris/sparc32 from gcc 4.3 to 4.5: 2010-10-13 11:18 jkrell * m3-sys/cminstall/src/config-no-install/SPARC32_SOLARIS.common, m3-sys/m3cc/gcc/gcc/m3cg/parse.c, m3-sys/m3cc/src/clean_marker.txt, m3-sys/m3cc/src/m3makefile, m3-libs/m3core/src/runtime/m3makefile, m3-sys/m3middle/src/Target.m3, m3-libs/m3core/src/runtime/SOLgnu/m3makefile, m3-libs/m3core/src/runtime/SOLgnu/m3makefile-old, m3-libs/m3core/src/runtime/SOLsun/m3makefile, m3-libs/m3core/src/runtime/SOLsun/m3makefile-old: disable Solaris/sparc32 stack walker switch Solaris/sparc32 to gcc 4.5 backend function.c: make failure to volatilize when setjmp/vfork present an error instead of a warning add missing volatilization pin Solaris/sparc32 at -O1 in the config file as -O2/-O3 were seen to hit internal compiler errors (assertion failures) remove the "all volatile" paths from parse.c (since they were only for Solaris/sparc32's stack walker) Tony ok'ing (in my interpretation) the abandonment of our stack walker: https://mail.elegosoft.com/pipermail/m3devel/2010-October/008019.html At least that was my interpretation. Using gcc's exception handling support and *its* stack walker (libgcc/libunwind) should provide the better and more portable functionality on many platforms. I'm not certain what'd it look like on systems where gcc isn't the usual C compiler (e.g. Solaris) but it's bound to work well on Linux, NetBSD, FreeBSD, OpenBSD, and Solaris using gcc. "more portable" as in, across all architectures. Perhaps I should have stuck back with 4.3 until implementing this however. It is definitely a step backward to not have the stack walker on Solaris/sparc32, but that is the only platform in years that has had one, and it is not terrible to have every platform on gcc 4.5.2 and not sprinkling volatile around. There are some backward steps but definitely a lot forward. I tried using 5.4.0 tonight and I didn't get far. > o possibly unsafe OS calls in new C code (this may be a wrong deduction > from my side) I don't know what this is referring to. The Enable/DisableScheduling? I all but undid that. It should be in a few functions, e.g. malloc/free/realloc/calloc/opendir/readdir/closedir/fopen/fclose. Some of those it already is in. With OpenBSD moving to pthreads it matters less. It only matters for user threads. > o GUI input not working for BadBricks and other games (only on Darwin?) Yes this is still a problem, and occurs in 5.8.6 release, on Darwin local X Server. Doesn't reproduce when remoted to Cygwin/X. Other X apps do work locally. Not understood. It'd be good to get confirmation if/when they ever worked. > o no clean way for exception handling with current gcc This is how things have *always* been, *except* on Alpha/OSF and Solaris/sparc32. Those two platforms have "regressed", but for Solaris/sparc32 it was discussed and Alpha/OSF I really don't think is important. Exception handling has always been very inefficient on all but approx. those two platforms. It has always been desirable to fix. The inefficiency has a few parts. Mainly that "try" costs pthread_getspecific and setjmp. The inefficiency of the actual throw/catch is not as worrisome. > o still alignment issues Details? > I'm concerned that things get tried out, don't work properly for all > our target platforms, but are left then and not cleaned up and something > else gets tried. I'm not sure this is correct, it is just me feeling > unwell after reading all those mails. Not really. > Hudson and Tinderbox status seem to be mostly OK though, but I haven't > checked in detail (FreeBSD failing was a disk failure on my system > recently). But the tests don't cover all the things we should check. Yep I try to remember to check Hudson fairly regularly. I never look at Tinderbox though. > I think it would be good to have an overview of the projects/work that > is in progress or pending and its status. For example, we've imported > a new gcc version, but that doesn't seem to work well on all targets, > or does it? If not, how are we going to address this? Use older versions > on some platforms? Can I read up on that somewhere? All platforms (except NT386) use gcc 4.5.2 for the backend. (I did the upgrade after the release was made but before it was announced; they delay announcement while it propagates to mirrors.) Ok, also ARM_DARWIN hypothetically uses 4.2. Apple forks gcc fairly aggressively. Perhaps we should merge the two forks. Perhaps. ARM_DARWIN isn't really supported currently. Probably that should be worked on. It'd also be interesting to see what Apple did to 4.2 for ppc/x86... > I'd like to suggest to simply use our Trac WiKi to document the ongoing Agreed but I'm lazy. I just throw "bombs" around.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 30 13:55:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 12:55:31 +0000 Subject: [M3devel] cross builds and netobj/proxy generation Message-ID: I found this problem trying to build Mika's Scheme implementation I hadn't rebuilt all tools to be I386_DARWIN -- some were still AMD64_DARWIN. It seems the proxy code got values for LAST(INTEGER) in it, but they were for the host, not the target. Tools need to not assume they are the same... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 30 15:28:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 14:28:31 +0000 Subject: [M3devel] factoring jmpbuf size via alloca(global constant)? Message-ID: factoring out jmpbuf size? Hey, um, how about something like this: somefile.c: #include extern const int sizeof_jmpbuf = sizeof(jmp_buf); where the frontend would allocate a local jmp_buf, instead issue a call to alloca(sizeof_jmpbuf), actually reading the constant out of the global. Yes I know this is a deoptimization. It is already slow. We hope hope hope to replace it all anyway. This would remove lots of target-specific code in Target.m3. Related, I'm again trying removing from m3core the knowledge of the size/alignment of jmpbuf. Or rather, to see if it really needs it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dknoto at next.com.pl Thu Dec 30 20:09:53 2010 From: dknoto at next.com.pl (Dariusz =?ISO-8859-2?Q?Knoci=F1ski?=) Date: Thu, 30 Dec 2010 20:09:53 +0100 Subject: [M3devel] Array indexing Message-ID: <20101230200953.1b229a27.dknoto@next.com.pl> Hi all, my name is Dariusz Knoci?ski, I am new in this list, it is my first letter. Best wishes for New Year to all. I have a problem with two-dimensional arrays. In my simple source code I can't get value from array indexed by two variables. But, I can get these values by indexing by constants. The program compile successfully but generates idiotic output. Source: MODULE aib EXPORTS Main; IMPORT IO, Fmt; CONST tab = ARRAY [0..2], [0..15] OF CARDINAL { ARRAY OF CARDINAL { 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17 }, ARRAY OF CARDINAL { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 17, 17, 17, 17, 17, 17 }, ARRAY OF CARDINAL { 17, 11, 12, 13, 14, 15, 16, 17, 17, 17, 17, 17, 17, 17, 17, 17 } }; VAR k, l : CARDINAL; BEGIN k := 1; l := 9; IO.Put( "k = " & Fmt.Int(k) & ", " ); IO.Put( "l = " & Fmt.Int(l) & "\n" ); k := tab[k][l]; IO.Put( "k = tab[k][l] => 0x" & Fmt.F( "%02s", Fmt.Unsigned(k)) & "\n" ); k := tab[1][9]; IO.Put( "k = tab[1][9] => 0x" & Fmt.F( "%02s", Fmt.Unsigned(k)) & "\n" ); FOR i := 0 TO 2 DO FOR j := 0 TO 15 DO IO.Put( Fmt.F( " %02s", Fmt.Int( tab[i][j] ) ) ); END; IO.Put( "\n" ); END; END aib. Output: k = 1, l = 9 k = tab[k][l] => 0x00 k = tab[1][9] => 0x0a 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 My system and compiler version is: $ uname -a Linux wenus.next.com.pl 2.6.35.10-74.fc14.x86_64 #1 SMP Thu Dec 23 16:04:50\ UTC 2010 x86_64 x86_64 x86_64 GNU/Linux $ cm3 -version Critical Mass Modula-3 version 5.8.6 last updated: 2010-04-11 compiled: 2010-07-12 20:10:34 configuration: /usr/local/cm3/bin/cm3.cfg host: AMD64_LINUX target: AMD64_LINUX or Critical Mass Modula-3 version d5.9.0 last updated: 2010-07-21 compiled: 2010-12-16 03:15:26 configuration: /usr/local/cm3/bin/cm3.cfg host: AMD64_LINUX quake runtime error: "/usr/local/cm3/bin/cm3.cfg", line 2: quake runtime error:\ undefined variable: SL --procedure-- -line- -file--- 2 /usr/local/cm3/bin/cm3.cfg target: Both compilers generate same results. Best regards DKnoto. From rodney_bates at lcwb.coop Thu Dec 30 21:12:22 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 30 Dec 2010 14:12:22 -0600 Subject: [M3devel] Array indexing In-Reply-To: <20101230200953.1b229a27.dknoto@next.com.pl> References: <20101230200953.1b229a27.dknoto@next.com.pl> Message-ID: <4D1CE7A6.4050409@lcwb.coop> I reproduced this immediately on LINUXLIBC6 and AMD64_LINUX. It's a compiler bug. A version of cm3 several years old, and an old pm3, both with the (much older) gcc backend and the x86 internal backend also all show the same problem. The memory area for each row of tab is getting initialized with dope for an open array, instead of the actual values. Moreover, the dope is not right either, though it's recognizable. Since the open array row constructor is assignable to the fixed array row of tab, the code is correct and the compiler should take care of the representation change. Making tab a VAR instead of CONST shows the same bad behavior. As a workaround, you can change the row constructors to fixed array constructors: CONST tab = ARRAY [0..2], [0..15] OF CARDINAL { ARRAY [0..15] OF CARDINAL { 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17 }, ARRAY [0..15] OF CARDINAL { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 17, 17, 17, 17, 17, 17 }, ARRAY [0..15] OF CARDINAL { 17, 11, 12, 13, 14, 15, 16, 17, 17, 17, 17, 17, 17, 17, 17, 17 } }; and this works as expected: (m3gdb) run Starting program: /home/rodney/proj/m3/exp/dknoto/AMD64_LINUX/prog Can't disable VM GC. Signal Stop Print Pass to program Description SIG64 No No Yes Real-time event 64 [Thread debugging using libthread_db enabled] [New LWP 9108] k = 1, l = 9 k = tab[k][l] => 0x0a k = tab[1][9] => 0x0a 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 01 02 03 04 05 06 07 08 09 10 17 17 17 17 17 17 17 11 12 13 14 15 16 17 17 17 17 17 17 17 17 17 Program exited normally. (m3gdb) Amazing that in all these years, nobody has coded a 2-D array constructor this way before, or at least didn't complain. Rodney Bates Dariusz Knoci?ski wrote: > Hi all, > > my name is Dariusz Knoci?ski, I am new in this list, it is my first letter. > Best wishes for New Year to all. > > I have a problem with two-dimensional arrays. In my simple source code I can't > get value from array indexed by two variables. But, I can get these values by > indexing by constants. The program compile successfully but generates idiotic > output. > > Source: > > MODULE aib EXPORTS Main; > > IMPORT IO, Fmt; > > CONST > tab = ARRAY [0..2], [0..15] OF CARDINAL { > ARRAY OF CARDINAL > { 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17 }, > ARRAY OF CARDINAL > { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 17, 17, 17, 17, 17, 17 }, > ARRAY OF CARDINAL > { 17, 11, 12, 13, 14, 15, 16, 17, 17, 17, 17, 17, 17, 17, 17, 17 } > }; > > VAR > k, l : CARDINAL; > > BEGIN > > k := 1; > l := 9; > > IO.Put( "k = " & Fmt.Int(k) & ", " ); > IO.Put( "l = " & Fmt.Int(l) & "\n" ); > k := tab[k][l]; > IO.Put( "k = tab[k][l] => 0x" & > Fmt.F( "%02s", Fmt.Unsigned(k)) & "\n" ); > > k := tab[1][9]; > IO.Put( "k = tab[1][9] => 0x" & > Fmt.F( "%02s", Fmt.Unsigned(k)) & "\n" ); > > FOR i := 0 TO 2 DO > FOR j := 0 TO 15 DO > IO.Put( Fmt.F( " %02s", Fmt.Int( tab[i][j] ) ) ); > END; > IO.Put( "\n" ); > END; > > END aib. > > Output: > > k = 1, l = 9 > k = tab[k][l] => 0x00 > k = tab[1][9] => 0x0a > 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > My system and compiler version is: > > $ uname -a > > Linux wenus.next.com.pl 2.6.35.10-74.fc14.x86_64 #1 SMP Thu Dec 23 16:04:50\ > UTC 2010 x86_64 x86_64 x86_64 GNU/Linux > > $ cm3 -version > > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-12 20:10:34 > configuration: /usr/local/cm3/bin/cm3.cfg > host: AMD64_LINUX > target: AMD64_LINUX > > or > > Critical Mass Modula-3 version d5.9.0 > last updated: 2010-07-21 > compiled: 2010-12-16 03:15:26 > configuration: /usr/local/cm3/bin/cm3.cfg > host: AMD64_LINUX > quake runtime error: "/usr/local/cm3/bin/cm3.cfg", line 2: quake runtime error:\ > undefined variable: SL > > --procedure-- -line- -file--- > 2 /usr/local/cm3/bin/cm3.cfg > target: > > Both compilers generate same results. > > Best regards > DKnoto. > From dknoto at next.com.pl Thu Dec 30 22:17:19 2010 From: dknoto at next.com.pl (Dariusz =?ISO-8859-2?Q?Knoci=F1ski?=) Date: Thu, 30 Dec 2010 22:17:19 +0100 Subject: [M3devel] Array indexing In-Reply-To: <4D1CE7A6.4050409@lcwb.coop> References: <20101230200953.1b229a27.dknoto@next.com.pl> <4D1CE7A6.4050409@lcwb.coop> Message-ID: <20101230221719.85e9d885.dknoto@next.com.pl> On Thu, 30 Dec 2010 14:12:22 -0600 "Rodney M. Bates" wrote: [...] > As a workaround, you can change the row constructors to fixed array constructors: > > CONST > tab = ARRAY [0..2], [0..15] OF CARDINAL { > ARRAY [0..15] OF CARDINAL > { 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17 }, > ARRAY [0..15] OF CARDINAL > { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 17, 17, 17, 17, 17, 17 }, > ARRAY [0..15] OF CARDINAL > { 17, 11, 12, 13, 14, 15, 16, 17, 17, 17, 17, 17, 17, 17, 17, 17 } > }; > Thankyou very much for workaround. > Amazing that in all these years, nobody has coded a 2-D array constructor this > way before, or at least didn't complain. > > Code similar to this I found on pages in tutorial, in chapter "Array Constructor": tictactoe := ARRAY [1..3], [1..3] OF CHAR{ ARRAY OF CHAR{' ', ' ', ' '}, ARRAY OF CHAR{' ', ' ', ' '}, ARRAY OF CHAR{' ', ' ', ' '} }; Best regards Dariusz Knoci?ski. From dabenavidesd at yahoo.es Thu Dec 30 22:31:04 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 30 Dec 2010 21:31:04 +0000 (GMT) Subject: [M3devel] Array indexing In-Reply-To: <4D1CE7A6.4050409@lcwb.coop> Message-ID: <280842.77354.qm@web29702.mail.ird.yahoo.com> Hi all: it seems the same to me, perhaps this uncovered bug has been there for years or a systematic problem, we would need to apply verification for the compiler intermediate code generation, though might be a problem in the code generation, we don't know, it should be provable that for a given input the Modula-3 compiler will gave the same intermediate code, this would open also a door for optimization, like in HP, was built a compiler like that, it will take some time, but eventually, before we can believe it, we may have the compiler specified front end (still if it were 100000 lines verifying would take 60 years/man, if its 10000, 6 years/man), like the Hoare utopia was to built itself. So between more correct more efficient! --- El jue, 30/12/10, Rodney M. Bates escribi?: > De: Rodney M. Bates > Asunto: Re: [M3devel] Array indexing > Para: "Dariusz Knoci?ski" > CC: m3devel at elegosoft.com > Fecha: jueves, 30 de diciembre, 2010 15:12 > I reproduced this immediately on > LINUXLIBC6 and AMD64_LINUX. It's a compiler bug. > A version of cm3 several years old, and an old pm3, both > with the (much older) > gcc backend and the x86 internal backend also all show the > same problem. > > The memory area for each row of tab is getting initialized > with dope for an > open array, instead of the actual values. Moreover, > the dope is not right > either, though it's recognizable. Since the open > array row constructor is > assignable to the fixed array row of tab, the code is > correct and the compiler > should take care of the representation change. > > Making tab a VAR instead of CONST shows the same bad > behavior. > > As a workaround, you can change the row constructors to > fixed array constructors: > > CONST > tab = ARRAY [0..2], [0..15] OF CARDINAL { > ARRAY [0..15] OF CARDINAL > { 17, 17, 17, 17, 17, 17, > 17, 17, 17, 17, 17, 17, 17, 17, 17, 17 }, > ARRAY [0..15] OF CARDINAL > { 1, 2, > 3, 4, 5, 6, 7, 8, 9, 10, > 17, 17, 17, 17, 17, 17 }, > ARRAY [0..15] OF CARDINAL > { 17, 11, 12, 13, 14, 15, > 16, 17, 17, 17, 17, 17, 17, 17, 17, 17 } > }; > > and this works as expected: > > (m3gdb) run > Starting program: > /home/rodney/proj/m3/exp/dknoto/AMD64_LINUX/prog > Can't disable VM GC. > Signal Stop > Print Pass to program Description > SIG64 No > No Yes > Real-time event 64 > [Thread debugging using libthread_db enabled] > [New LWP 9108] > k = 1, l = 9 > k = tab[k][l] => 0x0a > k = tab[1][9] => 0x0a > 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 > 01 02 03 04 05 06 07 08 09 10 17 17 17 17 17 17 > 17 11 12 13 14 15 16 17 17 17 17 17 17 17 17 17 > > Program exited normally. > (m3gdb) > > Amazing that in all these years, nobody has coded a 2-D > array constructor this > way before, or at least didn't complain. > > > Rodney Bates > > > Dariusz Knoci?ski wrote: > > Hi all, > > > > my name is Dariusz Knoci?ski, I am new in this list, > it is my first letter. > > Best wishes for New Year to all. > > > > I have a problem with two-dimensional arrays. In my > simple source code I can't > > get value from array indexed by two variables. But, I > can get these values by > > indexing by constants. The program compile > successfully but generates idiotic > > output. > > > > Source: > > > > MODULE aib EXPORTS Main; > > > > IMPORT IO, Fmt; > > > > CONST > > tab = ARRAY [0..2], [0..15] OF > CARDINAL { > > ARRAY OF CARDINAL > > { 17, 17, 17, 17, 17, > 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17 }, > > ARRAY OF CARDINAL > { 1, 2, > 3, 4, 5, 6, 7, 8, 9, 10, > 17, 17, 17, 17, 17, 17 }, > > ARRAY OF CARDINAL > { 17, 11, 12, 13, 14, 15, > 16, 17, 17, 17, 17, 17, 17, 17, 17, 17 } > > }; > > > > VAR > > k, l : CARDINAL; > > > > BEGIN > > > > k := 1; > > l := 9; > > > > IO.Put( "k = " & > Fmt.Int(k) & ", " ); > > IO.Put( "l = " & > Fmt.Int(l) & "\n" ); > > k := > tab[k][l]; > > IO.Put( "k = tab[k][l] => > 0x" & Fmt.F( "%02s", Fmt.Unsigned(k)) > & "\n" ); > > > > k := tab[1][9]; > > IO.Put( "k = > tab[1][9] => 0x" & > Fmt.F( "%02s", Fmt.Unsigned(k)) & > "\n" ); > > > > FOR i := 0 TO 2 DO > > FOR j := 0 TO 15 DO > > IO.Put( Fmt.F( " > %02s", Fmt.Int( tab[i][j] ) ) ); > > END; > > IO.Put( "\n" ); > > END; > > > > END aib. > > > > Output: > > > > k = 1, l = 9 > > k = tab[k][l] => 0x00 > > k = tab[1][9] => 0x0a > > 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 > > 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 > > 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 > > > > My system and compiler version is: > > > > $ uname -a > > > > Linux wenus.next.com.pl 2.6.35.10-74.fc14.x86_64 #1 > SMP Thu Dec 23 16:04:50\ > > UTC 2010 x86_64 x86_64 x86_64 > GNU/Linux > > $ cm3 -version > > > > Critical Mass Modula-3 version 5.8.6 > > last updated: 2010-04-11 > > compiled: 2010-07-12 20:10:34 > > configuration: > /usr/local/cm3/bin/cm3.cfg > > host: AMD64_LINUX > > target: AMD64_LINUX > > > > or > > > > Critical Mass Modula-3 version d5.9.0 > > last updated: 2010-07-21 > > compiled: 2010-12-16 03:15:26 > > configuration: > /usr/local/cm3/bin/cm3.cfg > > host: AMD64_LINUX > > quake runtime error: "/usr/local/cm3/bin/cm3.cfg", > line 2: quake runtime error:\ > > undefined variable: SL > > > > --procedure-- -line- -file--- > > > 2 /usr/local/cm3/bin/cm3.cfg > > target: > > Both compilers generate same results. > > > > Best regards > > DKnoto. > > > From dknoto at next.com.pl Thu Dec 30 23:14:42 2010 From: dknoto at next.com.pl (Dariusz =?UTF-8?B?S25vY2nFhHNraQ==?=) Date: Thu, 30 Dec 2010 23:14:42 +0100 Subject: [M3devel] Interpretation of numbers Message-ID: <20101230231442.2f3ee9a3.dknoto@next.com.pl> Hi all, in my spare time I write a lexer to Modula-3 for Scintilla library and I found mistake in numeric constants with explicitly given base number system, eg. octal numbers. This simple program in C generates compiler error: #include int main( void ) { unsigned o; o = 0787; printf( "o = %u\n", o ); return 0; } in gcc 4.5.1 20100924 (Red Hat 4.5.1-4) this is: Numbers.c: In function ?main?: Numbers.c:7:6: error: invalid digit "8" in octal constant but CM3 with analogical program: MODULE Numbers EXPORTS Main; IMPORT IO, Fmt; VAR o : CARDINAL; BEGIN o := 8_787; IO.Put( "o = 8_" & Fmt.Unsigned( o, 8 ) & "\n" ); END Numbers. compiles his properly and the program generate output: o = 8_1007 This is correct number, 519 decimal, but similar mistakes can be difficult to find. Best regards Dariusz Knoci?ski. From rcolebur at SCIRES.COM Thu Dec 30 23:29:50 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Thu, 30 Dec 2010 17:29:50 -0500 Subject: [M3devel] CM3 status In-Reply-To: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com> References: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com> Message-ID: Olaf et al: I think I share the concern you've voiced. My observation from the M3COMMIT log emails is that Jay seems to be the most prolific these days with changes, but I find it impossible to keep track of what problem he is trying to solve. Indeed, it seems he is working on multiple issues at the same time, but it is difficult from the posts to differentiate which issue goes with which posting, and this problem is compounded by the fact that my M3COMMIT/M3DEVEL e-mails don't always seem to be received in chronological order. Thus, it is extremely difficult to know how to channel the limited time I have available into helping cooperate to solve a particular problem. Maybe it would be a good idea when each person posts something to M3COMMIT or M3DEVEL that they tag it up front with a comment or reference to the problem the post is addressing. Another idea, and perhaps your TRAC system supports it, is to assign certain problems to specific individuals who work the problem and report back their solution approach for some type of concurrence before going off on a tangent to solve. This might cut down on some of the subsequent backtracking and reverting changes. It would also allow others to offer constructive comments on the solution approach, even if they don't have time to actually implement the solution. [In reading the posts, I'm seeing many places where work is done, then later someone disagrees with it, and wants the changes reverted.] Even if one person is assigned as the lead for a particular problem, perhaps others could join in on helping solve it, coordinating their effort thru the lead person. I really do want to help as much as I can, and we definitely need to grow the development support base, so anything we can do to foster teamwork and an up-to-date awareness of the major problem areas and proposed solution paths would be helpful I think. I certainly don't want to squash anyone's individual efforts, but right now I don't think we're maximizing our use of the team concept. Regards, Randy Coleburn -----Original Message----- From: Olaf Wagner [mailto:wagner at elegosoft.com] Sent: Thursday, December 30, 2010 6:23 AM To: m3devel at elegosoft.com Subject: [M3devel] CM3 status Hi all, after reading a couple of Modula-3 mails again after some time of 'abstinence' I'm a little bit confused about the state of the code and the direction of development. I see that several different failures and ideas are discussed, but don't seem to get resolved; none of them is documented in our Trac instance as far as I know. Some things I remember offhand: o at least 2 different compiler/assembler problems on Darwin/Snow Leopard o current gcc not working on Solaris (?!) o stack walker code abandoned o possibly unsafe OS calls in new C code (this may be a wrong deduction from my side) o GUI input not working for BadBricks and other games (only on Darwin?) o no clean way for exception handling with current gcc o still alignment issues I'm concerned that things get tried out, don't work properly for all our target platforms, but are left then and not cleaned up and something else gets tried. I'm not sure this is correct, it is just me feeling unwell after reading all those mails. Hudson and Tinderbox status seem to be mostly OK though, but I haven't checked in detail (FreeBSD failing was a disk failure on my system recently). But the tests don't cover all the things we should check. I think it would be good to have an overview of the projects/work that is in progress or pending and its status. For example, we've imported a new gcc version, but that doesn't seem to work well on all targets, or does it? If not, how are we going to address this? Use older versions on some platforms? Can I read up on that somewhere? I'd like to suggest to simply use our Trac WiKi to document the ongoing work (everybody can get write access to that on request) and to record all errors, failures and major tasks there as issues. This should help everybody to participate and make me much more relaxed if I consider the M3 emails (if anybody should care about my personal discomfort at all :-) Just for reference: the trac instance can be found at https://projects.elego.de/cm3 Several of the committers should already have access, and using the WiKi and the issue tracker should not be much more work than writing emails. But the information will be easier to access then. I hope to have offended nobody by this; I just wanted to make a suggestion how to improve collaboration and discussion. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Thu Dec 30 23:55:39 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 30 Dec 2010 14:55:39 -0800 Subject: [M3devel] cross builds and netobj/proxy generation In-Reply-To: References: Message-ID: <20101230225539.0B9A91A205B@async.async.caltech.edu> This is probably a bug in my code, actually. I should represent LAST(INTEGER) as LAST(INTEGER) and not as whatever it evaluates to. Although hm the evaluation probably comes from inside m3tk. That is how m3tk represents subranges (including the "subrange" FIRST(INTEGER)..LAST(INTEGER)). Mika Jay K writes: >--_a816f733-bbaf-451a-ba85-0ff058a4a08f_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >I found this problem trying to build Mika's Scheme implementation >I hadn't rebuilt all tools to be I386_DARWIN -- some were still AMD64_DARWI= >N. >It seems the proxy code got values for LAST(INTEGER) in it=2C but they >were for the host=2C not the target. >Tools need to not assume they are the same... > > > - Jay > = > >--_a816f733-bbaf-451a-ba85-0ff058a4a08f_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >I found this problem trying to build Mika's Scheme implementation
I hadn= >'t rebuilt all tools to be I386_DARWIN -- some were still AMD64_DARWIN.
= >It seems the proxy code got values for LAST(INTEGER) in it=2C but they
w= >ere for the host=2C not the target.
Tools need to not assume they are th= >e same...


 =3B- Jay
> >= > >--_a816f733-bbaf-451a-ba85-0ff058a4a08f_-- From mika at async.caltech.edu Thu Dec 30 23:58:27 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 30 Dec 2010 14:58:27 -0800 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , , Message-ID: <20101230225827.B99371A205B@async.async.caltech.edu> All right, I have been able to whittle down a test for the "code generation error": INTERFACE CG_Error; END CG_Error. MODULE CG_Error; TYPE SchemeObject_T = REFANY; EXCEPTION Scheme_E; PROCEDURE ToScheme_VAL0LONGINT__VAL0LONGINT(READONLY x : [ VAL(0, LONGINT )..VAL(0, LONGINT ) ]) : SchemeObject_T RAISES { Scheme_E } = BEGIN RETURN ToScheme_LONGINT(x) END ToScheme_VAL0LONGINT__VAL0LONGINT; PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject_T RAISES { Scheme_E } = BEGIN WITH ref = NEW(REF LONGINT) DO ref^ := x; END END ToScheme_LONGINT; BEGIN END CG_Error. new source -> compiling CG_Error.i3 new source -> compiling CG_Error.m3 "../src/CG_Error.m3", line 12: warning: exception is never raised: CG_Error.Scheme_E "../src/CG_Error.m3", line 6: warning: not used (ToScheme_VAL0LONGINT__VAL0LONGINT) "../src/CG_Error.m3", line 15: warning: function may not return a value (ToScheme_LONGINT) "../src/CG_Error.m3", line 1: 1 code generation error 1 error and 3 warnings encountered Mika From dabenavidesd at yahoo.es Fri Dec 31 00:13:57 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 30 Dec 2010 23:13:57 +0000 (GMT) Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: <20101230032636.GA31254@topoi.pooq.com> Message-ID: <206460.28608.qm@web29714.mail.ird.yahoo.com> Hi all: it makes and abstraction of the code in terms of Guarded commands of Dijkstra, then applies the static checking of the calculus of weakest preconditions type checking as a normal program too the code and then translates to first order logic formulae, if the annotated program can be satisfied then it will give no output, but if does prove that the program doesn't produce the anottated output, it will complain on where it fails, wherever it doesn't like the proof. The important thing is that if the checker satisfies all of his conditions, it doesn't mean it does not break, i.e it could be that the checker will no complain but still can't prove absolutely that is not to crash, is a kind of liberal, perhaps because of its logic calculus. There is also the case of possible false alarms, which could be triggered, but this is almost the case in any compiler and here too, even the M3 compiler (something called completeness, just very simple known type systems have), so we can't expect to type check in the semantic analyser it wrong and to accept it in the checker, but we could instead just to make that a unsound program, lets say unsafe, will not lock or crash because and specific error because of the non-completeness issue. However the ESC didn't accept some special kind of almost safe programs, recursive, partly I believe because of a problem exposed below, is perhaps that the program doesn't end, unlike a for loop. There is also the need of a efficient and smarter automatic theorem prover, Simplify is one of the best available for some time now, but still, the same problems arise on it, it could be that because of the first order logic, the program could not terminate but the prover believe it will and it apparently does it, but that its proofs will be not totally proved for all cases, if so, then we would need to take care of those by applying hand formal verification measures like below I explain a case. Also Simplify could rise that he can't prove that something is not provable by itself, but turn that it is doable, just that it can't by its own, so we need to also verify those cases. In the end, the best case our checks will end, but sometimes, the first order logic could be an endless proof or undefined, in those cases we would need a threshold given by the experience, so we might start sooner than later to make our own. The best of this is that are many things that have room for improvement as Dr Greg Nelson told me some time ago, would be nice thing to have the TODO list from him. My personal wish is to make Modula-3 totally verifiable, learning this by hand would be harder, but by the tools we could make it for using its internal logic, the most critical part, the Professor Greg Nelson did some work on that part of that I believe. Then the important parts are the semantic checker which it self is built on its internal logic, e.g a biased logic (i.e an unsound one, the proofs could not end or be too large to finish and unable to realize that after it spends time on it) it could be that never ends a proof or check it badly as good, the most perfect it checks it would be less efficient at some point (perhaps this was the reason to not check the total correctness besides the effort needed) so might be easier to pass the checks but less profitable in the checking. I really would like the most inner parts to be self provable, like more functional style programming then, but those are not verifiable by the ESC checker, it just doesn't do that, similar to when I had a problem on the checker I used sasylf.org, it had unimplemented the mutual induction proving part by that time of a course back in 2008, this is a theorem proof technique you need to use in advanced type theory of type system soundness proofs, sasylf is a programming language by itself to proof it is sound, so it turns out that if we can trust on them more than in any part of the checker we could move on from there to more advanced techniques, also this is harder I believe based on my small experience of type systems proofing. ESC developers say, the most provable source of those mis-checkings is automatic theorem prover, not in checker, then it might be more valuable to start there than in the checker's logic by itself, being more practical, more pragmatic. I have some experience with the use of automatic theorem provers part use by hand with sasylf, writing the proofs and let it check for one (say I was the ESC checker and sasylf was the automatic theorem prover), and it turns out not to be so difficult to use after some work and time of use, still there are many challenges open in the checkers for now, so the room for improvements there is also too big (i.e we can check more things, say, the Modula-3 arithmetic over and/or under flow, recurrence, by improving the core logic calculus and later working on the "second pass" or backend first order logic prover). A special feature was the Locking level notation developed by writing the Trestle library, as it was coded threaded, it is perhaps the most advanced part of it, more details than that I don't now, but more probably coming on the way. I just know its logic is more advanced from what I recall, it requires some clever reasoning and calculus too I guess. So we can have a lot discussion, perhaps the first kick is given now. I also hope its not too much blah, ... sorry for the long message Thanks in advance --- El mi?, 29/12/10, Hendrik Boom escribi?: > De: Hendrik Boom > Asunto: Re: [M3devel] gui problems? BadBricks? columns? > Para: m3devel at elegosoft.com > Fecha: mi?rcoles, 29 de diciembre, 2010 22:26 > On Wed, Dec 29, 2010 at 08:23:12PM > -0500, Coleburn, Randy wrote: > > Daniel et al: > > > > I tried a year or so ago to pursue getting the sources > for the ESC. > > I'd have to dig up my old emails, but my recollection > is that I ran into a dead end getting the sources and the > permission to put them in our repository. > > I don't think the Modula-3 edition was kept up when > the project moved on to other languages. > > What does the ESC do that's relevant to threading? I > mean, not just an > answer like "deadlock and race detection", but what > algorithms does it > use to accomplish it? Does the Modula 3 compiler > construct the proper > data structures that could provide the raw data those > algorithms would > need? How much work would it be to reimplement this > from scratch? > > -- hendrik > From hendrik at topoi.pooq.com Fri Dec 31 02:57:43 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 30 Dec 2010 20:57:43 -0500 Subject: [M3devel] ESC In-Reply-To: <206460.28608.qm@web29714.mail.ird.yahoo.com> References: <20101230032636.GA31254@topoi.pooq.com> <206460.28608.qm@web29714.mail.ird.yahoo.com> Message-ID: <20101231015743.GA17628@topoi.pooq.com> On Thu, Dec 30, 2010 at 11:13:57PM +0000, Daniel Alejandro Benavides D. wrote: > Hi all: > it makes and abstraction of the code in terms of Guarded commands of > Dijkstra, then applies the static checking of the calculus of weakest > preconditions type checking as a normal program too the code This will be difficult for loops. Dijkstra's formalism more or less requires a variant to decrease around the loop. In fact, in his "A Discipline of Programming", he shows multiple examples where the choice of variant and invariant that are used to prove the program correct more -r less determines the program itself. A lovely book. > and then translates to first order logic formulae, if the annotated > program can be satisfied then it will give no output, but if does > prove that the program doesn't produce the anottated output, it will > complain on where it fails, wherever it doesn't like the proof. > The important thing is that if the checker satisfies all of his > conditions, it doesn't mean it does not break, i.e it could be that > the checker will no complain but still can't prove absolutely that is > not to crash, is a kind of liberal, perhaps because of its logic > calculus. That's definitely not Dijkstra's weakest preconditions, then, but something similar. > There is also the case of possible false alarms, which could be > triggered, but this is almost the case in any compiler and here too, > even the M3 compiler (something called completeness, just very simple > known type systems have), so we can't expect to type check in the > semantic analyser it wrong and to accept it in the checker, but we > could instead just to make that a unsound program, lets say unsafe, > will not lock or crash because and specific error because of the > non-completeness issue. However the ESC didn't accept some special > kind of almost safe programs, recursive, partly I believe because of a > problem exposed below, is perhaps that the program doesn't end, unlike > a for loop. Dijkstra in his calculus in "A Discipline of Programming" didn't consider recursion. So far I get the impression that ESC didn't guarantee that the program would run properly if it passed all the checks, nor that failure to pass the checks implied invalidity. It just sort of points put things that may need attention. Kind of like a formal verificatin system that's implemented half-heartedly. > There is also the need of a efficient and smarter automatic theorem > prover, Simplify is one of the best available for some time now, Is it? Got references? I recall that formula simplification was a basic technique in one of the first formal-verification systems back in the late 60's, and that it solved a lot of complicated cases. They originated by substituting into standard formulas that expressed particular predicate transformations. You got a lot of things like i > 0 & i >= 0 & i < 2, which can be simplified to i = 0 if you know i is in integer. There were a huge number of these simplifications, trivial and tedious, and often they sufficed to shos one formula was equivalend to another. > but still, the same problems arise on it, it could be that because > of the first order logic, the program could not terminate but the > prover believe it will and it apparently does it, but that its > proofs will be not totally proved for all cases, if so, then we would > need to take care of those by applying hand formal verification > measures like below I explain a case. > Also Simplify could rise that he can't prove that something is not > provable by itself, but turn that it is doable, just that it can't by > its own, so we need to also verify those cases. > In the end, the best case our checks will end, but sometimes, the > first order logic could be an endless proof or undefined, in those > cases we would need a threshold given by the experience, so we might > start sooner than later to make our own. > The best of this is that are many things that have room for > improvement as Dr Greg Nelson told me some time ago, would be nice > thing to have the TODO list from him. > My personal wish is to make Modula-3 totally verifiable, learning this > by hand would be harder, but by the tools we could make it for using > its internal logic, the most critical part, the Professor Greg Nelson > did some work on that part of that I believe. Formal verification is a hard problem. > Then the important parts are the semantic checker which it self is > built on its internal logic, e.g a biased logic (i.e an unsound one, > the proofs could not end or be too large to finish and unable to > realize that after it spends time on it) it could be that never ends a > proof or check it badly as good, the most perfect it checks it would > be less efficient at some point (perhaps this was the reason to not > check the total correctness besides the effort needed) so might be > easier to pass the checks but less profitable in the checking. I > really would like the most inner parts to be self provable, like more > functional style programming then, but those are not verifiable by the > ESC checker, it just doesn't do that, similar to when I had a problem > on the checker I used sasylf.org, I'll have to look into that. > it had unimplemented the mutual > induction proving part by that time of a course back in 2008, this is > a theorem proof technique you need to use in advanced type theory of > type system soundness proofs, sasylf is a programming language by > itself to proof it is sound, so it turns out that if we can trust on > them more than in any part of the checker we could move on from there > to more advanced techniques, also this is harder I believe based on my > small experience of type systems proofing. I was working with Martin-Lof's type theory in the eighties. I ended up with a verifier, and manages to mechanically proof-check a merge-sort, written in the lazy functional language that's implicit in the logic. It was difficult to use, and really taxed the resources of our Vax 780, even though it has a whole 5 megabytes of memory! And the first verified sort had a bug -- not that it didn't sort; that had been proved, but that it wasn't the merge sort I had intended; it took quadratic time. That verifier is where I learned you have to debug the specifications as well as the code. Right now, the most sophisticated poof-checker of this kind seems to be coq, but some users of coq find they have to more-or-less rewrite coq to achieve efficiency of effort. > ESC developers say, the most provable source of those mis-checkings is > automatic theorem prover, not in checker, then it might be more > valuable to start there than in the checker's logic by itself, being > more practical, more pragmatic. I have some experience with the use of > automatic theorem provers part use by hand with sasylf, writing the > proofs and let it check for one (say I was the ESC checker and sasylf > was the automatic theorem prover), and it turns out not to be so > difficult to use after some work and time of use, still there are many > challenges open in the checkers for now, so the room for improvements > there is also too big (i.e we can check more things, say, the Modula-3 > arithmetic over and/or under flow, recurrence, by improving the core > logic calculus and later working on the "second pass" or backend first > order logic prover). > A special feature was the Locking level notation developed by writing > the Trestle library, Those locking levels were something special. I remember thinking deeply about the way those assertions worked, deciding that they were the right kind of assertions to base proofs on, and proceeded to ignore them when I read the rest of the code. > as it was coded threaded, it is perhaps the most > advanced part of it, more details than that I don't now, but more > probably coming on the way. I just know its logic is more advanced > from what I recall, it requires some clever reasoning and calculus too > I guess. Yeah... this is what we'd need to catch races and deadlocks and such. And it does seem to be mostly independent of the partial-correctness theorem proving described above. Deadlock and races are global issues. > So we can have a lot discussion, perhaps the first kick is given now. > I also hope its not too much blah, ... sorry for the long message Mostly you've outlined some traditional verification technology. ESC seems to use that, possibly with a restricted class of assertions (not clear just which ones), and has the limitations of the same. But the locking levels in trestle do seem to be something else. > Thanks in advance You're welcome. It seems to be a big project. to answer one of my original questions. The question is, whether there are smaller subprojects that are more feasible and will lead to a checker with code structure that can be easily grown. Without small successes, the motivation is often absent to proceed on to the large successes. That's especially true with FLOSS. Once you have something that actually does something useful, people start to use it, and suddenly your users realise how it could be improved, tell you, and if you're lucky, start to make the improvements themselves. --- My view of formal verification is that the proof has to be primary. You write a proof that there is some code that satisfies a spec, and the details of the proof reveal the program. This is completely different from the inductive-assertion method, in that you can use general theorems about particular loop structures, for example, and specialize then as necessary. In fact, I suspect that the theoretical feasibility of this approach is possibly the only reason why people can understand programs at all. You look at some code, decide after a while that there's a nest of six corecursive procedures, look at how parameters are passed down, and realize that it's recursion on a particulat tree structure -- at least you hope it's a tree structure, because its finite, noncyclic structure is nowhere explicit in the code. You reason backwards from patterns in the code to the reasoning the original programmer must have had in mind when he wrote it -- reasoning which rarely appears in the code, rarely even in comments. But using any of these methods for formal verification is still impractical except where the requirements for reliability justify extreme efforts. And I suspect strongly that the logic -- and the particular easy-to-use theorems about synthesizing program structures -- should dictate the structure of the programming language, which quite possibly won't end up being Modula 3. But who knows? The logic people use to decompose problems into implementable program components are largely independent of the pangauge they use, except for * restrictions of parameterization * absenes of convenient coding patterns for desired code structures * reliance on the particular properties that the language implementation guarantees (and therefore needs less explicit thought). I can imagine that the higher-order logics involved are similar for many programming languages, just as things like the Deduction Theorem are similar in many quite different formal logics (though the details of the proofs can be quite different). -- hendrik > > --- El mi?, 29/12/10, Hendrik Boom escribi?: > > > De: Hendrik Boom > > Asunto: Re: [M3devel] gui problems? BadBricks? columns? > > Para: m3devel at elegosoft.com > > Fecha: mi?rcoles, 29 de diciembre, 2010 22:26 > > On Wed, Dec 29, 2010 at 08:23:12PM > > -0500, Coleburn, Randy wrote: > > > Daniel et al: > > > > > > I tried a year or so ago to pursue getting the sources > > for the ESC. > > > I'd have to dig up my old emails, but my recollection > > is that I ran into a dead end getting the sources and the > > permission to put them in our repository. > > > I don't think the Modula-3 edition was kept up when > > the project moved on to other languages. > > > > What does the ESC do that's relevant to threading? I > > mean, not just an > > answer like "deadlock and race detection", but what > > algorithms does it > > use to accomplish it? Does the Modula 3 compiler > > construct the proper > > data structures that could provide the raw data those > > algorithms would > > need? How much work would it be to reimplement this > > from scratch? > > > > -- hendrik > > > > > From jay.krell at cornell.edu Fri Dec 31 07:51:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Dec 2010 06:51:21 +0000 Subject: [M3devel] CM3 status In-Reply-To: References: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com>, Message-ID: The system works fairly well, but also could use some obvious improvement. What do people want to work on that I am in the way of? If you do actually work on the same file as I do, you can still merge. Source control is not mutual exclusion. Granted, CVS doesn't help nearly as much as other source control systems. Perforce is the best I have used, by far, among just a few. Some of the possible future directions moot others. For example, enabling/fixing the typinfo in the gcc backend would be nice, but replacing it with LLVM and/or C++ and/or integrated backends moots that. Ditto for using the gcc exception handling infrastructure. Anything anyone is interested in doing, please speak up, and/or send diffs, and/or commit changes. Please don't be offended or discouraged if changes are backed out, if they don't work for some people. If there is target-dependence, consider some way to enable/disable based on target, and only enabling what you can test, waiting for others to test/enable others. I agree we have too little contribution from too few people, but not clear why. There are possibilities other than blaming me. The system has its interesting characteristics asis, but competition from other languages and libraries are probably more the cause (be careful not to confuse them!): C, C++, Qt, Java, GWT, C#, Perl, Python, Ruby, Tcl, Bash, "HTML", PHP, JavaScript, wxWindows, LUA, etc. It is indeed unusual to have a system with optional safety and native code generation (vs. interpreter or JIT). Just optional safety is rare, and present mainly only C#. I can't think of another language with optional safety and native code generation (granted, I can only name two languages with optional safety: Modula-3 and C#). Having a proper module system is also great, as it makes compilation very fast, on NT386 (similar to Java and C#). - Jay > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Thu, 30 Dec 2010 17:29:50 -0500 > Subject: Re: [M3devel] CM3 status > > Olaf et al: > > I think I share the concern you've voiced. > > My observation from the M3COMMIT log emails is that Jay seems to be the most prolific these days with changes, but I find it impossible to keep track of what problem he is trying to solve. Indeed, it seems he is working on multiple issues at the same time, but it is difficult from the posts to differentiate which issue goes with which posting, and this problem is compounded by the fact that my M3COMMIT/M3DEVEL e-mails don't always seem to be received in chronological order. > > Thus, it is extremely difficult to know how to channel the limited time I have available into helping cooperate to solve a particular problem. > > Maybe it would be a good idea when each person posts something to M3COMMIT or M3DEVEL that they tag it up front with a comment or reference to the problem the post is addressing. > > Another idea, and perhaps your TRAC system supports it, is to assign certain problems to specific individuals who work the problem and report back their solution approach for some type of concurrence before going off on a tangent to solve. This might cut down on some of the subsequent backtracking and reverting changes. It would also allow others to offer constructive comments on the solution approach, even if they don't have time to actually implement the solution. [In reading the posts, I'm seeing many places where work is done, then later someone disagrees with it, and wants the changes reverted.] > > Even if one person is assigned as the lead for a particular problem, perhaps others could join in on helping solve it, coordinating their effort thru the lead person. > > I really do want to help as much as I can, and we definitely need to grow the development support base, so anything we can do to foster teamwork and an up-to-date awareness of the major problem areas and proposed solution paths would be helpful I think. > > I certainly don't want to squash anyone's individual efforts, but right now I don't think we're maximizing our use of the team concept. > > Regards, > Randy Coleburn > > -----Original Message----- > From: Olaf Wagner [mailto:wagner at elegosoft.com] > Sent: Thursday, December 30, 2010 6:23 AM > To: m3devel at elegosoft.com > Subject: [M3devel] CM3 status > > Hi all, > > after reading a couple of Modula-3 mails again after some time of > 'abstinence' I'm a little bit confused about the state of the code > and the direction of development. I see that several different failures > and ideas are discussed, but don't seem to get resolved; none of them > is documented in our Trac instance as far as I know. Some things I > remember offhand: > > o at least 2 different compiler/assembler problems on Darwin/Snow Leopard > o current gcc not working on Solaris (?!) > o stack walker code abandoned > o possibly unsafe OS calls in new C code (this may be a wrong deduction > from my side) > o GUI input not working for BadBricks and other games (only on Darwin?) > o no clean way for exception handling with current gcc > o still alignment issues > > I'm concerned that things get tried out, don't work properly for all > our target platforms, but are left then and not cleaned up and something > else gets tried. I'm not sure this is correct, it is just me feeling > unwell after reading all those mails. > > Hudson and Tinderbox status seem to be mostly OK though, but I haven't > checked in detail (FreeBSD failing was a disk failure on my system > recently). But the tests don't cover all the things we should check. > > I think it would be good to have an overview of the projects/work that > is in progress or pending and its status. For example, we've imported > a new gcc version, but that doesn't seem to work well on all targets, > or does it? If not, how are we going to address this? Use older versions > on some platforms? Can I read up on that somewhere? > > I'd like to suggest to simply use our Trac WiKi to document the ongoing > work (everybody can get write access to that on request) and to record > all errors, failures and major tasks there as issues. This should help > everybody to participate and make me much more relaxed if I consider > the M3 emails (if anybody should care about my personal discomfort > at all :-) > > Just for reference: the trac instance can be found at > https://projects.elego.de/cm3 > > Several of the committers should already have access, and using > the WiKi and the issue tracker should not be much more work than > writing emails. But the information will be easier to access then. > > I hope to have offended nobody by this; I just wanted to make a suggestion > how to improve collaboration and discussion. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 31 08:11:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Dec 2010 07:11:24 +0000 Subject: [M3devel] factoring jmpbuf size via alloca(global constant)? In-Reply-To: References: Message-ID: The more I think about this, the more I like it. However there might be a better option. Gcc has some notion of built-in setjmp. For that matter, maybe using the gcc exception handling mechanism isn't difficult? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: factoring jmpbuf size via alloca(global constant)? Date: Thu, 30 Dec 2010 14:28:31 +0000 factoring out jmpbuf size? Hey, um, how about something like this: somefile.c: #include extern const int sizeof_jmpbuf = sizeof(jmp_buf); where the frontend would allocate a local jmp_buf, instead issue a call to alloca(sizeof_jmpbuf), actually reading the constant out of the global. Yes I know this is a deoptimization. It is already slow. We hope hope hope to replace it all anyway. This would remove lots of target-specific code in Target.m3. Related, I'm again trying removing from m3core the knowledge of the size/alignment of jmpbuf. Or rather, to see if it really needs it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 31 14:52:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Dec 2010 13:52:27 +0000 Subject: [M3devel] expressing 128 bit alignment? Message-ID: The alignment of jmpbuf is 128 bits for some targets. It seems like a hole in the language that this can't be expressed. Or maybe I just don't know how. Or maybe Target.max_align gets in the way?? I'd like to soon remove an accurately described jmpbuf from m3core, making this maybe moot. Linux/powerpc: /usr/include/bits/setjmp.h #ifndef _ASM # if __WORDSIZE == 64 typedef long int __jmp_buf[64] __attribute__ ((__aligned__ (16))); # else /* The alignment is not essential, i.e.the buffer can be copied to a 4 byte aligned buffer as per the ABI it is just added for performance reasons. */ typedef long int __jmp_buf[64 + (12 * 4)] __attribute__ ((__aligned__ (16))); # endif #endif Notice that the 128bit alignment on powerpc64 is not commented as being unessential, only for powerpc32. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Fri Dec 31 19:50:01 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 31 Dec 2010 10:50:01 -0800 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , , Message-ID: <20101231185001.2E77A1A205B@async.async.caltech.edu> I reported two compiler crashes on Snow Leopard. Earlier I provided a distilled version of the code that produces one crash. Here is the other one: MODULE Main; IMPORT FileWr, Wr; IMPORT Fmt; TYPE PV = RECORD price : LONGREAL; volume : CARDINAL; END; HFData_S = RECORD time : LONGREAL; pv : PV; END; PROCEDURE DumpMatching() = PROCEDURE DumpOne(trade : HFData_S) RAISES { Wr.Failure } = BEGIN Wr.PutText(wr, Fmt.LongReal(trade.time)); END DumpOne; VAR wr := FileWr.Open("out"); BEGIN END DumpMatching; BEGIN END Main. [hal:regress/ximport2/src] mika% cm3 -x --- building in ../I386_DARWIN --- new source -> compiling Main.m3 "../src/Main.m3", line 28: warning: potentially unhandled exception: OSError.E "../src/Main.m3", line 24: warning: potentially unhandled exception: Thread.Alerted "../src/Main.m3", line 22: warning: not used (DumpOne) "../src/Main.m3", line 20: warning: not used (DumpMatching) 4 warnings encountered ../src/Main.m3: In function 'Main__DumpMatching__DumpOne': ../src/Main.m3:25:0: error: unable to find a register to spill in class 'CREG' ../src/Main.m3:25:0: error: this is the insn: (insn 5 4 6 2 ../src/Main.m3:22 (parallel [ (set (reg:SI 0 ax [66]) (const_int 0 [0x0])) (set (reg:SI 1 dx [64]) (plus:SI (ashift:SI (reg:SI 0 ax [66]) (const_int 2 [0x2])) (reg:SI 1 dx [64]))) (set (reg:SI 4 si [65]) (plus:SI (ashift:SI (reg:SI 0 ax [66]) (const_int 2 [0x2])) (reg:SI 4 si [65]))) (set (mem/s/c:BLK (reg:SI 1 dx [64]) [0 trade+0 S24 A64]) (mem/s/c:BLK (reg:SI 4 si [65]) [0 trade+0 S24 A32])) (use (reg:SI 0 ax [66])) ]) 838 {*rep_movsi} (expr_list:REG_UNUSED (reg:SI 0 ax [66]) (expr_list:REG_UNUSED (reg:SI 4 si [65]) (expr_list:REG_UNUSED (reg:SI 1 dx [64]) (nil))))) ../src/Main.m3:25:0: internal compiler error: in spill_failure, at reload1.c:2163 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: Main.mc compilation failed => not building program "ximport" Fatal Error: package build failed [hal:regress/ximport2/src] mika% Happy New Year! Mika Jay K writes: >--_2d6969dc-a0fa-42e3-85e1-71600a2e9b7d_ >Content-Type: multipart/alternative; > boundary="_4765c0a9-911e-4b00-a171-d643958a7caa_" > >--_4765c0a9-911e-4b00-a171-d643958a7caa_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >From: jay.krell at cornell.edu >To: hosking at cs.purdue.edu >CC: m3devel at elegosoft.com >Subject: RE: [M3devel] compiler problems on Snow Leopard >Date: Mon=2C 27 Dec 2010 21:41:31 +0000 > > > > > > > > > > Rather than cluttering up CVS=2C why not put it in the bug-tracker? Tha= >t's what it is for! > >It is large. >It is more code that could be repeatedly tested=2C by building the entire "= >system"=2C for a gradually growing >definition of "system". > >We have had a number of problems that only appear in one or two or a few pi= >eces of code. >e.g. the removal of referenced nested functions. >e.g. optimizations causing compilation to fail (which this appears to be as= > well). > >A smaller example would be nice=2C but that is more work to get. > > - Jay > >From: hosking at cs.purdue.edu >Date: Mon=2C 27 Dec 2010 12:23:35 -0500 >To: jay.krell at cornell.edu >CC: m3devel at elegosoft.com >Subject: Re: [M3devel] compiler problems on Snow Leopard > > > >Rather than cluttering up CVS=2C why not put it in the bug-tracker? That's= > what it is for! > >Antony Hosking | Associate Professor | Computer Science | Purdue University= >305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494= > 6001 | Mobile +1 765 427 5484 > > >On Dec 27=2C 2010=2C at 5:17 AM=2C Jay K wrote:Can you put all your code in= > our CVS repository? > >> "../I386_DARWIN/FSSchemeStubs.m3"=2C line 434: 2 code generation errors > >There is a way to get that to show more information.. >Or does it already? > > - Jay > >> To: m3devel at elegosoft.com >> Date: Mon=2C 27 Dec 2010 02:14:21 -0800 >> From: mika at async.caltech.edu >> Subject: Re: [M3devel] compiler problems on Snow Leopard >>=20 >> I upgraded to the CVS head and now I get the following: >>=20 >> ... >> "../I386_DARWIN/FSSchemeStubs.m3"=2C line 872: warning: unreachable state= >ment >> "../I386_DARWIN/FSSchemeStubs.m3"=2C line 903: warning: unreachable state= >ment >> "../I386_DARWIN/FSSchemeStubs.m3"=2C line 434: 2 code generation errors >> 1 error and 23 warnings encountered >> new exporters -> recompiling FSSchemeStubs.i3 >> ... >>=20 >> The source code is: >>=20 >> TYPE FS_Iterator_Surrogate =3D FS.Iterator OBJECT (* line 434 *) >> interp : Scheme.T=3B >> next_slot : SchemeObject.T :=3D NIL=3B >> close_slot : SchemeObject.T :=3D NIL=3B >> nextWithStatus_slot : SchemeObject.T :=3D NIL=3B >> OVERRIDES >> next :=3D FS_Iterator_next_default=3B >> close :=3D FS_Iterator_close_default=3B >> nextWithStatus :=3D FS_Iterator_nextWithStatus_default=3B >> END=3B >>=20 >> Mika >>=20 >> Mika Nystrom writes: >> >Hi everyone=2C >> > >> >Well I was able to get past all my linking issues (mostly questions >> >of dynamic vs. static linking and how to do it=2C which seems to change = >from >> >version to version...) >> > >> >But now I did hit a real problem. >> > >> >"../I386_DARWIN/FSSchemeStubs.m3"=2C line 934: ** INTERNAL CG ERROR *** = >unaligne >> >d store type=3D6 s/o/a=3D32/0/32 >> >"../I386_DARWIN/FSSchemeStubs.m3"=2C line 981: ** INTERNAL CG ERROR *** = >unaligne >> >d load_indirect type=3D6 s/a=3D32/32 >> > >> >Here is the code=2C but it's not likely to be of much help... >> > >> >PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.= >T RAIS >> >ES { Scheme.E } =3D >> > BEGIN >> > VAR res : SchemePair.T:=3DNIL=3B BEGIN >> > res :=3D SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"= >)=2CT >> >oScheme_Atom_T(x.type))=2Cres)=3B >> > res :=3D SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modif= >ica >> >tionTime")=2CSchemeModula3Types.ToScheme_LONGREAL(x.modificationTime))= >=2Cres)=3B >> > res :=3D SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"= >)=2CT >> >oScheme_VAL0LONGINT__VAL16778080LONGINT(x.size))=2Cres)=3B (* line 934 *= >) >> > RETURN res >> > END >> > END ToScheme_File_Status=3B >> > >> > >> >... >> > >> >PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0= >=2C LONGI >> >NT )..VAL(16778080=2C LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = >=3D >> > BEGIN >> > RETURN ToScheme_LONGINT(x) (* line 981 *) >> > END ToScheme_VAL0LONGINT__VAL16778080LONGINT=3B >> > >> > >> >for reference=2C ToScheme_LONGINT is: >> > >> >PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISE= >S { S >> >cheme.E } =3D >> > BEGIN >> > WITH ref =3D NEW(REF LONGINT) DO >> > ref^ :=3D x=3B >> > RETURN SchemeModula3Types.ToScheme_LONGINT(ref) >> > END >> > END ToScheme_LONGINT=3B >> > >> > Mika > > = > >--_4765c0a9-911e-4b00-a171-d643958a7caa_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >


From: jay.krell at cornell.edu
To: hosk= >ing at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] co= >mpiler problems on Snow Leopard
Date: Mon=2C 27 Dec 2010 21:41:31 +0000<= >br>
> >"> > > > > > =3B>=3B Rather than cluttering up CVS=2C why not put it in the bug-t= >racker?  =3BThat's what it is for!

It is large.
It is more co= >de that could be repeatedly tested=2C by building the entire "system"=2C fo= >r a gradually growing
definition of "system".

We have had a numbe= >r of problems that only appear in one or two or a few pieces of code.
e.= >g. the removal of referenced nested functions.
e.g. optimizations causin= >g compilation to fail (which this appears to be as well).

A smaller = >example would be nice=2C but that is more work to get.

 =3B- Jay= >

From: hosking at cs.purdue.edu
Date: Mon= >=2C 27 Dec 2010 12:23:35 -0500
To: jay.krell at cornell.edu
CC: m3devel@= >elegosoft.com
Subject: Re: [M3devel] compiler problems on Snow Leopardr>
> >Rather than cluttering up CVS=2C why not put it in the bug-tracker?  = >=3BThat's what it is for!

>olor: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font= >-style: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spa= >cing: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: = >none=3B white-space: normal=3B word-spacing: 0px=3B">e-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)= >=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font= >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h= >eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n= >ormal=3B word-spacing: 0px=3B">
n class=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B color= >: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-sty= >le: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing= >: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: none= >=3B white-space: normal=3B word-spacing: 0px=3B">yle-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B = >font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-var= >iant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-heigh= >t: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: norma= >l=3B word-spacing: 0px=3B">der-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica= >=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B font-w= >eight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-inde= >nt: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing: 0px= >=3B">=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B= > font-style: normal=3B font-variant: normal=3B font-weight: normal=3B lette= >r-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-transf= >orm: none=3B white-space: normal=3B word-spacing: 0px=3B">xApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0= >=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal= >=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: normal= >=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whit= >e-space: normal=3B word-spacing: 0px=3B">" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-fam= >ily: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: no= >rmal=3B font-weight: normal=3B letter-spacing: normal=3B line-height: norma= >l=3B text-indent: 0px=3B text-transform: none=3B white-space: normal=3B wor= >d-spacing: 0px=3B">apse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font= >-size: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: n= >ormal=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px= >=3B text-transform: none=3B white-space: normal=3B word-spacing: 0px=3B">pan class=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B col= >or: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-s= >tyle: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spaci= >ng: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: no= >ne=3B white-space: normal=3B word-spacing: 0px=3B">
pple-style-span" color=3D"#0000ff">=3D"Gill Sans"> 0=2C 255)=3B font-family: 'Gill Sans'=3B">an" style=3D"color: rgb(0=2C 0=2C 255)=3B font-family: 'Gill Sans'=3B">Anto= >ny Hoskingace=3D"Gill Sans"> 'Gill Sans'=3B">'Gill Sans'=3B"> =3B|pan class=3D"ecxApple-converted-space"> =3Blass=3D"ecxApple-style-span" style=3D"font-family: 'Gill Sans'=3B">ass=3D"ecxApple-style-span" style=3D"font-family: 'Gill Sans'=3B">Associate= > Professoramily: 'Gill Sans'=3B">mily: 'Gill Sans'=3B"> =3B| Computer Science | Purdue University= >
ns-Light">s-Light=3B">305 N. University Street | West Lafayette | IN 47907 | USAn>
ace=3D"Gill Sans">=2C 0=2C 255)=3B font-family: 'Gill Sans'=3B">-span" style=3D"color: rgb(0=2C 0=2C 255)=3B font-family: 'Gill Sans'=3B">O= >fficeans-Light">ns-Light=3B">Sans-Light=3B"> =3B+1 765 494 6001 |pace"> =3Bn" color=3D"#0000ff" face=3D"Gill Sans"> style=3D"color: rgb(0=2C 0=2C 255)=3B font-family: 'Gill Sans'=3B">lass=3D"ecxApple-style-span" style=3D"color: rgb(0=2C 0=2C 255)=3B font-fam= >ily: 'Gill Sans'=3B">Mobilele-span" face=3D"GillSans-Light">=3D"font-family: GillSans-Light=3B">le=3D"font-family: GillSans-Light=3B">ce"> =3B+1 765 427 5484
ss=3D"ecxApple-style-span" face=3D"GillSans-Light">
ock-placeholder">
pan>
<= >br class=3D"ecxApple-interchange-newline"> >
>
On Dec 27=2C 2010=2C at 5:17 AM=2C Jay K wrote:

s=3D"ecxApple-interchange-newline">
e-span" style=3D"border-collapse: separate=3B font-family: Helvetica=3B fon= >t-style: normal=3B font-variant: normal=3B font-weight: normal=3B letter-sp= >acing: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform:= > none=3B white-space: normal=3B word-spacing: 0px=3B font-size: medium=3B">= >
=3B">Can you put all your code in our CVS repository?

>=3B "../I38= >6_DARWIN/FSSchemeStubs.m3"=2C line 434: 2 code generation errors

The= >re is a way to get that to show more information..
Or does it already?r>
 =3B- Jay

>=3B To:e"> =3Bm3devel at elegosof= >t.com
>=3B Date: Mon=2C 27 Dec 2010 02:14:21 -0800
>=3B From:= > =3Bika at async.caltech.edu">mika at async.caltech.edu
>=3B Subject: Re: [M= >3devel] compiler problems on Snow Leopard
>=3Bconverted-space"> =3B
>=3B I upgraded to the CVS head and n= >ow I get the following:
>=3B&= >nbsp=3B
>=3B ...
>=3B "../I386_DARWIN/FSSchemeStubs.m3"=2C= > line 872: warning: unreachable statement
>=3B "../I386_DARWIN/FSSchem= >eStubs.m3"=2C line 903: warning: unreachable statement
>=3B "../I386_D= >ARWIN/FSSchemeStubs.m3"=2C line 434: 2 code generation errors
>=3B 1 e= >rror and 23 warnings encountered
>=3B new exporters ->=3B recompilin= >g FSSchemeStubs.i3
>=3B ...
>=3B-space"> =3B
>=3B The source code is:
>=3B=3D"ecxApple-converted-space"> =3B
>=3B TYPE FS_Iterator_Su= >rrogate =3D FS.Iterator OBJECT (* line 434 *)
>=3B interp : Scheme.T= >=3B
>=3B next_slot : SchemeObject.T :=3D NIL=3B
>=3B close_slot := > SchemeObject.T :=3D NIL=3B
>=3B nextWithStatus_slot : SchemeObject.T = >:=3D NIL=3B
>=3B OVERRIDES
>=3B next :=3D FS_Iterator_next_defaul= >t=3B
>=3B close :=3D FS_Iterator_close_default=3B
>=3B nextWithSt= >atus :=3D FS_Iterator_nextWithStatus_default=3B
>=3B END=3B
>=3B<= >span class=3D"ecxApple-converted-space"> =3B
>=3B Mika
&= >gt=3B =3B
>=3B Mik= >a Nystrom writes:
>=3B >=3BHi everyone=2C
>=3B >=3B
>=3B= > >=3BWell I was able to get past all my linking issues (mostly questions<= >br>>=3B >=3Bof dynamic vs. static linking and how to do it=2C which see= >ms to change from
>=3B >=3Bversion to version...)
>=3B >=3Br>>=3B >=3BBut now I did hit a real problem.
>=3B >=3B
>=3B= > >=3B"../I386_DARWIN/FSSchemeStubs.m3"=2C line 934: ** INTERNAL CG ERROR = >*** unaligne
>=3B >=3Bd store type=3D6 s/o/a=3D32/0/32
>=3B >= >=3B"../I386_DARWIN/FSSchemeStubs.m3"=2C line 981: ** INTERNAL CG ERROR *** = >unaligne
>=3B >=3Bd load_indirect type=3D6 s/a=3D32/32
>=3B >= >=3B
>=3B >=3BHere is the code=2C but it's not likely to be of much h= >elp...
>=3B >=3B
>=3B >=3BPROCEDURE ToScheme_File_Status(READ= >ONLY x : File.Status) : SchemeObject.T RAIS
>=3B >=3BES { Scheme.E }= > =3D
>=3B >=3B BEGIN
>=3B >=3B VAR res : SchemePair.T:=3DNIL= >=3B BEGIN
>=3B >=3B res :=3D SchemeUtils.Cons(SchemeUtils.Cons(Schem= >eSymbol.FromText("type")=2CT
>=3B >=3BoScheme_Atom_T(x.type))=2Cres)= >=3B
>=3B >=3B res :=3D SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbo= >l.FromText("modifica
>=3B >=3BtionTime")=2CSchemeModula3Types.ToSche= >me_LONGREAL(x.modificationTime))=2Cres)=3B
>=3B >=3B res :=3D Scheme= >Utils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size")=2CT
>=3B >= >=3BoScheme_VAL0LONGINT__VAL16778080LONGINT(x.size))=2Cres)=3B (* line 934 *= >)
>=3B >=3B RETURN res
>=3B >=3B END
>=3B >=3B END ToS= >cheme_File_Status=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B...<= >br>>=3B >=3B
>=3B >=3BPROCEDURE ToScheme_VAL0LONGINT__VAL1677808= >0LONGINT(READONLY x : [ VAL(0=2C LONGI
>=3B >=3BNT )..VAL(16778080= >=2C LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } =3D
>=3B >=3B = >BEGIN
>=3B >=3B RETURN ToScheme_LONGINT(x) (* line 981 *)
>=3B = >>=3B END ToScheme_VAL0LONGINT__VAL16778080LONGINT=3B
>=3B >=3B
= >>=3B >=3B
>=3B >=3Bfor reference=2C ToScheme_LONGINT is:
>= >=3B >=3B
>=3B >=3BPROCEDURE ToScheme_LONGINT(READONLY x : LONGINT = >) : SchemeObject.T RAISES { S
>=3B >=3Bcheme.E } =3D
>=3B >= >=3B BEGIN
>=3B >=3B WITH ref =3D NEW(REF LONGINT) DO
>=3B >= >=3B ref^ :=3D x=3B
>=3B >=3B RETURN SchemeModula3Types.ToScheme_LONG= >INT(ref)
>=3B >=3B END
>=3B >=3B END ToScheme_LONGINT=3B
&= >gt=3B >=3B
>=3B >=3B Mika

<= >/div>
>= > >--_4765c0a9-911e-4b00-a171-d643958a7caa_-- > >--_2d6969dc-a0fa-42e3-85e1-71600a2e9b7d_ >Content-Type: application/octet-stream >Content-Transfer-Encoding: base64 >Content-Disposition: attachment; filename="FSSchemeStubs.i3" > >SU5URVJGQUNFIEZTU2NoZW1lU3R1YnM7CigqIEFVVE9NQVRJQ0FMTFkgR0VORVJBVEVEIERPIE5P >VCBFRElUICopCklNUE9SVCBTY2hlbWU7CklNUE9SVCBTY2hlbWVPYmplY3Q7CklNUE9SVCBTY2hl >bWVQYWlyOwpJTVBPUlQgU2NoZW1lTW9kdWxhM1R5cGVzOwpJTVBPUlQgT1NFcnJvcjsKSU1QT1JU >IEZpbGU7CklNUE9SVCBGUzsKSU1QT1JUIFNjaGVtZVN5bWJvbDsKSU1QT1JUIFNjaGVtZVV0aWxz >OwpJTVBPUlQgU2NoZW1lQXBwbHk7CklNUE9SVCBBdG9tTGlzdDsKSU1QT1JUIFNjaGVtZUJvb2xl >YW47CklNUE9SVCBBdG9tOwoKUFJPQ0VEVVJFIFJlZ2lzdGVyU3R1YnMoKTsKClBST0NFRFVSRSBU >b1NjaGVtZV9BdG9tTGlzdF9UKFJFQURPTkxZIHggOiBBdG9tTGlzdC5UKSA6IFNjaGVtZU9iamVj >dC5UIFJBSVNFUyB7IH07CgpQUk9DRURVUkUgVG9TY2hlbWVfRlNfSXRlcmF0b3IoUkVBRE9OTFkg >eCA6IEZTLkl0ZXJhdG9yKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IH07CgpQUk9DRURVUkUg >VG9TY2hlbWVfRmlsZV9UKFJFQURPTkxZIHggOiBGaWxlLlQpIDogU2NoZW1lT2JqZWN0LlQgUkFJ >U0VTIHsgfTsKClBST0NFRFVSRSBUb1NjaGVtZV9GaWxlX1N0YXR1cyhSRUFET05MWSB4IDogRmls >ZS5TdGF0dXMpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUgfTsKClBST0NFRFVS >RSBUb01vZHVsYV9GU19DcmVhdGVPcHRpb24oeCA6IFNjaGVtZU9iamVjdC5UKSA6IChGUy5DcmVh >dGVPcHRpb24pIFJBSVNFUyB7IFNjaGVtZS5FIH07CgpQUk9DRURVUkUgVG9Nb2R1bGFfRlNfQWNj >ZXNzT3B0aW9uKHggOiBTY2hlbWVPYmplY3QuVCkgOiAoRlMuQWNjZXNzT3B0aW9uKSBSQUlTRVMg >eyBTY2hlbWUuRSB9OwoKUFJPQ0VEVVJFIFRvTW9kdWxhX0ZpbGVfVCh4IDogU2NoZW1lT2JqZWN0 >LlQpIDogKEZpbGUuVCkgUkFJU0VTIHsgU2NoZW1lLkUgfTsKClBST0NFRFVSRSBUb1NjaGVtZV9W >QUwwTE9OR0lOVF9fVkFMMTA3Mzc0NTExMkxPTkdJTlQoUkVBRE9OTFkgeCA6IFsgVkFMKDAsIExP >TkdJTlQgKS4uVkFMKC0xMDczNzQ1MTEyLCBMT05HSU5UICkgXSkgOiBTY2hlbWVPYmplY3QuVCBS >QUlTRVMgeyBTY2hlbWUuRSB9OwoKUFJPQ0VEVVJFIFRvU2NoZW1lX0F0b21fVChSRUFET05MWSB4 >IDogQXRvbS5UKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IH07CgpQUk9DRURVUkUgVG9TY2hl >bWVfTE9OR0lOVChSRUFET05MWSB4IDogIExPTkdJTlQgKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNF >UyB7IFNjaGVtZS5FIH07CkNPTlNUIEJyYW5kID0gIkZTU2NoZW1lU3R1YnMiOwoKRU5EIEZTU2No >ZW1lU3R1YnMuCg== > >--_2d6969dc-a0fa-42e3-85e1-71600a2e9b7d_ >Content-Type: application/octet-stream >Content-Transfer-Encoding: base64 >Content-Disposition: attachment; filename="FSSchemeStubs.m3" > >TU9EVUxFIEZTU2NoZW1lU3R1YnM7CigqIEFVVE9NQVRJQ0FMTFkgR0VORVJBVEVEIERPIE5PVCBF >RElUICopCklNUE9SVCBTY2hlbWU7CklNUE9SVCBTY2hlbWVPYmplY3Q7CklNUE9SVCBTY2hlbWVQ >YWlyOwpJTVBPUlQgU2NoZW1lTW9kdWxhM1R5cGVzOwpJTVBPUlQgT1NFcnJvcjsKSU1QT1JUIEZp >bGU7CklNUE9SVCBTY2hlbWVQcm9jZWR1cmVTdHViczsKSU1QT1JUIEZTOwpJTVBPUlQgU2NoZW1l >U3ltYm9sOwpJTVBPUlQgU2NoZW1lVXRpbHM7CklNUE9SVCBTY2hlbWVBcHBseTsKSU1QT1JUIFJU >MDsKSU1QT1JUIEF0b21MaXN0OwpJTVBPUlQgU2NoZW1lQm9vbGVhbjsKSU1QT1JUIEF0b207CgpQ >Uk9DRURVUkUgQ2FsbFN0dWJfRlNfR2V0QWJzb2x1dGVQYXRobmFtZShpbnRlcnAgOiBTY2hlbWUu >VDsKICAgICAgICAgICAgICAgICAgICAgIGFyZ3MgOiBTY2hlbWVPYmplY3QuVDsKICAgICAgICAg >ICAgICAgICAgICAgIGV4Y0hhbmRsZXIgOiBTY2hlbWVPYmplY3QuVCkgOiBTY2hlbWVPYmplY3Qu >VAogIFJBSVNFUyB7IFNjaGVtZS5FIH0gPSAKIAogIFBST0NFRFVSRSBOZXh0KCkgOiBTY2hlbWVP >YmplY3QuVCBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAgICBCRUdJTgogICAgICBUUlkgUkVUVVJO >IFNjaGVtZVV0aWxzLkZpcnN0KHBfXykgRklOQUxMWSBwX18gOj0gU2NoZW1lUGFpci5QYWlyKFNj >aGVtZVV0aWxzLlJlc3QocF9fKSkgRU5ECiAgICBFTkQgTmV4dDsKIAogIFZBUiBwX18gOj0gU2No >ZW1lUGFpci5QYWlyKGFyZ3MpOwogIEJFR0lOCiAgICBUUlkKICAgICAgKCogdW5wYWNrIGZvcm1h >bHMgKikKICAgICAgVkFSIDwqTk9XQVJOKj5qdW5rX18gOj0gMDsKICAgICAgICAgICBmb3JtYWxf >cCA6PSBTY2hlbWVNb2R1bGEzVHlwZXMuVG9Nb2R1bGFfVEVYVChOZXh0KCkpOyBCRUdJTgogICAg >ICAgICgqIGNhcnJ5IG91dCBOSUwgY2hlY2tzIGZvciBvcGVuIGFycmF5cyAqKQoKICAgICAgICAo >KiBtYWtlIHByb2NlZHVyZSBjYWxsICopCiAgICAgICAgV0lUSCByZXMgPSBTY2hlbWVNb2R1bGEz >VHlwZXMuVG9TY2hlbWVfVEVYVChGUy5HZXRBYnNvbHV0ZVBhdGhuYW1lKGZvcm1hbF9wKSkgRE8K >ICAgICAgICAoKiB1bnBhY2sgVkFSIHBhcmFtcyAqKQogICAgICAgIHBfXyA6PSBTY2hlbWVQYWly >LlBhaXIoYXJncyk7CiAgICAgICAgRVZBTCBOZXh0KCk7CgogICAgICAgICgqIHJldHVybiBwcm9j >ZWR1cmUgcmVzdWx0ICopCiAgICAgICAgUkVUVVJOIHJlcwogICAgICAgIEVORAogICAgICBFTkQo >KldJVEgqKQogICAgRVhDRVBUCiAgICAgIHwgT1NFcnJvci5FKHhhcmcpID0+IEVWQUwgU2NoZW1l >QXBwbHkuT25lQXJnKGludGVycCxleGNIYW5kbGVyLFNjaGVtZVV0aWxzLkxpc3QyKFNjaGVtZVN5 >bWJvbC5Gcm9tVGV4dCgicXVvdGUiKSxTY2hlbWVVdGlscy5Db25zKFNjaGVtZVN5bWJvbC5Gcm9t >VGV4dCgiT1NFcnJvci5FIiksIFRvU2NoZW1lX0F0b21MaXN0X1QoeGFyZykpKSkKICAgIEVORDsK >ICAgIDwqTk9XQVJOKj5SRVRVUk4gU2NoZW1lQm9vbGVhbi5GYWxzZSgpCiAgRU5EIENhbGxTdHVi >X0ZTX0dldEFic29sdXRlUGF0aG5hbWU7CgpQUk9DRURVUkUgQ2FsbFN0dWJfRlNfT3BlbkZpbGUo >aW50ZXJwIDogU2NoZW1lLlQ7CiAgICAgICAgICAgICAgICAgICAgICBhcmdzIDogU2NoZW1lT2Jq >ZWN0LlQ7CiAgICAgICAgICAgICAgICAgICAgICBleGNIYW5kbGVyIDogU2NoZW1lT2JqZWN0LlQp >IDogU2NoZW1lT2JqZWN0LlQKICBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAKICBQUk9DRURVUkUg >TmV4dCgpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUgfSA9IAogICAgQkVHSU4K >ICAgICAgVFJZIFJFVFVSTiBTY2hlbWVVdGlscy5GaXJzdChwX18pIEZJTkFMTFkgcF9fIDo9IFNj >aGVtZVBhaXIuUGFpcihTY2hlbWVVdGlscy5SZXN0KHBfXykpIEVORAogICAgRU5EIE5leHQ7CiAK >ICBWQVIgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICBCRUdJTgogICAgVFJZCiAgICAg >ICgqIHVucGFjayBmb3JtYWxzICopCiAgICAgIFZBUiA8Kk5PV0FSTio+anVua19fIDo9IDA7CiAg >ICAgICAgICAgZm9ybWFsX3AgOj0gU2NoZW1lTW9kdWxhM1R5cGVzLlRvTW9kdWxhX1RFWFQoTmV4 >dCgpKTsKICAgICAgICAgICBmb3JtYWxfdHJ1bmNhdGUgOj0gU2NoZW1lTW9kdWxhM1R5cGVzLlRv >TW9kdWxhX0JPT0xFQU4oTmV4dCgpKTsKICAgICAgICAgICBmb3JtYWxfY3JlYXRlIDo9IFRvTW9k >dWxhX0ZTX0NyZWF0ZU9wdGlvbihOZXh0KCkpOwogICAgICAgICAgIGZvcm1hbF90ZW1wbGF0ZSA6 >PSBUb01vZHVsYV9GaWxlX1QoTmV4dCgpKTsKICAgICAgICAgICBmb3JtYWxfYWNjZXNzIDo9IFRv >TW9kdWxhX0ZTX0FjY2Vzc09wdGlvbihOZXh0KCkpOyBCRUdJTgogICAgICAgICgqIGNhcnJ5IG91 >dCBOSUwgY2hlY2tzIGZvciBvcGVuIGFycmF5cyAqKQoKICAgICAgICAoKiBtYWtlIHByb2NlZHVy >ZSBjYWxsICopCiAgICAgICAgV0lUSCByZXMgPSBUb1NjaGVtZV9GaWxlX1QoRlMuT3BlbkZpbGUo >Zm9ybWFsX3AsIGZvcm1hbF90cnVuY2F0ZSwgZm9ybWFsX2NyZWF0ZSwgZm9ybWFsX3RlbXBsYXRl >LCBmb3JtYWxfYWNjZXNzKSkgRE8KICAgICAgICAoKiB1bnBhY2sgVkFSIHBhcmFtcyAqKQogICAg >ICAgIHBfXyA6PSBTY2hlbWVQYWlyLlBhaXIoYXJncyk7CiAgICAgICAgRVZBTCBOZXh0KCk7CiAg >ICAgICAgRVZBTCBOZXh0KCk7CiAgICAgICAgRVZBTCBOZXh0KCk7CiAgICAgICAgRVZBTCBOZXh0 >KCk7CiAgICAgICAgRVZBTCBOZXh0KCk7CgogICAgICAgICgqIHJldHVybiBwcm9jZWR1cmUgcmVz >dWx0ICopCiAgICAgICAgUkVUVVJOIHJlcwogICAgICAgIEVORAogICAgICBFTkQoKldJVEgqKQog >ICAgRVhDRVBUCiAgICAgIHwgT1NFcnJvci5FKHhhcmcpID0+IEVWQUwgU2NoZW1lQXBwbHkuT25l >QXJnKGludGVycCxleGNIYW5kbGVyLFNjaGVtZVV0aWxzLkxpc3QyKFNjaGVtZVN5bWJvbC5Gcm9t >VGV4dCgicXVvdGUiKSxTY2hlbWVVdGlscy5Db25zKFNjaGVtZVN5bWJvbC5Gcm9tVGV4dCgiT1NF >cnJvci5FIiksIFRvU2NoZW1lX0F0b21MaXN0X1QoeGFyZykpKSkKICAgIEVORDsKICAgIDwqTk9X >QVJOKj5SRVRVUk4gU2NoZW1lQm9vbGVhbi5GYWxzZSgpCiAgRU5EIENhbGxTdHViX0ZTX09wZW5G >aWxlOwoKUFJPQ0VEVVJFIENhbGxTdHViX0ZTX09wZW5GaWxlUmVhZG9ubHkoaW50ZXJwIDogU2No >ZW1lLlQ7CiAgICAgICAgICAgICAgICAgICAgICBhcmdzIDogU2NoZW1lT2JqZWN0LlQ7CiAgICAg >ICAgICAgICAgICAgICAgICBleGNIYW5kbGVyIDogU2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2Jq >ZWN0LlQKICBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAKICBQUk9DRURVUkUgTmV4dCgpIDogU2No >ZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUgfSA9IAogICAgQkVHSU4KICAgICAgVFJZIFJF >VFVSTiBTY2hlbWVVdGlscy5GaXJzdChwX18pIEZJTkFMTFkgcF9fIDo9IFNjaGVtZVBhaXIuUGFp >cihTY2hlbWVVdGlscy5SZXN0KHBfXykpIEVORAogICAgRU5EIE5leHQ7CiAKICBWQVIgcF9fIDo9 >IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICBCRUdJTgogICAgVFJZCiAgICAgICgqIHVucGFjayBm >b3JtYWxzICopCiAgICAgIFZBUiA8Kk5PV0FSTio+anVua19fIDo9IDA7CiAgICAgICAgICAgZm9y >bWFsX3AgOj0gU2NoZW1lTW9kdWxhM1R5cGVzLlRvTW9kdWxhX1RFWFQoTmV4dCgpKTsgQkVHSU4K >ICAgICAgICAoKiBjYXJyeSBvdXQgTklMIGNoZWNrcyBmb3Igb3BlbiBhcnJheXMgKikKCiAgICAg >ICAgKCogbWFrZSBwcm9jZWR1cmUgY2FsbCAqKQogICAgICAgIFdJVEggcmVzID0gVG9TY2hlbWVf >RmlsZV9UKEZTLk9wZW5GaWxlUmVhZG9ubHkoZm9ybWFsX3ApKSBETwogICAgICAgICgqIHVucGFj >ayBWQVIgcGFyYW1zICopCiAgICAgICAgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICAg >ICAgICBFVkFMIE5leHQoKTsKCiAgICAgICAgKCogcmV0dXJuIHByb2NlZHVyZSByZXN1bHQgKikK >ICAgICAgICBSRVRVUk4gcmVzCiAgICAgICAgRU5ECiAgICAgIEVORCgqV0lUSCopCiAgICBFWENF >UFQKICAgICAgfCBPU0Vycm9yLkUoeGFyZykgPT4gRVZBTCBTY2hlbWVBcHBseS5PbmVBcmcoaW50 >ZXJwLGV4Y0hhbmRsZXIsU2NoZW1lVXRpbHMuTGlzdDIoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJx >dW90ZSIpLFNjaGVtZVV0aWxzLkNvbnMoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJPU0Vycm9yLkUi >KSwgVG9TY2hlbWVfQXRvbUxpc3RfVCh4YXJnKSkpKQogICAgRU5EOwogICAgPCpOT1dBUk4qPlJF >VFVSTiBTY2hlbWVCb29sZWFuLkZhbHNlKCkKICBFTkQgQ2FsbFN0dWJfRlNfT3BlbkZpbGVSZWFk >b25seTsKClBST0NFRFVSRSBDYWxsU3R1Yl9GU19DcmVhdGVEaXJlY3RvcnkoaW50ZXJwIDogU2No >ZW1lLlQ7CiAgICAgICAgICAgICAgICAgICAgICBhcmdzIDogU2NoZW1lT2JqZWN0LlQ7CiAgICAg >ICAgICAgICAgICAgICAgICBleGNIYW5kbGVyIDogU2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2Jq >ZWN0LlQKICBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAKICBQUk9DRURVUkUgTmV4dCgpIDogU2No >ZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUgfSA9IAogICAgQkVHSU4KICAgICAgVFJZIFJF >VFVSTiBTY2hlbWVVdGlscy5GaXJzdChwX18pIEZJTkFMTFkgcF9fIDo9IFNjaGVtZVBhaXIuUGFp >cihTY2hlbWVVdGlscy5SZXN0KHBfXykpIEVORAogICAgRU5EIE5leHQ7CiAKICBWQVIgcF9fIDo9 >IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICBCRUdJTgogICAgVFJZCiAgICAgICgqIHVucGFjayBm >b3JtYWxzICopCiAgICAgIFZBUiA8Kk5PV0FSTio+anVua19fIDo9IDA7CiAgICAgICAgICAgZm9y >bWFsX3AgOj0gU2NoZW1lTW9kdWxhM1R5cGVzLlRvTW9kdWxhX1RFWFQoTmV4dCgpKTsgQkVHSU4K >ICAgICAgICAoKiBjYXJyeSBvdXQgTklMIGNoZWNrcyBmb3Igb3BlbiBhcnJheXMgKikKCiAgICAg >ICAgKCogbWFrZSBwcm9jZWR1cmUgY2FsbCAqKQogICAgICAgIEZTLkNyZWF0ZURpcmVjdG9yeShm >b3JtYWxfcCk7CiAgICAgICAgKCogdW5wYWNrIFZBUiBwYXJhbXMgKikKICAgICAgICBwX18gOj0g >U2NoZW1lUGFpci5QYWlyKGFyZ3MpOwogICAgICAgIEVWQUwgTmV4dCgpOwoKICAgICAgICAoKiBw >cm9wZXIgcHJvY2VkdXJlIDogcmV0dXJuIFRSVUUgKikKICAgICAgICBSRVRVUk4gU2NoZW1lQm9v >bGVhbi5UcnVlKCkKICAgICAgRU5EKCpXSVRIKikKICAgIEVYQ0VQVAogICAgICB8IE9TRXJyb3Iu >RSh4YXJnKSA9PiBFVkFMIFNjaGVtZUFwcGx5Lk9uZUFyZyhpbnRlcnAsZXhjSGFuZGxlcixTY2hl >bWVVdGlscy5MaXN0MihTY2hlbWVTeW1ib2wuRnJvbVRleHQoInF1b3RlIiksU2NoZW1lVXRpbHMu >Q29ucyhTY2hlbWVTeW1ib2wuRnJvbVRleHQoIk9TRXJyb3IuRSIpLCBUb1NjaGVtZV9BdG9tTGlz >dF9UKHhhcmcpKSkpCiAgICBFTkQ7CiAgICA8Kk5PV0FSTio+UkVUVVJOIFNjaGVtZUJvb2xlYW4u >RmFsc2UoKQogIEVORCBDYWxsU3R1Yl9GU19DcmVhdGVEaXJlY3Rvcnk7CgpQUk9DRURVUkUgQ2Fs >bFN0dWJfRlNfRGVsZXRlRGlyZWN0b3J5KGludGVycCA6IFNjaGVtZS5UOwogICAgICAgICAgICAg >ICAgICAgICAgYXJncyA6IFNjaGVtZU9iamVjdC5UOwogICAgICAgICAgICAgICAgICAgICAgZXhj >SGFuZGxlciA6IFNjaGVtZU9iamVjdC5UKSA6IFNjaGVtZU9iamVjdC5UCiAgUkFJU0VTIHsgU2No >ZW1lLkUgfSA9IAogCiAgUFJPQ0VEVVJFIE5leHQoKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7 >IFNjaGVtZS5FIH0gPSAKICAgIEJFR0lOCiAgICAgIFRSWSBSRVRVUk4gU2NoZW1lVXRpbHMuRmly >c3QocF9fKSBGSU5BTExZIHBfXyA6PSBTY2hlbWVQYWlyLlBhaXIoU2NoZW1lVXRpbHMuUmVzdChw >X18pKSBFTkQKICAgIEVORCBOZXh0OwogCiAgVkFSIHBfXyA6PSBTY2hlbWVQYWlyLlBhaXIoYXJn >cyk7CiAgQkVHSU4KICAgIFRSWQogICAgICAoKiB1bnBhY2sgZm9ybWFscyAqKQogICAgICBWQVIg >PCpOT1dBUk4qPmp1bmtfXyA6PSAwOwogICAgICAgICAgIGZvcm1hbF9wIDo9IFNjaGVtZU1vZHVs >YTNUeXBlcy5Ub01vZHVsYV9URVhUKE5leHQoKSk7IEJFR0lOCiAgICAgICAgKCogY2Fycnkgb3V0 >IE5JTCBjaGVja3MgZm9yIG9wZW4gYXJyYXlzICopCgogICAgICAgICgqIG1ha2UgcHJvY2VkdXJl >IGNhbGwgKikKICAgICAgICBGUy5EZWxldGVEaXJlY3RvcnkoZm9ybWFsX3ApOwogICAgICAgICgq >IHVucGFjayBWQVIgcGFyYW1zICopCiAgICAgICAgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdz >KTsKICAgICAgICBFVkFMIE5leHQoKTsKCiAgICAgICAgKCogcHJvcGVyIHByb2NlZHVyZSA6IHJl >dHVybiBUUlVFICopCiAgICAgICAgUkVUVVJOIFNjaGVtZUJvb2xlYW4uVHJ1ZSgpCiAgICAgIEVO >RCgqV0lUSCopCiAgICBFWENFUFQKICAgICAgfCBPU0Vycm9yLkUoeGFyZykgPT4gRVZBTCBTY2hl >bWVBcHBseS5PbmVBcmcoaW50ZXJwLGV4Y0hhbmRsZXIsU2NoZW1lVXRpbHMuTGlzdDIoU2NoZW1l >U3ltYm9sLkZyb21UZXh0KCJxdW90ZSIpLFNjaGVtZVV0aWxzLkNvbnMoU2NoZW1lU3ltYm9sLkZy >b21UZXh0KCJPU0Vycm9yLkUiKSwgVG9TY2hlbWVfQXRvbUxpc3RfVCh4YXJnKSkpKQogICAgRU5E >OwogICAgPCpOT1dBUk4qPlJFVFVSTiBTY2hlbWVCb29sZWFuLkZhbHNlKCkKICBFTkQgQ2FsbFN0 >dWJfRlNfRGVsZXRlRGlyZWN0b3J5OwoKUFJPQ0VEVVJFIENhbGxTdHViX0ZTX0RlbGV0ZUZpbGUo >aW50ZXJwIDogU2NoZW1lLlQ7CiAgICAgICAgICAgICAgICAgICAgICBhcmdzIDogU2NoZW1lT2Jq >ZWN0LlQ7CiAgICAgICAgICAgICAgICAgICAgICBleGNIYW5kbGVyIDogU2NoZW1lT2JqZWN0LlQp >IDogU2NoZW1lT2JqZWN0LlQKICBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAKICBQUk9DRURVUkUg >TmV4dCgpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUgfSA9IAogICAgQkVHSU4K >ICAgICAgVFJZIFJFVFVSTiBTY2hlbWVVdGlscy5GaXJzdChwX18pIEZJTkFMTFkgcF9fIDo9IFNj >aGVtZVBhaXIuUGFpcihTY2hlbWVVdGlscy5SZXN0KHBfXykpIEVORAogICAgRU5EIE5leHQ7CiAK >ICBWQVIgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICBCRUdJTgogICAgVFJZCiAgICAg >ICgqIHVucGFjayBmb3JtYWxzICopCiAgICAgIFZBUiA8Kk5PV0FSTio+anVua19fIDo9IDA7CiAg >ICAgICAgICAgZm9ybWFsX3AgOj0gU2NoZW1lTW9kdWxhM1R5cGVzLlRvTW9kdWxhX1RFWFQoTmV4 >dCgpKTsgQkVHSU4KICAgICAgICAoKiBjYXJyeSBvdXQgTklMIGNoZWNrcyBmb3Igb3BlbiBhcnJh >eXMgKikKCiAgICAgICAgKCogbWFrZSBwcm9jZWR1cmUgY2FsbCAqKQogICAgICAgIEZTLkRlbGV0 >ZUZpbGUoZm9ybWFsX3ApOwogICAgICAgICgqIHVucGFjayBWQVIgcGFyYW1zICopCiAgICAgICAg >cF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICAgICAgICBFVkFMIE5leHQoKTsKCiAgICAg >ICAgKCogcHJvcGVyIHByb2NlZHVyZSA6IHJldHVybiBUUlVFICopCiAgICAgICAgUkVUVVJOIFNj >aGVtZUJvb2xlYW4uVHJ1ZSgpCiAgICAgIEVORCgqV0lUSCopCiAgICBFWENFUFQKICAgICAgfCBP >U0Vycm9yLkUoeGFyZykgPT4gRVZBTCBTY2hlbWVBcHBseS5PbmVBcmcoaW50ZXJwLGV4Y0hhbmRs >ZXIsU2NoZW1lVXRpbHMuTGlzdDIoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJxdW90ZSIpLFNjaGVt >ZVV0aWxzLkNvbnMoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJPU0Vycm9yLkUiKSwgVG9TY2hlbWVf >QXRvbUxpc3RfVCh4YXJnKSkpKQogICAgRU5EOwogICAgPCpOT1dBUk4qPlJFVFVSTiBTY2hlbWVC >b29sZWFuLkZhbHNlKCkKICBFTkQgQ2FsbFN0dWJfRlNfRGVsZXRlRmlsZTsKClBST0NFRFVSRSBD >YWxsU3R1Yl9GU19SZW5hbWUoaW50ZXJwIDogU2NoZW1lLlQ7CiAgICAgICAgICAgICAgICAgICAg >ICBhcmdzIDogU2NoZW1lT2JqZWN0LlQ7CiAgICAgICAgICAgICAgICAgICAgICBleGNIYW5kbGVy >IDogU2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQKICBSQUlTRVMgeyBTY2hlbWUuRSB9 >ID0gCiAKICBQUk9DRURVUkUgTmV4dCgpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1l >LkUgfSA9IAogICAgQkVHSU4KICAgICAgVFJZIFJFVFVSTiBTY2hlbWVVdGlscy5GaXJzdChwX18p >IEZJTkFMTFkgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihTY2hlbWVVdGlscy5SZXN0KHBfXykpIEVO >RAogICAgRU5EIE5leHQ7CiAKICBWQVIgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICBC >RUdJTgogICAgVFJZCiAgICAgICgqIHVucGFjayBmb3JtYWxzICopCiAgICAgIFZBUiA8Kk5PV0FS >Tio+anVua19fIDo9IDA7CiAgICAgICAgICAgZm9ybWFsX3AwIDo9IFNjaGVtZU1vZHVsYTNUeXBl >cy5Ub01vZHVsYV9URVhUKE5leHQoKSk7CiAgICAgICAgICAgZm9ybWFsX3AxIDo9IFNjaGVtZU1v >ZHVsYTNUeXBlcy5Ub01vZHVsYV9URVhUKE5leHQoKSk7IEJFR0lOCiAgICAgICAgKCogY2Fycnkg >b3V0IE5JTCBjaGVja3MgZm9yIG9wZW4gYXJyYXlzICopCgogICAgICAgICgqIG1ha2UgcHJvY2Vk >dXJlIGNhbGwgKikKICAgICAgICBGUy5SZW5hbWUoZm9ybWFsX3AwLCBmb3JtYWxfcDEpOwogICAg >ICAgICgqIHVucGFjayBWQVIgcGFyYW1zICopCiAgICAgICAgcF9fIDo9IFNjaGVtZVBhaXIuUGFp >cihhcmdzKTsKICAgICAgICBFVkFMIE5leHQoKTsKICAgICAgICBFVkFMIE5leHQoKTsKCiAgICAg >ICAgKCogcHJvcGVyIHByb2NlZHVyZSA6IHJldHVybiBUUlVFICopCiAgICAgICAgUkVUVVJOIFNj >aGVtZUJvb2xlYW4uVHJ1ZSgpCiAgICAgIEVORCgqV0lUSCopCiAgICBFWENFUFQKICAgICAgfCBP >U0Vycm9yLkUoeGFyZykgPT4gRVZBTCBTY2hlbWVBcHBseS5PbmVBcmcoaW50ZXJwLGV4Y0hhbmRs >ZXIsU2NoZW1lVXRpbHMuTGlzdDIoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJxdW90ZSIpLFNjaGVt >ZVV0aWxzLkNvbnMoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJPU0Vycm9yLkUiKSwgVG9TY2hlbWVf >QXRvbUxpc3RfVCh4YXJnKSkpKQogICAgRU5EOwogICAgPCpOT1dBUk4qPlJFVFVSTiBTY2hlbWVC >b29sZWFuLkZhbHNlKCkKICBFTkQgQ2FsbFN0dWJfRlNfUmVuYW1lOwoKUFJPQ0VEVVJFIENhbGxT >dHViX0ZTX0l0ZXJhdGUoaW50ZXJwIDogU2NoZW1lLlQ7CiAgICAgICAgICAgICAgICAgICAgICBh >cmdzIDogU2NoZW1lT2JqZWN0LlQ7CiAgICAgICAgICAgICAgICAgICAgICBleGNIYW5kbGVyIDog >U2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQKICBSQUlTRVMgeyBTY2hlbWUuRSB9ID0g >CiAKICBQUk9DRURVUkUgTmV4dCgpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUg >fSA9IAogICAgQkVHSU4KICAgICAgVFJZIFJFVFVSTiBTY2hlbWVVdGlscy5GaXJzdChwX18pIEZJ >TkFMTFkgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihTY2hlbWVVdGlscy5SZXN0KHBfXykpIEVORAog >ICAgRU5EIE5leHQ7CiAKICBWQVIgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICBCRUdJ >TgogICAgVFJZCiAgICAgICgqIHVucGFjayBmb3JtYWxzICopCiAgICAgIFZBUiA8Kk5PV0FSTio+ >anVua19fIDo9IDA7CiAgICAgICAgICAgZm9ybWFsX3AgOj0gU2NoZW1lTW9kdWxhM1R5cGVzLlRv >TW9kdWxhX1RFWFQoTmV4dCgpKTsgQkVHSU4KICAgICAgICAoKiBjYXJyeSBvdXQgTklMIGNoZWNr >cyBmb3Igb3BlbiBhcnJheXMgKikKCiAgICAgICAgKCogbWFrZSBwcm9jZWR1cmUgY2FsbCAqKQog >ICAgICAgIFdJVEggcmVzID0gVG9TY2hlbWVfRlNfSXRlcmF0b3IoRlMuSXRlcmF0ZShmb3JtYWxf >cCkpIERPCiAgICAgICAgKCogdW5wYWNrIFZBUiBwYXJhbXMgKikKICAgICAgICBwX18gOj0gU2No >ZW1lUGFpci5QYWlyKGFyZ3MpOwogICAgICAgIEVWQUwgTmV4dCgpOwoKICAgICAgICAoKiByZXR1 >cm4gcHJvY2VkdXJlIHJlc3VsdCAqKQogICAgICAgIFJFVFVSTiByZXMKICAgICAgICBFTkQKICAg >ICAgRU5EKCpXSVRIKikKICAgIEVYQ0VQVAogICAgICB8IE9TRXJyb3IuRSh4YXJnKSA9PiBFVkFM >IFNjaGVtZUFwcGx5Lk9uZUFyZyhpbnRlcnAsZXhjSGFuZGxlcixTY2hlbWVVdGlscy5MaXN0MihT >Y2hlbWVTeW1ib2wuRnJvbVRleHQoInF1b3RlIiksU2NoZW1lVXRpbHMuQ29ucyhTY2hlbWVTeW1i >b2wuRnJvbVRleHQoIk9TRXJyb3IuRSIpLCBUb1NjaGVtZV9BdG9tTGlzdF9UKHhhcmcpKSkpCiAg >ICBFTkQ7CiAgICA8Kk5PV0FSTio+UkVUVVJOIFNjaGVtZUJvb2xlYW4uRmFsc2UoKQogIEVORCBD >YWxsU3R1Yl9GU19JdGVyYXRlOwoKUFJPQ0VEVVJFIENhbGxTdHViX0ZTX1N0YXR1cyhpbnRlcnAg >OiBTY2hlbWUuVDsKICAgICAgICAgICAgICAgICAgICAgIGFyZ3MgOiBTY2hlbWVPYmplY3QuVDsK >ICAgICAgICAgICAgICAgICAgICAgIGV4Y0hhbmRsZXIgOiBTY2hlbWVPYmplY3QuVCkgOiBTY2hl >bWVPYmplY3QuVAogIFJBSVNFUyB7IFNjaGVtZS5FIH0gPSAKIAogIFBST0NFRFVSRSBOZXh0KCkg >OiBTY2hlbWVPYmplY3QuVCBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAgICBCRUdJTgogICAgICBU >UlkgUkVUVVJOIFNjaGVtZVV0aWxzLkZpcnN0KHBfXykgRklOQUxMWSBwX18gOj0gU2NoZW1lUGFp >ci5QYWlyKFNjaGVtZVV0aWxzLlJlc3QocF9fKSkgRU5ECiAgICBFTkQgTmV4dDsKIAogIFZBUiBw >X18gOj0gU2NoZW1lUGFpci5QYWlyKGFyZ3MpOwogIEJFR0lOCiAgICBUUlkKICAgICAgKCogdW5w >YWNrIGZvcm1hbHMgKikKICAgICAgVkFSIDwqTk9XQVJOKj5qdW5rX18gOj0gMDsKICAgICAgICAg >ICBmb3JtYWxfcCA6PSBTY2hlbWVNb2R1bGEzVHlwZXMuVG9Nb2R1bGFfVEVYVChOZXh0KCkpOyBC >RUdJTgogICAgICAgICgqIGNhcnJ5IG91dCBOSUwgY2hlY2tzIGZvciBvcGVuIGFycmF5cyAqKQoK >ICAgICAgICAoKiBtYWtlIHByb2NlZHVyZSBjYWxsICopCiAgICAgICAgV0lUSCByZXMgPSBUb1Nj >aGVtZV9GaWxlX1N0YXR1cyhGUy5TdGF0dXMoZm9ybWFsX3ApKSBETwogICAgICAgICgqIHVucGFj >ayBWQVIgcGFyYW1zICopCiAgICAgICAgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICAg >ICAgICBFVkFMIE5leHQoKTsKCiAgICAgICAgKCogcmV0dXJuIHByb2NlZHVyZSByZXN1bHQgKikK >ICAgICAgICBSRVRVUk4gcmVzCiAgICAgICAgRU5ECiAgICAgIEVORCgqV0lUSCopCiAgICBFWENF >UFQKICAgICAgfCBPU0Vycm9yLkUoeGFyZykgPT4gRVZBTCBTY2hlbWVBcHBseS5PbmVBcmcoaW50 >ZXJwLGV4Y0hhbmRsZXIsU2NoZW1lVXRpbHMuTGlzdDIoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJx >dW90ZSIpLFNjaGVtZVV0aWxzLkNvbnMoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJPU0Vycm9yLkUi >KSwgVG9TY2hlbWVfQXRvbUxpc3RfVCh4YXJnKSkpKQogICAgRU5EOwogICAgPCpOT1dBUk4qPlJF >VFVSTiBTY2hlbWVCb29sZWFuLkZhbHNlKCkKICBFTkQgQ2FsbFN0dWJfRlNfU3RhdHVzOwoKUFJP >Q0VEVVJFIENhbGxTdHViX0ZTX1NldE1vZGlmaWNhdGlvblRpbWUoaW50ZXJwIDogU2NoZW1lLlQ7 >CiAgICAgICAgICAgICAgICAgICAgICBhcmdzIDogU2NoZW1lT2JqZWN0LlQ7CiAgICAgICAgICAg >ICAgICAgICAgICBleGNIYW5kbGVyIDogU2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQK >ICBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAKICBQUk9DRURVUkUgTmV4dCgpIDogU2NoZW1lT2Jq >ZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUgfSA9IAogICAgQkVHSU4KICAgICAgVFJZIFJFVFVSTiBT >Y2hlbWVVdGlscy5GaXJzdChwX18pIEZJTkFMTFkgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihTY2hl >bWVVdGlscy5SZXN0KHBfXykpIEVORAogICAgRU5EIE5leHQ7CiAKICBWQVIgcF9fIDo9IFNjaGVt >ZVBhaXIuUGFpcihhcmdzKTsKICBCRUdJTgogICAgVFJZCiAgICAgICgqIHVucGFjayBmb3JtYWxz >ICopCiAgICAgIFZBUiA8Kk5PV0FSTio+anVua19fIDo9IDA7CiAgICAgICAgICAgZm9ybWFsX3Ag >Oj0gU2NoZW1lTW9kdWxhM1R5cGVzLlRvTW9kdWxhX1RFWFQoTmV4dCgpKTsKICAgICAgICAgICBm >b3JtYWxfdCA6PSBTY2hlbWVNb2R1bGEzVHlwZXMuVG9Nb2R1bGFfTE9OR1JFQUwoTmV4dCgpKTsg >QkVHSU4KICAgICAgICAoKiBjYXJyeSBvdXQgTklMIGNoZWNrcyBmb3Igb3BlbiBhcnJheXMgKikK >CiAgICAgICAgKCogbWFrZSBwcm9jZWR1cmUgY2FsbCAqKQogICAgICAgIEZTLlNldE1vZGlmaWNh >dGlvblRpbWUoZm9ybWFsX3AsIGZvcm1hbF90KTsKICAgICAgICAoKiB1bnBhY2sgVkFSIHBhcmFt >cyAqKQogICAgICAgIHBfXyA6PSBTY2hlbWVQYWlyLlBhaXIoYXJncyk7CiAgICAgICAgRVZBTCBO >ZXh0KCk7CiAgICAgICAgRVZBTCBOZXh0KCk7CgogICAgICAgICgqIHByb3BlciBwcm9jZWR1cmUg >OiByZXR1cm4gVFJVRSAqKQogICAgICAgIFJFVFVSTiBTY2hlbWVCb29sZWFuLlRydWUoKQogICAg >ICBFTkQoKldJVEgqKQogICAgRVhDRVBUCiAgICAgIHwgT1NFcnJvci5FKHhhcmcpID0+IEVWQUwg >U2NoZW1lQXBwbHkuT25lQXJnKGludGVycCxleGNIYW5kbGVyLFNjaGVtZVV0aWxzLkxpc3QyKFNj >aGVtZVN5bWJvbC5Gcm9tVGV4dCgicXVvdGUiKSxTY2hlbWVVdGlscy5Db25zKFNjaGVtZVN5bWJv >bC5Gcm9tVGV4dCgiT1NFcnJvci5FIiksIFRvU2NoZW1lX0F0b21MaXN0X1QoeGFyZykpKSkKICAg >IEVORDsKICAgIDwqTk9XQVJOKj5SRVRVUk4gU2NoZW1lQm9vbGVhbi5GYWxzZSgpCiAgRU5EIENh >bGxTdHViX0ZTX1NldE1vZGlmaWNhdGlvblRpbWU7CgoKUFJPQ0VEVVJFIFJlZ2lzdGVyU3R1YnMo >KSA9IAogIEJFR0lOCiAgICBTY2hlbWVQcm9jZWR1cmVTdHVicy5SZWdpc3Rlck9wKFRZUEVDT0RF >KEZTLkl0ZXJhdG9yKSwiY2FsbC1tZXRob2QiLE1ldGhvZERpc3BhdGNoZXJfRlNfSXRlcmF0b3Ip >OwogICAgU2NoZW1lUHJvY2VkdXJlU3R1YnMuUmVnaXN0ZXJOZXcoTkVXKFNjaGVtZVByb2NlZHVy >ZVN0dWJzLlFpZCwgaW50ZiA6PSBBdG9tLkZyb21UZXh0KCJGUyIpLCBpdGVtIDo9IEF0b20uRnJv >bVRleHQoIkl0ZXJhdG9yIikpLCBOZXdfRlNfSXRlcmF0b3IpOwogICAgU2NoZW1lUHJvY2VkdXJl >U3R1YnMuUmVnaXN0ZXJPcChUWVBFQ09ERShGUy5JdGVyYXRvciksIm5ldyIsR2VuTmV3X0ZTX0l0 >ZXJhdG9yKTsKICAgIFNjaGVtZVByb2NlZHVyZVN0dWJzLlJlZ2lzdGVyT3AoVFlQRUNPREUoRlMu >SXRlcmF0b3IpLCJnZXQtZmllbGQiLEZpZWxkR2V0X0ZTX0l0ZXJhdG9yKTsKICAgIFNjaGVtZVBy >b2NlZHVyZVN0dWJzLlJlZ2lzdGVyT3AoVFlQRUNPREUoRlMuSXRlcmF0b3IpLCJzZXQtZmllbGQh >IixGaWVsZFNldF9GU19JdGVyYXRvcik7CiAgICBTY2hlbWVQcm9jZWR1cmVTdHVicy5SZWdpc3Rl >clRDKFRZUEVDT0RFKEZTLkl0ZXJhdG9yKSwiRlMuSXRlcmF0b3IiKTsKICAgIFNjaGVtZVByb2Nl >ZHVyZVN0dWJzLlJlZ2lzdGVyT3AoVFlQRUNPREUoRlMuUHVibGljSXRlcmF0b3IpLCJjYWxsLW1l >dGhvZCIsTWV0aG9kRGlzcGF0Y2hlcl9GU19QdWJsaWNJdGVyYXRvcik7CiAgICBTY2hlbWVQcm9j >ZWR1cmVTdHVicy5SZWdpc3Rlck5ldyhORVcoU2NoZW1lUHJvY2VkdXJlU3R1YnMuUWlkLCBpbnRm >IDo9IEF0b20uRnJvbVRleHQoIkZTIiksIGl0ZW0gOj0gQXRvbS5Gcm9tVGV4dCgiUHVibGljSXRl >cmF0b3IiKSksIE5ld19GU19QdWJsaWNJdGVyYXRvcik7CiAgICBTY2hlbWVQcm9jZWR1cmVTdHVi >cy5SZWdpc3Rlck9wKFRZUEVDT0RFKEZTLlB1YmxpY0l0ZXJhdG9yKSwibmV3IixHZW5OZXdfRlNf >UHVibGljSXRlcmF0b3IpOwogICAgU2NoZW1lUHJvY2VkdXJlU3R1YnMuUmVnaXN0ZXJPcChUWVBF >Q09ERShGUy5QdWJsaWNJdGVyYXRvciksImdldC1maWVsZCIsRmllbGRHZXRfRlNfUHVibGljSXRl >cmF0b3IpOwogICAgU2NoZW1lUHJvY2VkdXJlU3R1YnMuUmVnaXN0ZXJPcChUWVBFQ09ERShGUy5Q >dWJsaWNJdGVyYXRvciksInNldC1maWVsZCEiLEZpZWxkU2V0X0ZTX1B1YmxpY0l0ZXJhdG9yKTsK >ICAgIFNjaGVtZVByb2NlZHVyZVN0dWJzLlJlZ2lzdGVyVEMoVFlQRUNPREUoRlMuUHVibGljSXRl >cmF0b3IpLCJGUy5QdWJsaWNJdGVyYXRvciIpOwogICAgVkFSCiAgICAgIEFyZ19UQyA6PSBBUlJB >WSBbMC4uM10gT0YgWy0xLi5MQVNUKFJUMC5UeXBlY29kZSldIHsgLTEsIC0xLCBUWVBFQ09ERShG >Uy5JdGVyYXRvciksIFRZUEVDT0RFKEZTLlB1YmxpY0l0ZXJhdG9yKX07CiAgICBDT05TVAogICAg >ICBBcmdfTmFtZXMgPSBBUlJBWSBPRiBURVhUIHsgIkZTLkNyZWF0ZU9wdGlvbiIsICJGUy5BY2Nl >c3NPcHRpb24iLCAiRlMuSXRlcmF0b3IiLCAiRlMuUHVibGljSXRlcmF0b3IifTsKICAgICAgQXJn >X1BpY2tsZSA9IEFSUkFZIE9GIENIQVIgeyBWQUwoMzgsQ0hBUiksIFZBTCgzNyxDSEFSKSwgVkFM >KDUwLENIQVIpLCBWQUwoNzMsQ0hBUiksIFZBTCg3NixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >NzgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgxMTAsQ0hBUiksIFZBTCgx >MTcsQ0hBUiksIFZBTCgxMDgsQ0hBUiksIFZBTCgxMDgsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDEyOCxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDIy >MCxDSEFSKSwgVkFMKDE5NCxDSEFSKSwgVkFMKDU1LENIQVIpLCBWQUwoMjE3LENIQVIpLCBWQUwo >MTUsQ0hBUiksIFZBTCgyMDUsQ0hBUiksIFZBTCg4OCxDSEFSKSwgVkFMKDMwLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDIyOSxDSEFSKSwgVkFMKDYzLENIQVIpLCBWQUwoMzcsQ0hBUiksIFZBTCgxOTMs >Q0hBUiksIFZBTCgyMSxDSEFSKSwgVkFMKDU5LENIQVIpLCBWQUwoMjE3LENIQVIpLCBWQUwoMTgs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgyMjcsQ0hBUiksIFZBTCgyMTEs >Q0hBUiksIFZBTCgxNjEsQ0hBUiksIFZBTCg5OCxDSEFSKSwgVkFMKDQxLENIQVIpLCBWQUwoNDAs >Q0hBUiksIFZBTCgyNixDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwoMTEsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg4NSxDSEFSKSwgVkFMKDExNSxDSEFS >KSwgVkFMKDEwMSxDSEFSKSwgVkFMKDExNCxDSEFSKSwgVkFMKDY4LENIQVIpLCBWQUwoMTAxLENI >QVIpLCBWQUwoMTAyLENIQVIpLCBWQUwoMTA1LENIQVIpLCBWQUwoMTEwLENIQVIpLCBWQUwoMTAx >LENIQVIpLCBWQUwoMTAwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCg1LENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgx >MDgsQ0hBUiksIFZBTCgxMDUsQ0hBUiksIFZBTCg5NyxDSEFSKSwgVkFMKDExNSxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoODEsQ0hBUiksIFZBTCgxMDUsQ0hBUiks >IFZBTCgxMDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgxMDUsQ0hBUiksIFZBTCgxMTAsQ0hB >UiksIFZBTCgxMTYsQ0hBUiksIFZBTCgxMDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hB >UiksIFZBTCg1MyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgxNTYsQ0hBUiksIFZBTCgyMTIsQ0hB >UiksIFZBTCgxNyxDSEFSKSwgVkFMKDE2NCxDSEFSKSwgVkFMKDE3OCxDSEFSKSwgVkFMKDE5NixD >SEFSKSwgVkFMKDU4LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNzAsQ0hBUiksIFZBTCg4MyxDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDEwNSxDSEFSKSwgVkFMKDExNixDSEFSKSwgVkFMKDEwMSxDSEFS >KSwgVkFMKDEwOSxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg4OCxDSEFSKSwgVkFMKDU4LENIQVIpLCBW >QUwoNDQsQ0hBUiksIFZBTCgyMzAsQ0hBUiksIFZBTCgxODQsQ0hBUiksIFZBTCgxMzMsQ0hBUiks >IFZBTCg4NyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCgxMixDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDY3LENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwo >MTAxLENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMTYsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZB >TCg3OSxDSEFSKSwgVkFMKDExMixDSEFSKSwgVkFMKDExNixDSEFSKSwgVkFMKDEwNSxDSEFSKSwg >VkFMKDExMSxDSEFSKSwgVkFMKDExMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIp >LCBWQUwoNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDExMCxDSEFSKSwgVkFMKDk3LENIQVIpLCBWQUwoMTA5LENIQVIpLCBWQUwoMTAxLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >OSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTUsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDQ5LENIQVIpLCBWQUwoMTksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDIxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFM >KDcsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgxMTgs >Q0hBUiksIFZBTCgxMDUsQ0hBUiksIFZBTCgxMTUsQ0hBUiksIFZBTCgxMDUsQ0hBUiksIFZBTCgx >MTYsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZBTCgxMDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgxODcsQ0hBUiksIFZBTCgxNCxDSEFSKSwgVkFMKDQ2LENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgyMjcsQ0hBUiksIFZBTCgxOTIsQ0hBUiksIFZBTCgyNixDSEFSKSwgVkFM >KDE5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoOCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDk4LENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwoOTcs >Q0hBUiksIFZBTCgxMTAsQ0hBUiksIFZBTCgxMDAsQ0hBUiksIFZBTCgxMTUsQ0hBUiksIFZBTCg3 >OSxDSEFSKSwgVkFMKDc1LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg3LENIQVIpLCBWQUwoMSxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0 >LENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDEwMSxDSEFSKSwgVkFMKDEwOCxDSEFSKSwgVkFMKDExNixDSEFSKSwgVkFMKDExNSxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCg2LENIQVIpLCBW >QUwoNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDc4 >LENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoMTE4LENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwo >MTE0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCgxLENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg3OSxDSEFSKSwgVkFMKDEwNyxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDYsQ0hB >UiksIFZBTCg2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNjUsQ0hBUiksIFZBTCgxMDgsQ0hBUiksIFZBTCgxMTksQ0hBUiksIFZBTCg5NyxDSEFSKSwg >VkFMKDEyMSxDSEFSKSwgVkFMKDExNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFS >KSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDIsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MTMsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDE1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE5LENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDEyLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNjUsQ0hBUiksIFZB >TCg5OSxDSEFSKSwgVkFMKDk5LENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoMTE1LENIQVIpLCBW >QUwoMTE1LENIQVIpLCBWQUwoNzksQ0hBUiksIFZBTCgxMTIsQ0hBUiksIFZBTCgxMTYsQ0hBUiks >IFZBTCgxMDUsQ0hBUiksIFZBTCgxMTEsQ0hBUiksIFZBTCgxMTAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDEzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNDksQ0hBUiksIFZBTCgxNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOSxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBW >QUwoNjQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0 >OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzNCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBW >QUwoMzYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzksQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDQxLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDQ0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgyNDUsQ0hBUiksIFZBTCgyMjksQ0hBUiksIFZBTCgxMTQsQ0hBUiksIFZBTCg4 >MyxDSEFSKSwgVkFMKDIwMixDSEFSKSwgVkFMKDEzLENIQVIpLCBWQUwoMTY2LENIQVIpLCBWQUwo >MjYsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMjMs >Q0hBUiksIFZBTCgxMTQsQ0hBUiksIFZBTCg3OSxDSEFSKSwgVkFMKDE1OCxDSEFSKSwgVkFMKDE1 >OSxDSEFSKSwgVkFMKDE1NSxDSEFSKSwgVkFMKDE5NixDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwo >MTcsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg3OSxD >SEFSKSwgVkFMKDExMCxDSEFSKSwgVkFMKDEwOCxDSEFSKSwgVkFMKDEyMSxDSEFSKSwgVkFMKDc5 >LENIQVIpLCBWQUwoMTE5LENIQVIpLCBWQUwoMTEwLENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwo >MTE0LENIQVIpLCBWQUwoNjcsQ0hBUiksIFZBTCg5NyxDSEFSKSwgVkFMKDExMCxDSEFSKSwgVkFM >KDgyLENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDYsQ0hB >UiksIFZBTCg4LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoODIsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZBTCg5NyxDSEFSKSwgVkFMKDEwMCxDSEFSKSwg >VkFMKDc5LENIQVIpLCBWQUwoMTEwLENIQVIpLCBWQUwoMTA4LENIQVIpLCBWQUwoMTIxLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDcsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg2OCxDSEFSKSwgVkFMKDEw >MSxDSEFSKSwgVkFMKDEwMixDSEFSKSwgVkFMKDk3LENIQVIpLCBWQUwoMTE3LENIQVIpLCBWQUwo >MTA4LENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDc5LENIQVIpLCBWQUwoMTEyLENIQVIpLCBWQUwoOTcsQ0hBUiks >IFZBTCgxMTMsQ0hBUiksIFZBTCgxMTcsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTMs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDE1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE5LENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDgsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg3MyxDSEFSKSwgVkFMKDEx >NixDSEFSKSwgVkFMKDEwMSxDSEFSKSwgVkFMKDExNCxDSEFSKSwgVkFMKDk3LENIQVIpLCBWQUwo >MTE2LENIQVIpLCBWQUwoMTExLENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTMs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDE1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE5LENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzNCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzYsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDQxLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCg2LENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMTE2LENIQVIp >LCBWQUwoMTE0LENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCg5OSxDSEFSKSwgVkFMKDEwMSxDSEFS >KSwgVkFMKDEwMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzYsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDcsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg5OCxDSEFSKSwg >VkFMKDExNCxDSEFSKSwgVkFMKDk3LENIQVIpLCBWQUwoMTEwLENIQVIpLCBWQUwoMTAwLENIQVIp >LCBWQUwoMTAxLENIQVIpLCBWQUwoMTAwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzNixDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENI >QVIpLCBWQUwoNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDk4LENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMTAsQ0hBUiks >IFZBTCgxMDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNyxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDExNCxDSEFS >KSwgVkFMKDEwMSxDSEFSKSwgVkFMKDExOCxDSEFSKSwgVkFMKDczLENIQVIpLCBWQUwoMTEwLENI >QVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoMTAyLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoNCxDSEFSKSwgVkFMKDE3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoMTE4LENIQVIpLCBWQUwo >MTAxLENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMDgsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZB >TCgxMDAsQ0hBUiksIFZBTCg4MyxDSEFSKSwgVkFMKDExNyxDSEFSKSwgVkFMKDExMixDSEFSKSwg >VkFMKDEwMSxDSEFSKSwgVkFMKDExNCxDSEFSKSwgVkFMKDg0LENIQVIpLCBWQUwoMTIxLENIQVIp >LCBWQUwoMTEyLENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoNCxDSEFSKSwgVkFMKDYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCg3OSxDSEFSKSwgVkFMKDk4LENIQVIpLCBWQUwoMTA2LENIQVIpLCBWQUwoMTAx >LENIQVIpLCBWQUwoOTksQ0hBUiksIFZBTCgxMTYsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NDksQ0hBUiksIFZBTCg5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDEzLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgx >NSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDYsQ0hBUiksIFZBTCgxNCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDgwLENIQVIpLCBWQUwoMTE3LENIQVIp >LCBWQUwoOTgsQ0hBUiksIFZBTCgxMDgsQ0hBUiksIFZBTCgxMDUsQ0hBUiksIFZBTCg5OSxDSEFS >KSwgVkFMKDczLENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoMTE0LENI >QVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMTYsQ0hBUiksIFZBTCgxMTEsQ0hBUiksIFZBTCgxMTQs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzNixDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNDksQ0hBUiksIFZBTCgzOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoNDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBW >QUwoMTE1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >NDksQ0hBUiksIFZBTCgzNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMTksQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDEyMyxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDEyNyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCg1 >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMTE1LENI >QVIpLCBWQUwoMTE3LENIQVIpLCBWQUwoMTEyLENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoMTE0 >LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDYsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgxMDIsQ0hBUiksIFZBTCgx >MDUsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZBTCgxMDgsQ0hBUiksIFZBTCgxMDAsQ0hBUiksIFZB >TCgxMTUsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFM >KDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNyxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDEwOSxDSEFSKSwg >VkFMKDEwMSxDSEFSKSwgVkFMKDExNixDSEFSKSwgVkFMKDEwNCxDSEFSKSwgVkFMKDExMSxDSEFS >KSwgVkFMKDEwMCxDSEFSKSwgVkFMKDExNSxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwo >NixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDc3LENI >QVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoMTA0LENIQVIpLCBWQUwoMTEx >LENIQVIpLCBWQUwoMTAwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDI1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwo >NCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDExMCxD >SEFSKSwgVkFMKDEwMSxDSEFSKSwgVkFMKDEyMCxDSEFSKSwgVkFMKDExNixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiks >IFZBTCg0LENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDExNSxDSEFSKSwgVkFMKDEwNSxDSEFSKSwgVkFMKDEwMyxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCg5LENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoODMsQ0hBUiksIFZBTCgxMDUsQ0hBUiks >IFZBTCgxMDMsQ0hBUiksIFZBTCgxMTAsQ0hBUiksIFZBTCg5NyxDSEFSKSwgVkFMKDExNixDSEFS >KSwgVkFMKDExNyxDSEFSKSwgVkFMKDExNCxDSEFSKSwgVkFMKDEwMSxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCg0LENIQVIpLCBWQUwoNyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDEwMixDSEFSKSwgVkFMKDExMSxDSEFSKSwgVkFMKDExNCxDSEFSKSwgVkFMKDEw >OSxDSEFSKSwgVkFMKDk3LENIQVIpLCBWQUwoMTA4LENIQVIpLCBWQUwoMTE1LENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxD >SEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDQsQ0hBUiksIFZBTCg2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoNzAsQ0hBUiksIFZBTCgxMTEsQ0hBUiksIFZBTCgxMTQsQ0hBUiksIFZB >TCgxMDksQ0hBUiksIFZBTCg5NyxDSEFSKSwgVkFMKDEwOCxDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENI >QVIpLCBWQUwoNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDEwOSxDSEFSKSwgVkFMKDExMSxDSEFSKSwgVkFMKDEwMCxDSEFSKSwgVkFMKDEwMSxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwg >VkFMKDgsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg3 >NyxDSEFSKSwgVkFMKDExMSxDSEFSKSwgVkFMKDEwMCxDSEFSKSwgVkFMKDEwMSxDSEFSKSwgVkFM >KDQ2LENIQVIpLCBWQUwoODYsQ0hBUiksIFZBTCg5NyxDSEFSKSwgVkFMKDExNCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCg0LENIQVIpLCBWQUwoNyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDExMSxDSEFSKSwgVkFMKDExNyxDSEFSKSwgVkFMKDExNixDSEFSKSwg >VkFMKDc5LENIQVIpLCBWQUwoMTEwLENIQVIpLCBWQUwoMTA4LENIQVIpLCBWQUwoMTIxLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCgzNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoMjUsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoNCxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgxMTYsQ0hBUiksIFZBTCgxMjEsQ0hBUiksIFZBTCgxMTIsQ0hBUiks >IFZBTCgxMDEsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNDksQ0hBUiksIFZBTCg5MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDksQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDQ5LENIQVIpLCBWQUwoMTMsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE5LENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDg0LENIQVIpLCBWQUwoNjksQ0hBUiksIFZB >TCg4OCxDSEFSKSwgVkFMKDg0LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDM5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCg0MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMTUs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDExOSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzYsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTIzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDQ5LENIQVIpLCBWQUwoMTI3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENI >QVIpLCBWQUwoMTMxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDksQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg4MixDSEFSKSwgVkFMKDEwMSxD >SEFSKSwgVkFMKDEwMixDSEFSKSwgVkFMKDEwMSxDSEFSKSwgVkFMKDExNCxDSEFSKSwgVkFMKDEw >MSxDSEFSKSwgVkFMKDExMCxDSEFSKSwgVkFMKDk5LENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxD >SEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiks >IFZBTCgxMyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDQ5LENIQVIpLCBWQUwoMjE0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE5LENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDgyLENIQVIpLCBWQUwoNjksQ0hB >UiksIFZBTCg3MCxDSEFSKSwgVkFMKDY1LENIQVIpLCBWQUwoNzgsQ0hBUiksIFZBTCg4OSxDSEFS >KSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDM0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDks >Q0hBUiksIFZBTCgzNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzOSxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoNDEs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTE1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0MSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNDksQ0hBUiksIFZBTCgxMTksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDEyMyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDEyNyxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4LENIQVIp >LCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNyxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDEwMCxDSEFS >KSwgVkFMKDEwMSxDSEFSKSwgVkFMKDEwMixDSEFSKSwgVkFMKDk3LENIQVIpLCBWQUwoMTE3LENI >QVIpLCBWQUwoMTA4LENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxD >SEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCg2LENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwoMTAx >LENIQVIpLCBWQUwoMTE1LENIQVIpLCBWQUwoMTE3LENIQVIpLCBWQUwoMTA4LENIQVIpLCBWQUwo >MTE2LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxD >SEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDksQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMTMsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDIxNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgx >OSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDcsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg2NixDSEFSKSwgVkFM >KDc5LENIQVIpLCBWQUwoNzksQ0hBUiksIFZBTCg3NixDSEFSKSwgVkFMKDY5LENIQVIpLCBWQUwo >NjUsQ0hBUiksIFZBTCg3OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDM0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCgzOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDQ5LENIQVIpLCBWQUwoNDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoNDQsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDcwLENIQVIpLCBWQUwoNjUsQ0hBUiksIFZBTCg3NixDSEFS >KSwgVkFMKDgzLENIQVIpLCBWQUwoNjksQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCg0LENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDg0LENIQVIpLCBWQUwoODIsQ0hBUiksIFZBTCg4NSxDSEFSKSwgVkFMKDY5LENI >QVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwo >NixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDExNCxD >SEFSKSwgVkFMKDk3LENIQVIpLCBWQUwoMTA1LENIQVIpLCBWQUwoMTE1LENIQVIpLCBWQUwoMTAx >LENIQVIpLCBWQUwoMTE1LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxNzEsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCg2LENIQVIpLCBWQUwoMTQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgxMTAsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZBTCgxMjAsQ0hBUiksIFZB >TCgxMTYsQ0hBUiksIFZBTCg4NyxDSEFSKSwgVkFMKDEwNSxDSEFSKSwgVkFMKDExNixDSEFSKSwg >VkFMKDEwNCxDSEFSKSwgVkFMKDgzLENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoOTcsQ0hBUiks >IFZBTCgxMTYsQ0hBUiksIFZBTCgxMTcsQ0hBUiksIFZBTCgxMTUsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgx >NzksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxODIsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTg2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDE5MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOTQsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE5NixDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyMDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0 >OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgy >MDYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDIwOCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOTAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTk0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOTYsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMjAwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgy >NSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDYsQ0hBUiks >IFZBTCg0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MTE1LENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMTYsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjA2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFM >KDYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg4MixD >SEFSKSwgVkFMKDEwMSxDSEFSKSwgVkFMKDk5LENIQVIpLCBWQUwoMTExLENIQVIpLCBWQUwoMTE0 >LENIQVIpLCBWQUwoMTAwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDI1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >OSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDYsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNzAsQ0hBUiksIFZBTCgxMDUsQ0hBUiks >IFZBTCgxMDgsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MTksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCg2LENIQVIp >LCBWQUwoNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDgzLENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMTYsQ0hBUiksIFZB >TCgxMTcsQ0hBUiksIFZBTCgxMTUsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiks >IFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzQsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiks >IFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFM >KDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0MSxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NDksQ0hBUiksIFZBTCgxNjMsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDUsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg3MCxDSEFSKSwgVkFMKDEwNSxDSEFSKSwgVkFMKDEw >MSxDSEFSKSwgVkFMKDEwOCxDSEFSKSwgVkFMKDEwMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjA2LENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDIwNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDkxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxD >SEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiks >IFZBTCgxMyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDYs >Q0hBUiksIFZBTCg0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNjUsQ0hBUiksIFZBTCgxMTYsQ0hBUiksIFZBTCgxMTEsQ0hBUiksIFZBTCgxMDksQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCg2LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDg0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoMzQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM5LENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZB >TCg0MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMTUsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDExOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzYsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENI >QVIpLCBWQUwoMTIzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MTI3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTMxLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZB >TCgyMzQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0 >OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0LENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZB >TCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5NixD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCg5LENIQVIpLCBWQUwoMTcsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgxMDksQ0hBUiksIFZBTCgxMTEsQ0hBUiksIFZBTCgxMDAsQ0hBUiksIFZB >TCgxMDUsQ0hBUiksIFZBTCgxMDIsQ0hBUiksIFZBTCgxMDUsQ0hBUiksIFZBTCg5OSxDSEFSKSwg >VkFMKDk3LENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoMTA1LENIQVIpLCBWQUwoMTExLENIQVIp >LCBWQUwoMTEwLENIQVIpLCBWQUwoODQsQ0hBUiksIFZBTCgxMDUsQ0hBUiksIFZBTCgxMDksQ0hB >UiksIFZBTCgxMDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg0OSxDSEFSKSwgVkFMKDIwNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCg4LENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNzYsQ0hBUiksIFZB >TCgxMTEsQ0hBUiksIFZBTCgxMTAsQ0hBUiksIFZBTCgxMDMsQ0hBUiksIFZBTCg4MixDSEFSKSwg >VkFMKDEwMSxDSEFSKSwgVkFMKDk3LENIQVIpLCBWQUwoMTA4LENIQVIpLCBWQUwoNTMsQ0hBUiks >IFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFM >KDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDQ5LENIQVIpLCBWQUwoOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMyxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoMjE0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE5LENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoOCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDc2LENIQVIpLCBWQUwoNzksQ0hBUiksIFZBTCg3 >OCxDSEFSKSwgVkFMKDcxLENIQVIpLCBWQUwoODIsQ0hBUiksIFZBTCg2OSxDSEFSKSwgVkFMKDY1 >LENIQVIpLCBWQUwoNzYsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxD >SEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCgzNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoMzksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg0OSxDSEFSKSwgVkFMKDQxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoNCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENI >QVIpLCBWQUwoOTYsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hB >UiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMTE1LENIQVIpLCBWQUwoMTA1LENIQVIpLCBW >QUwoMTIyLENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0 >OSxDSEFSKSwgVkFMKDIwNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCg4LENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoODMsQ0hBUiksIFZBTCgx >MTcsQ0hBUiksIFZBTCg5OCxDSEFSKSwgVkFMKDExNCxDSEFSKSwgVkFMKDk3LENIQVIpLCBWQUwo >MTEwLENIQVIpLCBWQUwoMTAzLENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFM >KDQ5LENIQVIpLCBWQUwoMzQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDM5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDks >Q0hBUiksIFZBTCg0MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDk4LENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMTUsQ0hB >UiksIFZBTCgxMDEsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCgxNjYsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5LENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDEzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyMTQsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENI >QVIpLCBWQUwoMTksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZB >TCg3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNzYs >Q0hBUiksIFZBTCg3OSxDSEFSKSwgVkFMKDc4LENIQVIpLCBWQUwoNzEsQ0hBUiksIFZBTCg3MyxD >SEFSKSwgVkFMKDc4LENIQVIpLCBWQUwoODQsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzYsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDQ5LENIQVIpLCBWQUwoMzksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDQxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDE3NixDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDQ5LENIQVIpLCBWQUwoMTc4LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hBUiks >IFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMTA5LENIQVIpLCBWQUwoMTA1LENIQVIpLCBWQUwo >MTEwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDcsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg3NixDSEFSKSwg >VkFMKDExMSxDSEFSKSwgVkFMKDExMCxDSEFSKSwgVkFMKDEwMyxDSEFSKSwgVkFMKDEwNSxDSEFS >KSwgVkFMKDExMCxDSEFSKSwgVkFMKDExNixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgxNCxDSEFSKSwgVkFMKDQ2LENIQVIpLCBWQUwoMjQwLENIQVIp >LCBWQUwoNzcsQ0hBUiksIFZBTCgxNSxDSEFSKSwgVkFMKDE1MyxDSEFSKSwgVkFMKDc2LENIQVIp >LCBWQUwoMjMsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgyMjQsQ0hBUiksIFZBTCgx >OTUsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgxMDksQ0hBUiksIFZBTCg5NyxDSEFSKSwgVkFM >KDEyMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0 >OSxDSEFSKSwgVkFMKDE5OSxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDEwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMjI0LENIQVIpLCBWQUwoNjcsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOTYsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCg0LENIQVIpLCBWQUwoNyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDc5LENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwoMTAwLENIQVIpLCBWQUwoMTA1 >LENIQVIpLCBWQUwoMTEwLENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMDgsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgxMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDIwNCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDIxMSxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDEwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMTM0LENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgyMDgsQ0hBUiksIFZBTCgxOTMsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4 >LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoNCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNDksQ0hBUiksIFZBTCg4LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCgzNCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFS >KSwgVkFMKDksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg2OSxDSEFSKSwgVkFMKDEyMCxDSEFSKSwgVkFMKDk5LENIQVIpLCBWQUwoMTAxLENIQVIpLCBW >QUwoMTEyLENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoMTA1LENIQVIpLCBWQUwoMTExLENIQVIp >LCBWQUwoMTEwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMTEzLENIQVIpLCBWQUwoMTA1LENI >QVIpLCBWQUwoMTAwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDQ5LENIQVIpLCBWQUwoOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMyxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDYsQ0hBUiksIFZB >TCg3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNzks >Q0hBUiksIFZBTCg4MyxDSEFSKSwgVkFMKDY5LENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwoMTE0 >LENIQVIpLCBWQUwoMTExLENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiks >IFZBTCgxLENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg2OSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMTQsQ0hB >UiksIFZBTCgxMDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCgxMzQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5LENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDEzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDgsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg2NSxDSEFSKSwgVkFMKDExNixDSEFSKSwgVkFMKDExMSxD >SEFSKSwgVkFMKDEwOSxDSEFSKSwgVkFMKDc2LENIQVIpLCBWQUwoMTA1LENIQVIpLCBWQUwoMTE1 >LENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTks >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDExMixDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM0 >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCgzNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzOSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoNDEsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTE1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzNixDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NDksQ0hBUiksIFZBTCgxMTksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDEyMyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4 >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDEyNyxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE1OSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE2MyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCg5NixDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDYsQ0hBUiksIFZBTCg0LENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMTA0LENIQVIpLCBWQUwo >MTAxLENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENI >QVIpLCBWQUwoMjA2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCgxMDIsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoNCxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4LENIQVIp >LCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >OTYsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCg2LENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDExNixDSEFSKSwgVkFMKDk3LENIQVIp >LCBWQUwoMTA1LENIQVIpLCBWQUwoMTA4LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDIwNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMjQ4LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDQsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4 >LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoMTY3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDksQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgxMTEsQ0hBUiksIFZBTCgxMTgsQ0hBUiks >IFZBTCgxMDEsQ0hBUiksIFZBTCgxMTQsQ0hBUiksIFZBTCgxMTQsQ0hBUiksIFZBTCgxMDUsQ0hB >UiksIFZBTCgxMDAsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZBTCgxMTUsQ0hBUiksIFZBTCg0OCxD >SEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENI >QVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBW >QUwoNCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4 >LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoMTcxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDUsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg5OSxDSEFSKSwgVkFMKDEw >OCxDSEFSKSwgVkFMKDExMSxDSEFSKSwgVkFMKDExNSxDSEFSKSwgVkFMKDEwMSxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDE3OSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDE4MixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxODYsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg4LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDQ5LENIQVIpLCBWQUwoMzQsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDgs >Q0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiks >IFZBTCg0OSxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoNDIsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBW >QUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTM0 >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDEz >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCgxNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTQzLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiks >IFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5LENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDEzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCgxNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOSxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoMTQzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzQs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM5LENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0MSxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMTUsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0 >OSxDSEFSKSwgVkFMKDExOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MTIzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTI3LENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTU5LENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTYzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDQ5LENIQVIpLCBWQUwoMTY3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE3 >MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTc1LENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiks >IFZBTCg0OSxDSEFSKSwgVkFMKDE3OSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0 >OSxDSEFSKSwgVkFMKDE4MixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxODYsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTkwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDE5NCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMTk2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDIwMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MzYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiks >IFZBTCg0OSxDSEFSKSwgVkFMKDIwNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjA4LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDQsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoOCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTAsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENI >QVIpLCBWQUwoMzQsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZB >TCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0 >OSxDSEFSKSwgVkFMKDE3MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >NDMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTc5LENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTgyLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDE4NixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOTAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFM >KDQ5LENIQVIpLCBWQUwoMTk0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOTYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBW >QUwoMjAwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >NDksQ0hBUiksIFZBTCgzNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MjUsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjA2LENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyMDgsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDQ5LENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTkwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDE5NCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMTk2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDIwMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MzYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDcwLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiks >IFZBTCg0OSxDSEFSKSwgVkFMKDIwNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0 >OSxDSEFSKSwgVkFMKDc1LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoOSxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NDksQ0hBUiksIFZBTCgxMyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoODIsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MTksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDg2LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MzQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM5LENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0MSxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxNjMsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoOTYsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDIwNixDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyMDYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCg5MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDksQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDQ5LENIQVIpLCBWQUwoMTMsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDEwOCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCgxOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDQ5LENIQVIpLCBWQUwoMTEyLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENI >QVIpLCBWQUwoMzQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM5LENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiks >IFZBTCg0MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMTUsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDExOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzYsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMTIzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBW >QUwoMTI3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >NDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTMxLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiks >IFZBTCgyMzQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0LENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiks >IFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5 >NixDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTM0LENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiks >IFZBTCg0OSxDSEFSKSwgVkFMKDIwNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTM5LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDQsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDk2LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxNjEs >Q0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjA2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTY2LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDI1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzQsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM5LENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0MSxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxD >SEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCgxNzYsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE3OCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCgxOTYsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZB >TCgyMTEsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0 >OSxDSEFSKSwgVkFMKDIxMyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyMDQsQ0hBUiks >IFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyMTEsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgxMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDExMCxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMjA4LENIQVIpLCBW >QUwoMTkzLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENI >QVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBW >QUwoOCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMTAsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiks >IFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzQsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDIyOSxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyMzMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDEzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNDksQ0hBUiksIFZBTCgyMzgsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTksQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDI0MixDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI0NixD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDEzNCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg0OSxDSEFSKSwgVkFMKDksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTMsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDI1NCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOSxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTEyLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzQsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDM5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCgxMTUsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDExOSxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoMzYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTIzLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTI3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDQ5LENIQVIpLCBWQUwoMTU5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMTYzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDk2LENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyMixDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCgyMDYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg0OSxDSEFSKSwgVkFMKDE3OSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0LENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiks >IFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5 >NixDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzIsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDQ5LENIQVIpLCBWQUwoMjA2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNTMsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoNCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxNjcsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NDksQ0hBUiksIFZBTCg0MixDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENI >QVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNDksQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxD >SEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCgxNzEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDUwLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE3OSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE4MixDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFM >KDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDks >Q0hBUiksIFZBTCgxODYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiks >IFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZB >TCg4LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzQsQ0hBUiks >IFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4 >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDQsQ0hBUiks >IFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFM >KDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENI >QVIpLCBWQUwoNDIsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MixDSEFSKSwg >VkFMKDEwLENIQVIpIH07CiAgICBCRUdJTgogICAgICBTY2hlbWVQcm9jZWR1cmVTdHVicy5SZWdp >c3RlclR5cGVQaWNrbGUoQXJnX1RDLCBBcmdfTmFtZXMsIEFyZ19QaWNrbGUpCiAgICBFTkQ7CiAg >ICBTY2hlbWVQcm9jZWR1cmVTdHVicy5SZWdpc3RlcihORVcoU2NoZW1lUHJvY2VkdXJlU3R1YnMu >UWlkLCBpbnRmIDo9IEF0b20uRnJvbVRleHQoIkZTIiksIGl0ZW0gOj0gQXRvbS5Gcm9tVGV4dCgi >R2V0QWJzb2x1dGVQYXRobmFtZSIpKSwgQ2FsbFN0dWJfRlNfR2V0QWJzb2x1dGVQYXRobmFtZSk7 >CiAgICBTY2hlbWVQcm9jZWR1cmVTdHVicy5SZWdpc3RlcihORVcoU2NoZW1lUHJvY2VkdXJlU3R1 >YnMuUWlkLCBpbnRmIDo9IEF0b20uRnJvbVRleHQoIkZTIiksIGl0ZW0gOj0gQXRvbS5Gcm9tVGV4 >dCgiT3BlbkZpbGUiKSksIENhbGxTdHViX0ZTX09wZW5GaWxlKTsKICAgIFNjaGVtZVByb2NlZHVy >ZVN0dWJzLlJlZ2lzdGVyKE5FVyhTY2hlbWVQcm9jZWR1cmVTdHVicy5RaWQsIGludGYgOj0gQXRv >bS5Gcm9tVGV4dCgiRlMiKSwgaXRlbSA6PSBBdG9tLkZyb21UZXh0KCJPcGVuRmlsZVJlYWRvbmx5 >IikpLCBDYWxsU3R1Yl9GU19PcGVuRmlsZVJlYWRvbmx5KTsKICAgIFNjaGVtZVByb2NlZHVyZVN0 >dWJzLlJlZ2lzdGVyKE5FVyhTY2hlbWVQcm9jZWR1cmVTdHVicy5RaWQsIGludGYgOj0gQXRvbS5G >cm9tVGV4dCgiRlMiKSwgaXRlbSA6PSBBdG9tLkZyb21UZXh0KCJDcmVhdGVEaXJlY3RvcnkiKSks >IENhbGxTdHViX0ZTX0NyZWF0ZURpcmVjdG9yeSk7CiAgICBTY2hlbWVQcm9jZWR1cmVTdHVicy5S >ZWdpc3RlcihORVcoU2NoZW1lUHJvY2VkdXJlU3R1YnMuUWlkLCBpbnRmIDo9IEF0b20uRnJvbVRl >eHQoIkZTIiksIGl0ZW0gOj0gQXRvbS5Gcm9tVGV4dCgiRGVsZXRlRGlyZWN0b3J5IikpLCBDYWxs >U3R1Yl9GU19EZWxldGVEaXJlY3RvcnkpOwogICAgU2NoZW1lUHJvY2VkdXJlU3R1YnMuUmVnaXN0 >ZXIoTkVXKFNjaGVtZVByb2NlZHVyZVN0dWJzLlFpZCwgaW50ZiA6PSBBdG9tLkZyb21UZXh0KCJG >UyIpLCBpdGVtIDo9IEF0b20uRnJvbVRleHQoIkRlbGV0ZUZpbGUiKSksIENhbGxTdHViX0ZTX0Rl >bGV0ZUZpbGUpOwogICAgU2NoZW1lUHJvY2VkdXJlU3R1YnMuUmVnaXN0ZXIoTkVXKFNjaGVtZVBy >b2NlZHVyZVN0dWJzLlFpZCwgaW50ZiA6PSBBdG9tLkZyb21UZXh0KCJGUyIpLCBpdGVtIDo9IEF0 >b20uRnJvbVRleHQoIlJlbmFtZSIpKSwgQ2FsbFN0dWJfRlNfUmVuYW1lKTsKICAgIFNjaGVtZVBy >b2NlZHVyZVN0dWJzLlJlZ2lzdGVyKE5FVyhTY2hlbWVQcm9jZWR1cmVTdHVicy5RaWQsIGludGYg >Oj0gQXRvbS5Gcm9tVGV4dCgiRlMiKSwgaXRlbSA6PSBBdG9tLkZyb21UZXh0KCJJdGVyYXRlIikp >LCBDYWxsU3R1Yl9GU19JdGVyYXRlKTsKICAgIFNjaGVtZVByb2NlZHVyZVN0dWJzLlJlZ2lzdGVy >KE5FVyhTY2hlbWVQcm9jZWR1cmVTdHVicy5RaWQsIGludGYgOj0gQXRvbS5Gcm9tVGV4dCgiRlMi >KSwgaXRlbSA6PSBBdG9tLkZyb21UZXh0KCJTdGF0dXMiKSksIENhbGxTdHViX0ZTX1N0YXR1cyk7 >CiAgICBTY2hlbWVQcm9jZWR1cmVTdHVicy5SZWdpc3RlcihORVcoU2NoZW1lUHJvY2VkdXJlU3R1 >YnMuUWlkLCBpbnRmIDo9IEF0b20uRnJvbVRleHQoIkZTIiksIGl0ZW0gOj0gQXRvbS5Gcm9tVGV4 >dCgiU2V0TW9kaWZpY2F0aW9uVGltZSIpKSwgQ2FsbFN0dWJfRlNfU2V0TW9kaWZpY2F0aW9uVGlt >ZSk7CiAgRU5EIFJlZ2lzdGVyU3R1YnM7CgpQUk9DRURVUkUgTmV3X0ZTX0l0ZXJhdG9yKGludGVy >cCA6IFNjaGVtZS5UOyBpbml0cyA6IFNjaGVtZU9iamVjdC5UKSA6IFNjaGVtZU9iamVjdC5UIFJB >SVNFUyB7IFNjaGVtZS5FIH0gPQogIFZBUgogICAgcCA6PSBTY2hlbWVQYWlyLlBhaXIoaW5pdHMp >OwogICAgZ29iYmxlZCA6IEJPT0xFQU47CiAgQkVHSU4KICAgIFdJVEggcmVzID0gTkVXKEZTX0l0 >ZXJhdG9yX1N1cnJvZ2F0ZSwgaW50ZXJwIDo9IGludGVycCkgRE8KICAgICAgV0hJTEUgcCAjIE5J >TCBETwogICAgICAgIFdJVEggciA9IFNjaGVtZVBhaXIuUGFpcihwLmZpcnN0KSBETwogICAgICAg >ICAgZ29iYmxlZCA6PSBGQUxTRTsKICAgICAgICAgIElGIHIgIyBOSUwgVEhFTgogICAgICAgICAg >ICBJRiByLmZpcnN0ID0gU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJuZXh0IikgVEhFTgogICAgICAg >ICAgICAgICByZXMubmV4dF9zbG90IDo9IHIucmVzdDsgZ29iYmxlZCA6PSBUUlVFCiAgICAgICAg >ICAgIEVORDsKICAgICAgICAgICAgSUYgci5maXJzdCA9IFNjaGVtZVN5bWJvbC5Gcm9tVGV4dCgi >Y2xvc2UiKSBUSEVOCiAgICAgICAgICAgICAgIHJlcy5jbG9zZV9zbG90IDo9IHIucmVzdDsgZ29i >YmxlZCA6PSBUUlVFCiAgICAgICAgICAgIEVORDsKICAgICAgICAgICAgSUYgci5maXJzdCA9IFNj >aGVtZVN5bWJvbC5Gcm9tVGV4dCgibmV4dFdpdGhTdGF0dXMiKSBUSEVOCiAgICAgICAgICAgICAg >IHJlcy5uZXh0V2l0aFN0YXR1c19zbG90IDo9IHIucmVzdDsgZ29iYmxlZCA6PSBUUlVFCiAgICAg >ICAgICAgIEVORDsKICAgICAgICAgIEVORDsKICAgICAgICAgIElGIE5PVCBnb2JibGVkIFRIRU4K >ICAgICAgICAgICAgUkFJU0UgU2NoZW1lLkUoIkZTX0l0ZXJhdG9yOiBVbmtub3duIGZpZWxkL21l >dGhvZCAiICYgU2NoZW1lVXRpbHMuU3RyaW5naWZ5KHIuZmlyc3QpICYgIiBpbiAiICYgU2NoZW1l >VXRpbHMuU3RyaW5naWZ5KGluaXRzKSkKICAgICAgICAgIEVORAogICAgICAgIEVORDsKICAgICAg >ICBwIDo9IFNjaGVtZVBhaXIuUGFpcihwLnJlc3QpCiAgICAgIEVORDsKICAgICAgUkVUVVJOIHJl >cwogICAgRU5ECiAgRU5EIE5ld19GU19JdGVyYXRvcjsKClBST0NFRFVSRSBHZW5OZXdfRlNfSXRl >cmF0b3IoaW50ZXJwIDogU2NoZW1lLlQ7IDwqVU5VU0VEKj5vYmogOiBTY2hlbWVPYmplY3QuVDsg >aW5pdHMgOiBTY2hlbWVPYmplY3QuVCkgOiBTY2hlbWVPYmplY3QuVCBSQUlTRVMgeyBTY2hlbWUu >RSB9ID0KICBCRUdJTiBSRVRVUk4gTmV3X0ZTX0l0ZXJhdG9yKGludGVycCxpbml0cykgRU5EIEdl >bk5ld19GU19JdGVyYXRvcjsKClRZUEUgRlNfSXRlcmF0b3JfU3Vycm9nYXRlID0gRlMuSXRlcmF0 >b3IgT0JKRUNUIAogICAgaW50ZXJwIDogU2NoZW1lLlQ7CiAgICBuZXh0X3Nsb3QgOiBTY2hlbWVP >YmplY3QuVCA6PSBOSUw7IAogICAgY2xvc2Vfc2xvdCA6IFNjaGVtZU9iamVjdC5UIDo9IE5JTDsg >CiAgICBuZXh0V2l0aFN0YXR1c19zbG90IDogU2NoZW1lT2JqZWN0LlQgOj0gTklMOyAKICBPVkVS >UklERVMKICAgIG5leHQgOj0gRlNfSXRlcmF0b3JfbmV4dF9kZWZhdWx0OwogICAgY2xvc2UgOj0g >RlNfSXRlcmF0b3JfY2xvc2VfZGVmYXVsdDsKICAgIG5leHRXaXRoU3RhdHVzIDo9IEZTX0l0ZXJh >dG9yX25leHRXaXRoU3RhdHVzX2RlZmF1bHQ7CiAgRU5EOwoKUFJPQ0VEVVJFIE1ldGhvZERpc3Bh >dGNoZXJfRlNfSXRlcmF0b3IoaW50ZXJwIDogU2NoZW1lLlQ7IG9iaiA6IFNjaGVtZU9iamVjdC5U >OyBhcmdzIDogU2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1l >LkUgfSA9CiAgVkFSCiAgICBtZXRoTmFtZSA6PSBTY2hlbWUuU3ltYm9sQ2hlY2soU2NoZW1lVXRp >bHMuRmlyc3QoYXJncykpOwogICAgbWV0aEFyZ3MgOj0gU2NoZW1lVXRpbHMuQ29ucyhvYmosU2No >ZW1lVXRpbHMuU2Vjb25kKGFyZ3MpKTsKICAgIG1ldGhFeGNIYW5kbGVyIDo9IFNjaGVtZVV0aWxz >LlRoaXJkKGFyZ3MpOwogIEJFR0lOCiAgICBJRiBGQUxTRSBUSEVOIDwqQVNTRVJUIEZBTFNFKj4K >ICAgIEVMU0lGIG1ldGhOYW1lID0gU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJuZXh0IikgVEhFTgog >ICAgICBSRVRVUk4gTWV0aG9kU3R1Yl9GU19JdGVyYXRvcl9uZXh0KGludGVycCxtZXRoQXJncyxt >ZXRoRXhjSGFuZGxlcikKICAgIEVMU0lGIG1ldGhOYW1lID0gU2NoZW1lU3ltYm9sLkZyb21UZXh0 >KCJjbG9zZSIpIFRIRU4KICAgICAgUkVUVVJOIE1ldGhvZFN0dWJfRlNfSXRlcmF0b3JfY2xvc2Uo >aW50ZXJwLG1ldGhBcmdzLG1ldGhFeGNIYW5kbGVyKQogICAgRUxTSUYgbWV0aE5hbWUgPSBTY2hl >bWVTeW1ib2wuRnJvbVRleHQoIm5leHRXaXRoU3RhdHVzIikgVEhFTgogICAgICBSRVRVUk4gTWV0 >aG9kU3R1Yl9GU19JdGVyYXRvcl9uZXh0V2l0aFN0YXR1cyhpbnRlcnAsbWV0aEFyZ3MsbWV0aEV4 >Y0hhbmRsZXIpCiAgICBFTFNFCiAgICAgIFJBSVNFIFNjaGVtZS5FKCJ1bmtub3duIG1ldGhvZCAi >JlNjaGVtZVN5bWJvbC5Ub1RleHQobWV0aE5hbWUpJiIgZm9yIHR5cGUgRlMuSXRlcmF0b3IiKTsK >ICAgIEVORAogIEVORCBNZXRob2REaXNwYXRjaGVyX0ZTX0l0ZXJhdG9yOwoKUFJPQ0VEVVJFIEZT >X0l0ZXJhdG9yX25leHRfZGVmYXVsdChvYmplY3RfXyA6IEZTX0l0ZXJhdG9yX1N1cnJvZ2F0ZTsg >VkFSIGZvcm1hbF9uYW1lIDogIFRFWFQgKSA6ICBCT09MRUFOICA9IAogIEJFR0lOCiAgICBJRiBv >YmplY3RfXy5uZXh0X3Nsb3QgPSBOSUwgVEhFTgogICAgICAoKiBwdW50IHRvIE1vZHVsYS0zIG9i >amVjdCB0eXBlIGRlZm4gKikKICAgICAgUkVUVVJOIEZTLkl0ZXJhdG9yLm5leHQob2JqZWN0X18s >IGZvcm1hbF9uYW1lKQogICAgRUxTRQogICAgICAoKiBtZXRob2Qgb3ZlcnJpZGVuIGJ5IFNjaGVt >ZSBjb2RlICopCiAgICAgIFZBUgogICAgICAgIGFyZ3NfXyA6IFNjaGVtZVBhaXIuVCA6PSBORVco >U2NoZW1lUGFpci5ULCBmaXJzdCA6PSBvYmplY3RfXywgcmVzdCA6PSBOSUwpOwogICAgICBCRUdJ >TgogICAgICAgIGFyZ3NfXyA6PSBTY2hlbWVVdGlscy5Db25zKFNjaGVtZU1vZHVsYTNUeXBlcy5U >b1NjaGVtZV9URVhUKGZvcm1hbF9uYW1lKSxhcmdzX18pOwogICAgICAgIGFyZ3NfXyA6PSBTY2hl >bWVVdGlscy5SZXZlcnNlKGFyZ3NfXyk7CiAgICAgICAgUkVUVVJOIFNjaGVtZU1vZHVsYTNUeXBl >cy5Ub01vZHVsYV9CT09MRUFOKFNjaGVtZVByb2NlZHVyZVN0dWJzLkNhbGxTY2hlbWUob2JqZWN0 >X18uaW50ZXJwLCBvYmplY3RfXy5uZXh0X3Nsb3QsIGFyZ3NfXykpCiAgICAgICAgKCogYW5kIHRo >aXMgaXMgd2hlcmUgd2UgbmVlZCB0byB1bnBhY2sgVkFSIHBhcmFtcyAqKQogICAgICBFTkQKICAg >IEVORAogIEVORCBGU19JdGVyYXRvcl9uZXh0X2RlZmF1bHQ7CgpQUk9DRURVUkUgRlNfSXRlcmF0 >b3JfY2xvc2VfZGVmYXVsdChvYmplY3RfXyA6IEZTX0l0ZXJhdG9yX1N1cnJvZ2F0ZSkgPSAKICBC >RUdJTgogICAgSUYgb2JqZWN0X18uY2xvc2Vfc2xvdCA9IE5JTCBUSEVOCiAgICAgICgqIHB1bnQg >dG8gTW9kdWxhLTMgb2JqZWN0IHR5cGUgZGVmbiAqKQogICAgICBGUy5JdGVyYXRvci5jbG9zZShv >YmplY3RfXykKICAgIEVMU0UKICAgICAgKCogbWV0aG9kIG92ZXJyaWRlbiBieSBTY2hlbWUgY29k >ZSAqKQogICAgICBWQVIKICAgICAgICBhcmdzX18gOiBTY2hlbWVQYWlyLlQgOj0gTkVXKFNjaGVt >ZVBhaXIuVCwgZmlyc3QgOj0gb2JqZWN0X18sIHJlc3QgOj0gTklMKTsKICAgICAgQkVHSU4KICAg >ICAgICBhcmdzX18gOj0gU2NoZW1lVXRpbHMuUmV2ZXJzZShhcmdzX18pOwogICAgICAgIEVWQUwg >KFNjaGVtZVByb2NlZHVyZVN0dWJzLkNhbGxTY2hlbWUob2JqZWN0X18uaW50ZXJwLCBvYmplY3Rf >Xy5jbG9zZV9zbG90LCBhcmdzX18pKQogICAgICAgICgqIGFuZCB0aGlzIGlzIHdoZXJlIHdlIG5l >ZWQgdG8gdW5wYWNrIFZBUiBwYXJhbXMgKikKICAgICAgRU5ECiAgICBFTkQKICBFTkQgRlNfSXRl >cmF0b3JfY2xvc2VfZGVmYXVsdDsKClBST0NFRFVSRSBGU19JdGVyYXRvcl9uZXh0V2l0aFN0YXR1 >c19kZWZhdWx0KG9iamVjdF9fIDogRlNfSXRlcmF0b3JfU3Vycm9nYXRlOyBWQVIgZm9ybWFsX25h >bWUgOiAgVEVYVCA7IFZBUiBmb3JtYWxfc3RhdCA6IEZpbGUuU3RhdHVzKSA6ICBCT09MRUFOICBS >QUlTRVMgeyBPU0Vycm9yLkUgfSA9IAogIEJFR0lOCiAgICBJRiBvYmplY3RfXy5uZXh0V2l0aFN0 >YXR1c19zbG90ID0gTklMIFRIRU4KICAgICAgKCogcHVudCB0byBNb2R1bGEtMyBvYmplY3QgdHlw >ZSBkZWZuICopCiAgICAgIFJFVFVSTiBGUy5JdGVyYXRvci5uZXh0V2l0aFN0YXR1cyhvYmplY3Rf >XywgZm9ybWFsX25hbWUsIGZvcm1hbF9zdGF0KQogICAgRUxTRQogICAgICAoKiBtZXRob2Qgb3Zl >cnJpZGVuIGJ5IFNjaGVtZSBjb2RlICopCiAgICAgIFZBUgogICAgICAgIGFyZ3NfXyA6IFNjaGVt >ZVBhaXIuVCA6PSBORVcoU2NoZW1lUGFpci5ULCBmaXJzdCA6PSBvYmplY3RfXywgcmVzdCA6PSBO >SUwpOwogICAgICBCRUdJTgogICAgICAgIGFyZ3NfXyA6PSBTY2hlbWVVdGlscy5Db25zKFNjaGVt >ZU1vZHVsYTNUeXBlcy5Ub1NjaGVtZV9URVhUKGZvcm1hbF9uYW1lKSxhcmdzX18pOwogICAgICAg >IGFyZ3NfXyA6PSBTY2hlbWVVdGlscy5Db25zKFRvU2NoZW1lX0ZpbGVfU3RhdHVzKGZvcm1hbF9z >dGF0KSxhcmdzX18pOwogICAgICAgIGFyZ3NfXyA6PSBTY2hlbWVVdGlscy5SZXZlcnNlKGFyZ3Nf >Xyk7CiAgICAgICAgUkVUVVJOIFNjaGVtZU1vZHVsYTNUeXBlcy5Ub01vZHVsYV9CT09MRUFOKFNj >aGVtZVByb2NlZHVyZVN0dWJzLkNhbGxTY2hlbWUob2JqZWN0X18uaW50ZXJwLCBvYmplY3RfXy5u >ZXh0V2l0aFN0YXR1c19zbG90LCBhcmdzX18pKQogICAgICAgICgqIGFuZCB0aGlzIGlzIHdoZXJl >IHdlIG5lZWQgdG8gdW5wYWNrIFZBUiBwYXJhbXMgKikKICAgICAgRU5ECiAgICBFTkQKICBFTkQg >RlNfSXRlcmF0b3JfbmV4dFdpdGhTdGF0dXNfZGVmYXVsdDsKClBST0NFRFVSRSBNZXRob2RTdHVi >X0ZTX0l0ZXJhdG9yX25leHQoaW50ZXJwIDogU2NoZW1lLlQ7CiAgICAgICAgICAgICAgICAgICAg >ICBhcmdzIDogU2NoZW1lT2JqZWN0LlQ7CiAgICAgICAgICAgICAgICAgICAgICBleGNIYW5kbGVy >IDogU2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQKICBSQUlTRVMgeyBTY2hlbWUuRSB9 >ID0gCiAKICBQUk9DRURVUkUgTmV4dCgpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1l >LkUgfSA9IAogICAgQkVHSU4KICAgICAgVFJZIFJFVFVSTiBTY2hlbWVVdGlscy5GaXJzdChwX18p >IEZJTkFMTFkgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihTY2hlbWVVdGlscy5SZXN0KHBfXykpIEVO >RAogICAgRU5EIE5leHQ7CiAKICBWQVIgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICBC >RUdJTgogICAgVFJZCiAgICAgICgqIHVucGFjayBmb3JtYWxzICopCiAgICAgIFZBUiA8Kk5PV0FS >Tio+anVua19fIDo9IDA7CiAgICAgICAgICAgdGhpcyA6PSBUb01vZHVsYV9GU19JdGVyYXRvcihO >ZXh0KCkpOwogICAgICAgICAgIGZvcm1hbF9uYW1lIDo9IFNjaGVtZU1vZHVsYTNUeXBlcy5Ub01v >ZHVsYV9URVhUKE5leHQoKSk7IEJFR0lOCiAgICAgICAgKCogY2Fycnkgb3V0IE5JTCBjaGVja3Mg >Zm9yIG9wZW4gYXJyYXlzICopCgogICAgICAgICgqIG1ha2UgcHJvY2VkdXJlIGNhbGwgKikKICAg >ICAgICBXSVRIIHJlcyA9IFNjaGVtZU1vZHVsYTNUeXBlcy5Ub1NjaGVtZV9CT09MRUFOKHRoaXMu >bmV4dChmb3JtYWxfbmFtZSkpIERPCiAgICAgICAgKCogdW5wYWNrIFZBUiBwYXJhbXMgKikKICAg >ICAgICBwX18gOj0gU2NoZW1lUGFpci5QYWlyKGFyZ3MpOwogICAgICAgIEVWQUwgTmV4dCgpOwog >ICAgICAgIEVWQUwgU2NoZW1lVXRpbHMuU2V0Rmlyc3QocF9fLFNjaGVtZU1vZHVsYTNUeXBlcy5U >b1NjaGVtZV9URVhUKGZvcm1hbF9uYW1lKSk7CiAgICAgICAgRVZBTCBOZXh0KCk7CgogICAgICAg >ICgqIHJldHVybiBwcm9jZWR1cmUgcmVzdWx0ICopCiAgICAgICAgUkVUVVJOIHJlcwogICAgICAg >IEVORAogICAgICBFTkQoKldJVEgqKQogICAgRVhDRVBUCiAgICBFTkQ7CiAgICA8Kk5PV0FSTio+ >UkVUVVJOIFNjaGVtZUJvb2xlYW4uRmFsc2UoKQogIEVORCBNZXRob2RTdHViX0ZTX0l0ZXJhdG9y >X25leHQ7ClBST0NFRFVSRSBNZXRob2RTdHViX0ZTX0l0ZXJhdG9yX2Nsb3NlKGludGVycCA6IFNj >aGVtZS5UOwogICAgICAgICAgICAgICAgICAgICAgYXJncyA6IFNjaGVtZU9iamVjdC5UOwogICAg >ICAgICAgICAgICAgICAgICAgZXhjSGFuZGxlciA6IFNjaGVtZU9iamVjdC5UKSA6IFNjaGVtZU9i >amVjdC5UCiAgUkFJU0VTIHsgU2NoZW1lLkUgfSA9IAogCiAgUFJPQ0VEVVJFIE5leHQoKSA6IFNj >aGVtZU9iamVjdC5UIFJBSVNFUyB7IFNjaGVtZS5FIH0gPSAKICAgIEJFR0lOCiAgICAgIFRSWSBS >RVRVUk4gU2NoZW1lVXRpbHMuRmlyc3QocF9fKSBGSU5BTExZIHBfXyA6PSBTY2hlbWVQYWlyLlBh >aXIoU2NoZW1lVXRpbHMuUmVzdChwX18pKSBFTkQKICAgIEVORCBOZXh0OwogCiAgVkFSIHBfXyA6 >PSBTY2hlbWVQYWlyLlBhaXIoYXJncyk7CiAgQkVHSU4KICAgIFRSWQogICAgICAoKiB1bnBhY2sg >Zm9ybWFscyAqKQogICAgICBWQVIgPCpOT1dBUk4qPmp1bmtfXyA6PSAwOwogICAgICAgICAgIHRo >aXMgOj0gVG9Nb2R1bGFfRlNfSXRlcmF0b3IoTmV4dCgpKTsgQkVHSU4KICAgICAgICAoKiBjYXJy >eSBvdXQgTklMIGNoZWNrcyBmb3Igb3BlbiBhcnJheXMgKikKCiAgICAgICAgKCogbWFrZSBwcm9j >ZWR1cmUgY2FsbCAqKQogICAgICAgIHRoaXMuY2xvc2UoKTsKICAgICAgICAoKiB1bnBhY2sgVkFS >IHBhcmFtcyAqKQogICAgICAgIHBfXyA6PSBTY2hlbWVQYWlyLlBhaXIoYXJncyk7CiAgICAgICAg >RVZBTCBOZXh0KCk7CgogICAgICAgICgqIHByb3BlciBwcm9jZWR1cmUgOiByZXR1cm4gVFJVRSAq >KQogICAgICAgIFJFVFVSTiBTY2hlbWVCb29sZWFuLlRydWUoKQogICAgICBFTkQoKldJVEgqKQog >ICAgRVhDRVBUCiAgICBFTkQ7CiAgICA8Kk5PV0FSTio+UkVUVVJOIFNjaGVtZUJvb2xlYW4uRmFs >c2UoKQogIEVORCBNZXRob2RTdHViX0ZTX0l0ZXJhdG9yX2Nsb3NlOwpQUk9DRURVUkUgTWV0aG9k >U3R1Yl9GU19JdGVyYXRvcl9uZXh0V2l0aFN0YXR1cyhpbnRlcnAgOiBTY2hlbWUuVDsKICAgICAg >ICAgICAgICAgICAgICAgIGFyZ3MgOiBTY2hlbWVPYmplY3QuVDsKICAgICAgICAgICAgICAgICAg >ICAgIGV4Y0hhbmRsZXIgOiBTY2hlbWVPYmplY3QuVCkgOiBTY2hlbWVPYmplY3QuVAogIFJBSVNF >UyB7IFNjaGVtZS5FIH0gPSAKIAogIFBST0NFRFVSRSBOZXh0KCkgOiBTY2hlbWVPYmplY3QuVCBS >QUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAgICBCRUdJTgogICAgICBUUlkgUkVUVVJOIFNjaGVtZVV0 >aWxzLkZpcnN0KHBfXykgRklOQUxMWSBwX18gOj0gU2NoZW1lUGFpci5QYWlyKFNjaGVtZVV0aWxz >LlJlc3QocF9fKSkgRU5ECiAgICBFTkQgTmV4dDsKIAogIFZBUiBwX18gOj0gU2NoZW1lUGFpci5Q >YWlyKGFyZ3MpOwogIEJFR0lOCiAgICBUUlkKICAgICAgKCogdW5wYWNrIGZvcm1hbHMgKikKICAg >ICAgVkFSIDwqTk9XQVJOKj5qdW5rX18gOj0gMDsKICAgICAgICAgICB0aGlzIDo9IFRvTW9kdWxh >X0ZTX0l0ZXJhdG9yKE5leHQoKSk7CiAgICAgICAgICAgZm9ybWFsX25hbWUgOj0gU2NoZW1lTW9k >dWxhM1R5cGVzLlRvTW9kdWxhX1RFWFQoTmV4dCgpKTsKICAgICAgICAgICBmb3JtYWxfc3RhdCA6 >PSBUb01vZHVsYV9GaWxlX1N0YXR1cyhOZXh0KCkpOyBCRUdJTgogICAgICAgICgqIGNhcnJ5IG91 >dCBOSUwgY2hlY2tzIGZvciBvcGVuIGFycmF5cyAqKQoKICAgICAgICAoKiBtYWtlIHByb2NlZHVy ZSBjYWxsICopCiAgICAgICAgV0lUSCByZXMgPSBTY2hlbWVNb2R1bGEzVHlwZXMuVG9TY2hlbWVf >Qk9PTEVBTih0aGlzLm5leHRXaXRoU3RhdHVzKGZvcm1hbF9uYW1lLCBmb3JtYWxfc3RhdCkpIERP >CiAgICAgICAgKCogdW5wYWNrIFZBUiBwYXJhbXMgKikKICAgICAgICBwX18gOj0gU2NoZW1lUGFp >ci5QYWlyKGFyZ3MpOwogICAgICAgIEVWQUwgTmV4dCgpOwogICAgICAgIEVWQUwgU2NoZW1lVXRp >bHMuU2V0Rmlyc3QocF9fLFNjaGVtZU1vZHVsYTNUeXBlcy5Ub1NjaGVtZV9URVhUKGZvcm1hbF9u >YW1lKSk7CiAgICAgICAgRVZBTCBOZXh0KCk7CiAgICAgICAgRVZBTCBTY2hlbWVVdGlscy5TZXRG >aXJzdChwX18sVG9TY2hlbWVfRmlsZV9TdGF0dXMoZm9ybWFsX3N0YXQpKTsKICAgICAgICBFVkFM >IE5leHQoKTsKCiAgICAgICAgKCogcmV0dXJuIHByb2NlZHVyZSByZXN1bHQgKikKICAgICAgICBS >RVRVUk4gcmVzCiAgICAgICAgRU5ECiAgICAgIEVORCgqV0lUSCopCiAgICBFWENFUFQKICAgICAg >fCBPU0Vycm9yLkUoeGFyZykgPT4gRVZBTCBTY2hlbWVBcHBseS5PbmVBcmcoaW50ZXJwLGV4Y0hh >bmRsZXIsU2NoZW1lVXRpbHMuTGlzdDIoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJxdW90ZSIpLFNj >aGVtZVV0aWxzLkNvbnMoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJPU0Vycm9yLkUiKSwgVG9TY2hl >bWVfQXRvbUxpc3RfVCh4YXJnKSkpKQogICAgRU5EOwogICAgPCpOT1dBUk4qPlJFVFVSTiBTY2hl >bWVCb29sZWFuLkZhbHNlKCkKICBFTkQgTWV0aG9kU3R1Yl9GU19JdGVyYXRvcl9uZXh0V2l0aFN0 >YXR1czsKUFJPQ0VEVVJFIE5ld19GU19QdWJsaWNJdGVyYXRvcihpbnRlcnAgOiBTY2hlbWUuVDsg >aW5pdHMgOiBTY2hlbWVPYmplY3QuVCkgOiBTY2hlbWVPYmplY3QuVCBSQUlTRVMgeyBTY2hlbWUu >RSB9ID0KICBWQVIKICAgIHAgOj0gU2NoZW1lUGFpci5QYWlyKGluaXRzKTsKICAgIGdvYmJsZWQg >OiBCT09MRUFOOwogIEJFR0lOCiAgICBXSVRIIHJlcyA9IE5FVyhGU19QdWJsaWNJdGVyYXRvcl9T >dXJyb2dhdGUsIGludGVycCA6PSBpbnRlcnApIERPCiAgICAgIFdISUxFIHAgIyBOSUwgRE8KICAg >ICAgICBXSVRIIHIgPSBTY2hlbWVQYWlyLlBhaXIocC5maXJzdCkgRE8KICAgICAgICAgIGdvYmJs >ZWQgOj0gRkFMU0U7CiAgICAgICAgICBJRiByICMgTklMIFRIRU4KICAgICAgICAgICAgSUYgci5m >aXJzdCA9IFNjaGVtZVN5bWJvbC5Gcm9tVGV4dCgibmV4dCIpIFRIRU4KICAgICAgICAgICAgICAg >cmVzLm5leHRfc2xvdCA6PSByLnJlc3Q7IGdvYmJsZWQgOj0gVFJVRQogICAgICAgICAgICBFTkQ7 >CiAgICAgICAgICAgIElGIHIuZmlyc3QgPSBTY2hlbWVTeW1ib2wuRnJvbVRleHQoImNsb3NlIikg >VEhFTgogICAgICAgICAgICAgICByZXMuY2xvc2Vfc2xvdCA6PSByLnJlc3Q7IGdvYmJsZWQgOj0g >VFJVRQogICAgICAgICAgICBFTkQ7CiAgICAgICAgICAgIElGIHIuZmlyc3QgPSBTY2hlbWVTeW1i >b2wuRnJvbVRleHQoIm5leHRXaXRoU3RhdHVzIikgVEhFTgogICAgICAgICAgICAgICByZXMubmV4 >dFdpdGhTdGF0dXNfc2xvdCA6PSByLnJlc3Q7IGdvYmJsZWQgOj0gVFJVRQogICAgICAgICAgICBF >TkQ7CiAgICAgICAgICBFTkQ7CiAgICAgICAgICBJRiBOT1QgZ29iYmxlZCBUSEVOCiAgICAgICAg >ICAgIFJBSVNFIFNjaGVtZS5FKCJGU19QdWJsaWNJdGVyYXRvcjogVW5rbm93biBmaWVsZC9tZXRo >b2QgIiAmIFNjaGVtZVV0aWxzLlN0cmluZ2lmeShyLmZpcnN0KSAmICIgaW4gIiAmIFNjaGVtZVV0 >aWxzLlN0cmluZ2lmeShpbml0cykpCiAgICAgICAgICBFTkQKICAgICAgICBFTkQ7CiAgICAgICAg >cCA6PSBTY2hlbWVQYWlyLlBhaXIocC5yZXN0KQogICAgICBFTkQ7CiAgICAgIFJFVFVSTiByZXMK >ICAgIEVORAogIEVORCBOZXdfRlNfUHVibGljSXRlcmF0b3I7CgpQUk9DRURVUkUgR2VuTmV3X0ZT >X1B1YmxpY0l0ZXJhdG9yKGludGVycCA6IFNjaGVtZS5UOyA8KlVOVVNFRCo+b2JqIDogU2NoZW1l >T2JqZWN0LlQ7IGluaXRzIDogU2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VT >IHsgU2NoZW1lLkUgfSA9CiAgQkVHSU4gUkVUVVJOIE5ld19GU19QdWJsaWNJdGVyYXRvcihpbnRl >cnAsaW5pdHMpIEVORCBHZW5OZXdfRlNfUHVibGljSXRlcmF0b3I7CgpUWVBFIEZTX1B1YmxpY0l0 >ZXJhdG9yX1N1cnJvZ2F0ZSA9IEZTLlB1YmxpY0l0ZXJhdG9yIE9CSkVDVCAKICAgIGludGVycCA6 >IFNjaGVtZS5UOwogICAgbmV4dF9zbG90IDogU2NoZW1lT2JqZWN0LlQgOj0gTklMOyAKICAgIGNs >b3NlX3Nsb3QgOiBTY2hlbWVPYmplY3QuVCA6PSBOSUw7IAogICAgbmV4dFdpdGhTdGF0dXNfc2xv >dCA6IFNjaGVtZU9iamVjdC5UIDo9IE5JTDsgCiAgT1ZFUlJJREVTCiAgICBuZXh0IDo9IEZTX1B1 >YmxpY0l0ZXJhdG9yX25leHRfZGVmYXVsdDsKICAgIGNsb3NlIDo9IEZTX1B1YmxpY0l0ZXJhdG9y >X2Nsb3NlX2RlZmF1bHQ7CiAgICBuZXh0V2l0aFN0YXR1cyA6PSBGU19QdWJsaWNJdGVyYXRvcl9u >ZXh0V2l0aFN0YXR1c19kZWZhdWx0OwogIEVORDsKClBST0NFRFVSRSBNZXRob2REaXNwYXRjaGVy >X0ZTX1B1YmxpY0l0ZXJhdG9yKGludGVycCA6IFNjaGVtZS5UOyBvYmogOiBTY2hlbWVPYmplY3Qu >VDsgYXJncyA6IFNjaGVtZU9iamVjdC5UKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IFNjaGVt >ZS5FIH0gPQogIFZBUgogICAgbWV0aE5hbWUgOj0gU2NoZW1lLlN5bWJvbENoZWNrKFNjaGVtZVV0 >aWxzLkZpcnN0KGFyZ3MpKTsKICAgIG1ldGhBcmdzIDo9IFNjaGVtZVV0aWxzLkNvbnMob2JqLFNj >aGVtZVV0aWxzLlNlY29uZChhcmdzKSk7CiAgICBtZXRoRXhjSGFuZGxlciA6PSBTY2hlbWVVdGls >cy5UaGlyZChhcmdzKTsKICBCRUdJTgogICAgSUYgRkFMU0UgVEhFTiA8KkFTU0VSVCBGQUxTRSo+ >CiAgICBFTFNJRiBtZXRoTmFtZSA9IFNjaGVtZVN5bWJvbC5Gcm9tVGV4dCgibmV4dCIpIFRIRU4K >ICAgICAgUkVUVVJOIE1ldGhvZFN0dWJfRlNfUHVibGljSXRlcmF0b3JfbmV4dChpbnRlcnAsbWV0 >aEFyZ3MsbWV0aEV4Y0hhbmRsZXIpCiAgICBFTFNJRiBtZXRoTmFtZSA9IFNjaGVtZVN5bWJvbC5G >cm9tVGV4dCgiY2xvc2UiKSBUSEVOCiAgICAgIFJFVFVSTiBNZXRob2RTdHViX0ZTX1B1YmxpY0l0 >ZXJhdG9yX2Nsb3NlKGludGVycCxtZXRoQXJncyxtZXRoRXhjSGFuZGxlcikKICAgIEVMU0lGIG1l >dGhOYW1lID0gU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJuZXh0V2l0aFN0YXR1cyIpIFRIRU4KICAg >ICAgUkVUVVJOIE1ldGhvZFN0dWJfRlNfUHVibGljSXRlcmF0b3JfbmV4dFdpdGhTdGF0dXMoaW50 >ZXJwLG1ldGhBcmdzLG1ldGhFeGNIYW5kbGVyKQogICAgRUxTRQogICAgICBSQUlTRSBTY2hlbWUu >RSgidW5rbm93biBtZXRob2QgIiZTY2hlbWVTeW1ib2wuVG9UZXh0KG1ldGhOYW1lKSYiIGZvciB0 >eXBlIEZTLlB1YmxpY0l0ZXJhdG9yIik7CiAgICBFTkQKICBFTkQgTWV0aG9kRGlzcGF0Y2hlcl9G >U19QdWJsaWNJdGVyYXRvcjsKClBST0NFRFVSRSBGU19QdWJsaWNJdGVyYXRvcl9uZXh0X2RlZmF1 >bHQob2JqZWN0X18gOiBGU19QdWJsaWNJdGVyYXRvcl9TdXJyb2dhdGU7IFZBUiBmb3JtYWxfbmFt >ZSA6ICBURVhUICkgOiAgQk9PTEVBTiAgPSAKICBCRUdJTgogICAgSUYgb2JqZWN0X18ubmV4dF9z >bG90ID0gTklMIFRIRU4KICAgICAgKCogcHVudCB0byBNb2R1bGEtMyBvYmplY3QgdHlwZSBkZWZu >ICopCiAgICAgIFJFVFVSTiBGUy5QdWJsaWNJdGVyYXRvci5uZXh0KG9iamVjdF9fLCBmb3JtYWxf >bmFtZSkKICAgIEVMU0UKICAgICAgKCogbWV0aG9kIG92ZXJyaWRlbiBieSBTY2hlbWUgY29kZSAq >KQogICAgICBWQVIKICAgICAgICBhcmdzX18gOiBTY2hlbWVQYWlyLlQgOj0gTkVXKFNjaGVtZVBh >aXIuVCwgZmlyc3QgOj0gb2JqZWN0X18sIHJlc3QgOj0gTklMKTsKICAgICAgQkVHSU4KICAgICAg >ICBhcmdzX18gOj0gU2NoZW1lVXRpbHMuQ29ucyhTY2hlbWVNb2R1bGEzVHlwZXMuVG9TY2hlbWVf >VEVYVChmb3JtYWxfbmFtZSksYXJnc19fKTsKICAgICAgICBhcmdzX18gOj0gU2NoZW1lVXRpbHMu >UmV2ZXJzZShhcmdzX18pOwogICAgICAgIFJFVFVSTiBTY2hlbWVNb2R1bGEzVHlwZXMuVG9Nb2R1 >bGFfQk9PTEVBTihTY2hlbWVQcm9jZWR1cmVTdHVicy5DYWxsU2NoZW1lKG9iamVjdF9fLmludGVy >cCwgb2JqZWN0X18ubmV4dF9zbG90LCBhcmdzX18pKQogICAgICAgICgqIGFuZCB0aGlzIGlzIHdo >ZXJlIHdlIG5lZWQgdG8gdW5wYWNrIFZBUiBwYXJhbXMgKikKICAgICAgRU5ECiAgICBFTkQKICBF >TkQgRlNfUHVibGljSXRlcmF0b3JfbmV4dF9kZWZhdWx0OwoKUFJPQ0VEVVJFIEZTX1B1YmxpY0l0 >ZXJhdG9yX2Nsb3NlX2RlZmF1bHQob2JqZWN0X18gOiBGU19QdWJsaWNJdGVyYXRvcl9TdXJyb2dh >dGUpID0gCiAgQkVHSU4KICAgIElGIG9iamVjdF9fLmNsb3NlX3Nsb3QgPSBOSUwgVEhFTgogICAg >ICAoKiBwdW50IHRvIE1vZHVsYS0zIG9iamVjdCB0eXBlIGRlZm4gKikKICAgICAgRlMuUHVibGlj >SXRlcmF0b3IuY2xvc2Uob2JqZWN0X18pCiAgICBFTFNFCiAgICAgICgqIG1ldGhvZCBvdmVycmlk >ZW4gYnkgU2NoZW1lIGNvZGUgKikKICAgICAgVkFSCiAgICAgICAgYXJnc19fIDogU2NoZW1lUGFp >ci5UIDo9IE5FVyhTY2hlbWVQYWlyLlQsIGZpcnN0IDo9IG9iamVjdF9fLCByZXN0IDo9IE5JTCk7 >CiAgICAgIEJFR0lOCiAgICAgICAgYXJnc19fIDo9IFNjaGVtZVV0aWxzLlJldmVyc2UoYXJnc19f >KTsKICAgICAgICBFVkFMIChTY2hlbWVQcm9jZWR1cmVTdHVicy5DYWxsU2NoZW1lKG9iamVjdF9f >LmludGVycCwgb2JqZWN0X18uY2xvc2Vfc2xvdCwgYXJnc19fKSkKICAgICAgICAoKiBhbmQgdGhp >cyBpcyB3aGVyZSB3ZSBuZWVkIHRvIHVucGFjayBWQVIgcGFyYW1zICopCiAgICAgIEVORAogICAg >RU5ECiAgRU5EIEZTX1B1YmxpY0l0ZXJhdG9yX2Nsb3NlX2RlZmF1bHQ7CgpQUk9DRURVUkUgRlNf >UHVibGljSXRlcmF0b3JfbmV4dFdpdGhTdGF0dXNfZGVmYXVsdChvYmplY3RfXyA6IEZTX1B1Ymxp >Y0l0ZXJhdG9yX1N1cnJvZ2F0ZTsgVkFSIGZvcm1hbF9uYW1lIDogIFRFWFQgOyBWQVIgZm9ybWFs >X3N0YXQgOiBGaWxlLlN0YXR1cykgOiAgQk9PTEVBTiAgUkFJU0VTIHsgT1NFcnJvci5FIH0gPSAK >ICBCRUdJTgogICAgSUYgb2JqZWN0X18ubmV4dFdpdGhTdGF0dXNfc2xvdCA9IE5JTCBUSEVOCiAg >ICAgICgqIHB1bnQgdG8gTW9kdWxhLTMgb2JqZWN0IHR5cGUgZGVmbiAqKQogICAgICBSRVRVUk4g >RlMuUHVibGljSXRlcmF0b3IubmV4dFdpdGhTdGF0dXMob2JqZWN0X18sIGZvcm1hbF9uYW1lLCBm >b3JtYWxfc3RhdCkKICAgIEVMU0UKICAgICAgKCogbWV0aG9kIG92ZXJyaWRlbiBieSBTY2hlbWUg >Y29kZSAqKQogICAgICBWQVIKICAgICAgICBhcmdzX18gOiBTY2hlbWVQYWlyLlQgOj0gTkVXKFNj >aGVtZVBhaXIuVCwgZmlyc3QgOj0gb2JqZWN0X18sIHJlc3QgOj0gTklMKTsKICAgICAgQkVHSU4K >ICAgICAgICBhcmdzX18gOj0gU2NoZW1lVXRpbHMuQ29ucyhTY2hlbWVNb2R1bGEzVHlwZXMuVG9T >Y2hlbWVfVEVYVChmb3JtYWxfbmFtZSksYXJnc19fKTsKICAgICAgICBhcmdzX18gOj0gU2NoZW1l >VXRpbHMuQ29ucyhUb1NjaGVtZV9GaWxlX1N0YXR1cyhmb3JtYWxfc3RhdCksYXJnc19fKTsKICAg >ICAgICBhcmdzX18gOj0gU2NoZW1lVXRpbHMuUmV2ZXJzZShhcmdzX18pOwogICAgICAgIFJFVFVS >TiBTY2hlbWVNb2R1bGEzVHlwZXMuVG9Nb2R1bGFfQk9PTEVBTihTY2hlbWVQcm9jZWR1cmVTdHVi >cy5DYWxsU2NoZW1lKG9iamVjdF9fLmludGVycCwgb2JqZWN0X18ubmV4dFdpdGhTdGF0dXNfc2xv >dCwgYXJnc19fKSkKICAgICAgICAoKiBhbmQgdGhpcyBpcyB3aGVyZSB3ZSBuZWVkIHRvIHVucGFj >ayBWQVIgcGFyYW1zICopCiAgICAgIEVORAogICAgRU5ECiAgRU5EIEZTX1B1YmxpY0l0ZXJhdG9y >X25leHRXaXRoU3RhdHVzX2RlZmF1bHQ7CgpQUk9DRURVUkUgTWV0aG9kU3R1Yl9GU19QdWJsaWNJ >dGVyYXRvcl9uZXh0KGludGVycCA6IFNjaGVtZS5UOwogICAgICAgICAgICAgICAgICAgICAgYXJn >cyA6IFNjaGVtZU9iamVjdC5UOwogICAgICAgICAgICAgICAgICAgICAgZXhjSGFuZGxlciA6IFNj >aGVtZU9iamVjdC5UKSA6IFNjaGVtZU9iamVjdC5UCiAgUkFJU0VTIHsgU2NoZW1lLkUgfSA9IAog >CiAgUFJPQ0VEVVJFIE5leHQoKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IFNjaGVtZS5FIH0g >PSAKICAgIEJFR0lOCiAgICAgIFRSWSBSRVRVUk4gU2NoZW1lVXRpbHMuRmlyc3QocF9fKSBGSU5B >TExZIHBfXyA6PSBTY2hlbWVQYWlyLlBhaXIoU2NoZW1lVXRpbHMuUmVzdChwX18pKSBFTkQKICAg >IEVORCBOZXh0OwogCiAgVkFSIHBfXyA6PSBTY2hlbWVQYWlyLlBhaXIoYXJncyk7CiAgQkVHSU4K >ICAgIFRSWQogICAgICAoKiB1bnBhY2sgZm9ybWFscyAqKQogICAgICBWQVIgPCpOT1dBUk4qPmp1 >bmtfXyA6PSAwOwogICAgICAgICAgIHRoaXMgOj0gVG9Nb2R1bGFfRlNfUHVibGljSXRlcmF0b3Io >TmV4dCgpKTsKICAgICAgICAgICBmb3JtYWxfbmFtZSA6PSBTY2hlbWVNb2R1bGEzVHlwZXMuVG9N >b2R1bGFfVEVYVChOZXh0KCkpOyBCRUdJTgogICAgICAgICgqIGNhcnJ5IG91dCBOSUwgY2hlY2tz >IGZvciBvcGVuIGFycmF5cyAqKQoKICAgICAgICAoKiBtYWtlIHByb2NlZHVyZSBjYWxsICopCiAg >ICAgICAgV0lUSCByZXMgPSBTY2hlbWVNb2R1bGEzVHlwZXMuVG9TY2hlbWVfQk9PTEVBTih0aGlz >Lm5leHQoZm9ybWFsX25hbWUpKSBETwogICAgICAgICgqIHVucGFjayBWQVIgcGFyYW1zICopCiAg >ICAgICAgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICAgICAgICBFVkFMIE5leHQoKTsK >ICAgICAgICBFVkFMIFNjaGVtZVV0aWxzLlNldEZpcnN0KHBfXyxTY2hlbWVNb2R1bGEzVHlwZXMu >VG9TY2hlbWVfVEVYVChmb3JtYWxfbmFtZSkpOwogICAgICAgIEVWQUwgTmV4dCgpOwoKICAgICAg >ICAoKiByZXR1cm4gcHJvY2VkdXJlIHJlc3VsdCAqKQogICAgICAgIFJFVFVSTiByZXMKICAgICAg >ICBFTkQKICAgICAgRU5EKCpXSVRIKikKICAgIEVYQ0VQVAogICAgRU5EOwogICAgPCpOT1dBUk4q >PlJFVFVSTiBTY2hlbWVCb29sZWFuLkZhbHNlKCkKICBFTkQgTWV0aG9kU3R1Yl9GU19QdWJsaWNJ >dGVyYXRvcl9uZXh0OwpQUk9DRURVUkUgTWV0aG9kU3R1Yl9GU19QdWJsaWNJdGVyYXRvcl9jbG9z >ZShpbnRlcnAgOiBTY2hlbWUuVDsKICAgICAgICAgICAgICAgICAgICAgIGFyZ3MgOiBTY2hlbWVP >YmplY3QuVDsKICAgICAgICAgICAgICAgICAgICAgIGV4Y0hhbmRsZXIgOiBTY2hlbWVPYmplY3Qu >VCkgOiBTY2hlbWVPYmplY3QuVAogIFJBSVNFUyB7IFNjaGVtZS5FIH0gPSAKIAogIFBST0NFRFVS >RSBOZXh0KCkgOiBTY2hlbWVPYmplY3QuVCBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAgICBCRUdJ >TgogICAgICBUUlkgUkVUVVJOIFNjaGVtZVV0aWxzLkZpcnN0KHBfXykgRklOQUxMWSBwX18gOj0g >U2NoZW1lUGFpci5QYWlyKFNjaGVtZVV0aWxzLlJlc3QocF9fKSkgRU5ECiAgICBFTkQgTmV4dDsK >IAogIFZBUiBwX18gOj0gU2NoZW1lUGFpci5QYWlyKGFyZ3MpOwogIEJFR0lOCiAgICBUUlkKICAg >ICAgKCogdW5wYWNrIGZvcm1hbHMgKikKICAgICAgVkFSIDwqTk9XQVJOKj5qdW5rX18gOj0gMDsK >ICAgICAgICAgICB0aGlzIDo9IFRvTW9kdWxhX0ZTX1B1YmxpY0l0ZXJhdG9yKE5leHQoKSk7IEJF >R0lOCiAgICAgICAgKCogY2Fycnkgb3V0IE5JTCBjaGVja3MgZm9yIG9wZW4gYXJyYXlzICopCgog >ICAgICAgICgqIG1ha2UgcHJvY2VkdXJlIGNhbGwgKikKICAgICAgICB0aGlzLmNsb3NlKCk7CiAg >ICAgICAgKCogdW5wYWNrIFZBUiBwYXJhbXMgKikKICAgICAgICBwX18gOj0gU2NoZW1lUGFpci5Q >YWlyKGFyZ3MpOwogICAgICAgIEVWQUwgTmV4dCgpOwoKICAgICAgICAoKiBwcm9wZXIgcHJvY2Vk >dXJlIDogcmV0dXJuIFRSVUUgKikKICAgICAgICBSRVRVUk4gU2NoZW1lQm9vbGVhbi5UcnVlKCkK >ICAgICAgRU5EKCpXSVRIKikKICAgIEVYQ0VQVAogICAgRU5EOwogICAgPCpOT1dBUk4qPlJFVFVS >TiBTY2hlbWVCb29sZWFuLkZhbHNlKCkKICBFTkQgTWV0aG9kU3R1Yl9GU19QdWJsaWNJdGVyYXRv >cl9jbG9zZTsKUFJPQ0VEVVJFIE1ldGhvZFN0dWJfRlNfUHVibGljSXRlcmF0b3JfbmV4dFdpdGhT >dGF0dXMoaW50ZXJwIDogU2NoZW1lLlQ7CiAgICAgICAgICAgICAgICAgICAgICBhcmdzIDogU2No >ZW1lT2JqZWN0LlQ7CiAgICAgICAgICAgICAgICAgICAgICBleGNIYW5kbGVyIDogU2NoZW1lT2Jq >ZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQKICBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAKICBQUk9D >RURVUkUgTmV4dCgpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUgfSA9IAogICAg >QkVHSU4KICAgICAgVFJZIFJFVFVSTiBTY2hlbWVVdGlscy5GaXJzdChwX18pIEZJTkFMTFkgcF9f >IDo9IFNjaGVtZVBhaXIuUGFpcihTY2hlbWVVdGlscy5SZXN0KHBfXykpIEVORAogICAgRU5EIE5l >eHQ7CiAKICBWQVIgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICBCRUdJTgogICAgVFJZ >CiAgICAgICgqIHVucGFjayBmb3JtYWxzICopCiAgICAgIFZBUiA8Kk5PV0FSTio+anVua19fIDo9 >IDA7CiAgICAgICAgICAgdGhpcyA6PSBUb01vZHVsYV9GU19QdWJsaWNJdGVyYXRvcihOZXh0KCkp >OwogICAgICAgICAgIGZvcm1hbF9uYW1lIDo9IFNjaGVtZU1vZHVsYTNUeXBlcy5Ub01vZHVsYV9U >RVhUKE5leHQoKSk7CiAgICAgICAgICAgZm9ybWFsX3N0YXQgOj0gVG9Nb2R1bGFfRmlsZV9TdGF0 >dXMoTmV4dCgpKTsgQkVHSU4KICAgICAgICAoKiBjYXJyeSBvdXQgTklMIGNoZWNrcyBmb3Igb3Bl >biBhcnJheXMgKikKCiAgICAgICAgKCogbWFrZSBwcm9jZWR1cmUgY2FsbCAqKQogICAgICAgIFdJ >VEggcmVzID0gU2NoZW1lTW9kdWxhM1R5cGVzLlRvU2NoZW1lX0JPT0xFQU4odGhpcy5uZXh0V2l0 >aFN0YXR1cyhmb3JtYWxfbmFtZSwgZm9ybWFsX3N0YXQpKSBETwogICAgICAgICgqIHVucGFjayBW >QVIgcGFyYW1zICopCiAgICAgICAgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICAgICAg >ICBFVkFMIE5leHQoKTsKICAgICAgICBFVkFMIFNjaGVtZVV0aWxzLlNldEZpcnN0KHBfXyxTY2hl >bWVNb2R1bGEzVHlwZXMuVG9TY2hlbWVfVEVYVChmb3JtYWxfbmFtZSkpOwogICAgICAgIEVWQUwg >TmV4dCgpOwogICAgICAgIEVWQUwgU2NoZW1lVXRpbHMuU2V0Rmlyc3QocF9fLFRvU2NoZW1lX0Zp >bGVfU3RhdHVzKGZvcm1hbF9zdGF0KSk7CiAgICAgICAgRVZBTCBOZXh0KCk7CgogICAgICAgICgq >IHJldHVybiBwcm9jZWR1cmUgcmVzdWx0ICopCiAgICAgICAgUkVUVVJOIHJlcwogICAgICAgIEVO >RAogICAgICBFTkQoKldJVEgqKQogICAgRVhDRVBUCiAgICAgIHwgT1NFcnJvci5FKHhhcmcpID0+ >IEVWQUwgU2NoZW1lQXBwbHkuT25lQXJnKGludGVycCxleGNIYW5kbGVyLFNjaGVtZVV0aWxzLkxp >c3QyKFNjaGVtZVN5bWJvbC5Gcm9tVGV4dCgicXVvdGUiKSxTY2hlbWVVdGlscy5Db25zKFNjaGVt >ZVN5bWJvbC5Gcm9tVGV4dCgiT1NFcnJvci5FIiksIFRvU2NoZW1lX0F0b21MaXN0X1QoeGFyZykp >KSkKICAgIEVORDsKICAgIDwqTk9XQVJOKj5SRVRVUk4gU2NoZW1lQm9vbGVhbi5GYWxzZSgpCiAg >RU5EIE1ldGhvZFN0dWJfRlNfUHVibGljSXRlcmF0b3JfbmV4dFdpdGhTdGF0dXM7CgpQUk9DRURV >UkUgRmllbGRHZXRfRlNfSXRlcmF0b3IoaW50ZXJwIDogU2NoZW1lLlQ7IG9iaiA6IFNjaGVtZU9i >amVjdC5UOyBhcmdzIDogU2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsg >U2NoZW1lLkUgfSA9CiAgVkFSCiAgICBmaWVsZCAgIDo9IFNjaGVtZVV0aWxzLkZpcnN0KGFyZ3Mp >OwogICAgbmFycm93IDogRlMuSXRlcmF0b3I7CiAgQkVHSU4KICAgIElGIE5PVCBJU1RZUEUob2Jq >LEZTLkl0ZXJhdG9yKSBPUiBvYmo9TklMIFRIRU4KICAgICAgUkFJU0UgU2NoZW1lLkUoIk5vdCBv >ZiB0eXBlIEZTLkl0ZXJhdG9yIDogIiAmIFNjaGVtZVV0aWxzLlN0cmluZ2lmeShvYmopKQogICAg >RU5EOwogICAgbmFycm93IDo9IE5BUlJPVyhvYmosRlMuSXRlcmF0b3IpOwogICAgSUYgRkFMU0Ug >VEhFTiA8KkFTU0VSVCBGQUxTRSo+CiAgICBFTFNFIFJBSVNFIFNjaGVtZS5FKCJVbmtub3duIGZp >ZWxkICIgJiBTY2hlbWVVdGlscy5TdHJpbmdpZnkoZmllbGQpKQogICAgRU5ECiAgRU5EIEZpZWxk >R2V0X0ZTX0l0ZXJhdG9yOwoKUFJPQ0VEVVJFIEZpZWxkU2V0X0ZTX0l0ZXJhdG9yKGludGVycCA6 >IFNjaGVtZS5UOyBvYmogOiBTY2hlbWVPYmplY3QuVDsgYXJncyA6IFNjaGVtZU9iamVjdC5UKSA6 >IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IFNjaGVtZS5FIH0gPQogIFZBUgogICAgZmllbGQgICA6 >PSBTY2hlbWVVdGlscy5GaXJzdChhcmdzKTsKICAgIHZhbHVlICAgOj0gU2NoZW1lVXRpbHMuRmly >c3QoU2NoZW1lVXRpbHMuUmVzdChhcmdzKSk7CiAgICBuYXJyb3cgOiBGUy5JdGVyYXRvcjsKICAg >IHJlcyA6IFNjaGVtZU9iamVjdC5UOwogIEJFR0lOCiAgICBJRiBOT1QgSVNUWVBFKG9iaixGUy5J >dGVyYXRvcikgT1Igb2JqPU5JTCBUSEVOCiAgICAgIFJBSVNFIFNjaGVtZS5FKCJOb3Qgb2YgdHlw >ZSBGUy5JdGVyYXRvciA6ICIgJiBTY2hlbWVVdGlscy5TdHJpbmdpZnkob2JqKSkKICAgIEVORDsK >ICAgIG5hcnJvdyA6PSBOQVJST1cob2JqLEZTLkl0ZXJhdG9yKTsKICAgIElGIEZBTFNFIFRIRU4g >PCpBU1NFUlQgRkFMU0UqPgogICAgRUxTRSBSQUlTRSBTY2hlbWUuRSgiVW5rbm93biBmaWVsZCAi >ICYgU2NoZW1lVXRpbHMuU3RyaW5naWZ5KGZpZWxkKSkKICAgIEVORDsKICAgIFJFVFVSTiByZXMK >ICBFTkQgRmllbGRTZXRfRlNfSXRlcmF0b3I7CgpQUk9DRURVUkUgRmllbGRHZXRfRlNfUHVibGlj >SXRlcmF0b3IoaW50ZXJwIDogU2NoZW1lLlQ7IG9iaiA6IFNjaGVtZU9iamVjdC5UOyBhcmdzIDog >U2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUgfSA9CiAg >VkFSCiAgICBmaWVsZCAgIDo9IFNjaGVtZVV0aWxzLkZpcnN0KGFyZ3MpOwogICAgbmFycm93IDog >RlMuUHVibGljSXRlcmF0b3I7CiAgQkVHSU4KICAgIElGIE5PVCBJU1RZUEUob2JqLEZTLlB1Ymxp >Y0l0ZXJhdG9yKSBPUiBvYmo9TklMIFRIRU4KICAgICAgUkFJU0UgU2NoZW1lLkUoIk5vdCBvZiB0 >eXBlIEZTLlB1YmxpY0l0ZXJhdG9yIDogIiAmIFNjaGVtZVV0aWxzLlN0cmluZ2lmeShvYmopKQog >ICAgRU5EOwogICAgbmFycm93IDo9IE5BUlJPVyhvYmosRlMuUHVibGljSXRlcmF0b3IpOwogICAg >SUYgRkFMU0UgVEhFTiA8KkFTU0VSVCBGQUxTRSo+CiAgICBFTFNFIFJBSVNFIFNjaGVtZS5FKCJV >bmtub3duIGZpZWxkICIgJiBTY2hlbWVVdGlscy5TdHJpbmdpZnkoZmllbGQpKQogICAgRU5ECiAg >RU5EIEZpZWxkR2V0X0ZTX1B1YmxpY0l0ZXJhdG9yOwoKUFJPQ0VEVVJFIEZpZWxkU2V0X0ZTX1B1 >YmxpY0l0ZXJhdG9yKGludGVycCA6IFNjaGVtZS5UOyBvYmogOiBTY2hlbWVPYmplY3QuVDsgYXJn >cyA6IFNjaGVtZU9iamVjdC5UKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IFNjaGVtZS5FIH0g >PQogIFZBUgogICAgZmllbGQgICA6PSBTY2hlbWVVdGlscy5GaXJzdChhcmdzKTsKICAgIHZhbHVl >ICAgOj0gU2NoZW1lVXRpbHMuRmlyc3QoU2NoZW1lVXRpbHMuUmVzdChhcmdzKSk7CiAgICBuYXJy >b3cgOiBGUy5QdWJsaWNJdGVyYXRvcjsKICAgIHJlcyA6IFNjaGVtZU9iamVjdC5UOwogIEJFR0lO >CiAgICBJRiBOT1QgSVNUWVBFKG9iaixGUy5QdWJsaWNJdGVyYXRvcikgT1Igb2JqPU5JTCBUSEVO >CiAgICAgIFJBSVNFIFNjaGVtZS5FKCJOb3Qgb2YgdHlwZSBGUy5QdWJsaWNJdGVyYXRvciA6ICIg >JiBTY2hlbWVVdGlscy5TdHJpbmdpZnkob2JqKSkKICAgIEVORDsKICAgIG5hcnJvdyA6PSBOQVJS >T1cob2JqLEZTLlB1YmxpY0l0ZXJhdG9yKTsKICAgIElGIEZBTFNFIFRIRU4gPCpBU1NFUlQgRkFM >U0UqPgogICAgRUxTRSBSQUlTRSBTY2hlbWUuRSgiVW5rbm93biBmaWVsZCAiICYgU2NoZW1lVXRp >bHMuU3RyaW5naWZ5KGZpZWxkKSkKICAgIEVORDsKICAgIFJFVFVSTiByZXMKICBFTkQgRmllbGRT >ZXRfRlNfUHVibGljSXRlcmF0b3I7CgoKCgoKClBST0NFRFVSRSBUb1NjaGVtZV9BdG9tTGlzdF9U >KFJFQURPTkxZIHggOiBBdG9tTGlzdC5UKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IH0gPSAK >ICBCRUdJTgogICAgUkVUVVJOIHgKICBFTkQgVG9TY2hlbWVfQXRvbUxpc3RfVDsKCgpQUk9DRURV >UkUgVG9TY2hlbWVfRlNfSXRlcmF0b3IoUkVBRE9OTFkgeCA6IEZTLkl0ZXJhdG9yKSA6IFNjaGVt >ZU9iamVjdC5UIFJBSVNFUyB7IH0gPSAKICBCRUdJTgogICAgUkVUVVJOIHgKICBFTkQgVG9TY2hl >bWVfRlNfSXRlcmF0b3I7CgoKUFJPQ0VEVVJFIFRvU2NoZW1lX0ZpbGVfVChSRUFET05MWSB4IDog >RmlsZS5UKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IH0gPSAKICBCRUdJTgogICAgUkVUVVJO >IHgKICBFTkQgVG9TY2hlbWVfRmlsZV9UOwoKClBST0NFRFVSRSBUb1NjaGVtZV9GaWxlX1N0YXR1 >cyhSRUFET05MWSB4IDogRmlsZS5TdGF0dXMpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2No >ZW1lLkUgfSA9IAogIEJFR0lOCiAgICBWQVIgcmVzIDogU2NoZW1lUGFpci5UOj1OSUw7IEJFR0lO >CiAgICAgIHJlcyA6PSBTY2hlbWVVdGlscy5Db25zKFNjaGVtZVV0aWxzLkNvbnMoU2NoZW1lU3lt >Ym9sLkZyb21UZXh0KCJ0eXBlIiksVG9TY2hlbWVfQXRvbV9UKHgudHlwZSkpLHJlcyk7CiAgICAg >IHJlcyA6PSBTY2hlbWVVdGlscy5Db25zKFNjaGVtZVV0aWxzLkNvbnMoU2NoZW1lU3ltYm9sLkZy >b21UZXh0KCJtb2RpZmljYXRpb25UaW1lIiksU2NoZW1lTW9kdWxhM1R5cGVzLlRvU2NoZW1lX0xP >TkdSRUFMKHgubW9kaWZpY2F0aW9uVGltZSkpLHJlcyk7CiAgICAgIHJlcyA6PSBTY2hlbWVVdGls >cy5Db25zKFNjaGVtZVV0aWxzLkNvbnMoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJzaXplIiksVG9T >Y2hlbWVfVkFMMExPTkdJTlRfX1ZBTDEwNzM3NDUxMTJMT05HSU5UKHguc2l6ZSkpLHJlcyk7CiAg >ICAgIFJFVFVSTiByZXMKICAgIEVORAogIEVORCBUb1NjaGVtZV9GaWxlX1N0YXR1czsKCgpQUk9D >RURVUkUgVG9Nb2R1bGFfRlNfQ3JlYXRlT3B0aW9uKHggOiBTY2hlbWVPYmplY3QuVCkgOiAoRlMu >Q3JlYXRlT3B0aW9uKSBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAgQkVHSU4KQ09OU1QKICAgICAg >TmFtZSA9IEFSUkFZIEZTLkNyZWF0ZU9wdGlvbiBPRiBURVhUIHsgIk5ldmVyIiwgIk9rIiwgIkFs >d2F5cyIgfTsgCiAgICBCRUdJTgogICAgICBGT1IgaSA6PSBGSVJTVChOYW1lKSBUTyBMQVNUKE5h >bWUpIERPCiAgICAgICAgSUYgU2NoZW1lU3ltYm9sLkZyb21UZXh0KE5hbWVbaV0pID0geCBUSEVO >CiAgICAgICAgICBSRVRVUk4gaQogICAgICAgIEVORAogICAgICBFTkQ7CiAgICAgIFJBSVNFIFNj >aGVtZS5FKCJOb3QgYSB2YWx1ZSBvZiBGUy5DcmVhdGVPcHRpb24gOiAiICYgU2NoZW1lVXRpbHMu >U3RyaW5naWZ5KHgpKQogICAgRU5ECiAgRU5EIFRvTW9kdWxhX0ZTX0NyZWF0ZU9wdGlvbjsKCgpQ >Uk9DRURVUkUgVG9Nb2R1bGFfRlNfQWNjZXNzT3B0aW9uKHggOiBTY2hlbWVPYmplY3QuVCkgOiAo >RlMuQWNjZXNzT3B0aW9uKSBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAgQkVHSU4KQ09OU1QKICAg >ICAgTmFtZSA9IEFSUkFZIEZTLkFjY2Vzc09wdGlvbiBPRiBURVhUIHsgIk9ubHlPd25lckNhblJl >YWQiLCAiUmVhZE9ubHkiLCAiRGVmYXVsdCIgfTsgCiAgICBCRUdJTgogICAgICBGT1IgaSA6PSBG >SVJTVChOYW1lKSBUTyBMQVNUKE5hbWUpIERPCiAgICAgICAgSUYgU2NoZW1lU3ltYm9sLkZyb21U >ZXh0KE5hbWVbaV0pID0geCBUSEVOCiAgICAgICAgICBSRVRVUk4gaQogICAgICAgIEVORAogICAg >ICBFTkQ7CiAgICAgIFJBSVNFIFNjaGVtZS5FKCJOb3QgYSB2YWx1ZSBvZiBGUy5BY2Nlc3NPcHRp >b24gOiAiICYgU2NoZW1lVXRpbHMuU3RyaW5naWZ5KHgpKQogICAgRU5ECiAgRU5EIFRvTW9kdWxh >X0ZTX0FjY2Vzc09wdGlvbjsKCgpQUk9DRURVUkUgVG9Nb2R1bGFfRmlsZV9UKHggOiBTY2hlbWVP >YmplY3QuVCkgOiAoRmlsZS5UKSBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAgQkVHSU4KICAgIElG >IE5PVCBJU1RZUEUoeCxGaWxlLlQpIFRIRU4KICAgICAgUkFJU0UgU2NoZW1lLkUoIk5vdCBvZiB0 >eXBlIEZpbGUuVCA6ICIgJiBTY2hlbWVVdGlscy5TdHJpbmdpZnkoeCkpCiAgICBFTkQ7CiAgICBS >RVRVUk4geAogIEVORCBUb01vZHVsYV9GaWxlX1Q7CgoKUFJPQ0VEVVJFIFRvU2NoZW1lX1ZBTDBM >T05HSU5UX19WQUwxMDczNzQ1MTEyTE9OR0lOVChSRUFET05MWSB4IDogWyBWQUwoMCwgTE9OR0lO >VCApLi5WQUwoLTEwNzM3NDUxMTIsIExPTkdJTlQgKSBdKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNF >UyB7IFNjaGVtZS5FIH0gPSAKICBCRUdJTgogICAgUkVUVVJOIFRvU2NoZW1lX0xPTkdJTlQoeCkK >ICBFTkQgVG9TY2hlbWVfVkFMMExPTkdJTlRfX1ZBTDEwNzM3NDUxMTJMT05HSU5UOwoKClBST0NF >RFVSRSBUb1NjaGVtZV9BdG9tX1QoUkVBRE9OTFkgeCA6IEF0b20uVCkgOiBTY2hlbWVPYmplY3Qu >VCBSQUlTRVMgeyB9ID0gCiAgQkVHSU4KICAgIFJFVFVSTiB4CiAgRU5EIFRvU2NoZW1lX0F0b21f >VDsKCgpQUk9DRURVUkUgVG9TY2hlbWVfTE9OR0lOVChSRUFET05MWSB4IDogIExPTkdJTlQgKSA6 >IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IFNjaGVtZS5FIH0gPSAKICBCRUdJTgogICAgV0lUSCBy >ZWYgPSBORVcoUkVGIExPTkdJTlQpIERPCiAgICAgIHJlZl4gOj0geDsKICAgICAgUkVUVVJOIFNj >aGVtZU1vZHVsYTNUeXBlcy5Ub1NjaGVtZV9MT05HSU5UKHJlZikKICAgIEVORAogIEVORCBUb1Nj >aGVtZV9MT05HSU5UOwoKUFJPQ0VEVVJFIFRvTW9kdWxhX0ZTX1B1YmxpY0l0ZXJhdG9yKHggOiBT >Y2hlbWVPYmplY3QuVCkgOiAoRlMuUHVibGljSXRlcmF0b3IpIFJBSVNFUyB7IFNjaGVtZS5FIH0g >PSAKICBCRUdJTgogICAgSUYgTk9UIElTVFlQRSh4LEZTLlB1YmxpY0l0ZXJhdG9yKSBUSEVOCiAg >ICAgIFJBSVNFIFNjaGVtZS5FKCJOb3Qgb2YgdHlwZSBGUy5QdWJsaWNJdGVyYXRvciA6ICIgJiBT >Y2hlbWVVdGlscy5TdHJpbmdpZnkoeCkpCiAgICBFTkQ7CiAgICBSRVRVUk4geAogIEVORCBUb01v >ZHVsYV9GU19QdWJsaWNJdGVyYXRvcjsKCgpQUk9DRURVUkUgVG9Nb2R1bGFfRlNfSXRlcmF0b3Io >eCA6IFNjaGVtZU9iamVjdC5UKSA6IChGUy5JdGVyYXRvcikgUkFJU0VTIHsgU2NoZW1lLkUgfSA9 >IAogIEJFR0lOCiAgICBJRiBOT1QgSVNUWVBFKHgsRlMuSXRlcmF0b3IpIFRIRU4KICAgICAgUkFJ >U0UgU2NoZW1lLkUoIk5vdCBvZiB0eXBlIEZTLkl0ZXJhdG9yIDogIiAmIFNjaGVtZVV0aWxzLlN0 >cmluZ2lmeSh4KSkKICAgIEVORDsKICAgIFJFVFVSTiB4CiAgRU5EIFRvTW9kdWxhX0ZTX0l0ZXJh >dG9yOwoKClBST0NFRFVSRSBUb01vZHVsYV9GaWxlX1N0YXR1cyh4IDogU2NoZW1lT2JqZWN0LlQp >IDogKEZpbGUuU3RhdHVzKSBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAgQkVHSU4KICAgIFZBUiBy >ZXMgOiBGaWxlLlN0YXR1czsKICAgICAgICBwIDo9IFNjaGVtZVBhaXIuUGFpcih4KTsKICAgIEJF >R0lOCiAgICAgIFdISUxFIHAgIyBOSUwgRE8KICAgICAgICBJRiBGQUxTRSBUSEVOCiAgICAgICAg >RUxTSUYgU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJ0eXBlIikgPSBTY2hlbWVVdGlscy5GaXJzdChw >LmZpcnN0KSBUSEVOCiAgICAgICAgICByZXMudHlwZSA6PSBUb01vZHVsYV9BdG9tX1QoU2NoZW1l >VXRpbHMuUmVzdChwLmZpcnN0KSkKICAgICAgICBFTFNJRiBTY2hlbWVTeW1ib2wuRnJvbVRleHQo >Im1vZGlmaWNhdGlvblRpbWUiKSA9IFNjaGVtZVV0aWxzLkZpcnN0KHAuZmlyc3QpIFRIRU4KICAg >ICAgICAgIHJlcy5tb2RpZmljYXRpb25UaW1lIDo9IFNjaGVtZU1vZHVsYTNUeXBlcy5Ub01vZHVs >YV9MT05HUkVBTChTY2hlbWVVdGlscy5SZXN0KHAuZmlyc3QpKQogICAgICAgIEVMU0lGIFNjaGVt >ZVN5bWJvbC5Gcm9tVGV4dCgic2l6ZSIpID0gU2NoZW1lVXRpbHMuRmlyc3QocC5maXJzdCkgVEhF >TgogICAgICAgICAgcmVzLnNpemUgOj0gVG9Nb2R1bGFfVkFMMExPTkdJTlRfX1ZBTDEwNzM3NDUz >MzZMT05HSU5UKFNjaGVtZVV0aWxzLlJlc3QocC5maXJzdCkpCiAgICAgICAgRU5EOwogICAgICAg >IHAgOj0gU2NoZW1lUGFpci5QYWlyKHAucmVzdCkKICAgICAgRU5EOwogICAgICBSRVRVUk4gcmVz >CiAgICBFTkQKICBFTkQgVG9Nb2R1bGFfRmlsZV9TdGF0dXM7CgoKUFJPQ0VEVVJFIFRvTW9kdWxh >X1ZBTDBMT05HSU5UX19WQUwxMDczNzQ1MzM2TE9OR0lOVCh4IDogU2NoZW1lT2JqZWN0LlQpIDog >KFsgVkFMKDAsIExPTkdJTlQgKS4uVkFMKC0xMDczNzQ1MzM2LCBMT05HSU5UICkgXSkgUkFJU0VT >IHsgU2NoZW1lLkUgfSA9IAogIEJFR0lOCiAgICBXSVRIIGJhc2VWYWwgPSBUb01vZHVsYV9MT05H >SU5UKHgpIERPCiAgICAgIElGIGJhc2VWYWwgPCBGSVJTVChbIFZBTCgwLCBMT05HSU5UICkuLlZB >TCgtMTA3Mzc0NTMzNiwgTE9OR0lOVCApIF0pIE9SIGJhc2VWYWwgPiBMQVNUKFsgVkFMKDAsIExP >TkdJTlQgKS4uVkFMKC0xMDczNzQ1MzM2LCBMT05HSU5UICkgXSkgVEhFTgogICAgICAgIFJBSVNF >IFNjaGVtZS5FKCJWYWx1ZSBvdXQgb2YgcmFuZ2UgZm9yIFsgVkFMKDAsIExPTkdJTlQgKS4uVkFM >KC0xMDczNzQ1MzM2LCBMT05HSU5UICkgXSA6IiAmIFNjaGVtZVV0aWxzLlN0cmluZ2lmeSh4KSkK >ICAgICAgRU5EOwogICAgICBSRVRVUk4gYmFzZVZhbAogICAgRU5ECiAgRU5EIFRvTW9kdWxhX1ZB >TDBMT05HSU5UX19WQUwxMDczNzQ1MzM2TE9OR0lOVDsKCgpQUk9DRURVUkUgVG9Nb2R1bGFfQXRv >bV9UKHggOiBTY2hlbWVPYmplY3QuVCkgOiAoQXRvbS5UKSBSQUlTRVMgeyBTY2hlbWUuRSB9ID0g >CiAgQkVHSU4KICAgIElGIE5PVCBJU1RZUEUoeCxBdG9tLlQpIFRIRU4KICAgICAgUkFJU0UgU2No >ZW1lLkUoIk5vdCBvZiB0eXBlIEF0b20uVCA6ICIgJiBTY2hlbWVVdGlscy5TdHJpbmdpZnkoeCkp >CiAgICBFTkQ7CiAgICBSRVRVUk4geAogIEVORCBUb01vZHVsYV9BdG9tX1Q7CgoKUFJPQ0VEVVJF >IFRvTW9kdWxhX0xPTkdJTlQoeCA6IFNjaGVtZU9iamVjdC5UKSA6ICBMT05HSU5UICBSQUlTRVMg >eyBTY2hlbWUuRSB9ID0gCiAgQkVHSU4KICAgIFdJVEggcmVmID0gU2NoZW1lTW9kdWxhM1R5cGVz >LlRvTW9kdWxhX0xPTkdJTlQoeCkgRE8KICAgICAgUkVUVVJOIE5BUlJPVyhyZWYsIFJFRiBMT05H >SU5UKV4KICAgIEVORAogIEVORCBUb01vZHVsYV9MT05HSU5UOwoKQkVHSU4gRU5EIEZTU2NoZW1l >U3R1YnMuCg== > >--_2d6969dc-a0fa-42e3-85e1-71600a2e9b7d_-- From hosking at cs.purdue.edu Fri Dec 31 23:01:27 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 31 Dec 2010 17:01:27 -0500 Subject: [M3devel] CM3 status In-Reply-To: References: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com> Message-ID: <9EF449E4-72AB-4461-AC0C-1B0A79341E44@cs.purdue.edu> I didn't OK dropping SPARC stack walking, just agreeing that we should move all platforms to gcc-supported stack walking. On Dec 30, 2010, at 7:01 AM, Jay K wrote: > Tony ok'ed this for Solaris/sparc32 a few months ago. I couldn't get it working with gcc 4.5, not even without optimization. > That was the last step in moving off of gcc 4.3 backend. I wasn't real happy about dropping stack walking for Solaris. It should not be difficult to retain. I thought you were going to try to fix m3cg 4.5 to handle it. My preference would be to retain the stack walking code on Solaris/SPARC (since it is so easy to do...) modulo making sure that m3cg 4.5 could cope with it. > Alpha/OSF also doesn't work. I didn't look much into it, and I really don't think it matters. > It is an extremely little used platform. This year I saw it work on 4.0 and 5.1 but otherwise > it had been unused for several years I believe, and I don't see its use continuing much. Last time I ran M3 on Alpha/OSF it did work. > Upgrade of Solaris/sparc32 from gcc 4.3 to 4.5: > > 2010-10-13 11:18 jkrell > > * m3-sys/cminstall/src/config-no-install/SPARC32_SOLARIS.common, > m3-sys/m3cc/gcc/gcc/m3cg/parse.c, m3-sys/m3cc/src/clean_marker.txt, > m3-sys/m3cc/src/m3makefile, m3-libs/m3core/src/runtime/m3makefile, > m3-sys/m3middle/src/Target.m3, > m3-libs/m3core/src/runtime/SOLgnu/m3makefile, > m3-libs/m3core/src/runtime/SOLgnu/m3makefile-old, > m3-libs/m3core/src/runtime/SOLsun/m3makefile, > m3-libs/m3core/src/runtime/SOLsun/m3makefile-old: > > disable Solaris/sparc32 stack walker > switch Solaris/sparc32 to gcc 4.5 backend > function.c: make failure to volatilize when setjmp/vfork present an error > instead of a warning > add missing volatilization > pin Solaris/sparc32 at -O1 in the config file as -O2/-O3 were > seen to hit internal compiler errors (assertion failures) > remove the "all volatile" paths from parse.c (since they > were only for Solaris/sparc32's stack walker) > > > Tony ok'ing (in my interpretation) the abandonment of our stack walker: > > https://mail.elegosoft.com/pipermail/m3devel/2010-October/008019.html > > > At least that was my interpretation. > Using gcc's exception handling support and *its* stack walker (libgcc/libunwind) > should provide the better and more portable functionality on many platforms. > I'm not certain what'd it look like on systems where gcc isn't the usual C compiler (e.g. Solaris) > but it's bound to work well on Linux, NetBSD, FreeBSD, OpenBSD, and Solaris using gcc. > "more portable" as in, across all architectures. > > > Perhaps I should have stuck back with 4.3 until implementing this however. > > > It is definitely a step backward to not have the stack walker on Solaris/sparc32, > but that is the only platform in years that has had one, and it is not terrible > to have every platform on gcc 4.5.2 and not sprinkling volatile around. > There are some backward steps but definitely a lot forward. > I tried using 5.4.0 tonight and I didn't get far. > > > > o possibly unsafe OS calls in new C code (this may be a wrong deduction > > from my side) > > > I don't know what this is referring to. > The Enable/DisableScheduling? I all but undid that. > It should be in a few functions, e.g. malloc/free/realloc/calloc/opendir/readdir/closedir/fopen/fclose. > Some of those it already is in. With OpenBSD moving to pthreads it matters less. > It only matters for user threads. > > > > o GUI input not working for BadBricks and other games (only on Darwin?) > > > Yes this is still a problem, and occurs in 5.8.6 release, on Darwin local X Server. > Doesn't reproduce when remoted to Cygwin/X. Other X apps do work locally. > Not understood. > It'd be good to get confirmation if/when they ever worked. > > > > o no clean way for exception handling with current gcc > > > This is how things have *always* been, *except* on Alpha/OSF and Solaris/sparc32. > Those two platforms have "regressed", but for Solaris/sparc32 it was discussed and > Alpha/OSF I really don't think is important. > > > Exception handling has always been very inefficient on all but approx. those two platforms. > It has always been desirable to fix. > > The inefficiency has a few parts. Mainly that "try" costs pthread_getspecific and setjmp. > The inefficiency of the actual throw/catch is not as worrisome. > > > > o still alignment issues > > > Details? > > > > I'm concerned that things get tried out, don't work properly for all > > our target platforms, but are left then and not cleaned up and something > > else gets tried. I'm not sure this is correct, it is just me feeling > > unwell after reading all those mails. > > > Not really. > > > > > Hudson and Tinderbox status seem to be mostly OK though, but I haven't > > checked in detail (FreeBSD failing was a disk failure on my system > > recently). But the tests don't cover all the things we should check. > > > Yep I try to remember to check Hudson fairly regularly. > I never look at Tinderbox though. > > > > I think it would be good to have an overview of the projects/work that > > is in progress or pending and its status. For example, we've imported > > a new gcc version, but that doesn't seem to work well on all targets, > > or does it? If not, how are we going to address this? Use older versions > > on some platforms? Can I read up on that somewhere? > > All platforms (except NT386) use gcc 4.5.2 for the backend. > (I did the upgrade after the release was made but before it was announced; > they delay announcement while it propagates to mirrors.) > > > Ok, also ARM_DARWIN hypothetically uses 4.2. > Apple forks gcc fairly aggressively. > Perhaps we should merge the two forks. Perhaps. > ARM_DARWIN isn't really supported currently. Probably that should be worked on. > It'd also be interesting to see what Apple did to 4.2 for ppc/x86... > > > > I'd like to suggest to simply use our Trac WiKi to document the ongoing > > > Agreed but I'm lazy. > I just throw "bombs" around.. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Fri Dec 31 23:26:50 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Fri, 31 Dec 2010 17:26:50 -0500 Subject: [M3devel] emac Message-ID: <20101231222650.GB2428@topoi.pooq.com> I may be acquiring an emac, which is a small (but heavy -- 50 pounds) power-PC-based Apple Mac, if I've been informed correctly, running a somewhat obsolete OS. If I end up with it, would there be anything I can usefully test on it that's not being adequately tested already? -- hendrik From jay.krell at cornell.edu Fri Dec 31 23:47:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Dec 2010 22:47:02 +0000 Subject: [M3devel] CM3 status In-Reply-To: <9EF449E4-72AB-4461-AC0C-1B0A79341E44@cs.purdue.edu> References: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com>, , <9EF449E4-72AB-4461-AC0C-1B0A79341E44@cs.purdue.edu> Message-ID: Oops, you can see the ambiguity? So you'd rather leave Solaris/sparc32 back on gcc-4.3 for now, if the gcc-supported stack walking isn't imminent? And possibly volatile on load/store a lot. (That was more out of laziness maybe, I remember if I tried removing it.) I don't like that, but I can do it. Or is it imminent, by someone other than me? gcc-4.5 even without any optimizations and volatile everywhere didn't work with the Solaris/sparc32 stack walker. I tried a fair amount to debug it but gave up at the time. I continue to assume that Alpha/OSF is even much less interesting, given that it has extremely few users. The code continues to sit unused in CVS, same as it mostly ever did. > Last time I ran M3 on Alpha/OSF it did work. I ran it in 2010 and it didn't work. I don't remember though if that was with gcc 4.3 or 4.5. I could try again with 4.3, but I don't know what the result would be -- we'd leave it back with 4.3 also? > I wasn't real happy about dropping stack walking for Solaris. It should not be difficult to retain. I thought you were going to try to fix m3cg 4.5 to handle it > ...modulo making sure that m3cg 4.5 could cope with it. This was looking to be difficult. Even volatile everywhere and no optimization didn't work. I could give it another try perhaps. Or maybe someone else can? Getting it to work without any optimization and volatile on every load/store should be useful and easy, but it wasn't proving even easy. I figure moving to 4.5 has a fair amount of value, and optimizing one platform Solaris/sparc32 uniquely beyond all others, is less so. Or maybe I should look again more closely at the gcc stuff. Maybe it could be done imminently.. That would nicely remove a lot of target-dependent-ness out of the front/middle end!. - Jay From: hosking at cs.purdue.edu Date: Fri, 31 Dec 2010 17:01:27 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] CM3 status I didn't OK dropping SPARC stack walking, just agreeing that we should move all platforms to gcc-supported stack walking. On Dec 30, 2010, at 7:01 AM, Jay K wrote:Tony ok'ed this for Solaris/sparc32 a few months ago. I couldn't get it working with gcc 4.5, not even without optimization. That was the last step in moving off of gcc 4.3 backend. I wasn't real happy about dropping stack walking for Solaris. It should not be difficult to retain. I thought you were going to try to fix m3cg 4.5 to handle it. My preference would be to retain the stack walking code on Solaris/SPARC (since it is so easy to do...) modulo making sure that m3cg 4.5 could cope with it. Alpha/OSF also doesn't work. I didn't look much into it, and I really don't think it matters. It is an extremely little used platform. This year I saw it work on 4.0 and 5.1 but otherwise it had been unused for several years I believe, and I don't see its use continuing much. Last time I ran M3 on Alpha/OSF it did work. Upgrade of Solaris/sparc32 from gcc 4.3 to 4.5: 2010-10-13 11:18 jkrell * m3-sys/cminstall/src/config-no-install/SPARC32_SOLARIS.common, m3-sys/m3cc/gcc/gcc/m3cg/parse.c, m3-sys/m3cc/src/clean_marker.txt, m3-sys/m3cc/src/m3makefile, m3-libs/m3core/src/runtime/m3makefile, m3-sys/m3middle/src/Target.m3, m3-libs/m3core/src/runtime/SOLgnu/m3makefile, m3-libs/m3core/src/runtime/SOLgnu/m3makefile-old, m3-libs/m3core/src/runtime/SOLsun/m3makefile, m3-libs/m3core/src/runtime/SOLsun/m3makefile-old: disable Solaris/sparc32 stack walker switch Solaris/sparc32 to gcc 4.5 backend function.c: make failure to volatilize when setjmp/vfork present an error instead of a warning add missing volatilization pin Solaris/sparc32 at -O1 in the config file as -O2/-O3 were seen to hit internal compiler errors (assertion failures) remove the "all volatile" paths from parse.c (since they were only for Solaris/sparc32's stack walker) Tony ok'ing (in my interpretation) the abandonment of our stack walker: https://mail.elegosoft.com/pipermail/m3devel/2010-October/008019.html At least that was my interpretation. Using gcc's exception handling support and *its* stack walker (libgcc/libunwind) should provide the better and more portable functionality on many platforms. I'm not certain what'd it look like on systems where gcc isn't the usual C compiler (e.g. Solaris) but it's bound to work well on Linux, NetBSD, FreeBSD, OpenBSD, and Solaris using gcc. "more portable" as in, across all architectures. Perhaps I should have stuck back with 4.3 until implementing this however. It is definitely a step backward to not have the stack walker on Solaris/sparc32, but that is the only platform in years that has had one, and it is not terrible to have every platform on gcc 4.5.2 and not sprinkling volatile around. There are some backward steps but definitely a lot forward. I tried using 5.4.0 tonight and I didn't get far. > o possibly unsafe OS calls in new C code (this may be a wrong deduction > from my side) I don't know what this is referring to. The Enable/DisableScheduling? I all but undid that. It should be in a few functions, e.g. malloc/free/realloc/calloc/opendir/readdir/closedir/fopen/fclose. Some of those it already is in. With OpenBSD moving to pthreads it matters less. It only matters for user threads. > o GUI input not working for BadBricks and other games (only on Darwin?) Yes this is still a problem, and occurs in 5.8.6 release, on Darwin local X Server. Doesn't reproduce when remoted to Cygwin/X. Other X apps do work locally. Not understood. It'd be good to get confirmation if/when they ever worked. > o no clean way for exception handling with current gcc This is how things have *always* been, *except* on Alpha/OSF and Solaris/sparc32. Those two platforms have "regressed", but for Solaris/sparc32 it was discussed and Alpha/OSF I really don't think is important. Exception handling has always been very inefficient on all but approx. those two platforms. It has always been desirable to fix. The inefficiency has a few parts. Mainly that "try" costs pthread_getspecific and setjmp. The inefficiency of the actual throw/catch is not as worrisome. > o still alignment issues Details? > I'm concerned that things get tried out, don't work properly for all > our target platforms, but are left then and not cleaned up and something > else gets tried. I'm not sure this is correct, it is just me feeling > unwell after reading all those mails. Not really. > Hudson and Tinderbox status seem to be mostly OK though, but I haven't > checked in detail (FreeBSD failing was a disk failure on my system > recently). But the tests don't cover all the things we should check. Yep I try to remember to check Hudson fairly regularly. I never look at Tinderbox though. > I think it would be good to have an overview of the projects/work that > is in progress or pending and its status. For example, we've imported > a new gcc version, but that doesn't seem to work well on all targets, > or does it? If not, how are we going to address this? Use older versions > on some platforms? Can I read up on that somewhere? All platforms (except NT386) use gcc 4.5.2 for the backend. (I did the upgrade after the release was made but before it was announced; they delay announcement while it propagates to mirrors.) Ok, also ARM_DARWIN hypothetically uses 4.2. Apple forks gcc fairly aggressively. Perhaps we should merge the two forks. Perhaps. ARM_DARWIN isn't really supported currently. Probably that should be worked on. It'd also be interesting to see what Apple did to 4.2 for ppc/x86... > I'd like to suggest to simply use our Trac WiKi to document the ongoing Agreed but I'm lazy. I just throw "bombs" around.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From ttmrichter at gmail.com Wed Dec 1 06:45:34 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Wed, 1 Dec 2010 13:45:34 +0800 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> <20101130150418.GB11084@topoi.pooq.com> Message-ID: On 1 December 2010 01:18, Jay K wrote: > In the case of templates leading to some meta programming, it was an > accident. > But in the case of operator overloading it seems just goodness. > I am badly conflicted in the case of operator overloading. In its favour we have: - more succinct code that clearly states intent (when overloaded properly) - opportunities to optimize calculations (like your example with intermediate forms for matrix manipulations) Countering that favour, however, we have: - idiots redefining operators in ways that are emphatically *not* proper in terms of semantics (operator<< and operator>> being obvious cases, but also operator+ for concatenation and some of the ... utterly painful uses for operator,) - the inability to define *new* operators (which leads to the first problem of idiots redefining the semantics of operators) - unexpected costs to operations making the eyeballing of execution complexity (time-wise and memory-wise) literally impossible - painful interaction with templates that makes a perfect storm of eye-damaging syntax -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 1 07:49:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 1 Dec 2010 06:49:36 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, , , <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, <20101130150418.GB11084@topoi.pooq.com>, , Message-ID: opportunities to optimize calculations (like your example with intermediate forms for matrix manipulations) Just to be clear, that power is not easily created, and would not be do-able in the constrained form I suggested, where it is always, e.g. T +(T,T) > not proper in terms of semantics (operator<< and operator>> being obvious cases) This would not be allowed in my constrained proposal. > but also operator+ for concatenation This is very reasonable. > utterly painful uses for operator,) I'm surprised that is overloadable, but indeed it appears it is. I don't think I have *ever* seen anyone overload it, and I have seen a lot. > the inability to define new operators (which leads to the first problem of idiots redefining the semantics of operators) Stroupstroup rejected this as too complex. (See the Design&Evolution book). I don't see people pine for this often and I suspect he did the right thing. It creates a layering problem I believe in the typical structure. The lexical analysis would have to get information from higher layers. > unexpected costs to operations making the eyeballing of execution complexity (time-wise and memory-wise) literally impossible This is already the case. As I said. So let's say that every single function call is shown. It is hard to know which functions have which cost. There are also hidden function calls e.g. for "try" and every pointer derereference (right?) Please consider floating point. Historically floating point was "soft float". Sometimes these days it still us. Yet we still have operators for floating point. Why? Because it is just so convenient and idiomatic. Why stop there? A primary design point of C++ is to give user defined types all the powers of built in types. No longer does it require a compiler change to introduce a type with the "power" of int. And so on. > painful interaction with templates that makes a perfect storm of eye-damaging syntax Huh? Specifically? The one vague reason I don't fully understand is: C doesn't have it. Does C represent a good example of a sort of minimalism? Maybe. It isn't clear to me the value of C. It has been *very* widely abandoned in favor of C++. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.async.caltech.edu Wed Dec 1 08:55:49 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Tue, 30 Nov 2010 23:55:49 -0800 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, , , <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, <20101130150418.GB11084@topoi.pooq.com>, , Message-ID: <20101201075549.426511A208F@async.async.caltech.edu> I think if you want overloaded operators, you code in Scheme or your own invented language and write a little compiler/translator (to C or Modula-3, for example), for the particular expressions you want to convert. You can have whatever crazy syntax and features you want if you do it that way, and it doesn't gum up everyone else's day... Mika P.S. People were listing things they liked about Modula-3 a few days ago. I'm surprised no one mentioned my favorite properties: -- no possibility of breaking existing code by adding new symbols to an interface, no matter how public -- no possibility of breaking existing code by adding new methods to an object type, no matter how widely exported or how widely used or "subclassed" about how many other programming languages can you say that? (Note also that these features are on a quite different level from Jay's list...) Jay K writes: >--_25139682-7cce-49b1-ae17-6a4dff3488ee_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > >opportunities to optimize calculations (like your example with intermediate= > forms for matrix manipulations) >Just to be clear=2C that power is not easily created=2C and would not be do= >-able in the constrained form I suggested=2C where it is always=2C e.g. T += >(T=2CT) > > > not proper in terms of semantics (operator<< and operator>> being obvio= >us cases) > >This would not be allowed in my constrained proposal. > >> but also operator+ for concatenation > >This is very reasonable. > > > utterly painful uses for operator=2C) > > >I'm surprised that is overloadable=2C but indeed it appears it is. I don't = >think I have *ever* seen anyone overload it=2C and I have seen a lot. > > > > > the inability to define new operators (which leads to the first problem = >of idiots redefining the semantics of operators) > > >Stroupstroup rejected this as too complex. (See the Design&Evolution book). >I don't see people pine for this often and I suspect he did the right thing= >. >It creates a layering problem I believe in the typical structure. >The lexical analysis would have to get information from higher layers. > > > > unexpected costs to operations making the eyeballing of execution comple= >xity (time-wise and memory-wise) literally impossible > > >This is already the case. As I said. So let's say that every single functio= >n call is shown. It is hard to know which functions have which cost. >There are also hidden function calls e.g. for "try" and every pointer derer= >eference (right?) > > >Please consider floating point. Historically floating point was "soft float= >". Sometimes these days it still us. Yet we still have operators for floati= >ng point. >Why? Because it is just so convenient and idiomatic. Why stop there? > > >A primary design point of C++ is to give user defined types all the powers = >of built in types. >No longer does it require a compiler change to introduce a type with the "p= >ower" of int. And so on. > > > >> painful interaction with templates that makes a perfect storm of eye-dama= >ging syntax >Huh? Specifically? > >The one vague reason I don't fully understand is: C doesn't have it. >Does C represent a good example of a sort of minimalism? Maybe. >It isn't clear to me the value of C. It has been *very* widely abandoned in= > favor of C++. > > - Jay > = > >--_25139682-7cce-49b1-ae17-6a4dff3488ee_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >
  • opportunities to optimize calculations (like your example with = >intermediate forms for matrix manipulations)

Just to be clear= >=2C that power is not easily created=2C and would not be do-able in the con= >strained form I suggested=2C where it is always=2C e.g. T +(T=2CT)

<= >div class=3D"ecxgmail_quote"> =3B>=3B =3B not =3Bprope= >r in terms of semantics (e=3D"'courier new'=2C monospace">operator<=3B<=3B and e=3D"" class=3D"ecxApple-style-span" face=3D"'courier new'=2C monospace">op= >erator>=3B>=3B being obvious cases)

This would not be all= >owed in my constrained proposal.

>=3B but also ass=3D"ecxApple-style-span" face=3D"'courier new'=2C monospace">operator+font> for concatenation

This is very reasonable.

 =3B>= >=3B utterly painful uses for face=3D"'courier new'=2C monospace">operator=2C)


I'm sur= >prised that is overloadable=2C but indeed it appears it is. I don't think I= > have *ever* seen anyone overload it=2C and I have seen a lot.
>

 =3B>=3B the inability to define new =3Boperators = >(which leads to the first problem of idiots redefining the semantics of ope= >rators)


Stroupstroup rejected this as too complex. (See the Desi= >gn&=3BEvolution book).
I don't see people pine for this often and I s= >uspect he did the right thing.
It creates a layering problem I believe i= >n the typical structure.
The lexical analysis would have to get informat= >ion from higher layers.


 =3B>=3B unexpected costs to opera= >tions making the eyeballing of execution complexity (time-wise and memory-w= >ise) literally impossible


This is already the case. As I said. S= >o let's say that every single function call is shown. It is hard to know wh= >ich functions have which cost.
There are also hidden function calls e.g.= > for "try" and every pointer derereference (right?)


Please consi= >der floating point. Historically floating point was "soft float". Sometimes= > these days it still us. Yet we still have operators for floating point.>Why? Because it is just so convenient and idiomatic. Why stop there?
r>
A primary design point of C++ is to give user defined types all the p= >owers of built in types.
No longer does it require a compiler change to = >introduce a type with the "power" of int. And so on.


>>=3B painful interaction with templates that makes a perfect storm of eye= >-damaging syntax

Huh? Specifically?

The one vague reason I = >don't fully understand is: C doesn't have it.
Does C represent a good ex= >ample of a sort of minimalism? Maybe.
It isn't clear to me the value of = >C. It has been *very* widely abandoned in favor of C++.

 =3B- Ja= >y
>= > >--_25139682-7cce-49b1-ae17-6a4dff3488ee_-- From dragisha at m3w.org Wed Dec 1 09:18:55 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 1 Dec 2010 09:18:55 +0100 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, , , <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, <20101130150418.GB11084@topoi.pooq.com>, , Message-ID: <4C27C8EE-5A26-456A-A0D7-EC176113CCB5@m3w.org> Look for Modula-2 R10 and how they spec'd it. On Dec 1, 2010, at 7:49 AM, Jay K wrote: > A primary design point of C++ is to give user defined types all the powers of built in types. > No longer does it require a compiler change to introduce a type with the "power" of int. And so on. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed Dec 1 17:00:10 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 01 Dec 2010 10:00:10 -0600 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: , , <4CF42AEE.3000807@lcwb.coop>, , <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> Message-ID: <4CF6710A.4010907@lcwb.coop> Jay K wrote: >> generics are good, but not as good as C++ templates On the contrary, Modula-3 generics are overall, *far* superior to C++ templates, which are a language complexity nightmare, about as bad as user-defined overloading. Modula-3 generics are vastly simpler, yet more flexible. (Modula-3 generics do achieve this at the cost of a small inconvenience.) Here is a comparison I wrote some time ago of the generic/template facilities of Ada, C++, and Modula-3: ----------------------------------------------------------------------- Some comparisons of generics/templates in Ada, C++, and Modula-3 C++'s template facility is *vastly* more complicated than Modula-3's. C++(2003) has a 58-page chapter on templates, more that the entire Modula-3 reference. Additionally, C++ has a lot of additional material on templates woven throughout the rest of the language. Modula-3 devotes 2 pages to its generics and defines them with a translation to equivalent, generic-free code, so that they need not be mentioned elsewhere. Ada's generics are a bit less complicated than C++'s, but not a whole lot. Here are some of the sources of the gratuitous complexity: Confused identifier resolution Probably the worst source of C++'s template complexity derives from interaction with the identifier resolution rules it inherits from C. They were already cobbled-up in C and got worse in C++. In a single scope, the same identifier can be declared with different meanings, most importantly, two different ways of naming types (typedef names, class names), neither of which is sufficient by itself, and ordinary identifiers (variables and functions). The rules for deciding what an identifier reference actually means are highly dependent on the context of the reference. Moreover, the very syntax depends on the surrounding declarations. The template facility makes this immeasurably worse, because, in a template, the needed context is not there. So this is fixed by new and different syntactic and semantic rules for making the distinction. In contexts where the syntax does not determine whether a type or ordinary meaning is needed, the presence or absence of 'typename' (or a class key) makes the needed distinction. But there are several contexts where the syntax does imply that a type is needed, and these are full of inconsistency. In some, 'typename' is required, in others, it is optional, and in yet others, it is not allowed. So a programmer cannot just establish a habit of always doing it a certain way. None of this conveys any useful function to the language. In Modula-3 and Ada, all identifiers in a scope are really in the same scope, and both the syntax and rules for looking up identifiers are independent of the referencing context. A drastic simplification. Many kinds of template/generic units Another source is the ability to have several kinds of template units (functions, classes, member functions, member templates, etc.) and template parameters. Moreover, these are not necessarily tied to separate compilation units. Like C++, Ada also allows several kinds of units, not necessarily separately compiled, to be generic, instantiated, and in the case of procedures, generic parameters. In Modula-3, only interfaces and modules can be generic, and only interfaces can be generic parameters. But since an interface or module can contain any declarable entity, the result is every bit as flexible, probably even more so. Yet this greatly simplifies generics. It does come at a price of minor inconvenience by requiring more very small, separately compiled interfaces and modules as instantiations and more small interfaces as generic actuals. As an aside, the ability to create instantiations using the build system is only an added convenience, not mandated by the language. You can always write Modula-3 code for all instantiations and generic actuals, with no more burden added to the build system or its use by than ordinary, non-generic interfaces and modules. The Quake commands we have in the implementations of Modula-3 merely generate common cases of these almost trivial compilation units, as a quicker alternative. All instantiations are anonymous Yet another source of complexity in C++ is the lack of named instantiations. Everywhere you want to refer to an instantiation, you have to repeat is full structural definition, complete with repeats of the template actuals. This makes some code awfully pedantic. It gets worse when there are nested instantiations. And, of course, it complicates the language itself. Aside from language complexity, this also creates a very difficult problem for an implementation, because it must locate and combine all the structurally-equivalent instantiations, even from separate compilations. This the worst source of very highly mangled linker names. In both Ada and Modula-3, you always declare a name for an instantiation, attached to its definition, providing the generic actuals exactly once here. Then you use the name (a single identifier) everywhere else. If you don't want multiple copies of structurally-equivalent instantiations to be compiled, you just take care to code it this way, as is the case in virtually all other constructs in all languages. The implementation doesn't need to find the duplicates. Static checkability of template/generic units One source of complexity in Ada's generics is Ada's policy that a generic can be fully statically checked in the absence of any instantiation. The instantiations have some semantic rules that must still be applied, but they don't involve anything but the normal kinds of interface properties of the generic unit. An instantiation cannot cause internal semantic errors to pop up inside the generic. (In Ada 83, there was one language bug in this property. It was fixed in the next version, Ada 99.) This is a very nice property. Unfortunately, it complicates the language greatly. On the one hand, there has to be an elaborate set of rules about what kinds of generic parameters are allowed at all and how different generic parameters of a single generic unit can be interrelated. The programmer then has to specify these relationships. Inevitably, while this system of rules is complicated, it is also incomplete. C++ and Modula-3 postpone semantic checking until instantiation time, which removes these limitations, at the cost that an instantiation could mysteriously fail to compile if the actuals don't have the right properties. The compile errors will likely be deep inside the body of the generic--where the instantiator would ideally not need to venture. Modula-3 at least informally encourages the writers of generics to write comments spelling out the necessary properties of the generic actuals. AFAIK, C++ does not. This postponement sacrifices a very nice property for static checking. In Modula-3, the sacrifice buys a lot of simplicity and some increased flexibility. C++ gives the worst of both worlds, as the same static checking is lost, with no simplicity benefit. Interaction with overloading Both C++ and Ada allow user-defined overloading of both operators and procedure/function identifiers. This creates massive language complexity in many ways. A template/generic facility provides more things to interact with overloading, heaping on more complexity. ----------------------------------------------------------------------- From ttmrichter at gmail.com Thu Dec 2 07:36:05 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Thu, 2 Dec 2010 14:36:05 +0800 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> <20101130150418.GB11084@topoi.pooq.com> Message-ID: On 1 December 2010 14:49, Jay K wrote: > > *not* proper in terms of semantics (operator<< and operator>> being > obvious cases) > > This would not be allowed in my constrained proposal. > How would you stop it? How would you enforce a rule that says "<<" means that you are somehow shifting something to the left, even if the representation isn't a binary integer? How would you enforce a rule that says "+" must add, not concatenate, subtract, multiply or reset the computer? > > but also operator+ for concatenation > > This is very reasonable. > No, it is not. The semantics of concatenation are hugely different from the semantics of addition. Consider 3+4 vs. 4+3. Now consider "three"+"four" vs. "four"+"three". If you want to do concatenation, have an operator for concatenation. (++, say, as a random example.) Do not overload addition with an operation that isn't even vaguely analogous. > > utterly painful uses for operator,) > > I'm surprised that is overloadable, but indeed it appears it is. I don't > think I have *ever* seen anyone overload it, and I have seen a lot. > I would tell you how I used it, but I'm utterly ashamed of that portion of my life. ;) (It was in a type-safe SQL query builder.) > > the inability to define *new* operators (which leads to the first > problem of idiots redefining the semantics of operators) > > Stroupstroup rejected this as too complex. (See the Design&Evolution book). > Stroustrup is, not to put too fine a point on this, a gibbering lunatic. He rejected defining new operators as "too complex" -- yet created a language that to this day is nigh-impossible to implement according to specification (a situation that will be made even worse with the never-arriving C++1x). In the meantime languages far simpler than C++ (syntactically, at least) have had the ability to define new operators at will for ages. Haskell, for example, as a top of my head instance. Prolog too, if memory serves. Personally, I'd much rather try to implement a parser for Haskell or Prolog or languages in that vein than I would a C++ parser. > I don't see people pine for this often and I suspect he did the right > thing. > People don't pine for it often because people don't pine for capabilities they don't know exist. Most people don't pine for hygenic macro systems either -- until they use them in languages that provide that kind of capability. People didn't pine for RTTI in C++ either ... until it became available in some compilers and other compilers seemed far more constrained. People didn't pine for automated memory management ... until Java came along and made it mainstream. People didn't pine for multi-threading ... until everybody and their dog supported it. Hell, people didn't pine, by and large, for *operator overloading *until C++ made it mainstream! What people pine for vs. what people need or at least can truly use are such radically disjoint sets that I often use what people pine for as a hint for what to *avoid*. > It creates a layering problem I believe in the typical structure. > The lexical analysis would have to get information from higher layers. > Or you could go the Haskell route. Any token that consists of purely "special symbols" is an operator that can be used directly as an operator. To use it as a regular function you need to wrap it in parens. This means I can define, say, a "UFO operator" like <=+=+=+=> (made deliberately gonzo for fun) and use it as-is--e.g.: Expr1 <=+=+=+=> Expr2--or as a two-parameter function call--(<=+=+=+=>) Expr1 Expr2. Further you can go more down the Haskell route and make any function usable as an operator: myFunc Expr1 Expr2 is equally usable as Expr1 `myFunc` Expr2. Can you see how lexical analysis can trivially identify your operator definitions and usage here? > > unexpected costs to operations making the eyeballing of execution > complexity (time-wise and memory-wise) literally impossible > > This is already the case. As I said. So let's say that every single > function call is shown. It is hard to know which functions have which cost. > There are also hidden function calls e.g. for "try" and every pointer > derereference (right?) > Operator overloading can multiply these by orders of magnitude and have the added problem of being, in effect, "COME FROM" statements. I mean they're not as bad in this regard as, say, Aspect-Oriented Programming, but they're still pretty nasty. The fact that features X and Y have hidden costs is not really a good argument for adding feature Z that has all those hidden costs and an order of magnitude more all concealed in such a way that it is almost impossible to keep track of where things are really going. > Please consider floating point. Historically floating point was "soft > float". Sometimes these days it still us. Yet we still have operators for > floating point. > Why? Because it is just so convenient and idiomatic. Why stop there? > Because at some point the costs outweigh the benefits. Operator overloading is at just that cusp point for me to be torn. It has some major benefits, but it has major costs and right now I actually lean slightly in the direction of thinking the costs outweigh the benefits. (A few years ago I leaned slightly in the other direction, mind, so it, as a feature is not something I'm going to reject a language for.) > A primary design point of C++ is to give user defined types all the powers > of built in types. > No longer does it require a compiler change to introduce a type with the > "power" of int. And so on. > Instead it allows you to introduce a type that looks like an int but has such wildly varying semantics that it will confuse the ever living daylights out of people using it. Like using "+" for concatenation. > > painful interaction with templates that makes a perfect storm of > eye-damaging syntax > > Huh? Specifically? > My C++ days are a decade behind me so I no longer have any source that illustrates this. I just recall that any time we had a templated class with overloaded operators that it turned into an asinine stew of unreadable code. > The one vague reason I don't fully understand is: C doesn't have it. > Does C represent a good example of a sort of minimalism? Maybe. > It isn't clear to me the value of C. It has been *very* widely abandoned in > favor of C++. > What is the FFI lingua franca again? C or C++? (Hint: one of those two languages has syntax to make it compatible with the other, but not vice versa.) -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 2 07:53:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 2 Dec 2010 06:53:37 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, , , <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, <20101130150418.GB11084@topoi.pooq.com>, , , , Message-ID: > What is the FFI lingua franca again? C or C++? C is fairly lingua franca, but how do I *efficiently* *portably* implement exception handling? NT, Tru64, VMS all extend C slightly to allow it. I don't believe C on any other system does. C also doesn't offer "good idioms" for operator overloading. Easy enough for a target language, but as we are discussing here, not for a source language. + for String really is ok. Java, C++, C#. I realize it has completely different meaning than for integers, but even float vs. int are quite different in what + means. You know, big + small float == big. At this point, probably millions of programmers are comfortable with + being concat. At least in statically typed systems, where 3 and "3" are clearly different. > Any token that consists of purely "special symbols" is an operator that > can be used directly as an operator This changes the meaning of existing code in both C/C++ and Modula-3. e.g.: a:=+b; a:=-b; a:=--b; a:=---b; Maybe this can be resolved though. Still, I think there is plenty value in overloading existing operators. As well, one might just go ahead and define new rules for "unused" characters, if we have any. e.g. tilde, percent? > What people pine for vs. what people need or at least can truly use are > such radically disjoint sets that I often use what people pine for as a > hint for what to avoid. True. > How would you enforce a rule that says "<<" means that you are somehow > shifting something to the left My proposal was, like, that + is always T +(T,T). Similar for *, -, DIV. For << I think it'd always be T <<(T, integer). := would also be, like, := (T designator?, T) Granted, the semantic could still be arbitrary. But you wouldn't be able to define the family: <<(stream, integer) <<(stream, text) <<(stream, float) so that'd probably stop you from <<(stream, integer) meaning to print an integer. This limited form of operator overloading supports many scenarios. It does not however support the Blitz++ construct that optimizes all temporaries out of matrix/vector math. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Dec 2 08:59:35 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 2 Dec 2010 08:59:35 +0100 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, , , <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, <20101130150418.GB11084@topoi.pooq.com>, , , , Message-ID: <0E7D490B-41B9-4B90-B689-A280B2B2E0C8@m3w.org> Then obviously you are hitting blind alley there. Go other route. For example, LLVM route. On Dec 2, 2010, at 7:53 AM, Jay K wrote: > > What is the FFI lingua franca again? C or C++? > > > C is fairly lingua franca, but how do I *efficiently* *portably* > implement exception handling? NT, Tru64, VMS all extend C slightly > to allow it. I don't believe C on any other system does. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 2 10:17:32 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 2 Dec 2010 09:17:32 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: <0E7D490B-41B9-4B90-B689-A280B2B2E0C8@m3w.org> References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, , , , , , <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, , <20101130150418.GB11084@topoi.pooq.com>, , , , , , , , , , <0E7D490B-41B9-4B90-B689-A280B2B2E0C8@m3w.org> Message-ID: The gcc intermediate form does support exception handling. Efficient exception handling doesn't motivate gcc to llvm switch. As well, generating C++ is a good option for this reason. At least on non-NT/Tru64/VMS systems. As well, since this is multiple axes, an initial C backend could generate code like we do today -- pthread_getspecific/setjmp. Switching to LLVM is a big task. - Jay From: dragisha at m3w.org Date: Thu, 2 Dec 2010 08:59:35 +0100 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Enumeration or subrange value out of range Then obviously you are hitting blind alley there. Go other route. For example, LLVM route. On Dec 2, 2010, at 7:53 AM, Jay K wrote:> What is the FFI lingua franca again? C or C++? C is fairly lingua franca, but how do I *efficiently* *portably* implement exception handling? NT, Tru64, VMS all extend C slightly to allow it. I don't believe C on any other system does. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragisha at m3w.org Thu Dec 2 10:29:24 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 2 Dec 2010 10:29:24 +0100 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, , , , , , <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, , <20101130150418.GB11084@topoi.pooq.com>, , , , , , , , , , <0E7D490B-41B9-4B90-B689-A280B2B2E0C8@m3w.org> Message-ID: On Dec 2, 2010, at 10:17 AM, Jay K wrote: > The gcc intermediate form does support exception handling. > Efficient exception handling doesn't motivate gcc to llvm switch. > As well, generating C++ is a good option for this reason. > At least on non-NT/Tru64/VMS systems. > As well, since this is multiple axes, an initial C backend could generate code > like we do today -- pthread_getspecific/setjmp. > > Switching to LLVM is a big task. As big as making C++ backend? I don't see it as a switch. Just as another backend. And yes, I know it's easier from audience. It is your call, but anything C, C++, GCC is pain long term. We will probably all reap benefits of that C backend, as good intermediate solution if nothing else, but sooner we settle on LLVM, and forget GCC's wriggling backend, better. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 2 10:41:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 2 Dec 2010 09:41:13 +0000 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu>, ,,, ,,, ,,<16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org>, ,,<20101130150418.GB11084@topoi.pooq.com>, ,,, ,,, ,,, , , , , , , <0E7D490B-41B9-4B90-B689-A280B2B2E0C8@m3w.org>, , Message-ID: A C/C++ backend is definitely easier than anything else. It requires no learning of the target form! I know C and C++ very well, very little of C++ is relevant, mainly exception handling (*), and surely there is far more familiarity in the world of C and C++ than LLVM or gcc trees. * -- other parts of C++ might be interesting, such as putting module initializers in statics with constructors. This feature of C++ doesn't work well, but this would possibly help e.g. LoadLibrary/dlopen(mod3.dll) run the module initializers. Though here again, there is a way to do in C for NT and probably C in general, with platform-specific code. - Jay From: dragisha at m3w.org Date: Thu, 2 Dec 2010 10:29:24 +0100 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] Enumeration or subrange value out of range On Dec 2, 2010, at 10:17 AM, Jay K wrote:The gcc intermediate form does support exception handling. Efficient exception handling doesn't motivate gcc to llvm switch. As well, generating C++ is a good option for this reason. At least on non-NT/Tru64/VMS systems. As well, since this is multiple axes, an initial C backend could generate code like we do today -- pthread_getspecific/setjmp. Switching to LLVM is a big task. As big as making C++ backend? I don't see it as a switch. Just as another backend. And yes, I know it's easier from audience. It is your call, but anything C, C++, GCC is pain long term. We will probably all reap benefits of that C backend, as good intermediate solution if nothing else, but sooner we settle on LLVM, and forget GCC's wriggling backend, better. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ttmrichter at gmail.com Thu Dec 2 13:51:08 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Thu, 2 Dec 2010 20:51:08 +0800 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> <20101130150418.GB11084@topoi.pooq.com> Message-ID: On 2 December 2010 14:53, Jay K wrote: > + for String really is ok. > We will have to agree to disagree here. I really cannot stand having addition and concatenation using the same operator. It bugs me at a very profound level, even more than using left- and right-shift operators for output and input. > At this point, probably millions of programmers are comfortable > with + being concat. At least in statically typed systems, > where 3 and "3" are clearly different. > At this point millions of programmers are comfortable programming without a clean separation between interface and implementation. I still prefer the Modula series of languages and would not want them to change into an abortion like C++. > > Any token that consists of purely "special symbols" is an operator that > > can be used directly as an operator > > This changes the meaning of existing code in both C/C++ and Modula-3. > > e.g.: > a:=+b; > a:=-b; > a:=--b; > a:=---b; > I wasn't actually suggesting that we directly use Haskell's system. I was just pointing out that it's trivial to allow operators to be defined by the programmer without having the lexer communicating outside of the lexing process. It's a matter of language design. Were I to retrofit a "define new operator" mechanism into an established language like Modula-3, I'd probably insist that user-added operators be wrapped in something like backquotes. So a hypothetical concatenation operator might become `++`. Basically user-defined operators would have to have some way to uniquely identify themselves as such to the lexer in the absence of a language built from scratch to support them. > Still, I think there is plenty value in overloading existing operators. > There can be, yes. It's just that I've seen more abuse of operator overloading than I have good uses. This makes me nervous of having them, even though they *really are* damned convenient when used correctly. -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Dec 2 15:12:56 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 2 Dec 2010 09:12:56 -0500 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> <20101130150418.GB11084@topoi.pooq.com> Message-ID: <20101202141256.GA17591@topoi.pooq.com> On Thu, Dec 02, 2010 at 02:36:05PM +0800, Michael Richter wrote: > On 1 December 2010 14:49, Jay K wrote: > > No, it is not. The semantics of concatenation are hugely different from the > semantics of addition. Consider 3+4 vs. 4+3. > Now consider "three"+"four" > vs. "four"+"three". If you want to do concatenation, have an operator for > concatenation. (++, say, as a random example.) Do not overload addition > with an operation that isn't even vaguely analogous. The semantics of matrix multiplication are hugely different from those of integer multiplication. Consider A*B vs B*A. By this this doesn't mean that we necessarily need a different operator symbol. For string concatenation, there's even a homomorphism (length) mapping it to natural number addition. Just like determinant for matrices. > > > > > utterly painful uses for operator,) > > > > > > I'm surprised that is overloadable, but indeed it appears it is. I don't > > think I have *ever* seen anyone overload it, and I have seen a lot. > > > > I would tell you how I used it, but I'm utterly ashamed of that portion of > my life. ;) (It was in a type-safe SQL query builder.) That sounds as if you were defining . to be a reasonable approximation to SQL's . That sounds like a reasonable thing to do -- except if any of its uses would have to be disambiguated with C++'s hopelessly complicated disambiguation rules. > > Operator overloading can multiply these by orders of magnitude and have the > added problem of being, in effect, "COME FROM" statements. Those were fun. Good thing no one took hem seriously. > My C++ days are a decade behind me so I no longer have any source that > illustrates this. I just recall that any time we had a templated class with > overloaded operators that it turned into an asinine stew of unreadable code. > > > > The one vague reason I don't fully understand is: C doesn't have it. > > Does C represent a good example of a sort of minimalism? Maybe. > > It isn't clear to me the value of C. It has been *very* widely abandoned in > > favor of C++. I use the subset of C++ that's more or less equivalent to C. It gives me slightly better type-checking, but that's the main benefit. Very rarely I use single inheritance. If I do anything that involves a lot of that, I prefer Modula 3. > > What is the FFI lingua franca again? C or C++? (Hint: one of those two > languages has syntax to make it compatible with the other, but not vice > versa.) C has interfacing specs that are more or less consistent from machine to machine. C++ doesn't seem to. > > -- > "Perhaps people don't believe this, but throughout all of the discussions of > entering China our focus has really been what's best for the Chinese people. > It's not been about our revenue or profit or whatnot." > --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. More demonstrating how difficult some ethical decisions, even with the best of intentions. - hendrik From hendrik at topoi.pooq.com Thu Dec 2 15:22:03 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 2 Dec 2010 09:22:03 -0500 Subject: [M3devel] Code generation (was: Enumeration or subrange value out of range) In-Reply-To: References: <0E7D490B-41B9-4B90-B689-A280B2B2E0C8@m3w.org> Message-ID: <20101202142203.GB17591@topoi.pooq.com> On Thu, Dec 02, 2010 at 09:17:32AM +0000, Jay K wrote: > > The gcc intermediate form does support exception handling. > Efficient exception handling doesn't motivate gcc to llvm switch. > As well, generating C++ is a good option for this reason. > At least on non-NT/Tru64/VMS systems. > As well, since this is multiple axes, an initial C backend could generate code > like we do today -- pthread_getspecific/setjmp. > > Switching to LLVM is a big task. > > - Jay We seem to have switched from language design to Modula 3 implementatin decisions. Are either LLVN or gcc-intermediate as well-documented as C--, C, or C++? Too bad C-- seems to be somewhat lacking in implementatins of multiple kinds of hardware. It's otherwise excellent. -- hendrik From ttmrichter at gmail.com Thu Dec 2 15:36:59 2010 From: ttmrichter at gmail.com (Michael Richter) Date: Thu, 2 Dec 2010 22:36:59 +0800 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: <20101202141256.GA17591@topoi.pooq.com> References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> <20101130150418.GB11084@topoi.pooq.com> <20101202141256.GA17591@topoi.pooq.com> Message-ID: On 2 December 2010 22:12, Hendrik Boom wrote: > > The semantics of concatenation are hugely different from the > > semantics of addition. Consider 3+4 vs. 4+3. > > Now consider "three"+"four" > > vs. "four"+"three". If you want to do concatenation, have an operator > for > > concatenation. (++, say, as a random example.) Do not overload addition > > with an operation that isn't even vaguely analogous. > > The semantics of matrix multiplication are hugely different from those > of integer multiplication. Consider A*B vs B*A. > This is why, if memory serves, there's two different "multiplication" operations and operators for matrices? > > > I'm surprised that is overloadable, but indeed it appears it is. I > don't > > > think I have *ever* seen anyone overload it, and I have seen a lot. > > > I would tell you how I used it, but I'm utterly ashamed of that portion > of > > my life. ;) (It was in a type-safe SQL query builder.) > > That sounds as if you were defining . to be a reasonable approximation > to SQL's . That sounds like a reasonable thing to do -- except if any of > its uses would have to be disambiguated with C++'s hopelessly > complicated disambiguation rules. > Yeah, that was a problem. It also required some utterly retarded constructs like function calls that had double-parentheses because the comma is used differently in argument lists than in expressions and so forth. The final product was marginally better to use than the traditional format string-style SQL statement builders, but only marginally so and at a huge expense in implementation comprehension (and thus testing and debugging). > > Operator overloading can multiply these by orders of magnitude and have > the > > added problem of being, in effect, "COME FROM" statements. > > Those were fun. Good thing no one took hem seriously. > Sure they did. It's called "Aspect-Oriented Programming". ;) > I use the subset of C++ that's more or less equivalent to C. It gives > me slightly better type-checking, but that's the main benefit. > I think this plus limited use of inheritance is the majority use of C++. > > What is the FFI lingua franca again? C or C++? (Hint: one of those two > > languages has syntax to make it compatible with the other, but not vice > > versa.) > > C has interfacing specs that are more or less consistent from machine to > machine. > > C++ doesn't seem to. > C++ doesn't even have interfacing specs that are consistent and compatible from compiler to compiler. Or, often, compiler version to compiler version in the same family. > > "Perhaps people don't believe this, but throughout all of the discussions > of > entering China our focus has really been what's best for the Chinese > people. > It's not been about our revenue or profit or whatnot." > --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. More demonstrating how difficult some ethical decisions, even with the best of intentions. This presumes you actually believe what Brin says. I don't. I think revenue and profit was their only concern in moving into China and a lack thereof on both fronts was their motive to leave. -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 2 15:48:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 2 Dec 2010 14:48:35 +0000 Subject: [M3devel] Code generation (was: Enumeration or subrange value out of range) In-Reply-To: <20101202142203.GB17591@topoi.pooq.com> References: <0E7D490B-41B9-4B90-B689-A280B2B2E0C8@m3w.org>, , <20101202142203.GB17591@topoi.pooq.com> Message-ID: > Are either LLVN or gcc-intermediate as well-documented as C--, C, or > C++? > Too bad C-- seems to be somewhat lacking in implementatins of multiple > kinds of hardware. It's otherwise excellent. gcc-intermediate isn't necessarily poorly documented or changes much, but C and C++ are clearly the better documented forms. Just go to a bookstore. And even if they weren't better documented, there is much broader experience with them, by me and the wider world. It's a numbers thing. I have written thousands of lines of C and C++ and overall millions or billions have been written. Most of mine have been compiled by one line of compilers, but not all, and, in reality, I don't believe a backend would use the language(s) very intensely. The main reason I advocate C++ as a target vs. C is for portable efficient exception handling. (As well, Visual C++ I think is closer to the standard in terms of lack of extensions than gcc; I have also compiled some code with its /Za switch that disables extensions.) I should point out that nested functions will probably pose a small problem. Using "this" in C++ might help some, esp. to get the extra parameter efficiently passed on 32bit x86. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Dec 2 19:08:41 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 2 Dec 2010 13:08:41 -0500 Subject: [M3devel] Code generation (was: Enumeration or subrange value out of range) In-Reply-To: References: <20101202142203.GB17591@topoi.pooq.com> Message-ID: <20101202180841.GA2541@topoi.pooq.com> On Thu, Dec 02, 2010 at 02:48:35PM +0000, Jay K wrote: > > > Are either LLVN or gcc-intermediate as well-documented as C--, C, or > > C++? > > Too bad C-- seems to be somewhat lacking in implementatins of multiple > > kinds of hardware. It's otherwise excellent. > > > gcc-intermediate isn't necessarily poorly documented or changes much, > but C and C++ are clearly the better documented forms. > Just go to a bookstore. > > > And even if they weren't better documented, there is much broader > experience with them, by me and the wider world. > > > It's a numbers thing. I have written thousands of lines of C and C++ > and overall millions or billions have been written. > > > Most of mine have been compiled by one line of compilers, but not all, > and, in reality, I don't believe a backend would use the language(s) > very intensely. The main reason I advocate C++ as a target vs. C > is for portable efficient exception handling. > (As well, Visual C++ I think is closer to the standard in terms > of lack of extensions than gcc; I have also compiled some code > with its /Za switch that disables extensions.) > > > I should point out that nested functions will probably pose a small problem. > Using "this" in C++ might help some, esp. to get the extra parameter efficiently > passed on 32bit x86. I've used "this" trick for environments in a language in which almost every source line resulted in multiple functions, each with its own environment. I ended up with a huge number of classes and enormous link times. I'm not at all sure that the many classes were the cause of the link times. That was about 20 years ago. -- hendrik From mika at async.async.caltech.edu Thu Dec 2 20:29:19 2010 From: mika at async.async.caltech.edu (Mika Nystrom) Date: Thu, 02 Dec 2010 11:29:19 -0800 Subject: [M3devel] Enumeration or subrange value out of range In-Reply-To: <20101202141256.GA17591@topoi.pooq.com> References: <36A3E96C-421F-44A3-835D-4CC7D03C6312@cs.purdue.edu> <16040713-8F2E-43EE-A25A-CC688E3D22AC@m3w.org> <20101130150418.GB11084@topoi.pooq.com> <20101202141256.GA17591@topoi.pooq.com> Message-ID: <20101202192919.AFAE01A209B@async.async.caltech.edu> Hendrik Boom writes: >On Thu, Dec 02, 2010 at 02:36:05PM +0800, Michael Richter wrote: >> On 1 December 2010 14:49, Jay K wrote: >> >> No, it is not. The semantics of concatenation are hugely different from the >> semantics of addition. Consider 3+4 vs. 4+3. >> Now consider "three"+"four" >> vs. "four"+"three". If you want to do concatenation, have an operator for >> concatenation. (++, say, as a random example.) Do not overload addition >> with an operation that isn't even vaguely analogous. > >The semantics of matrix multiplication are hugely different from those >of integer multiplication. Consider A*B vs B*A. Ummm... integer multiplication is a special case of matrix multiplication.... Mika From jay.krell at cornell.edu Tue Dec 7 23:45:36 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 7 Dec 2010 22:45:36 +0000 Subject: [M3devel] ongoing hardware clearance -- anyone want a working Alpha, Sparcs? Message-ID: ongoing hardware clearance.. The hardware clearance is ongoing. In particular, with mixed feelings, my only HPPA/HP-UX/Linux machine is gone. On the other hand, last night I installed Linux/alpha and it can soon be in Hudson (albeit with a 9GB hard drive, which has proven challenging on Linux/sparc). This is the first I've had an Alpha locally up and running. I'm torn: keep the machine, running Linux Linux has the advantage of having Java across all architectures, so easily put into Hudson keep the machine, try NetBSD, OpenBSD, FreeBSD (6.4), VMS, Tru64. *BSD generally lack Java except on x86/AMD64. VMS would be nice to get working. It was on the machine originally. Tru64 probably redundant with Mika's machine, which we should try to get into Hudson. Get rid of the machine. I have 2 other Alphas, physically smaller, don't know yet if they work. Fourth Alpha already gone, not sure it worked. Machine is like: alphaev5 266MHz ? 256MB ? 9GB CD-ROM drive noticably slow but working ok no video out -- using serial console -- a fun rare little exercise :) (the other hand is easily implemented as Windows XP laptop running Hyperterm, using a USB to serial device, they run about $20; someday I might try a dedicated serial terminal device) Linux/sparc might be on the chopping block soon too. Someone to host that would be nice. Shipping outside the US is generally too expensive. The current Hudson node has no takers on ebay yet. http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=120657135772 I do have some other Sparcs I haven't used yet, might try them, or might get rid of them. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sat Dec 11 13:09:48 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 11 Dec 2010 12:09:48 +0000 Subject: [M3devel] Linux/Alpha working, uploaded archives Message-ID: Alpha/Linux works, builds itself, Juno comes up. There are builds here: http://modula3.elegosoft.com/cm3/uploaded-archives/ built on Debian 5.0. Debian 6.0 drops support for Alpha. It was easy as usual: setup the machine workaround one small gcc bug get the jmpbuf size, and the ucontext field My intention is to: not keep the machine up and running, not in Hudson go through and get OpenBSD, FreeBSD, NetBSD, VMS to work, however: so far I haven't been able to boot OpenBSD, NetBSD on my DS10L, FreeBSD doesn't see the hard drive, Linux works fine, and the I seem to have toasted the machine I was using so: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=120659104744 If anyone knows how to fix that, please let me know, thanks. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sat Dec 11 23:19:02 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Sat, 11 Dec 2010 14:19:02 -0800 Subject: [M3devel] cm3 on snow leopard? Message-ID: <20101211221902.B71F81A207C@async.async.caltech.edu> Hello m3devel, I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook Air, but it seems I have the wrong assembler? I had to force dpkg to override the architecture on install (it was expecting i386, I think, and my machine identified itself as being "i386-darwin"?) Here are some details... [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version Critical Mass Modula-3 version 5.8.6 last updated: 2010-04-11 compiled: 2010-07-14 21:27:23 configuration: /usr/local/cm3/bin/cm3.cfg host: I386_DARWIN target: I386_DARWIN compiling an empty Main.m3 yields: [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands --- building in ../I386_DARWIN --- cd ../I386_DARWIN rm .M3SHIP rm .M3OVERRIDES inhale prog.mx inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a new source -> compiling Main.m3 m3front ../src/Main.m3 -w1 /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno-reorde r-blocks Main.mc -o Main.ms echo "rep movsl" | as -o /dev/null 2> /dev/null as Main.ms -o Main.mo Main.ms:15:suffix or operands invalid for `push' assemble => 1 assembler failed assembling: Main.ms rm Main.mo exhale prog.mx rm prog.manifest compilation failed => not building program "prog" Fatal Error: package build failed [HAL:~/test/src] mika% uname -a Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 [HAL:~/test/src] mika% as -v Apple Inc version cctools-782~33, GNU assembler version 1.38 I have XCode installed. [HAL:~/test/src] mika% gcc -v Using built-in specs. Target: i686-apple-darwin10 Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Apple Inc. build 5664) [HAL:~/test/src] mika% which gcc /usr/bin/gcc I must be doing something very obviously wrong (obviously to someone on this list, right??) Mika From jay.krell at cornell.edu Sun Dec 12 01:59:18 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 12 Dec 2010 00:59:18 +0000 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: <20101211221902.B71F81A207C@async.async.caltech.edu> References: <20101211221902.B71F81A207C@async.async.caltech.edu> Message-ID: I admit I'm still using Leopard. - Jay > To: m3devel at elegosoft.com > Date: Sat, 11 Dec 2010 14:19:02 -0800 > From: mika at async.caltech.edu > Subject: [M3devel] cm3 on snow leopard? > > Hello m3devel, > > I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook > Air, but it seems I have the wrong assembler? > > I had to force dpkg to override the architecture on install (it was expecting > i386, I think, and my machine identified itself as being "i386-darwin"?) > > Here are some details... > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-14 21:27:23 > configuration: /usr/local/cm3/bin/cm3.cfg > host: I386_DARWIN > target: I386_DARWIN > > compiling an empty Main.m3 yields: > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands > --- building in ../I386_DARWIN --- > > cd ../I386_DARWIN > rm .M3SHIP > rm .M3OVERRIDES > inhale prog.mx > inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a > inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a > > new source -> compiling Main.m3 > m3front ../src/Main.m3 -w1 > /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno-reorde > r-blocks Main.mc -o Main.ms > echo "rep movsl" | as -o /dev/null 2> /dev/null > as Main.ms -o Main.mo > Main.ms:15:suffix or operands invalid for `push' > assemble => 1 > assembler failed assembling: Main.ms > rm Main.mo > exhale prog.mx > rm prog.manifest > > compilation failed => not building program "prog" > Fatal Error: package build failed > > [HAL:~/test/src] mika% uname -a > Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 > [HAL:~/test/src] mika% as -v > Apple Inc version cctools-782~33, GNU assembler version 1.38 > > > I have XCode installed. > > [HAL:~/test/src] mika% gcc -v > Using built-in specs. > Target: i686-apple-darwin10 > Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 > Thread model: posix > gcc version 4.2.1 (Apple Inc. build 5664) > [HAL:~/test/src] mika% which gcc > /usr/bin/gcc > > > I must be doing something very obviously wrong (obviously to someone on this list, right??) > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 12 06:26:37 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 12 Dec 2010 05:26:37 +0000 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: References: <20101211221902.B71F81A207C@async.async.caltech.edu>, Message-ID: I'm rudely (but helpfully) ignoring your details and giving some of mine. I though what is supposed to happen, specifically on Darwin, is the assembly code is supposed to indicate an architecture. jbook2:m3core jay$ CM3_TARGET=I386_DARWIN M3CONFIG=/cm3/bin/config/I386_DARWIN cm3 -keep ^C jbook2:m3core jay$ CM3_TARGET=AMD64_DARWIN M3CONFIG=/cm3/bin/config/AMD64_DARWIN cm3 -keep ^C head */RTHooks.ms but no. But then this: jbook2:m3core jay$ CM3_TARGET=AMD64_DARWIN M3CONFIG=/cm3/bin/config/AMD64_DARWIN cm3 -keep -commands --- building in AMD64_DARWIN --- .. /usr/libexec/gcc/darwin/x86_64/as RTAllocator.ms -o RTAllocator.mo CM3_TARGET=I386_DARWIN M3CONFIG=/cm3/bin/config/I386_DARWIN cm3 -keep -commands ... /usr/libexec/gcc/darwin/i386/as Ctypes.is -o Ctypes.io i386 vs. x86_64. Darwin.common: proc configure_assembler() is if defined("SYSTEM_ASM") return end SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" if not FileExists(SYSTEM_ASM) SYSTEM_ASM = "as" end end jbook2:m3core jay$ grep DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-install/* /dev2/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN:DarwinArch = "x86_64" /dev2/cm3/m3-sys/cminstall/src/config-no-install/ARM_DARWIN:DarwinArch = "armv6" % ? /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: local arch = " -arch " & DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: arch = " -arch_only " & DarwinArch & " " /dev2/cm3/m3-sys/cminstall/src/config-no-install/I386_DARWIN:DarwinArch = "i386" /dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC64_DARWIN:DarwinArch = "ppc64" /dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC_DARWIN:DarwinArch = "ppc" ? cm3 -commands? find /usr/lib | grep /as$ find /usr/libexec | grep /as$ Maybe the path changed? Has a version? or is there is only i686-apple-darwin9, powerpc-apple-darwin9? I should look into getting the architecture into the assembly code though and just running "as", esp. on newer hosts. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; m3devel at elegosoft.com Date: Sun, 12 Dec 2010 00:59:18 +0000 Subject: Re: [M3devel] cm3 on snow leopard? I admit I'm still using Leopard. - Jay > To: m3devel at elegosoft.com > Date: Sat, 11 Dec 2010 14:19:02 -0800 > From: mika at async.caltech.edu > Subject: [M3devel] cm3 on snow leopard? > > Hello m3devel, > > I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook > Air, but it seems I have the wrong assembler? > > I had to force dpkg to override the architecture on install (it was expecting > i386, I think, and my machine identified itself as being "i386-darwin"?) > > Here are some details... > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-14 21:27:23 > configuration: /usr/local/cm3/bin/cm3.cfg > host: I386_DARWIN > target: I386_DARWIN > > compiling an empty Main.m3 yields: > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands > --- building in ../I386_DARWIN --- > > cd ../I386_DARWIN > rm .M3SHIP > rm .M3OVERRIDES > inhale prog.mx > inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a > inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a > > new source -> compiling Main.m3 > m3front ../src/Main.m3 -w1 > /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno-reorde > r-blocks Main.mc -o Main.ms > echo "rep movsl" | as -o /dev/null 2> /dev/null > as Main.ms -o Main.mo > Main.ms:15:suffix or operands invalid for `push' > assemble => 1 > assembler failed assembling: Main.ms > rm Main.mo > exhale prog.mx > rm prog.manifest > > compilation failed => not building program "prog" > Fatal Error: package build failed > > [HAL:~/test/src] mika% uname -a > Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 > [HAL:~/test/src] mika% as -v > Apple Inc version cctools-782~33, GNU assembler version 1.38 > > > I have XCode installed. > > [HAL:~/test/src] mika% gcc -v > Using built-in specs. > Target: i686-apple-darwin10 > Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 > Thread model: posix > gcc version 4.2.1 (Apple Inc. build 5664) > [HAL:~/test/src] mika% which gcc > /usr/bin/gcc > > > I must be doing something very obviously wrong (obviously to someone on this list, right??) > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 12 06:36:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 12 Dec 2010 05:36:02 +0000 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: References: <20101211221902.B71F81A207C@async.async.caltech.edu>, , , Message-ID: Please experiment a bit with this and let me know. Notice how I only get .machine for ppc. jbook2:~ jay$ cat 1.c void F1() {} jbook2:~ jay$ gcc -arch ppc64 -c 1.c -S && grep machine 1.s .machine ppc64 jbook2:~ jay$ gcc -arch ppc -c 1.c -S && grep machine 1.s .machine ppc7400 jbook2:~ jay$ gcc -arch i386 -c 1.c -S && grep machine 1.s jbook2:~ jay$ gcc -arch x86_64 -c 1.c -S && grep machine 1.s Oh, here: gcc-4.2 -arch ppc64 -c 1.c -v gcc-4.2 -arch x86_64 -c 1.c -v /usr/libexec/gcc/i686-apple-darwin9/4.2.1/as -arch x86_64 -force_cpusubtype_ALL -o 1.o /var/folders/QG/Q Ok, I think we should use the C compiler on Darwin to assemble. It costs an extra fork/exec. This is probably a reasonable idea on all systems, and cheap enough except on Cygwin. I'll try to get around to this fairly soon. It'll require per-target. More generally we *might* be able to extract enough from the gcc driver in m3-sys/m3cc and use it. I might might might might pursue that. Might. In particular, we could build both cm3cg and gcc driver (renamed -- m3gcc?) and trigger gcc to run both cm3cg (m3cgc1) and as. This seems very very reasonable. gcc driver (renamed) merely has to know that .is/.ms map to cm3cg or m3cgc1. This is a good idea. But more work. Thanks, - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; m3devel at elegosoft.com Date: Sun, 12 Dec 2010 05:26:37 +0000 Subject: Re: [M3devel] cm3 on snow leopard? I'm rudely (but helpfully) ignoring your details and giving some of mine. I though what is supposed to happen, specifically on Darwin, is the assembly code is supposed to indicate an architecture. jbook2:m3core jay$ CM3_TARGET=I386_DARWIN M3CONFIG=/cm3/bin/config/I386_DARWIN cm3 -keep ^C jbook2:m3core jay$ CM3_TARGET=AMD64_DARWIN M3CONFIG=/cm3/bin/config/AMD64_DARWIN cm3 -keep ^C head */RTHooks.ms but no. But then this: jbook2:m3core jay$ CM3_TARGET=AMD64_DARWIN M3CONFIG=/cm3/bin/config/AMD64_DARWIN cm3 -keep -commands --- building in AMD64_DARWIN --- .. /usr/libexec/gcc/darwin/x86_64/as RTAllocator.ms -o RTAllocator.mo CM3_TARGET=I386_DARWIN M3CONFIG=/cm3/bin/config/I386_DARWIN cm3 -keep -commands ... /usr/libexec/gcc/darwin/i386/as Ctypes.is -o Ctypes.io i386 vs. x86_64. Darwin.common: proc configure_assembler() is if defined("SYSTEM_ASM") return end SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" if not FileExists(SYSTEM_ASM) SYSTEM_ASM = "as" end end jbook2:m3core jay$ grep DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-install/* /dev2/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN:DarwinArch = "x86_64" /dev2/cm3/m3-sys/cminstall/src/config-no-install/ARM_DARWIN:DarwinArch = "armv6" % ? /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: local arch = " -arch " & DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: arch = " -arch_only " & DarwinArch & " " /dev2/cm3/m3-sys/cminstall/src/config-no-install/I386_DARWIN:DarwinArch = "i386" /dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC64_DARWIN:DarwinArch = "ppc64" /dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC_DARWIN:DarwinArch = "ppc" ? cm3 -commands? find /usr/lib | grep /as$ find /usr/libexec | grep /as$ Maybe the path changed? Has a version? or is there is only i686-apple-darwin9, powerpc-apple-darwin9? I should look into getting the architecture into the assembly code though and just running "as", esp. on newer hosts. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; m3devel at elegosoft.com Date: Sun, 12 Dec 2010 00:59:18 +0000 Subject: Re: [M3devel] cm3 on snow leopard? I admit I'm still using Leopard. - Jay > To: m3devel at elegosoft.com > Date: Sat, 11 Dec 2010 14:19:02 -0800 > From: mika at async.caltech.edu > Subject: [M3devel] cm3 on snow leopard? > > Hello m3devel, > > I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook > Air, but it seems I have the wrong assembler? > > I had to force dpkg to override the architecture on install (it was expecting > i386, I think, and my machine identified itself as being "i386-darwin"?) > > Here are some details... > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-14 21:27:23 > configuration: /usr/local/cm3/bin/cm3.cfg > host: I386_DARWIN > target: I386_DARWIN > > compiling an empty Main.m3 yields: > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands > --- building in ../I386_DARWIN --- > > cd ../I386_DARWIN > rm .M3SHIP > rm .M3OVERRIDES > inhale prog.mx > inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a > inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a > > new source -> compiling Main.m3 > m3front ../src/Main.m3 -w1 > /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno-reorde > r-blocks Main.mc -o Main.ms > echo "rep movsl" | as -o /dev/null 2> /dev/null > as Main.ms -o Main.mo > Main.ms:15:suffix or operands invalid for `push' > assemble => 1 > assembler failed assembling: Main.ms > rm Main.mo > exhale prog.mx > rm prog.manifest > > compilation failed => not building program "prog" > Fatal Error: package build failed > > [HAL:~/test/src] mika% uname -a > Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 > [HAL:~/test/src] mika% as -v > Apple Inc version cctools-782~33, GNU assembler version 1.38 > > > I have XCode installed. > > [HAL:~/test/src] mika% gcc -v > Using built-in specs. > Target: i686-apple-darwin10 > Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 > Thread model: posix > gcc version 4.2.1 (Apple Inc. build 5664) > [HAL:~/test/src] mika% which gcc > /usr/bin/gcc > > > I must be doing something very obviously wrong (obviously to someone on this list, right??) > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 12 06:49:29 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 12 Dec 2010 05:49:29 +0000 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: References: <20101211221902.B71F81A207C@async.async.caltech.edu>, , , Message-ID: I'm more sympathetic to using the already installed C compiler to drive the assembler, than to build the current gcc driver. You can see on Darwin we already probe around fairly aggressively for a C compiler that can be told the target: Darwin.common: proc configure_c_compiler() is if defined("SYSTEM_CC") return end % % older compiler doesn't like -m32 or -arch % % gcc -c -m32 -x c /dev/null % cc1: error: invalid option ?m32? % % fPIC is not usually needed here. % It is the default for Apple gcc and left % here in case user is using a self-built FSF gcc. % SYSTEM_CC = "gcc -gstabs+ -fPIC" local m = " -m" & {"32BITS":"32","64BITS":"64"}{WORD_SIZE} local arch = " -arch " & DarwinArch if not equal(try_exec("@" & SYSTEM_CC & m & " -c -x c /dev/null -o /dev/null 2>&1 | fgrep \"cc1: error: invalid option \\\`32'\" >/dev/null"), 0) SYSTEM_CC = SYSTEM_CC & m end if not equal(try_exec("@" & SYSTEM_CC & arch & " -c -x c /dev/null -o /dev/null 2>&1 | fgrep \"cc1: error: unrecognized command line option \\\\\"-arch\\\\\"\" >/dev/null"), 0) SYSTEM_CC = SYSTEM_CC & arch end %write("SYSTEM_CC is " & SYSTEM_CC) end Most likely if we merely set SYSTEM_ASM = SYSTEM_CC & "-x assembler" it'll work well. Maybe only in this else case: proc configure_assembler() is if defined("SYSTEM_ASM") return end SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" if not FileExists(SYSTEM_ASM) SYSTEM_ASM = "as" <<== here end end All this is addressed by autoconf and/or a C-generating backend..... - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; m3devel at elegosoft.com Date: Sun, 12 Dec 2010 05:26:37 +0000 Subject: Re: [M3devel] cm3 on snow leopard? I'm rudely (but helpfully) ignoring your details and giving some of mine. I though what is supposed to happen, specifically on Darwin, is the assembly code is supposed to indicate an architecture. jbook2:m3core jay$ CM3_TARGET=I386_DARWIN M3CONFIG=/cm3/bin/config/I386_DARWIN cm3 -keep ^C jbook2:m3core jay$ CM3_TARGET=AMD64_DARWIN M3CONFIG=/cm3/bin/config/AMD64_DARWIN cm3 -keep ^C head */RTHooks.ms but no. But then this: jbook2:m3core jay$ CM3_TARGET=AMD64_DARWIN M3CONFIG=/cm3/bin/config/AMD64_DARWIN cm3 -keep -commands --- building in AMD64_DARWIN --- .. /usr/libexec/gcc/darwin/x86_64/as RTAllocator.ms -o RTAllocator.mo CM3_TARGET=I386_DARWIN M3CONFIG=/cm3/bin/config/I386_DARWIN cm3 -keep -commands ... /usr/libexec/gcc/darwin/i386/as Ctypes.is -o Ctypes.io i386 vs. x86_64. Darwin.common: proc configure_assembler() is if defined("SYSTEM_ASM") return end SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" if not FileExists(SYSTEM_ASM) SYSTEM_ASM = "as" end end jbook2:m3core jay$ grep DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-install/* /dev2/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN:DarwinArch = "x86_64" /dev2/cm3/m3-sys/cminstall/src/config-no-install/ARM_DARWIN:DarwinArch = "armv6" % ? /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: local arch = " -arch " & DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: arch = " -arch_only " & DarwinArch & " " /dev2/cm3/m3-sys/cminstall/src/config-no-install/I386_DARWIN:DarwinArch = "i386" /dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC64_DARWIN:DarwinArch = "ppc64" /dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC_DARWIN:DarwinArch = "ppc" ? cm3 -commands? find /usr/lib | grep /as$ find /usr/libexec | grep /as$ Maybe the path changed? Has a version? or is there is only i686-apple-darwin9, powerpc-apple-darwin9? I should look into getting the architecture into the assembly code though and just running "as", esp. on newer hosts. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; m3devel at elegosoft.com Date: Sun, 12 Dec 2010 00:59:18 +0000 Subject: Re: [M3devel] cm3 on snow leopard? I admit I'm still using Leopard. - Jay > To: m3devel at elegosoft.com > Date: Sat, 11 Dec 2010 14:19:02 -0800 > From: mika at async.caltech.edu > Subject: [M3devel] cm3 on snow leopard? > > Hello m3devel, > > I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook > Air, but it seems I have the wrong assembler? > > I had to force dpkg to override the architecture on install (it was expecting > i386, I think, and my machine identified itself as being "i386-darwin"?) > > Here are some details... > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-14 21:27:23 > configuration: /usr/local/cm3/bin/cm3.cfg > host: I386_DARWIN > target: I386_DARWIN > > compiling an empty Main.m3 yields: > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands > --- building in ../I386_DARWIN --- > > cd ../I386_DARWIN > rm .M3SHIP > rm .M3OVERRIDES > inhale prog.mx > inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a > inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a > > new source -> compiling Main.m3 > m3front ../src/Main.m3 -w1 > /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno-reorde > r-blocks Main.mc -o Main.ms > echo "rep movsl" | as -o /dev/null 2> /dev/null > as Main.ms -o Main.mo > Main.ms:15:suffix or operands invalid for `push' > assemble => 1 > assembler failed assembling: Main.ms > rm Main.mo > exhale prog.mx > rm prog.manifest > > compilation failed => not building program "prog" > Fatal Error: package build failed > > [HAL:~/test/src] mika% uname -a > Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 > [HAL:~/test/src] mika% as -v > Apple Inc version cctools-782~33, GNU assembler version 1.38 > > > I have XCode installed. > > [HAL:~/test/src] mika% gcc -v > Using built-in specs. > Target: i686-apple-darwin10 > Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 > Thread model: posix > gcc version 4.2.1 (Apple Inc. build 5664) > [HAL:~/test/src] mika% which gcc > /usr/bin/gcc > > > I must be doing something very obviously wrong (obviously to someone on this list, right??) > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 12 07:01:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 12 Dec 2010 06:01:21 +0000 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: References: <20101211221902.B71F81A207C@async.async.caltech.edu>, , , , , , Message-ID: Please try my updated Darwin.common. IsX86 = equal(TARGET, "I386_DARWIN") or equal(TARGET, "AMD64_DARWIN") proc configure_assembler() is if defined("SYSTEM_ASM") return end SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" if not FileExists(SYSTEM_ASM) if IsX86 configure_c_compiler () SYSTEM_ASM = SYSTEM_CC_ASM & " -c -x assembler" else SYSTEM_ASM = "as" end end %SYSTEM_ASM = SYSTEM_CC_ASM & " -v -c -x assembler" end proc configure_c_compiler() is if defined("SYSTEM_CC") return end % % older compiler doesn't like -m32 or -arch % % gcc -c -m32 -x c /dev/null % cc1: error: invalid option ?m32? % % fPIC is not usually needed here. % It is the default for Apple gcc and left % here in case user is using a self-built FSF gcc. % SYSTEM_CC = "gcc -gstabs+ -fPIC" SYSTEM_CC_ASM = "gcc -fPIC" local m = " -m" & {"32BITS":"32","64BITS":"64"}{WORD_SIZE} local arch = " -arch " & DarwinArch if not equal(try_exec("@" & SYSTEM_CC & m & " -c -x c /dev/null -o /dev/null 2>&1 | fgrep \"cc1: error: invalid option \\\`32'\" >/dev/null"), 0) SYSTEM_CC = SYSTEM_CC & m SYSTEM_CC_ASM = SYSTEM_CC_ASM & m end if not equal(try_exec("@" & SYSTEM_CC & arch & " -c -x c /dev/null -o /dev/null 2>&1 | fgrep \"cc1: error: unrecognized command line option \\\\\"-arch\\\\\"\" >/dev/null"), 0) SYSTEM_CC = SYSTEM_CC & arch SYSTEM_CC_ASM = SYSTEM_CC_ASM & arch end %write("SYSTEM_CC is " & SYSTEM_CC) end - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; m3devel at elegosoft.com Date: Sun, 12 Dec 2010 05:49:29 +0000 Subject: Re: [M3devel] cm3 on snow leopard? I'm more sympathetic to using the already installed C compiler to drive the assembler, than to build the current gcc driver. You can see on Darwin we already probe around fairly aggressively for a C compiler that can be told the target: Darwin.common: proc configure_c_compiler() is if defined("SYSTEM_CC") return end % % older compiler doesn't like -m32 or -arch % % gcc -c -m32 -x c /dev/null % cc1: error: invalid option ?m32? % % fPIC is not usually needed here. % It is the default for Apple gcc and left % here in case user is using a self-built FSF gcc. % SYSTEM_CC = "gcc -gstabs+ -fPIC" local m = " -m" & {"32BITS":"32","64BITS":"64"}{WORD_SIZE} local arch = " -arch " & DarwinArch if not equal(try_exec("@" & SYSTEM_CC & m & " -c -x c /dev/null -o /dev/null 2>&1 | fgrep \"cc1: error: invalid option \\\`32'\" >/dev/null"), 0) SYSTEM_CC = SYSTEM_CC & m end if not equal(try_exec("@" & SYSTEM_CC & arch & " -c -x c /dev/null -o /dev/null 2>&1 | fgrep \"cc1: error: unrecognized command line option \\\\\"-arch\\\\\"\" >/dev/null"), 0) SYSTEM_CC = SYSTEM_CC & arch end %write("SYSTEM_CC is " & SYSTEM_CC) end Most likely if we merely set SYSTEM_ASM = SYSTEM_CC & "-x assembler" it'll work well. Maybe only in this else case: proc configure_assembler() is if defined("SYSTEM_ASM") return end SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" if not FileExists(SYSTEM_ASM) SYSTEM_ASM = "as" <<== here end end All this is addressed by autoconf and/or a C-generating backend..... - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; m3devel at elegosoft.com Date: Sun, 12 Dec 2010 05:26:37 +0000 Subject: Re: [M3devel] cm3 on snow leopard? I'm rudely (but helpfully) ignoring your details and giving some of mine. I though what is supposed to happen, specifically on Darwin, is the assembly code is supposed to indicate an architecture. jbook2:m3core jay$ CM3_TARGET=I386_DARWIN M3CONFIG=/cm3/bin/config/I386_DARWIN cm3 -keep ^C jbook2:m3core jay$ CM3_TARGET=AMD64_DARWIN M3CONFIG=/cm3/bin/config/AMD64_DARWIN cm3 -keep ^C head */RTHooks.ms but no. But then this: jbook2:m3core jay$ CM3_TARGET=AMD64_DARWIN M3CONFIG=/cm3/bin/config/AMD64_DARWIN cm3 -keep -commands --- building in AMD64_DARWIN --- .. /usr/libexec/gcc/darwin/x86_64/as RTAllocator.ms -o RTAllocator.mo CM3_TARGET=I386_DARWIN M3CONFIG=/cm3/bin/config/I386_DARWIN cm3 -keep -commands ... /usr/libexec/gcc/darwin/i386/as Ctypes.is -o Ctypes.io i386 vs. x86_64. Darwin.common: proc configure_assembler() is if defined("SYSTEM_ASM") return end SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" if not FileExists(SYSTEM_ASM) SYSTEM_ASM = "as" end end jbook2:m3core jay$ grep DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-install/* /dev2/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN:DarwinArch = "x86_64" /dev2/cm3/m3-sys/cminstall/src/config-no-install/ARM_DARWIN:DarwinArch = "armv6" % ? /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: SYSTEM_ASM = "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: local arch = " -arch " & DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: arch = " -arch_only " & DarwinArch & " " /dev2/cm3/m3-sys/cminstall/src/config-no-install/I386_DARWIN:DarwinArch = "i386" /dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC64_DARWIN:DarwinArch = "ppc64" /dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC_DARWIN:DarwinArch = "ppc" ? cm3 -commands? find /usr/lib | grep /as$ find /usr/libexec | grep /as$ Maybe the path changed? Has a version? or is there is only i686-apple-darwin9, powerpc-apple-darwin9? I should look into getting the architecture into the assembly code though and just running "as", esp. on newer hosts. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu; m3devel at elegosoft.com Date: Sun, 12 Dec 2010 00:59:18 +0000 Subject: Re: [M3devel] cm3 on snow leopard? I admit I'm still using Leopard. - Jay > To: m3devel at elegosoft.com > Date: Sat, 11 Dec 2010 14:19:02 -0800 > From: mika at async.caltech.edu > Subject: [M3devel] cm3 on snow leopard? > > Hello m3devel, > > I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook > Air, but it seems I have the wrong assembler? > > I had to force dpkg to override the architecture on install (it was expecting > i386, I think, and my machine identified itself as being "i386-darwin"?) > > Here are some details... > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-14 21:27:23 > configuration: /usr/local/cm3/bin/cm3.cfg > host: I386_DARWIN > target: I386_DARWIN > > compiling an empty Main.m3 yields: > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands > --- building in ../I386_DARWIN --- > > cd ../I386_DARWIN > rm .M3SHIP > rm .M3OVERRIDES > inhale prog.mx > inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a > inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a > > new source -> compiling Main.m3 > m3front ../src/Main.m3 -w1 > /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno-reorde > r-blocks Main.mc -o Main.ms > echo "rep movsl" | as -o /dev/null 2> /dev/null > as Main.ms -o Main.mo > Main.ms:15:suffix or operands invalid for `push' > assemble => 1 > assembler failed assembling: Main.ms > rm Main.mo > exhale prog.mx > rm prog.manifest > > compilation failed => not building program "prog" > Fatal Error: package build failed > > [HAL:~/test/src] mika% uname -a > Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 > [HAL:~/test/src] mika% as -v > Apple Inc version cctools-782~33, GNU assembler version 1.38 > > > I have XCode installed. > > [HAL:~/test/src] mika% gcc -v > Using built-in specs. > Target: i686-apple-darwin10 > Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 > Thread model: posix > gcc version 4.2.1 (Apple Inc. build 5664) > [HAL:~/test/src] mika% which gcc > /usr/bin/gcc > > > I must be doing something very obviously wrong (obviously to someone on this list, right??) > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Dec 12 10:35:35 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 12 Dec 2010 01:35:35 -0800 Subject: [M3devel] cm3 on snow leopard? Message-ID: <20101212093535.155ED1A207C@async.async.caltech.edu> Thanks, Jay. I wasn't able to use your Darwin.config (remember, I'm installing from the release .deb)---there seem to have been too many changes to these files for me to be able to sort it all out. However, I figured out how to do a "quick and dirty" from your email. This fixed it for me: if not defined("SYSTEM_ASM") SYSTEM_ASM="/usr/libexec/gcc/darwin/i386/as" end Now to check on all the other problems. Mika Jay K writes: >--_1377ed26-bb42-4722-b430-c9bf3b1b287d_ >Content-Type: text/plain; charset="Windows-1252" >Content-Transfer-Encoding: quoted-printable > > >I'm more sympathetic to using the already installed C compiler >to drive the assembler=2C than to build the current gcc driver. > > >You can see on Darwin we already probe around fairly aggressively >for a C compiler that can be told the target: > >Darwin.common: > > >proc configure_c_compiler() is > > if defined("SYSTEM_CC") > return > end > > % > % older compiler doesn't like -m32 or -arch > % > % gcc -c -m32 -x c /dev/null > % cc1: error: invalid option =91m32=92 > % > % fPIC is not usually needed here. > % It is the default for Apple gcc and left > % here in case user is using a self-built FSF gcc. > % > > SYSTEM_CC =3D "gcc -gstabs+ -fPIC" > local m =3D " -m" & {"32BITS":"32"=2C"64BITS":"64"}{WORD_SIZE} > local arch =3D " -arch " & DarwinArch > if not equal(try_exec("@" & SYSTEM_CC & m & " -c -x c /dev/null -o /dev/n= >ull 2>&1 | fgrep \"cc1: error: invalid option \\\`32'\" >/dev/null")=2C 0) > SYSTEM_CC =3D SYSTEM_CC & m > end > if not equal(try_exec("@" & SYSTEM_CC & arch & " -c -x c /dev/null -o /de= >v/null 2>&1 | fgrep \"cc1: error: unrecognized command line option \\\\\"-a= >rch\\\\\"\" >/dev/null")=2C 0) > SYSTEM_CC =3D SYSTEM_CC & arch > end > %write("SYSTEM_CC is " & SYSTEM_CC) >end > ... From jay.krell at cornell.edu Sun Dec 12 10:51:06 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 12 Dec 2010 09:51:06 +0000 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: References: <20101211221902.B71F81A207C@async.async.caltech.edu>, , , , , , , <20101212093436.813921A207A@async.async.caltech.edu>, Message-ID: oh, oops, I didn't realize release was so far behind, duh. :) It reads, AMD64_DARWIN: SYSTEM_ASM = "/usr/libexec/gcc/darwin/x86_64/as" if not FileExists(SYSTEM_ASM) SYSTEM_ASM = "as" end I386_DARWIN: proc configure_assembler() is if defined("SYSTEM_ASM") return end local a = try_exec("@echo \"rep movsl\" | as -o /dev/null 2> /dev/null") % write("a is " & a & CR) if equal(a, 0) SYSTEM_ASM = "as" % write(SYSTEM_ASM & " works" & CR) return end % write("as does not work" & CR) if FileExists("/cctools-698.1/usr/bin/as") SYSTEM_ASM = "/cctools-698.1/usr/bin/as" % write("using " & SYSTEM_ASM & ", which is presumed to work" & CR) return end error("as does not work (does not recognize \"rep movsl\"), please upgrade to " & "cctools-698.1 or newer and install to /cctools-698.1") % % another good option is probably to put an assembler next to cm3cg % end I have since changed m3cc to work with the older assembler. :) (The gcc folks might have also, but I did so differently.) - Jay > To: jay.krell at cornell.edu > CC: m3devel at async.caltech.edu > Subject: Re: [M3devel] cm3 on snow leopard? > Date: Sun, 12 Dec 2010 01:34:36 -0800 > From: mika at async.caltech.edu > > Thanks, Jay. > > I wasn't able to use your Darwin.config (remember, I'm installing > from the release .deb)---there seem to have been too many changes to > these files for me to be able to sort it all out. However, I figured > out how to do a "quick and dirty" from your email. > > This fixed it for me: > > if not defined("SYSTEM_ASM") > SYSTEM_ASM="/usr/libexec/gcc/darwin/i386/as" > end > > Now to check on all the other problems. > > Mika > > Jay K writes: > >--_1377ed26-bb42-4722-b430-c9bf3b1b287d_ > >Content-Type: text/plain; charset="Windows-1252" > >Content-Transfer-Encoding: quoted-printable > > > > > >I'm more sympathetic to using the already installed C compiler > >to drive the assembler=2C than to build the current gcc driver. > > > > > >You can see on Darwin we already probe around fairly aggressively > >for a C compiler that can be told the target: > > > >Darwin.common: > > > > > >proc configure_c_compiler() is > > > > if defined("SYSTEM_CC") > > return > > end > > > > % > > % older compiler doesn't like -m32 or -arch > > % > > % gcc -c -m32 -x c /dev/null > > % cc1: error: invalid option =91m32=92 > > % > > % fPIC is not usually needed here. > > % It is the default for Apple gcc and left > > % here in case user is using a self-built FSF gcc. > > % > > > > SYSTEM_CC =3D "gcc -gstabs+ -fPIC" > > local m =3D " -m" & {"32BITS":"32"=2C"64BITS":"64"}{WORD_SIZE} > > local arch =3D " -arch " & DarwinArch > > if not equal(try_exec("@" & SYSTEM_CC & m & " -c -x c /dev/null -o /dev/n= > >ull 2>&1 | fgrep \"cc1: error: invalid option \\\`32'\" >/dev/null")=2C 0) > > SYSTEM_CC =3D SYSTEM_CC & m > > end > > if not equal(try_exec("@" & SYSTEM_CC & arch & " -c -x c /dev/null -o /de= > >v/null 2>&1 | fgrep \"cc1: error: unrecognized command line option \\\\\"-a= > >rch\\\\\"\" >/dev/null")=2C 0) > > SYSTEM_CC =3D SYSTEM_CC & arch > > end > > %write("SYSTEM_CC is " & SYSTEM_CC) > >end > > > > > >Most likely if we merely set SYSTEM_ASM =3D SYSTEM_CC & "-x assembler" > >it'll work well. > >Maybe only in this else case: > > > > > >proc configure_assembler() is > > if defined("SYSTEM_ASM") > > return > > end > > SYSTEM_ASM =3D "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" > > if not FileExists(SYSTEM_ASM) > > SYSTEM_ASM =3D "as" <<=3D=3D here > > end > >end > > > > > >All this is addressed by autoconf and/or a C-generating backend..... > > > > > > - Jay > > > > > > > > > > > > > >From: jay.krell at cornell.edu > >To: mika at async.caltech.edu=3B m3devel at elegosoft.com > >Date: Sun=2C 12 Dec 2010 05:26:37 +0000 > >Subject: Re: [M3devel] cm3 on snow leopard? > > > > > > > > > > > > > > > > > >I'm rudely (but helpfully) ignoring your details and giving some of mine. > > > >I though what is supposed to happen=2C specifically on Darwin=2C is the ass= > >embly code is supposed to indicate an architecture. > > > >jbook2:m3core jay$ CM3_TARGET=3DI386_DARWIN M3CONFIG=3D/cm3/bin/config/I386= > >_DARWIN cm3 -keep > >^C > > > >jbook2:m3core jay$ CM3_TARGET=3DAMD64_DARWIN M3CONFIG=3D/cm3/bin/config/AMD= > >64_DARWIN cm3 -keep > >^C > > > >head */RTHooks.ms > > > >but no. > > > >But then this: > > > >jbook2:m3core jay$ CM3_TARGET=3DAMD64_DARWIN M3CONFIG=3D/cm3/bin/config/AMD= > >64_DARWIN cm3 -keep -commands > >--- building in AMD64_DARWIN --- > > > >.. > >/usr/libexec/gcc/darwin/x86_64/as RTAllocator.ms -o RTAllocator.mo > > > >CM3_TARGET=3DI386_DARWIN M3CONFIG=3D/cm3/bin/config/I386_DARWIN cm3 -keep -= > >commands > > > >... > >/usr/libexec/gcc/darwin/i386/as Ctypes.is -o Ctypes.io > > > >i386 vs. x86_64. > > > >Darwin.common: > >proc configure_assembler() is > > if defined("SYSTEM_ASM") > > return > > end > > SYSTEM_ASM =3D "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" > > if not FileExists(SYSTEM_ASM) > > SYSTEM_ASM =3D "as" > > end > >end > > > > > >jbook2:m3core jay$ grep DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no= > >-install/* > >/dev2/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN:DarwinArch = > >=3D "x86_64" > >/dev2/cm3/m3-sys/cminstall/src/config-no-install/ARM_DARWIN:DarwinArch =3D = > >"armv6" % ? > >/dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: SYSTEM_ASM= > > =3D "/usr/libexec/gcc/darwin/" & DarwinArch & "/as" > >/dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: local arch= > > =3D " -arch " & DarwinArch > >/dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: arch = > >=3D " -arch_only " & DarwinArch & " " > >/dev2/cm3/m3-sys/cminstall/src/config-no-install/I386_DARWIN:DarwinArch =3D= > > "i386" > >/dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC64_DARWIN:DarwinArch = > >=3D "ppc64" > >/dev2/cm3/m3-sys/cminstall/src/config-no-install/PPC_DARWIN:DarwinArch =3D = > >"ppc" > > > >? > >cm3 -commands? > > > >find /usr/lib | grep /as$ > >find /usr/libexec | grep /as$ > > > > > >Maybe the path changed? Has a version? or is there is only i686-apple-darwi= > >n9=2C powerpc-apple-darwin9? > > > >I should look into getting the architecture into the assembly code though a= > >nd just running "as"=2C esp. on newer hosts. > > > > - Jay > > > > > >From: jay.krell at cornell.edu > >To: mika at async.caltech.edu=3B m3devel at elegosoft.com > >Date: Sun=2C 12 Dec 2010 00:59:18 +0000 > >Subject: Re: [M3devel] cm3 on snow leopard? > > > > > > > > > > > > > > > > > >I admit I'm still using Leopard. > > > > - Jay > > > > > > > >> To: m3devel at elegosoft.com > >> Date: Sat=2C 11 Dec 2010 14:19:02 -0800 > >> From: mika at async.caltech.edu > >> Subject: [M3devel] cm3 on snow leopard? > >>=20 > >> Hello m3devel=2C > >>=20 > >> I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook > >> Air=2C but it seems I have the wrong assembler? > >>=20 > >> I had to force dpkg to override the architecture on install (it was expec= > >ting > >> i386=2C I think=2C and my machine identified itself as being "i386-darwin= > >"?) > >>=20 > >> Here are some details... > >>=20 > >> [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version > >> Critical Mass Modula-3 version 5.8.6 > >> last updated: 2010-04-11 > >> compiled: 2010-07-14 21:27:23 > >> configuration: /usr/local/cm3/bin/cm3.cfg > >> host: I386_DARWIN > >> target: I386_DARWIN > >>=20 > >> compiling an empty Main.m3 yields: > >>=20 > >> [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands > >> --- building in ../I386_DARWIN --- > >>=20 > >> cd ../I386_DARWIN > >> rm .M3SHIP > >> rm .M3OVERRIDES > >> inhale prog.mx > >> inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a > >> inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a > >>=20 > >> new source -> compiling Main.m3 > >> m3front ../src/Main.m3 -w1 > >> /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno= > >-reorde > >> r-blocks Main.mc -o Main.ms > >> echo "rep movsl" | as -o /dev/null 2> /dev/null > >> as Main.ms -o Main.mo > >> Main.ms:15:suffix or operands invalid for `push' > >> assemble =3D> 1 > >> assembler failed assembling: Main.ms > >> rm Main.mo > >> exhale prog.mx > >> rm prog.manifest > >>=20 > >> compilation failed =3D> not building program "prog" > >> Fatal Error: package build failed > >>=20 > >> [HAL:~/test/src] mika% uname -a > >> Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39= > > PDT 2010=3B root:xnu-1504.9.17~1/RELEASE_I386 i386 > >> [HAL:~/test/src] mika% as -v > >> Apple Inc version cctools-782~33=2C GNU assembler version 1.38 > >>=20 > >>=20 > >> I have XCode installed. > >>=20 > >> [HAL:~/test/src] mika% gcc -v > >> Using built-in specs. > >> Target: i686-apple-darwin10 > >> Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checkin= > >g --enable-werror --prefix=3D/usr --mandir=3D/share/man --enable-languages= > >=3Dc=2Cobjc=2Cc++=2Cobj-c++ --program-transform-name=3D/^[cg][^.-]*$/s/$/-4= > >.2/ --with-slibdir=3D/usr/lib --build=3Di686-apple-darwin10 --program-prefi= > >x=3Di686-apple-darwin10- --host=3Dx86_64-apple-darwin10 --target=3Di686-app= > >le-darwin10 --with-gxx-include-dir=3D/include/c++/4.2.1 > >> Thread model: posix > >> gcc version 4.2.1 (Apple Inc. build 5664) > >> [HAL:~/test/src] mika% which gcc > >> /usr/bin/gcc > >>=20 > >>=20 > >> I must be doing something very obviously wrong (obviously to someone on t= > >his list=2C right??) > >>=20 > >> Mika > > = > > > >--_1377ed26-bb42-4722-b430-c9bf3b1b287d_ > >Content-Type: text/html; charset="Windows-1252" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >I'm more sympathetic to using the already installed C compiler
to drive = > >the assembler=2C than to build the current gcc driver.


You can s= > >ee on Darwin we already probe around fairly aggressively
for a C compile= > >r that can be told the target:

Darwin.common:


proc config= > >ure_c_compiler() is

 =3B if defined("SYSTEM_CC")
 =3B&nbs= > >p=3B =3B return
 =3B end

 =3B %
 =3B % older c= > >ompiler doesn't like -m32 or -arch
 =3B %
 =3B % gcc -c -m32 = > >-x c /dev/null
 =3B % cc1: error: invalid option =91m32=92
 = > >=3B %
 =3B % fPIC is not usually needed here.
 =3B % It is th= > >e default for Apple gcc and left
 =3B % here in case user is using a= > > self-built FSF gcc.
 =3B %

 =3B SYSTEM_CC =3D "gcc -gsta= > >bs+ -fPIC"
 =3B local m =3D " -m" &=3B {"32BITS":"32"=2C"64BITS":= > >"64"}{WORD_SIZE}
 =3B local arch =3D " -arch " &=3B DarwinArch >> =3B if not equal(try_exec("@" &=3B SYSTEM_CC &=3B m &=3B " -= > >c -x c /dev/null -o /dev/null 2>=3B&=3B1 | fgrep \"cc1: error: invalid= > > option \\\`32'\" >=3B/dev/null")=2C 0)
 =3B =3B =3B SYSTE= > >M_CC =3D SYSTEM_CC &=3B m
 =3B end
 =3B if not equal(try_e= > >xec("@" &=3B SYSTEM_CC &=3B arch &=3B " -c -x c /dev/null -o /dev/= > >null 2>=3B&=3B1 | fgrep \"cc1: error: unrecognized command line option= > > \\\\\"-arch\\\\\"\" >=3B/dev/null")=2C 0)
 =3B =3B =3B SY= > >STEM_CC =3D SYSTEM_CC &=3B arch
 =3B end
 =3B %write("SYST= > >EM_CC is " &=3B SYSTEM_CC)
end


Most likely if we merely se= > >t SYSTEM_ASM =3D SYSTEM_CC &=3B "-x assembler"
it'll work well.
Ma= > >ybe only in this else case:


proc configure_assembler() is
&nb= > >sp=3B if defined("SYSTEM_ASM")
 =3B =3B =3B return
 = > >=3B end
 =3B SYSTEM_ASM =3D "/usr/libexec/gcc/darwin/" &=3B Darwi= > >nArch &=3B "/as"
 =3B if not FileExists(SYSTEM_ASM)
 =3B&n= > >bsp=3B =3B =3B =3B SYSTEM_ASM =3D "as" <=3B<=3B=3D=3D here<= > >br> =3B end
end


All this is addressed by autoconf and/or = > >a C-generating backend.....


 =3B- Jay




>>
From: jay.krell at cornell.edu
To: mika at async.= > >caltech.edu=3B m3devel at elegosoft.com
Date: Sun=2C 12 Dec 2010 05:26:37 += > >0000
Subject: Re: [M3devel] cm3 on snow leopard?

> > > > >"> > > > > > > > > > >I'm rudely (but helpfully) ignoring your details and giving some of mine. >r>
I though what is supposed to happen=2C specifically on Darwin=2C is t= > >he assembly code is supposed to indicate an architecture.

jbook2:m3c= > >ore jay$ CM3_TARGET=3DI386_DARWIN M3CONFIG=3D/cm3/bin/config/I386_DARWIN cm= > >3 -keep
^C

jbook2:m3core jay$ CM3_TARGET=3DAMD64_DARWIN M3CONFIG= > >=3D/cm3/bin/config/AMD64_DARWIN cm3 -keep
^C

head */RTHooks.ms >>
but no.

But then this:

jbook2:m3core jay$ CM3_TARGET=3DA= > >MD64_DARWIN M3CONFIG=3D/cm3/bin/config/AMD64_DARWIN cm3 -keep -commands
= > >--- building in AMD64_DARWIN ---

..
/usr/libexec/gcc/darwin/x86_6= > >4/as RTAllocator.ms -o RTAllocator.mo

CM3_TARGET=3DI386_DARWIN M3CON= > >FIG=3D/cm3/bin/config/I386_DARWIN cm3 -keep -commands

...
/usr/li= > >bexec/gcc/darwin/i386/as Ctypes.is -o Ctypes.io

i386 vs. x86_64.
= > >
Darwin.common:
proc configure_assembler() is
 =3B if defined(= > >"SYSTEM_ASM")
 =3B =3B =3B return
 =3B end
 = > >=3B SYSTEM_ASM =3D "/usr/libexec/gcc/darwin/" &=3B DarwinArch &=3B "/= > >as"
 =3B if not FileExists(SYSTEM_ASM)
 =3B =3B =3B&n= > >bsp=3B =3B SYSTEM_ASM =3D "as"
 =3B end
end


jbook2= > >:m3core jay$ grep DarwinArch /dev2/cm3/m3-sys/cminstall/src/config-no-insta= > >ll/*
/dev2/cm3/m3-sys/cminstall/src/config-no-install/AMD64_DARWIN:Darwi= > >nArch =3D "x86_64"
/dev2/cm3/m3-sys/cminstall/src/config-no-install/ARM_= > >DARWIN:DarwinArch =3D "armv6" % ?
/dev2/cm3/m3-sys/cminstall/src/config-= > >no-install/Darwin.common: =3B SYSTEM_ASM =3D "/usr/libexec/gcc/darwin/"= > > &=3B DarwinArch &=3B "/as"
/dev2/cm3/m3-sys/cminstall/src/config-= > >no-install/Darwin.common: =3B local arch =3D " -arch " &=3B DarwinAr= > >ch
/dev2/cm3/m3-sys/cminstall/src/config-no-install/Darwin.common: = > >=3B =3B =3B =3B =3B arch =3D " -arch_only " &=3B DarwinA= > >rch &=3B " "
/dev2/cm3/m3-sys/cminstall/src/config-no-install/I386_DA= > >RWIN:DarwinArch =3D "i386"
/dev2/cm3/m3-sys/cminstall/src/config-no-inst= > >all/PPC64_DARWIN:DarwinArch =3D "ppc64"
/dev2/cm3/m3-sys/cminstall/src/c= > >onfig-no-install/PPC_DARWIN:DarwinArch =3D "ppc"

?
cm3 -commands?= > >

find /usr/lib | grep /as$
find /usr/libexec | grep /as$
> >
Maybe the path changed? Has a version? or is there is only i686-apple-d= > >arwin9=2C powerpc-apple-darwin9?

I should look into getting the arch= > >itecture into the assembly code though and just running "as"=2C esp. on new= > >er hosts.

 =3B- Jay


From: = > >jay.krell at cornell.edu
To: mika at async.caltech.edu=3B m3devel at elegosoft.co= > >m
Date: Sun=2C 12 Dec 2010 00:59:18 +0000
Subject: Re: [M3devel] cm3 = > >on snow leopard?

> > > > > > > > > > > > > >I admit I'm still using Leopard.

 =3B- Jay



>=3B= > > To: m3devel at elegosoft.com
>=3B Date: Sat=2C 11 Dec 2010 14:19:02 -080= > >0
>=3B From: mika at async.caltech.edu
>=3B Subject: [M3devel] cm3 o= > >n snow leopard?
>=3B
>=3B Hello m3devel=2C
>=3B
>=3B = > >I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook >r>>=3B Air=2C but it seems I have the wrong assembler?
>=3B
>= > >=3B I had to force dpkg to override the architecture on install (it was exp= > >ecting
>=3B i386=2C I think=2C and my machine identified itself as bei= > >ng "i386-darwin"?)
>=3B
>=3B Here are some details...
>=3B = > >
>=3B [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version
>=3B= > > Critical Mass Modula-3 version 5.8.6
>=3B last updated: 2010-04-11<= > >br>>=3B compiled: 2010-07-14 21:27:23
>=3B configuration: /usr/l= > >ocal/cm3/bin/cm3.cfg
>=3B host: I386_DARWIN
>=3B target: I386= > >_DARWIN
>=3B
>=3B compiling an empty Main.m3 yields:
>=3B <= > >br>>=3B [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands
= > >>=3B --- building in ../I386_DARWIN ---
>=3B
>=3B cd ../I386_D= > >ARWIN
>=3B rm .M3SHIP
>=3B rm .M3OVERRIDES
>=3B inhale prog.= > >mx
>=3B inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a
&g= > >t=3B inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a
>=3B
>= > >=3B new source ->=3B compiling Main.m3
>=3B m3front ../src/Main.m3 -= > >w1
>=3B /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 = > >-quiet -fno-reorde
>=3B r-blocks Main.mc -o Main.ms
>=3B echo "re= > >p movsl" | as -o /dev/null 2>=3B /dev/null
>=3B as Main.ms -o Main.m= > >o
>=3B Main.ms:15:suffix or operands invalid for `push'
>=3B as= > >semble =3D>=3B 1
>=3B assembler failed assembling: Main.ms
>=3B= > > rm Main.mo
>=3B exhale prog.mx
>=3B rm prog.manifest
>=3B <= > >br>>=3B compilation failed =3D>=3B not building program "prog"
>= > >=3B Fatal Error: package build failed
>=3B
>=3B [HAL:~/test/src]= > > mika% uname -a
>=3B Darwin HAL.local 10.5.0 Darwin Kernel Version 10.= > >5.0: Fri Nov 5 23:20:39 PDT 2010=3B root:xnu-1504.9.17~1/RELEASE_I386 i386= > >
>=3B [HAL:~/test/src] mika% as -v
>=3B Apple Inc version cctools= > >-782~33=2C GNU assembler version 1.38
>=3B
>=3B
>=3B I hav= > >e XCode installed.
>=3B
>=3B [HAL:~/test/src] mika% gcc -v
&g= > >t=3B Using built-in specs.
>=3B Target: i686-apple-darwin10
>=3B = > >Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking = > >--enable-werror --prefix=3D/usr --mandir=3D/share/man --enable-languages=3D= > >c=2Cobjc=2Cc++=2Cobj-c++ --program-transform-name=3D/^[cg][^.-]*$/s/$/-4.2/= > > --with-slibdir=3D/usr/lib --build=3Di686-apple-darwin10 --program-prefix= > >=3Di686-apple-darwin10- --host=3Dx86_64-apple-darwin10 --target=3Di686-appl= > >e-darwin10 --with-gxx-include-dir=3D/include/c++/4.2.1
>=3B Thread mod= > >el: posix
>=3B gcc version 4.2.1 (Apple Inc. build 5664)
>=3B [HA= > >L:~/test/src] mika% which gcc
>=3B /usr/bin/gcc
>=3B
>=3B <= > >br>>=3B I must be doing something very obviously wrong (obviously to some= > >one on this list=2C right??)
>=3B
>=3B Mika
> > = > > > >= > > > >--_1377ed26-bb42-4722-b430-c9bf3b1b287d_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sun Dec 12 21:14:58 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 12 Dec 2010 12:14:58 -0800 Subject: [M3devel] compiler problems on Snow Leopard Message-ID: <20101212201458.BEFA41A2079@async.async.caltech.edu> Hi everyone, Well I was able to get past all my linking issues (mostly questions of dynamic vs. static linking and how to do it, which seems to change from version to version...) But now I did hit a real problem. "../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** unaligned store type=6 s/o/a=32/0/32 "../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** unaligned load_indirect type=6 s/a=32/32 Here is the code, but it's not likely to be of much help... PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.T RAISES { Scheme.E } = BEGIN VAR res : SchemePair.T:=NIL; BEGIN res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),ToScheme_Atom_T(x.type)),res); res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modificationTime"),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),ToScheme_VAL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) RETURN res END END ToScheme_File_Status; ... PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0, LONGINT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = BEGIN RETURN ToScheme_LONGINT(x) (* line 981 *) END ToScheme_VAL0LONGINT__VAL16778080LONGINT; for reference, ToScheme_LONGINT is: PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISES { Scheme.E } = BEGIN WITH ref = NEW(REF LONGINT) DO ref^ := x; RETURN SchemeModula3Types.ToScheme_LONGINT(ref) END END ToScheme_LONGINT; Mika From hosking at cs.purdue.edu Sun Dec 12 21:19:15 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Dec 2010 15:19:15 -0500 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: <20101211221902.B71F81A207C@async.async.caltech.edu> References: <20101211221902.B71F81A207C@async.async.caltech.edu> Message-ID: My config file has: SYSTEM_ASM="as" ... return try_exec ("@" & SYSTEM_ASM, "-arch", "i386", "-q", source, "-o", object Works fine for me on Snow Leopard. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 11, 2010, at 5:19 PM, Mika Nystrom wrote: > Hello m3devel, > > I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook > Air, but it seems I have the wrong assembler? > > I had to force dpkg to override the architecture on install (it was expecting > i386, I think, and my machine identified itself as being "i386-darwin"?) > > Here are some details... > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-14 21:27:23 > configuration: /usr/local/cm3/bin/cm3.cfg > host: I386_DARWIN > target: I386_DARWIN > > compiling an empty Main.m3 yields: > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands > --- building in ../I386_DARWIN --- > > cd ../I386_DARWIN > rm .M3SHIP > rm .M3OVERRIDES > inhale prog.mx > inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a > inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a > > new source -> compiling Main.m3 > m3front ../src/Main.m3 -w1 > /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno-reorde > r-blocks Main.mc -o Main.ms > echo "rep movsl" | as -o /dev/null 2> /dev/null > as Main.ms -o Main.mo > Main.ms:15:suffix or operands invalid for `push' > assemble => 1 > assembler failed assembling: Main.ms > rm Main.mo > exhale prog.mx > rm prog.manifest > > compilation failed => not building program "prog" > Fatal Error: package build failed > > [HAL:~/test/src] mika% uname -a > Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 > [HAL:~/test/src] mika% as -v > Apple Inc version cctools-782~33, GNU assembler version 1.38 > > > I have XCode installed. > > [HAL:~/test/src] mika% gcc -v > Using built-in specs. > Target: i686-apple-darwin10 > Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 > Thread model: posix > gcc version 4.2.1 (Apple Inc. build 5664) > [HAL:~/test/src] mika% which gcc > /usr/bin/gcc > > > I must be doing something very obviously wrong (obviously to someone on this list, right??) > > Mika From hosking at cs.purdue.edu Sun Dec 12 21:20:20 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Dec 2010 15:20:20 -0500 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: <20101212093535.155ED1A207C@async.async.caltech.edu> References: <20101212093535.155ED1A207C@async.async.caltech.edu> Message-ID: <6545A943-6879-4B23-B3C4-17E5BDEB83C4@cs.purdue.edu> PS My "as" shows version: Apple Inc version cctools-782~37, GNU assembler version 1.38 Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 12, 2010, at 4:35 AM, Mika Nystrom wrote: > Thanks, Jay. > > I wasn't able to use your Darwin.config (remember, I'm installing > from the release .deb)---there seem to have been too many changes to > these files for me to be able to sort it all out. However, I figured > out how to do a "quick and dirty" from your email. > > This fixed it for me: > > if not defined("SYSTEM_ASM") > SYSTEM_ASM="/usr/libexec/gcc/darwin/i386/as" > end > > Now to check on all the other problems. > > Mika > > Jay K writes: >> --_1377ed26-bb42-4722-b430-c9bf3b1b287d_ >> Content-Type: text/plain; charset="Windows-1252" >> Content-Transfer-Encoding: quoted-printable >> >> >> I'm more sympathetic to using the already installed C compiler >> to drive the assembler=2C than to build the current gcc driver. >> >> >> You can see on Darwin we already probe around fairly aggressively >> for a C compiler that can be told the target: >> >> Darwin.common: >> >> >> proc configure_c_compiler() is >> >> if defined("SYSTEM_CC") >> return >> end >> >> % >> % older compiler doesn't like -m32 or -arch >> % >> % gcc -c -m32 -x c /dev/null >> % cc1: error: invalid option =91m32=92 >> % >> % fPIC is not usually needed here. >> % It is the default for Apple gcc and left >> % here in case user is using a self-built FSF gcc. >> % >> >> SYSTEM_CC =3D "gcc -gstabs+ -fPIC" >> local m =3D " -m" & {"32BITS":"32"=2C"64BITS":"64"}{WORD_SIZE} >> local arch =3D " -arch " & DarwinArch >> if not equal(try_exec("@" & SYSTEM_CC & m & " -c -x c /dev/null -o /dev/n= >> ull 2>&1 | fgrep \"cc1: error: invalid option \\\`32'\" >/dev/null")=2C 0) >> SYSTEM_CC =3D SYSTEM_CC & m >> end >> if not equal(try_exec("@" & SYSTEM_CC & arch & " -c -x c /dev/null -o /de= >> v/null 2>&1 | fgrep \"cc1: error: unrecognized command line option \\\\\"-a= >> rch\\\\\"\" >/dev/null")=2C 0) >> SYSTEM_CC =3D SYSTEM_CC & arch >> end >> %write("SYSTEM_CC is " & SYSTEM_CC) >> end >> > ... From hosking at cs.purdue.edu Sun Dec 12 21:25:13 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Dec 2010 15:25:13 -0500 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <20101212201458.BEFA41A2079@async.async.caltech.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu> Message-ID: <8A823CE8-A4A2-4280-8558-39D494F87160@cs.purdue.edu> That's an alignment problem alright. Perhaps the alignment information for VAL is wrong? Or for LONGINT? Jay, any ideas? On Dec 12, 2010, at 3:14 PM, Mika Nystrom wrote: > Hi everyone, > > Well I was able to get past all my linking issues (mostly questions > of dynamic vs. static linking and how to do it, which seems to change from > version to version...) > > But now I did hit a real problem. > > "../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** unaligned store type=6 s/o/a=32/0/32 > "../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** unaligned load_indirect type=6 s/a=32/32 > > Here is the code, but it's not likely to be of much help... > > PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.T RAISES { Scheme.E } = > BEGIN > VAR res : SchemePair.T:=NIL; BEGIN > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),ToScheme_Atom_T(x.type)),res); > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modificationTime"),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),ToScheme_VAL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) > RETURN res > END > END ToScheme_File_Status; > > > ... > > PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0, LONGINT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = > BEGIN > RETURN ToScheme_LONGINT(x) (* line 981 *) > END ToScheme_VAL0LONGINT__VAL16778080LONGINT; > > > for reference, ToScheme_LONGINT is: > > PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISES { Scheme.E } = > BEGIN > WITH ref = NEW(REF LONGINT) DO > ref^ := x; > RETURN SchemeModula3Types.ToScheme_LONGINT(ref) > END > END ToScheme_LONGINT; > > Mika From hosking at cs.purdue.edu Sun Dec 12 21:26:06 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 12 Dec 2010 15:26:06 -0500 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <20101212201458.BEFA41A2079@async.async.caltech.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu> Message-ID: <8E56EB70-2DF9-40F8-8842-0D782A46EC7B@cs.purdue.edu> Mika, Did this LONGINT code work previously? I'm trying to figure out when the problem was introduced. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 12, 2010, at 3:14 PM, Mika Nystrom wrote: > Hi everyone, > > Well I was able to get past all my linking issues (mostly questions > of dynamic vs. static linking and how to do it, which seems to change from > version to version...) > > But now I did hit a real problem. > > "../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** unaligned store type=6 s/o/a=32/0/32 > "../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** unaligned load_indirect type=6 s/a=32/32 > > Here is the code, but it's not likely to be of much help... > > PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.T RAISES { Scheme.E } = > BEGIN > VAR res : SchemePair.T:=NIL; BEGIN > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),ToScheme_Atom_T(x.type)),res); > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modificationTime"),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),ToScheme_VAL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) > RETURN res > END > END ToScheme_File_Status; > > > ... > > PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0, LONGINT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = > BEGIN > RETURN ToScheme_LONGINT(x) (* line 981 *) > END ToScheme_VAL0LONGINT__VAL16778080LONGINT; > > > for reference, ToScheme_LONGINT is: > > PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISES { Scheme.E } = > BEGIN > WITH ref = NEW(REF LONGINT) DO > ref^ := x; > RETURN SchemeModula3Types.ToScheme_LONGINT(ref) > END > END ToScheme_LONGINT; > > Mika From mika at async.caltech.edu Sun Dec 12 21:49:02 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Sun, 12 Dec 2010 12:49:02 -0800 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <8E56EB70-2DF9-40F8-8842-0D782A46EC7B@cs.purdue.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu> <8E56EB70-2DF9-40F8-8842-0D782A46EC7B@cs.purdue.edu> Message-ID: <20101212204902.D68291A2079@async.async.caltech.edu> Tony, It's been a long, long time since I last compiled anything on I386_DARWIN, so I'm not sure. It did/does work on AMD64_LINUX and _FREEBSD, as far as I know. Mika Tony Hosking writes: >Mika, > >Did this LONGINT code work previously? I'm trying to figure out when = >the problem was introduced. > >Antony Hosking | Associate Professor | Computer Science | Purdue = >University >305 N. University Street | West Lafayette | IN 47907 | USA >Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > >On Dec 12, 2010, at 3:14 PM, Mika Nystrom wrote: > >> Hi everyone, >>=20 >> Well I was able to get past all my linking issues (mostly questions >> of dynamic vs. static linking and how to do it, which seems to change = >from >> version to version...) >>=20 >> But now I did hit a real problem. >>=20 >> "../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** = >unaligned store type=3D6 s/o/a=3D32/0/32 >> "../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** = >unaligned load_indirect type=3D6 s/a=3D32/32 >>=20 >> Here is the code, but it's not likely to be of much help... >>=20 >> PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : = >SchemeObject.T RAISES { Scheme.E } =3D >> BEGIN >> VAR res : SchemePair.T:=3DNIL; BEGIN >> res :=3D = >SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),ToScheme_A= >tom_T(x.type)),res); >> res :=3D = >SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modificationTime"= >),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); >> res :=3D = >SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),ToScheme_V= >AL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) >> RETURN res >> END >> END ToScheme_File_Status; >>=20 >>=20 >> ... >>=20 >> PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ = >VAL(0, LONGINT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { = >Scheme.E } =3D >> BEGIN >> RETURN ToScheme_LONGINT(x) (* line 981 *) >> END ToScheme_VAL0LONGINT__VAL16778080LONGINT; >>=20 >>=20 >> for reference, ToScheme_LONGINT is: >>=20 >> PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T = >RAISES { Scheme.E } =3D >> BEGIN >> WITH ref =3D NEW(REF LONGINT) DO >> ref^ :=3D x; >> RETURN SchemeModula3Types.ToScheme_LONGINT(ref) >> END >> END ToScheme_LONGINT; >>=20 >> Mika From jay.krell at cornell.edu Mon Dec 13 09:23:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Dec 2010 08:23:31 +0000 Subject: [M3devel] cm3 on snow leopard? In-Reply-To: References: <20101211221902.B71F81A207C@async.async.caltech.edu>, Message-ID: Do all Darwin/x86 assemblers accept -arch flag? I don't know. e.g. 10.4? I might bring such a system back online.... Do all Darwin assemblers accept -arch? I doubt it. - Jay > From: hosking at cs.purdue.edu > Date: Sun, 12 Dec 2010 15:19:15 -0500 > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] cm3 on snow leopard? > > My config file has: > > SYSTEM_ASM="as" > ... > return try_exec ("@" & SYSTEM_ASM, "-arch", "i386", "-q", source, "-o", object > > Works fine for me on Snow Leopard. > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Office +1 765 494 6001 | Mobile +1 765 427 5484 > > > > > On Dec 11, 2010, at 5:19 PM, Mika Nystrom wrote: > > > Hello m3devel, > > > > I just tried to install CM3 from cm3-I386_DARWIN-REL.deb on a new MacBook > > Air, but it seems I have the wrong assembler? > > > > I had to force dpkg to override the architecture on install (it was expecting > > i386, I think, and my machine identified itself as being "i386-darwin"?) > > > > Here are some details... > > > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -version > > Critical Mass Modula-3 version 5.8.6 > > last updated: 2010-04-11 > > compiled: 2010-07-14 21:27:23 > > configuration: /usr/local/cm3/bin/cm3.cfg > > host: I386_DARWIN > > target: I386_DARWIN > > > > compiling an empty Main.m3 yields: > > > > [HAL:~/test/src] mika% /usr/local/cm3/bin/cm3 -keep -commands > > --- building in ../I386_DARWIN --- > > > > cd ../I386_DARWIN > > rm .M3SHIP > > rm .M3OVERRIDES > > inhale prog.mx > > inhale /usr/local/cm3/pkg/m3core/I386_DARWIN/libm3core.a > > inhale /usr/local/cm3/pkg/libm3/I386_DARWIN/libm3.a > > > > new source -> compiling Main.m3 > > m3front ../src/Main.m3 -w1 > > /usr/local/cm3//bin/cm3cg -funwind-tables -fPIC -gstabs+ -m32 -quiet -fno-reorde > > r-blocks Main.mc -o Main.ms > > echo "rep movsl" | as -o /dev/null 2> /dev/null > > as Main.ms -o Main.mo > > Main.ms:15:suffix or operands invalid for `push' > > assemble => 1 > > assembler failed assembling: Main.ms > > rm Main.mo > > exhale prog.mx > > rm prog.manifest > > > > compilation failed => not building program "prog" > > Fatal Error: package build failed > > > > [HAL:~/test/src] mika% uname -a > > Darwin HAL.local 10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 > > [HAL:~/test/src] mika% as -v > > Apple Inc version cctools-782~33, GNU assembler version 1.38 > > > > > > I have XCode installed. > > > > [HAL:~/test/src] mika% gcc -v > > Using built-in specs. > > Target: i686-apple-darwin10 > > Configured with: /var/tmp/gcc/gcc-5664~89/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 > > Thread model: posix > > gcc version 4.2.1 (Apple Inc. build 5664) > > [HAL:~/test/src] mika% which gcc > > /usr/bin/gcc > > > > > > I must be doing something very obviously wrong (obviously to someone on this list, right??) > > > > Mika > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 13 09:49:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Dec 2010 08:49:21 +0000 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <8A823CE8-A4A2-4280-8558-39D494F87160@cs.purdue.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, <8A823CE8-A4A2-4280-8558-39D494F87160@cs.purdue.edu> Message-ID: Head looks much better than release here. I'm not "just" saying that. release has stuff like m3front/src/misc/CG.m3: ELSIF (t = Target.Word.cg_type) OR (t = Target.Integer.cg_type) THEN ... ELSE Err("unaligned..." where head has: ELSIF (t = Target.Word.cg_type) OR (t = Target.Integer.cg_type) OR (t = Target.Long.cg_type) OR (t = Target.Longint.cg_type) THEN ... ELSE Err("unaligned..." several instances. Please try head. - Jay > From: hosking at cs.purdue.edu > Date: Sun, 12 Dec 2010 15:25:13 -0500 > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] compiler problems on Snow Leopard > > That's an alignment problem alright. Perhaps the alignment information for VAL is wrong? Or for LONGINT? Jay, any ideas? > > On Dec 12, 2010, at 3:14 PM, Mika Nystrom wrote: > > > Hi everyone, > > > > Well I was able to get past all my linking issues (mostly questions > > of dynamic vs. static linking and how to do it, which seems to change from > > version to version...) > > > > But now I did hit a real problem. > > > > "../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** unaligned store type=6 s/o/a=32/0/32 > > "../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** unaligned load_indirect type=6 s/a=32/32 > > > > Here is the code, but it's not likely to be of much help... > > > > PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.T RAISES { Scheme.E } = > > BEGIN > > VAR res : SchemePair.T:=NIL; BEGIN > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),ToScheme_Atom_T(x.type)),res); > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modificationTime"),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),ToScheme_VAL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) > > RETURN res > > END > > END ToScheme_File_Status; > > > > > > ... > > > > PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0, LONGINT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = > > BEGIN > > RETURN ToScheme_LONGINT(x) (* line 981 *) > > END ToScheme_VAL0LONGINT__VAL16778080LONGINT; > > > > > > for reference, ToScheme_LONGINT is: > > > > PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISES { Scheme.E } = > > BEGIN > > WITH ref = NEW(REF LONGINT) DO > > ref^ := x; > > RETURN SchemeModula3Types.ToScheme_LONGINT(ref) > > END > > END ToScheme_LONGINT; > > > > Mika > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 13 23:32:41 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Dec 2010 22:32:41 +0000 Subject: [M3devel] hardware woes (sort of).. Message-ID: Oops. Anyone in USA want an Itanium, no strings attached (but some suggested)? eBay item 290507974646 http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rt=nc&nma=true&item=290507974646 Thanks, - Jay From mika at async.caltech.edu Mon Dec 13 23:40:56 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 13 Dec 2010 14:40:56 -0800 Subject: [M3devel] file descriptor confusion? Message-ID: <20101213224056.18B341A2078@async.async.caltech.edu> Hi m3devel, Still fiddling with I386_DARWIN. I've been able to get everything that I need compiling with the release compiler so I haven't upgraded to the head yet. I'm trying hard to get a new product ready and am already behind, was hoping I could debug my own code on this new laptop... Maybe soon (actually I have already found a bug in my own code under the compiler so I shouldn't complain). But I've run into a mystery that I think may be due to some change in CM3, but it might also be a bug of mine, so please just let me know if there *might* have been some changes that could have had the following effect. My code uses a pretty elaborate debugging framework with a "Debug" module that prints debug messages and conditionally can turn on and off various input streams (types of debug messages) and output streams (targets: terminal, files, etc.) I have a program that connects over TCP to a server, using Wr and Rd on ConnFD.T, TCP.T, and such objects. I am now finding that my debug output is going to the server! It's supposed to be a completely separate stream. It looks like the file descriptors have gotten confused. Maybe. Does this ring a bell for anyone? Sometime in the last year I would guess. Code works perfectly under PM3 (as always). If it does ring a bell anywhere, what are the chances it's different in the head? Mika From jay.krell at cornell.edu Mon Dec 13 23:52:35 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 13 Dec 2010 22:52:35 +0000 Subject: [M3devel] file descriptor confusion? In-Reply-To: <20101213224056.18B341A2078@async.async.caltech.edu> References: <20101213224056.18B341A2078@async.async.caltech.edu> Message-ID: Maybe some detail of fork? Does problem occur on other systems? Are you interfacing with C at all, besides what m3core/libm3 does for you? - Jay ---------------------------------------- > To: m3devel at elegosoft.com > Date: Mon, 13 Dec 2010 14:40:56 -0800 > From: mika at async.caltech.edu > Subject: [M3devel] file descriptor confusion? > > Hi m3devel, > > Still fiddling with I386_DARWIN. > > I've been able to get everything that I need compiling with the release > compiler so I haven't upgraded to the head yet. I'm trying hard to > get a new product ready and am already behind, was hoping I could debug > my own code on this new laptop... Maybe soon (actually I have already > found a bug in my own code under the compiler so I shouldn't complain). > > But I've run into a mystery that I think may be due to some change in CM3, > but it might also be a bug of mine, so please just let me know if there > *might* have been some changes that could have had the following effect. > > My code uses a pretty elaborate debugging framework with a "Debug" > module that prints debug messages and conditionally can turn on and > off various input streams (types of debug messages) and output streams > (targets: terminal, files, etc.) > > I have a program that connects over TCP to a server, using Wr and Rd on > ConnFD.T, TCP.T, and such objects. I am now finding that my debug > output is going to the server! It's supposed to be a completely separate > stream. It looks like the file descriptors have gotten confused. Maybe. > > Does this ring a bell for anyone? Sometime in the last year I would guess. > Code works perfectly under PM3 (as always). If it does ring a bell > anywhere, what are the chances it's different in the head? > > Mika From wagner at elegosoft.com Tue Dec 14 11:03:08 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Tue, 14 Dec 2010 11:03:08 +0100 Subject: [M3devel] file descriptor confusion? In-Reply-To: <20101213224056.18B341A2078@async.async.caltech.edu> References: <20101213224056.18B341A2078@async.async.caltech.edu> Message-ID: <20101214110308.5q5cl8v484o8844g@mail.elegosoft.com> Quoting Mika Nystrom : > Hi m3devel, > > Still fiddling with I386_DARWIN. > > I've been able to get everything that I need compiling with the release > compiler so I haven't upgraded to the head yet. I'm trying hard to > get a new product ready and am already behind, was hoping I could debug > my own code on this new laptop... Maybe soon (actually I have already > found a bug in my own code under the compiler so I shouldn't complain). > > But I've run into a mystery that I think may be due to some change in CM3, > but it might also be a bug of mine, so please just let me know if there > *might* have been some changes that could have had the following effect. > > My code uses a pretty elaborate debugging framework with a "Debug" > module that prints debug messages and conditionally can turn on and > off various input streams (types of debug messages) and output streams > (targets: terminal, files, etc.) > > I have a program that connects over TCP to a server, using Wr and Rd on > ConnFD.T, TCP.T, and such objects. I am now finding that my debug > output is going to the server! It's supposed to be a completely separate > stream. It looks like the file descriptors have gotten confused. Maybe. > > Does this ring a bell for anyone? Sometime in the last year I would guess. > Code works perfectly under PM3 (as always). If it does ring a bell > anywhere, what are the chances it's different in the head? I think the main differences that one should look at are these two: o CM3 now uses a different threading implementation on most platforms (operating system (p)threads), and not self-implemented user threads any more. o Process.Create has been changed in order to cope with the change above, IIRC. All user threads used to be duplicated by fork, whereas the pthreads now need to be restarted in the child process. Please correct me if I remember this wrong, Jay. There's nothing more specific I can think of though that would explain the behaviour. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Wed Dec 15 23:37:33 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 15 Dec 2010 22:37:33 +0000 Subject: [M3devel] bit field operations for insert/extract In-Reply-To: References: , , <4FC6CE6F-FE19-461E-ACCC-41D6762CA3BC@cs.purdue.edu>, , , , , , Message-ID: I'm a bit nervous, like, that the semantics are the same esp. at the edge or past-the-edge cases -- extracting 0, 1, 31, 32, 33 bits, etc. I guess testing should show one way or the other -- assuming there aren't "undefined" things in gcc that vary per target (not sure if I have the patience or not to look at all the assembly for all the targets for all of the particular test case where I combinatorially generate everything, I probably should bite that bullet though, maybe split it into 4 easier to digest cases (32bit, 64bit, big endian, little endian). - Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > CC: m3devel at elegosoft.com > Subject: RE: [M3devel] bit field operations for insert/extract > Date: Tue, 23 Nov 2010 22:53:25 +0000 > > > Fair enough, easy enough. > I'd want to double check that the existing use is wanting that interpretation. > > > Obviously for that matter, we can leave the code asis for big endian. > And just take your code as it was, but under if (target_is_little_endian). > Big endian is the minority anyway. > :) > (no, I won't do that) > > > It would be cool if the frontend never checked target endianness. > It does it very little as it is. But ok either way. > (I want to move the Target.m3 stuff to the config files -- endianness, > setjmp name, jmpbuf size/align, etc., though that's about all that is left) > > > > - Jay > > > ---------------------------------------- > > From: hosking at cs.purdue.edu > > Date: Tue, 23 Nov 2010 17:46:06 -0500 > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: [M3devel] bit field operations for insert/extract > > > > If that's the case then I would argue for adjusting the offset accordingly in parse.c. > > extract_mn and insert_mn are defined as equivalent to Word.Extract/Word.Insert, respectively. > > > > On Nov 23, 2010, at 4:46 PM, Jay K wrote: > > > > > > > > Let me clarify. > > > Remember when you used bit field operations for extract_mn? > > > And they didn't work on any big endian system? > > > And I had to undo it? With your approval. > > > > > > > > > I believe the way to go: > > > the change you did in parse.c; it was correct, highly likely > > > removing those endian checks in m3front, which you didn't do at the time > > > > > > > > > Removing the endian checks will only affect big endian. > > > The code reads something like: > > > if little_endian extract_mn(offset, count) > > > else extract_mn(size - offset, size - count) > > > > > > > > > So just change it to: > > > extract_mn(offset, count) > > > > > > > > > And I strongly suspect it will affect it "in the right way". > > > But I'm going to try diffing assembly before/after to be sure. > > > And then watch the sparc and ppc hudson builds. :) > > > (and fix PPC_DARWIN beforehand as well) > > > > > > > > > > > > This is perhaps an interface change in m3cg, but there are no other big endian backends > > > and there are no other uses of extract_mn in the frontend, I think. > > > i.e. the meaning of extract_mn will have been changed to match gcc's interpretation, which it already did for little endian. Either that, or very reasonably in gcc we can check what the target endian is and adjust the count/offset. Either way. But one way involves target-specifieity in two places, the other zero. I like removing target-specificity. Though it is probably kind of implied in the next layer down, in gcc. > > > > > > > > > Anyway, still speculation at this point. > > > But this is pretty high on my list, low hanging fruit granted, probably no affect in the optimized code or perhaps unoptimized code, but I do like the idea to keep parse.c "thin" here if possible. > > > (ie: if this goes well, the next thing to look at is rotate, however in all of these bit operations, > > > I do worry that our definition of count/offset = 0, = type_precision, > type_precision may not match the gcc backend; > > > perhaps it is best to just leave everything asis...?) > > > > > > > > > and then I'll try to focus again on the type stuff, which is currently disabled because there was some problem, and then I decided I needed multiple passes, so I needed an in-memory form besides locals, so I wanted structs, declaratively declared (!) and depersisted, so I wanted C++, so I spent a week fixing that, oops...and there was also an m3cg/ir change which we found Hudson wasn't dealing with properly...and then configure enable-checking which I also have wanted...[i.e. I think have good excuses lately!] > > > > > > > > > (and then the later part of the type stuff is array/component_refs, and *then* enabling all optimizations, *including* not taking the address of so many things....(we're actually pretty good now and only disable one optimization, but taking the address probably is still a big downer)) > > > > > > > > > - Jay > > > > > > > > > ________________________________ > > >> Subject: Re: [M3devel] bit field operations for insert/extract > > >> From: hosking at cs.purdue.edu > > >> Date: Tue, 23 Nov 2010 16:34:25 -0500 > > >> CC: m3devel at elegosoft.com > > >> To: jay.krell at cornell.edu > > >> > > >> Are they wrong? Seems strange that they worked previously! > > >> > > >> On Nov 23, 2010, at 1:46 PM, Jay K wrote: > > >> > > >> None yet. But notice the endian checks around the insert_mn or > > >> extract_mn uses in cg.m3. > > >> The change would be to remove those. > > >> > > >> - Jay > > >> > > >> > > >> ________________________________ > > >> Subject: Re: [M3devel] bit field operations for insert/extract > > >> From: hosking at cs.purdue.edu > > >> Date: Tue, 23 Nov 2010 09:37:00 -0500 > > >> CC: m3devel at elegosoft.com > > >> To: jay.krell at cornell.edu > > >> > > >> Refresh my memory. What m3front change did you make? > > >> > > >> > > >> On Nov 23, 2010, at 3:33 AM, Jay K wrote: > > >> > > >> Tony, I'm going to try again to use bitfield operations for extract_mn. > > >> And insert_mn. > > >> I think I know what went wrong before for extract_mn: just remove the > > >> endian check in m3front. > > >> But I'm going to be sure test p240 covers it well. > > >> > > >> The easy part, duh, your original extract_mn was correct I think, just, > > >> again, missing the m3front change. > > >> > > >> Insert_mn is less obvious. > > >> I started writing it... bitfield_ref..modify_expr...uh, seems > > >> suspicious, to be modifying an existing value. > > >> > > >> I guess it's more like, that, but with a temp that starts with the full > > >> value of x: > > >> create temp > > >> modify(temp, x) > > >> modify(bitfield_ref(temp, count, offset), y); > > >> m3_load(temp) > > >> > > >> ? > > >> > > >> I'll try something like that. > > >> It seems unfortunate. > > >> Maybe we can know if x is already a value and not a variable? > > >> > > >> > > >> - Jay > > >> > > >> > > >> > > From dragisha at m3w.org Fri Dec 17 10:25:32 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Fri, 17 Dec 2010 10:25:32 +0100 Subject: [M3devel] swig Message-ID: Hi, GNU Modula-2 has this: http://www.nongnu.org/gm2/gm2.html#SEC23, and it's probably interesting for us too. Fancy approach there - instead of including a language parser into SWIG proper, a compiler emits .i files. SWIG is then used to process it to "client" platforms. d From jay.krell at cornell.edu Sat Dec 18 11:43:46 2010 From: jay.krell at cornell.edu (Jay) Date: Sat, 18 Dec 2010 02:43:46 -0800 Subject: [M3devel] TCardinal Message-ID: > CARDINAL is only ever used for values that should be in range on all > architectures. really? - Jay From hosking at cs.purdue.edu Sat Dec 18 16:45:42 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sat, 18 Dec 2010 10:45:42 -0500 Subject: [M3devel] TCardinal In-Reply-To: References: Message-ID: <8530EEC4-872F-490B-94BB-3254834593B6@cs.purdue.edu> Yep. As far as I can tell. On Dec 18, 2010, at 5:43 AM, Jay wrote: >> CARDINAL is only ever used for values that should be in range on all >> architectures. > > really? > > - Jay From mika at async.caltech.edu Mon Dec 20 13:43:13 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 20 Dec 2010 04:43:13 -0800 Subject: [M3devel] swig In-Reply-To: References: Message-ID: <20101220124313.E25011A2061@async.async.caltech.edu> =?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?= writes: >Hi, > >GNU Modula-2 has this: http://www.nongnu.org/gm2/gm2.html#SEC23, and = >it's probably interesting for us too. Fancy approach there - instead of = >including a language parser into SWIG proper, a compiler emits .i files. = >SWIG is then used to process it to "client" platforms. > >d One could also use m3tk for this. That's the approach I take for my Scheme environment, which I in principle have no objections to releasing, but haven't had the time to clean up properly.. (like so many other things). Of course since my Scheme interpreter is written in Modula-3, my code is (in principle) independent of implementation decisions in the Modula-3 compiler. (The code that the compiler sees is pure Modula-3.) Mika From dragisha at m3w.org Thu Dec 23 17:12:44 2010 From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 23 Dec 2010 17:12:44 +0100 Subject: [M3devel] still alive? Message-ID: <1293120764.8612.1.camel@boromir.m3w.org> Holiday season started already? -- Dragi?a Duri? From dabenavidesd at yahoo.es Fri Dec 24 15:13:38 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Fri, 24 Dec 2010 14:13:38 +0000 (GMT) Subject: [M3devel] still alive? In-Reply-To: <1293120764.8612.1.camel@boromir.m3w.org> Message-ID: <441851.14864.qm@web29708.mail.ird.yahoo.com> Hi all: I hope you had started, merry Christmas and let's wait this thing has very interesting things for us: https://groups.google.com/group/comp.std.c++/tree/browse_frm/month/1994-03/3dbb4bad549f75d4?rnum=51&_done=/group/comp.std.c%2B%2B/browse_frm/month/1994-03?&hl=pt&pli=1 check for the post for he third message: There is someone who was the mentioned OS sources, he was wondering in there what would mean CAMEL (the Application Manager at some time in that not commercialized project told me that it might be Compiler for Acorn Modula-2 Extended Language), it seems those guys there liked a lot to use exceptions, but the Application Manager said that there were in Xerox/Alto machines program crashes a lot times with run-time message uncaught exception. Hope it helps to awareness of this things --- El jue, 23/12/10, Dragi?a Duri? escribi?: > De: Dragi?a Duri? > Asunto: [M3devel] still alive? > Para: "m3devel" > Fecha: jueves, 23 de diciembre, 2010 11:12 > Holiday season started already? > -- > Dragi?a Duri? > > From dragisha at m3w.org Sat Dec 25 22:22:34 2010 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Sat, 25 Dec 2010 22:22:34 +0100 Subject: [M3devel] Out-of-place error? Message-ID: I am getting this message *** *** runtime error: *** An enumeration or subrange value was out of range. *** file "../src/types/XLTypeList.m3", line 235 *** And code is: 235 RETURN RefSeq.Sub(o1, from-1, XLTypeNumber.FromInt(range.get(1))); In this environment (just to get an idea): IF range.get(1) = NIL THEN RETURN RefSeq.Sub(o1, from-1); ELSE RETURN RefSeq.Sub(o1, from-1, XLTypeNumber.FromInt(range.get(1))); END; Same crash, same line :), happened when I inserted <* DEBUG range.get(1) *> before RETURN statement in ELSE branch.. Why this happens? TIA, dd p.s. Merry Christmass, of course :) From jay.krell at cornell.edu Sun Dec 26 00:41:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Sat, 25 Dec 2010 23:41:28 +0000 Subject: [M3devel] Out-of-place error? In-Reply-To: References: Message-ID: I don't understand the question. > From: dragisha at m3w.org > Date: Sat, 25 Dec 2010 22:22:34 +0100 > To: m3devel at elegosoft.com > Subject: [M3devel] Out-of-place error? > > I am getting this message > > *** > *** runtime error: > *** An enumeration or subrange value was out of range. > *** file "../src/types/XLTypeList.m3", line 235 > *** > > And code is: > 235 RETURN RefSeq.Sub(o1, from-1, XLTypeNumber.FromInt(range.get(1))); > > In this environment (just to get an idea): > IF range.get(1) = NIL THEN > RETURN RefSeq.Sub(o1, from-1); > ELSE > RETURN RefSeq.Sub(o1, from-1, XLTypeNumber.FromInt(range.get(1))); > END; > > Same crash, same line :), happened when I inserted > <* DEBUG range.get(1) *> > > before RETURN statement in ELSE branch.. > > Why this happens? > > TIA, > dd > > p.s. Merry Christmass, of course :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 26 11:02:12 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Dec 2010 10:02:12 +0000 Subject: [M3devel] assertion failure in compiler Message-ID: MODULE bug1; PROCEDURE F1()= CONST a=ARRAY OF INTEGER{0}; VAR b := SUBARRAY(0,1,a); BEGIN END F1; BEGIN END bug1. new source -> compiling bug1.m3 "../src/bug1.m3", line 5: SUBARRAY: first argument must be an array *** *** runtime error: *** <*ASSERT*> failed. *** file "../src/exprs/Expr.m3", line 337 *** -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Dec 26 11:28:40 2010 From: jay.krell at cornell.edu (Jay K) Date: Sun, 26 Dec 2010 10:28:40 +0000 Subject: [M3devel] offsetof, et. al? Message-ID: construction various data? So, I have this C: typedef struct _enum_t { const char* name; uint64_t value; } enum_t; typedef struct _field_t { char name[16]; uchar offset; uchar size; uchar element_size; uchar str; uchar macho_string; uchar enum_table_count; const enum_t* enum_table; } field_t; #define FIELD(t, f) {STRINGIZE(f), offsetof(t, f), sizeof((((t*)0)->f))} #define FIELD_ARRAY(t, f) {STRINGIZE(f), offsetof(t, f), sizeof((((t*)0)->f)), sizeof((((t*)0)->f)[0]) } #define FIELD_STRING(t, f) {STRINGIZE(f), offsetof(t, f), sizeof((((t*)0)->f)), sizeof((((t*)0)->f)[0]), 1 } #define FIELD_ENUM(t, f, e) {STRINGIZE(f), offsetof(t, f), sizeof((((t*)0)->f)), 0, 0, 0, sizeof(e)/sizeof((e)[0]), e } #define FIELD_MACHO_STRING(t, f) {STRINGIZE(f), offsetof(t, f), sizeof((((t*)0)->f)), 0, 0, 1 } typedef struct _struct_t { const char* name; uint size; uint nfields; const field_t* fields; int widest_field; } struct_t; #define STRUCT(a) {STRINGIZE(a), sizeof(a), NUMBER_OF(PASTE(a,_fields)), PASTE(a,_fields)} extern_const enum_t macho_magic_names[] = { { "magic32", macho_magic32 }, { "magic64", macho_magic64 } }; extern_const enum_t macho_cputype_names[] = { { "x86", macho_cpu_type_x86 }, { "amd64", macho_cpu_type_amd64 }, { "powerpc", macho_cpu_type_powerpc }, { "powerpc64", macho_cpu_type_powerpc64 } }; extern_const enum_t macho_cpusubtype_names[] = { { "powerpc_all", macho_cpu_subtype_powerpc_all }, { "x86_all", macho_cpu_subtype_x86_all } }; extern_const enum_t macho_filetype_names[] = { { "object", macho_type_object }, { "execute", macho_type_execute }, { "fixed_vm_library", macho_type_fixed_vm_library }, { "core", macho_type_core }, { "preload", macho_type_preload }, { "dylib", macho_type_dylib }, { "dylinker", macho_type_dylinker }, { "bundle", macho_type_bundle }, { "dylib_stub", macho_type_dylib_stub }, { "dsym", macho_type_dsym } }; extern_const field_t macho_header32_t_fields[] = { FIELD_ENUM(macho_header32_t, magic, macho_magic_names), FIELD_ENUM(macho_header32_t, cputype, macho_cputype_names), FIELD_ENUM(macho_header32_t, cpusubtype, macho_cpusubtype_names), FIELD_ENUM(macho_header32_t, filetype, macho_filetype_names), FIELD(macho_header32_t, ncmds), FIELD(macho_header32_t, sizeofcmds), FIELD(macho_header32_t, flags) }; how do I "best" convert this to Modula-3? I don't see a good analog to offsetof. I don't see a good analog of variably sized non-copying arrays, esp. constants. I have something kind of close, but I have to use VAR in places instead of CONST, and I have to make copies of the arrays, and I have to compute the offsets/sizes myself, which isn't difficult. I understand that using offset of is necesssarily unsafe. What I have, C and Modula-3, is checked in, in scratch/macho. Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 26 21:15:37 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Dec 2010 15:15:37 -0500 Subject: [M3devel] Out-of-place error? In-Reply-To: References: Message-ID: <00F41A55-5306-4C7D-8E7C-1BE206AAF47C@cs.purdue.edu> Weird. What does the signature of range.get look like? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 25, 2010, at 6:41 PM, Jay K wrote: > I don't understand the question. > > > From: dragisha at m3w.org > > Date: Sat, 25 Dec 2010 22:22:34 +0100 > > To: m3devel at elegosoft.com > > Subject: [M3devel] Out-of-place error? > > > > I am getting this message > > > > *** > > *** runtime error: > > *** An enumeration or subrange value was out of range. > > *** file "../src/types/XLTypeList.m3", line 235 > > *** > > > > And code is: > > 235 RETURN RefSeq.Sub(o1, from-1, XLTypeNumber.FromInt(range.get(1))); > > > > In this environment (just to get an idea): > > IF range.get(1) = NIL THEN > > RETURN RefSeq.Sub(o1, from-1); > > ELSE > > RETURN RefSeq.Sub(o1, from-1, XLTypeNumber.FromInt(range.get(1))); > > END; > > > > Same crash, same line :), happened when I inserted > > <* DEBUG range.get(1) *> > > > > before RETURN statement in ELSE branch.. > > > > Why this happens? > > > > TIA, > > dd > > > > p.s. Merry Christmass, of course :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Sun Dec 26 21:25:42 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Sun, 26 Dec 2010 15:25:42 -0500 Subject: [M3devel] assertion failure in compiler In-Reply-To: References: Message-ID: I think this is a known bug, related to one we already have a testcase for. On Dec 26, 2010, at 5:02 AM, Jay K wrote: > MODULE bug1; > > PROCEDURE F1()= > CONST a=ARRAY OF INTEGER{0}; > VAR b := SUBARRAY(0,1,a); > BEGIN > END F1; > > BEGIN > END bug1. > > > new source -> compiling bug1.m3 > "../src/bug1.m3", line 5: SUBARRAY: first argument must be an array > > > *** > *** runtime error: > *** <*ASSERT*> failed. > *** file "../src/exprs/Expr.m3", line 337 > *** > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 27 03:11:28 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 02:11:28 +0000 Subject: [M3devel] pointers/arrays? Message-ID: a: UNTRACED REF T; i: INTEGER; a[i] ? (a + i)^ ? Or I'm really stuck with LOOPEHOLE(a + i * BYTESIZE(a^), UNTRACED REF T) Seems kind of stinky. I've got some nice efficient readable safe-enough C and it doesn't seem to translate well easily efficiently to Modula-3. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 27 05:37:07 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 04:37:07 +0000 Subject: [M3devel] pointers/arrays? In-Reply-To: References: Message-ID: I'm still wrestling with this. I have found a few options that work and they all have glaring problems. VAR macho_header32_t_fields := ARRAY [0..6] OF field_t{ field_t{ "magic", 0, 4, enum_table := EnumTable(macho_magic_names)}, ... field_t{ "flags", 24, 4}}; 1) I shouldn't have to give the size of the array. 2) I shouldn't have to copy the enum table to make it an indexable array. Disappointing.. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Mon, 27 Dec 2010 02:11:28 +0000 Subject: [M3devel] pointers/arrays? a: UNTRACED REF T; i: INTEGER; a[i] ? (a + i)^ ? Or I'm really stuck with LOOPEHOLE(a + i * BYTESIZE(a^), UNTRACED REF T) Seems kind of stinky. I've got some nice efficient readable safe-enough C and it doesn't seem to translate well easily efficiently to Modula-3. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 27 08:15:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 07:15:26 +0000 Subject: [M3devel] constants/offsetof? Message-ID: Is it unreasonble to expect more/all of these to be constant? UNSAFE MODULE bug1; TYPE T1 = RECORD i,j:INTEGER END; <*NOWARN*>VAR a:T1; <*NOWARN*>CONST b: UNTRACED REF T1 = NIL; <*NOWARN*>CONST c: ADDRESS = ADR(a); (* line 7 *) <*NOWARN*>CONST d: ADDRESS = ADR(a.i); <*NOWARN*>CONST e: ADDRESS = ADR(a.j); <*NOWARN*>CONST f: INTEGER = ADR(a.j) - NIL; <*NOWARN*>CONST g: ADDRESS = ADR(b.i); <*NOWARN*>CONST h: ADDRESS = ADR(b.j); <*NOWARN*>CONST i: INTEGER = ADR(b.j) - NIL; <*NOWARN*>VAR vc: ADDRESS := ADR(a); <*NOWARN*>VAR vd: ADDRESS := ADR(a.i); <*NOWARN*>VAR ve: ADDRESS := ADR(a.j); <*NOWARN*>VAR vf: INTEGER := ADR(a.j) - NIL; (* oops, didn't mean this one *) <*NOWARN*>VAR vg: ADDRESS := ADR(b.i); <*NOWARN*>VAR vh: ADDRESS := ADR(b.j); <*NOWARN*>VAR vi: INTEGER := ADR(b.j) - NIL; BEGIN END bug1. "../src/bug1.m3", line 7: value is not constant "../src/bug1.m3", line 8: value is not constant "../src/bug1.m3", line 9: value is not constant "../src/bug1.m3", line 10: value is not constant "../src/bug1.m3", line 11: value is not constant "../src/bug1.m3", line 12: value is not constant "../src/bug1.m3", line 13: value is not constant It works in C... #include typedef struct { ptrdiff_t i, j;}T1; T1 a; #define b ((T1*)0) T1* const c = &a; ptrdiff_t* const d = &a.i; ptrdiff_t* const e = &a.j; ptrdiff_t const f = offsetof(T1,j); ptrdiff_t* const g = &b->i; ptrdiff_t* const h = &b->j; ptrdiff_t const i = &b->j - (ptrdiff_t*)0; Thanks, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Dec 27 11:14:21 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Dec 2010 02:14:21 -0800 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <20101212201458.BEFA41A2079@async.async.caltech.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu> Message-ID: <20101227101421.38A6A1A205B@async.async.caltech.edu> I upgraded to the CVS head and now I get the following: ... "../I386_DARWIN/FSSchemeStubs.m3", line 872: warning: unreachable statement "../I386_DARWIN/FSSchemeStubs.m3", line 903: warning: unreachable statement "../I386_DARWIN/FSSchemeStubs.m3", line 434: 2 code generation errors 1 error and 23 warnings encountered new exporters -> recompiling FSSchemeStubs.i3 ... The source code is: TYPE FS_Iterator_Surrogate = FS.Iterator OBJECT (* line 434 *) interp : Scheme.T; next_slot : SchemeObject.T := NIL; close_slot : SchemeObject.T := NIL; nextWithStatus_slot : SchemeObject.T := NIL; OVERRIDES next := FS_Iterator_next_default; close := FS_Iterator_close_default; nextWithStatus := FS_Iterator_nextWithStatus_default; END; Mika Mika Nystrom writes: >Hi everyone, > >Well I was able to get past all my linking issues (mostly questions >of dynamic vs. static linking and how to do it, which seems to change from >version to version...) > >But now I did hit a real problem. > >"../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** unaligne >d store type=6 s/o/a=32/0/32 >"../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** unaligne >d load_indirect type=6 s/a=32/32 > >Here is the code, but it's not likely to be of much help... > >PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.T RAIS >ES { Scheme.E } = > BEGIN > VAR res : SchemePair.T:=NIL; BEGIN > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),T >oScheme_Atom_T(x.type)),res); > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modifica >tionTime"),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),T >oScheme_VAL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) > RETURN res > END > END ToScheme_File_Status; > > >... > >PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0, LONGI >NT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = > BEGIN > RETURN ToScheme_LONGINT(x) (* line 981 *) > END ToScheme_VAL0LONGINT__VAL16778080LONGINT; > > >for reference, ToScheme_LONGINT is: > >PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISES { S >cheme.E } = > BEGIN > WITH ref = NEW(REF LONGINT) DO > ref^ := x; > RETURN SchemeModula3Types.ToScheme_LONGINT(ref) > END > END ToScheme_LONGINT; > > Mika From mika at async.caltech.edu Mon Dec 27 11:16:53 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Dec 2010 02:16:53 -0800 Subject: [M3devel] another Snow Leopard compiler crash Message-ID: <20101227101653.307241A205B@async.async.caltech.edu> ===> calarm/regress/ximport --- building in I386_DARWIN --- new source -> compiling Main.m3 "../src/Main.m3", line 258: warning: potentially unhandled exception: Main.ParamErr "../src/Main.m3", line 260: warning: potentially unhandled exception: Main.ParamErr "../src/Main.m3", line 261: warning: potentially unhandled exception: Main.ParamErr 3 warnings encountered ../src/Main.m3: In function 'Main__DumpMatching__DumpOne': ../src/Main.m3:225:0: error: unable to find a register to spill in class 'CREG' ../src/Main.m3:225:0: error: this is the insn: (insn 5 4 6 2 ../src/Main.m3:204 (parallel [ (set (reg:SI 0 ax [130]) (const_int 0 [0x0])) (set (reg:SI 1 dx [128]) (plus:SI (ashift:SI (reg:SI 0 ax [130]) (const_int 2 [0x2])) (reg:SI 1 dx [128]))) (set (reg:SI 4 si [129]) (plus:SI (ashift:SI (reg:SI 0 ax [130]) (const_int 2 [0x2])) (reg:SI 4 si [129]))) (set (mem/s/c:BLK (reg:SI 1 dx [128]) [0 trade+0 S24 A64]) (mem/s/c:BLK (reg:SI 4 si [129]) [0 trade+0 S24 A32])) (use (reg:SI 0 ax [130])) ]) 838 {*rep_movsi} (expr_list:REG_UNUSED (reg:SI 0 ax [130]) (expr_list:REG_UNUSED (reg:SI 4 si [129]) (expr_list:REG_UNUSED (reg:SI 1 dx [128]) (nil))))) ../src/Main.m3:225:0: internal compiler error: in spill_failure, at reload1.c:2163 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: Main.mc compilation failed => not building program "ximport" Fatal Error: package build failed Here is the code: PROCEDURE DumpMatching(tr : TickerRef; trades, bids, asks : HFDataSSeq.T) RAISES { Wr.Failure } = PROCEDURE DumpOne(trade, bid, ask : HFData.S) RAISES { Wr.Failure } = BEGIN <* ASSERT trade.time = bid.time AND bid.time = ask.time *> Wr.PutText(wr, Fmt.LongReal(trade.time)); Wr.PutChar(wr, ' '); Wr.PutText(wr, Fmt.LongReal(aFactor*trade.pv.price)); Wr.PutChar(wr, ' '); Wr.PutText(wr, Fmt.LongReal(FLOAT(trade.pv.volume,LONGREAL)/aFactor)); Wr.PutChar(wr, ' '); Wr.PutText(wr, Fmt.LongReal(aFactor*bid.pv.price)); Wr.PutChar(wr, ' '); Wr.PutText(wr, Fmt.LongReal(FLOAT(bid.pv.volume,LONGREAL)/aFactor)); Wr.PutChar(wr, ' '); Wr.PutText(wr, Fmt.LongReal(aFactor*ask.pv.price)); Wr.PutChar(wr, ' '); Wr.PutText(wr, Fmt.LongReal(FLOAT(ask.pv.volume,LONGREAL)/aFactor)); Wr.PutChar(wr, '\n') END DumpOne; CONST NoTime = FIRST(Time.T); VAR wr := FileWr.Open(odir & "/" & tr.ticker); tp, bp, ap := 0; ttime, btime, atime := NoTime; aFactor : LONGREAL := 1.0d0; BEGIN WHILE tp < trades.size() AND bp < bids.size() AND ap < asks.size() DO IF ttime = NoTime THEN ttime := trades.get(tp).time END; IF btime = NoTime THEN btime := bids.get(bp).time END; IF atime = NoTime THEN atime := asks.get(ap).time END; IF ttime = btime AND btime = atime THEN DumpOne(trades.get(tp),bids.get(bp),asks.get(ap)); INC(tp); INC(bp); INC(ap); ttime := NoTime; btime := NoTime; atime := NoTime ELSIF ttime < btime OR ttime < atime THEN INC(tp); ttime := NoTime ELSIF btime < atime OR btime < ttime THEN INC(bp); btime := NoTime ELSIF atime < btime OR atime < ttime THEN INC(ap); atime := NoTime END END; Wr.Close(wr) END DumpMatching; Miika From jay.krell at cornell.edu Mon Dec 27 11:17:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 10:17:51 +0000 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <20101227101421.38A6A1A205B@async.async.caltech.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, <20101227101421.38A6A1A205B@async.async.caltech.edu> Message-ID: Can you put all your code in our CVS repository? > "../I386_DARWIN/FSSchemeStubs.m3", line 434: 2 code generation errors There is a way to get that to show more information.. Or does it already? - Jay > To: m3devel at elegosoft.com > Date: Mon, 27 Dec 2010 02:14:21 -0800 > From: mika at async.caltech.edu > Subject: Re: [M3devel] compiler problems on Snow Leopard > > I upgraded to the CVS head and now I get the following: > > ... > "../I386_DARWIN/FSSchemeStubs.m3", line 872: warning: unreachable statement > "../I386_DARWIN/FSSchemeStubs.m3", line 903: warning: unreachable statement > "../I386_DARWIN/FSSchemeStubs.m3", line 434: 2 code generation errors > 1 error and 23 warnings encountered > new exporters -> recompiling FSSchemeStubs.i3 > ... > > The source code is: > > TYPE FS_Iterator_Surrogate = FS.Iterator OBJECT (* line 434 *) > interp : Scheme.T; > next_slot : SchemeObject.T := NIL; > close_slot : SchemeObject.T := NIL; > nextWithStatus_slot : SchemeObject.T := NIL; > OVERRIDES > next := FS_Iterator_next_default; > close := FS_Iterator_close_default; > nextWithStatus := FS_Iterator_nextWithStatus_default; > END; > > Mika > > Mika Nystrom writes: > >Hi everyone, > > > >Well I was able to get past all my linking issues (mostly questions > >of dynamic vs. static linking and how to do it, which seems to change from > >version to version...) > > > >But now I did hit a real problem. > > > >"../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** unaligne > >d store type=6 s/o/a=32/0/32 > >"../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** unaligne > >d load_indirect type=6 s/a=32/32 > > > >Here is the code, but it's not likely to be of much help... > > > >PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.T RAIS > >ES { Scheme.E } = > > BEGIN > > VAR res : SchemePair.T:=NIL; BEGIN > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),T > >oScheme_Atom_T(x.type)),res); > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modifica > >tionTime"),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),T > >oScheme_VAL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) > > RETURN res > > END > > END ToScheme_File_Status; > > > > > >... > > > >PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0, LONGI > >NT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = > > BEGIN > > RETURN ToScheme_LONGINT(x) (* line 981 *) > > END ToScheme_VAL0LONGINT__VAL16778080LONGINT; > > > > > >for reference, ToScheme_LONGINT is: > > > >PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISES { S > >cheme.E } = > > BEGIN > > WITH ref = NEW(REF LONGINT) DO > > ref^ := x; > > RETURN SchemeModula3Types.ToScheme_LONGINT(ref) > > END > > END ToScheme_LONGINT; > > > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Dec 27 11:38:10 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Dec 2010 02:38:10 -0800 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, <20101227101421.38A6A1A205B@async.async.caltech.edu> Message-ID: <20101227103810.94DF21A205B@async.async.caltech.edu> Jay K writes: >--_6f82bcb2-663f-4046-87f2-073a1528a819_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >Can you put all your code in our CVS repository? > I can't put all the code I work with in m3devel's repository: some of it is proprietary. The Scheme code however I have no restrictions on distributing (that's what's got problems in this case). It is however large and unwieldy and I'd like to have other people's suggestions for how to submit/incorporate it with CM3 before I just dump it in the repository. It also overlaps a bit with "caltech-parser", so there should probably be a "caltech-common" package for the overlaps? If you run the following commands in a fresh directory, you should get to the error I emailed: setenv CM3 1 cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -d . make regress # GNU make : 'gmake regress' on BSD cd mscheme/sstubgen/example cm3 -x Mika From jay.krell at cornell.edu Mon Dec 27 11:35:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 10:35:24 +0000 Subject: [M3devel] enable/disableswitching around external calls? Message-ID: I noticed calls to free in M3toC missing Enable/DisableSwitching. I'm going to generalize this, somewhat, in m3core.h, but that still leaves a fair number of custom wrappers. This area seems extremely error prone and extremely difficult to get test coverage on. These functions only do anything for user threads. Which we only use by default on OpenBSD. How about the frontend emit the calls around any external calls? Theory being: external calls are rare? Perhaps frontend/m3middle would know if user threads are in use and only emit the calls in that case. Perhaps. I don't like sprinking much target-specific information around. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 27 11:46:55 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 10:46:55 +0000 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <20101227103810.94DF21A205B@async.async.caltech.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , <20101227103810.94DF21A205B@async.async.caltech.edu> Message-ID: aside: overlap with caltech_parser: if you can come up with a merged version that works with both, good If you can't, I think you have to rename one or the other. Maybe someday we can support some sort of hierarchy that automatically maps to/from the file system hierarchy... I'll try to reproduce the problem. All targets? Workaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) - Jay > To: jay.krell at cornell.edu > Date: Mon, 27 Dec 2010 02:38:10 -0800 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] compiler problems on Snow Leopard > > Jay K writes: > >--_6f82bcb2-663f-4046-87f2-073a1528a819_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Can you put all your code in our CVS repository? > > > > I can't put all the code I work with in m3devel's repository: some of > it is proprietary. > > The Scheme code however I have no restrictions on distributing (that's > what's got problems in this case). It is however large and unwieldy and > I'd like to have other people's suggestions for how to submit/incorporate > it with CM3 before I just dump it in the repository. It also overlaps a bit > with "caltech-parser", so there should probably be a "caltech-common" > package for the overlaps? > > If you run the following commands in a fresh directory, you should get > to the error I emailed: > > setenv CM3 1 > cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -d . > make regress # GNU make : 'gmake regress' on BSD > cd mscheme/sstubgen/example > cm3 -x > > Mika > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 27 11:51:10 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 10:51:10 +0000 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , , , <20101227103810.94DF21A205B@async.async.caltech.edu>, Message-ID: I can't quite reproduce it, but I can compile a bunch of your code. new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-lib.a" -> archiving libsstubgen.a ===> mscheme/sstubgen/program --- building in I386_DARWIN --- -> linking sstubgen i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/libmscheme.a: No such file or directory m3_link => 1 linker failed linking: sstubgen Fatal Error: package build failed jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example jbook2:example jay$ c,3 -bash: c,3: command not found jbook2:example jay$ cm3 --- building in I386_DARWIN --- ignoring ../src/m3overrides "/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3makefile", line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/I386_DARWIN/.M3EXPORTS" for reading --procedure-- -line- -file--- import -- include_dir 3 /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3makefile - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu Date: Mon, 27 Dec 2010 10:46:55 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] compiler problems on Snow Leopard aside: overlap with caltech_parser: if you can come up with a merged version that works with both, good If you can't, I think you have to rename one or the other. Maybe someday we can support some sort of hierarchy that automatically maps to/from the file system hierarchy... I'll try to reproduce the problem. All targets? Workaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) - Jay > To: jay.krell at cornell.edu > Date: Mon, 27 Dec 2010 02:38:10 -0800 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] compiler problems on Snow Leopard > > Jay K writes: > >--_6f82bcb2-663f-4046-87f2-073a1528a819_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >Can you put all your code in our CVS repository? > > > > I can't put all the code I work with in m3devel's repository: some of > it is proprietary. > > The Scheme code however I have no restrictions on distributing (that's > what's got problems in this case). It is however large and unwieldy and > I'd like to have other people's suggestions for how to submit/incorporate > it with CM3 before I just dump it in the repository. It also overlaps a bit > with "caltech-parser", so there should probably be a "caltech-common" > package for the overlaps? > > If you run the following commands in a fresh directory, you should get > to the error I emailed: > > setenv CM3 1 > cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -d . > make regress # GNU make : 'gmake regress' on BSD > cd mscheme/sstubgen/example > cm3 -x > > Mika > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Dec 27 11:53:17 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Dec 2010 02:53:17 -0800 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , <20101227103810.94DF21A205B@async.async.caltech.edu> Message-ID: <20101227105317.52A861A205B@async.async.caltech.edu> I'mu sure a merged version is possible. I still have a separate version of caltech-parser in "my" repository that works with "my" Debug.i3, etc. I have only tried Snow Leopard (I386_DARWIN). I use PM3 on FreeBSD... I haven't tried workarounds here because I don't desperately need this code to work (at least not yet). The problem I reported a couple of weeks ago with "file descriptors" turned out to have something to do with closing a file through C somehow.. not sure exactly what was going on since I am using a helper C process to do terminal I/O using GNU readline. Mika Jay K writes: >--_f9584f16-e235-418f-823d-1c2a51c6bc9b_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >aside: overlap with caltech_parser: >if you can come up with a merged version that works with both=2C good >If you can't=2C I think you have to rename one or the other. > >Maybe someday we can support some sort of hierarchy that automatically maps= > to/from the file system hierarchy... > >I'll try to reproduce the problem. > >All targets? >Workaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) > > - Jay > > >> To: jay.krell at cornell.edu >> Date: Mon=2C 27 Dec 2010 02:38:10 -0800 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] compiler problems on Snow Leopard >>=20 >> Jay K writes: >> >--_6f82bcb2-663f-4046-87f2-073a1528a819_ >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> >Can you put all your code in our CVS repository? >> > >>=20 >> I can't put all the code I work with in m3devel's repository: some of=20 >> it is proprietary. >>=20 >> The Scheme code however I have no restrictions on distributing (that's >> what's got problems in this case). It is however large and unwieldy and >> I'd like to have other people's suggestions for how to submit/incorporate >> it with CM3 before I just dump it in the repository. It also overlaps a = >bit >> with "caltech-parser"=2C so there should probably be a "caltech-common" >> package for the overlaps? >>=20 >> If you run the following commands in a fresh directory=2C you should get >> to the error I emailed: >>=20 >> setenv CM3 1 >> cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -d . >> make regress # GNU make : 'gmake regress' on BSD >> cd mscheme/sstubgen/example >> cm3 -x >>=20 >> Mika >>=20 >>=20 > = > >--_f9584f16-e235-418f-823d-1c2a51c6bc9b_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >aside: overlap with caltech_parser:
if you can come up with a merged ver= >sion that works with both=2C good
If you can't=2C I think you have to re= >name one or the other.

Maybe someday we can support some sort of hie= >rarchy that automatically maps to/from the file system hierarchy...

= >I'll try to reproduce the problem.

All targets?
Workaround with d= >ifferent cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?)

 =3B- Jay>

>=3B To: jay.krell at cornell.edu
>=3B Date: Mon=2C 27 Dec 201= >0 02:38:10 -0800
>=3B From: mika at async.caltech.edu
>=3B CC: m3dev= >el at elegosoft.com
>=3B Subject: Re: [M3devel] compiler problems on Snow= > Leopard
>=3B
>=3B Jay K writes:
>=3B >=3B--_6f82bcb2-663= >f-4046-87f2-073a1528a819_
>=3B >=3BContent-Type: text/plain=3B chars= >et=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encoding: quoted-printab= >le
>=3B >=3B
>=3B >=3B
>=3B >=3BCan you put all your c= >ode in our CVS repository?
>=3B >=3B
>=3B
>=3B I can't pu= >t all the code I work with in m3devel's repository: some of
>=3B it i= >s proprietary.
>=3B
>=3B The Scheme code however I have no restr= >ictions on distributing (that's
>=3B what's got problems in this case)= >. It is however large and unwieldy and
>=3B I'd like to have other pe= >ople's suggestions for how to submit/incorporate
>=3B it with CM3 befo= >re I just dump it in the repository. It also overlaps a bit
>=3B with= > "caltech-parser"=2C so there should probably be a "caltech-common"
>= >=3B package for the overlaps?
>=3B
>=3B If you run the following= > commands in a fresh directory=2C you should get
>=3B to the error I e= >mailed:
>=3B
>=3B setenv CM3 1
>=3B cvs -d :pserver:anonymo= >us at pluto.gcapltd.com:/home/gcap-public-cvs up -d .
>=3B make regress = > # GNU make : 'gmake regress' on BSD
>=3B cd mscheme/sstubgen/example= >
>=3B cm3 -x
>=3B
>=3B Mika
>=3B
>=3B
= > >= > >--_f9584f16-e235-418f-823d-1c2a51c6bc9b_-- From mika at async.caltech.edu Mon Dec 27 11:58:59 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Dec 2010 02:58:59 -0800 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , , , <20101227103810.94DF21A205B@async.async.caltech.edu>, Message-ID: <20101227105859.8E1F21A205B@async.async.caltech.edu> Run cm3 -x instead of just cm3. Did you get an error compiling package "mscheme"? I certainly have a libmscheme.a in there. /m3overrides has build_standalone() in it. I normally didn't use build_standalone() but something has changed in how the system searches for shared libs when building with overrides and this was the easiest solution (at least for now). Mika Jay K writes: >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >I can't quite reproduce it=2C but I can compile a bunch of your code. > > >new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-lib.a" = >-> archiving libsstubgen.a > >=3D=3D=3D> mscheme/sstubgen/program >--- building in I386_DARWIN --- > > -> linking sstubgen >i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/lib= >mscheme.a: No such file or directory > m3_link =3D> 1 >linker failed linking: sstubgen >Fatal Error: package build failed > >jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example >jbook2:example jay$ c=2C3 >-bash: c=2C3: command not found >jbook2:example jay$ cm3 >--- building in I386_DARWIN --- > >ignoring ../src/m3overrides > >"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3makefile"= >=2C line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/I386_DARW= >IN/.M3EXPORTS" for reading > >--procedure-- -line- -file--- >import -- >include_dir 3 /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/exa= >mple/src/m3makefile > > > - Jay > > > > > > >From: jay.krell at cornell.edu >To: mika at async.caltech.edu >Date: Mon=2C 27 Dec 2010 10:46:55 +0000 >CC: m3devel at elegosoft.com >Subject: Re: [M3devel] compiler problems on Snow Leopard > > > > > > > > >aside: overlap with caltech_parser: >if you can come up with a merged version that works with both=2C good >If you can't=2C I think you have to rename one or the other. > >Maybe someday we can support some sort of hierarchy that automatically maps= > to/from the file system hierarchy... > >I'll try to reproduce the problem. > >All targets? >Workaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) > > - Jay > > >> To: jay.krell at cornell.edu >> Date: Mon=2C 27 Dec 2010 02:38:10 -0800 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] compiler problems on Snow Leopard >>=20 >> Jay K writes: >> >--_6f82bcb2-663f-4046-87f2-073a1528a819_ >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> >Can you put all your code in our CVS repository? >> > >>=20 >> I can't put all the code I work with in m3devel's repository: some of=20 >> it is proprietary. >>=20 >> The Scheme code however I have no restrictions on distributing (that's >> what's got problems in this case). It is however large and unwieldy and >> I'd like to have other people's suggestions for how to submit/incorporate >> it with CM3 before I just dump it in the repository. It also overlaps a = >bit >> with "caltech-parser"=2C so there should probably be a "caltech-common" >> package for the overlaps? >>=20 >> If you run the following commands in a fresh directory=2C you should get >> to the error I emailed: >>=20 >> setenv CM3 1 >> cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -d . >> make regress # GNU make : 'gmake regress' on BSD >> cd mscheme/sstubgen/example >> cm3 -x >>=20 >> Mika >>=20 >>=20 > = > >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >I can't quite reproduce it=2C but I can compile a bunch of your code.
r>
new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-l= >ib.a" ->=3B archiving libsstubgen.a

=3D=3D=3D>=3B mscheme/sstubg= >en/program
--- building in I386_DARWIN ---

 =3B->=3B linkin= >g sstubgen
i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I= >386_DARWIN/libmscheme.a: No such file or directory
 =3B m3_link =3D&= >gt=3B 1
linker failed linking: sstubgen
Fatal Error: package build fa= >iled

jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example
jboo= >k2:example jay$ c=2C3
-bash: c=2C3: command not found
jbook2:example = >jay$ cm3
--- building in I386_DARWIN ---

ignoring ../src/m3overri= >des

"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3= >makefile"=2C line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/= >I386_DARWIN/.M3EXPORTS" for reading

--procedure-- =3B -line-&nbs= >p=3B -file---
import =3B =3B =3B =3B =3B =3B&nbs= >p=3B =3B =3B =3B =3B =3B -- =3B <=3Bbuiltin>=3B= >
include_dir =3B =3B =3B =3B =3B =3B =3B&nbs= >p=3B 3 =3B /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src= >/m3makefile


 =3B- Jay






topSpelling">From: jay.krell at cornell.edu
To: mika at async.caltech.edu
D= >ate: Mon=2C 27 Dec 2010 10:46:55 +0000
CC: m3devel at elegosoft.com
Subj= >ect: Re: [M3devel] compiler problems on Snow Leopard

> >"> > > > > >aside: overlap with caltech_parser:
if you can come up with a merged ver= >sion that works with both=2C good
If you can't=2C I think you have to re= >name one or the other.

Maybe someday we can support some sort of hie= >rarchy that automatically maps to/from the file system hierarchy...

= >I'll try to reproduce the problem.

All targets?
Workaround with d= >ifferent cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?)

 =3B- Jay>

>=3B To: jay.krell at cornell.edu
>=3B Date: Mon=2C 27 Dec 201= >0 02:38:10 -0800
>=3B From: mika at async.caltech.edu
>=3B CC: m3dev= >el at elegosoft.com
>=3B Subject: Re: [M3devel] compiler problems on Snow= > Leopard
>=3B
>=3B Jay K writes:
>=3B >=3B--_6f82bcb2-663= >f-4046-87f2-073a1528a819_
>=3B >=3BContent-Type: text/plain=3B chars= >et=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encoding: quoted-printab= >le
>=3B >=3B
>=3B >=3B
>=3B >=3BCan you put all your c= >ode in our CVS repository?
>=3B >=3B
>=3B
>=3B I can't pu= >t all the code I work with in m3devel's repository: some of
>=3B it i= >s proprietary.
>=3B
>=3B The Scheme code however I have no restr= >ictions on distributing (that's
>=3B what's got problems in this case)= >. It is however large and unwieldy and
>=3B I'd like to have other pe= >ople's suggestions for how to submit/incorporate
>=3B it with CM3 befo= >re I just dump it in the repository. It also overlaps a bit
>=3B with= > "caltech-parser"=2C so there should probably be a "caltech-common"
>= >=3B package for the overlaps?
>=3B
>=3B If you run the following= > commands in a fresh directory=2C you should get
>=3B to the error I e= >mailed:
>=3B
>=3B setenv CM3 1
>=3B cvs -d :pserver:anonymo= >us at pluto.gcapltd.com:/home/gcap-public-cvs up -d .
>=3B make regress = > # GNU make : 'gmake regress' on BSD
>=3B cd mscheme/sstubgen/example= >
>=3B cm3 -x
>=3B
>=3B Mika
>=3B
>=3B
= > >= > >--_9ece0c56-2524-4879-9a65-2407b1dbf664_-- From jay.krell at cornell.edu Mon Dec 27 12:04:11 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 11:04:11 +0000 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <20101227105859.8E1F21A205B@async.async.caltech.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , , , <20101227103810.94DF21A205B@async.async.caltech.edu>, , <20101227105859.8E1F21A205B@async.async.caltech.edu> Message-ID: Yes, overrides and standalone is a problem. Maybe I'll get around to addressing this for the next release. A proposed solution is: go back to mostly the old method: hard coded runpaths, with much overlap for global builds (to be shipped/installed), monstrously long paths for local builds (not to be shipped), AND link upon install Some systems allow for "slight relinking", including Solaris and Darwin, where just the paths get edited. That would be nicer. The old approach had problems too. If you build the system yourself, I think you automatically already today get what is described -- hardcoded run paths, with much overlap for global builds. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] compiler problems on Snow Leopard > Date: Mon, 27 Dec 2010 02:58:59 -0800 > From: mika at async.caltech.edu > > Run cm3 -x instead of just cm3. > > Did you get an error compiling package "mscheme"? I certainly have a > libmscheme.a in there. > > /m3overrides has build_standalone() in it. > > I normally didn't use build_standalone() but something has changed in > how the system searches for shared libs when building with overrides > and this was the easiest solution (at least for now). > > Mika > > Jay K writes: > >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >I can't quite reproduce it=2C but I can compile a bunch of your code. > > > > > >new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-lib.a" = > >-> archiving libsstubgen.a > > > >=3D=3D=3D> mscheme/sstubgen/program > >--- building in I386_DARWIN --- > > > > -> linking sstubgen > >i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/lib= > >mscheme.a: No such file or directory > > m3_link =3D> 1 > >linker failed linking: sstubgen > >Fatal Error: package build failed > > > >jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example > >jbook2:example jay$ c=2C3 > >-bash: c=2C3: command not found > >jbook2:example jay$ cm3 > >--- building in I386_DARWIN --- > > > >ignoring ../src/m3overrides > > > >"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3makefile"= > >=2C line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/I386_DARW= > >IN/.M3EXPORTS" for reading > > > >--procedure-- -line- -file--- > >import -- > >include_dir 3 /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/exa= > >mple/src/m3makefile > > > > > > - Jay > > > > > > > > > > > > > >From: jay.krell at cornell.edu > >To: mika at async.caltech.edu > >Date: Mon=2C 27 Dec 2010 10:46:55 +0000 > >CC: m3devel at elegosoft.com > >Subject: Re: [M3devel] compiler problems on Snow Leopard > > > > > > > > > > > > > > > > > >aside: overlap with caltech_parser: > >if you can come up with a merged version that works with both=2C good > >If you can't=2C I think you have to rename one or the other. > > > >Maybe someday we can support some sort of hierarchy that automatically maps= > > to/from the file system hierarchy... > > > >I'll try to reproduce the problem. > > > >All targets? > >Workaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) > > > > - Jay > > > > > >> To: jay.krell at cornell.edu > >> Date: Mon=2C 27 Dec 2010 02:38:10 -0800 > >> From: mika at async.caltech.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] compiler problems on Snow Leopard > >>=20 > >> Jay K writes: > >> >--_6f82bcb2-663f-4046-87f2-073a1528a819_ > >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> >Can you put all your code in our CVS repository? > >> > > >>=20 > >> I can't put all the code I work with in m3devel's repository: some of=20 > >> it is proprietary. > >>=20 > >> The Scheme code however I have no restrictions on distributing (that's > >> what's got problems in this case). It is however large and unwieldy and > >> I'd like to have other people's suggestions for how to submit/incorporate > >> it with CM3 before I just dump it in the repository. It also overlaps a = > >bit > >> with "caltech-parser"=2C so there should probably be a "caltech-common" > >> package for the overlaps? > >>=20 > >> If you run the following commands in a fresh directory=2C you should get > >> to the error I emailed: > >>=20 > >> setenv CM3 1 > >> cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -d . > >> make regress # GNU make : 'gmake regress' on BSD > >> cd mscheme/sstubgen/example > >> cm3 -x > >>=20 > >> Mika > >>=20 > >>=20 > > = > > > >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >I can't quite reproduce it=2C but I can compile a bunch of your code.
>r>
new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-l= > >ib.a" ->=3B archiving libsstubgen.a

=3D=3D=3D>=3B mscheme/sstubg= > >en/program
--- building in I386_DARWIN ---

 =3B->=3B linkin= > >g sstubgen
i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I= > >386_DARWIN/libmscheme.a: No such file or directory
 =3B m3_link =3D&= > >gt=3B 1
linker failed linking: sstubgen
Fatal Error: package build fa= > >iled

jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example
jboo= > >k2:example jay$ c=2C3
-bash: c=2C3: command not found
jbook2:example = > >jay$ cm3
--- building in I386_DARWIN ---

ignoring ../src/m3overri= > >des

"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3= > >makefile"=2C line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/= > >I386_DARWIN/.M3EXPORTS" for reading

--procedure-- =3B -line-&nbs= > >p=3B -file---
import =3B =3B =3B =3B =3B =3B&nbs= > >p=3B =3B =3B =3B =3B =3B -- =3B <=3Bbuiltin>=3B= > >
include_dir =3B =3B =3B =3B =3B =3B =3B&nbs= > >p=3B 3 =3B /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src= > >/m3makefile


 =3B- Jay






>topSpelling">From: jay.krell at cornell.edu
To: mika at async.caltech.edu
D= > >ate: Mon=2C 27 Dec 2010 10:46:55 +0000
CC: m3devel at elegosoft.com
Subj= > >ect: Re: [M3devel] compiler problems on Snow Leopard

> > > > >"> > > > > > > > > > >aside: overlap with caltech_parser:
if you can come up with a merged ver= > >sion that works with both=2C good
If you can't=2C I think you have to re= > >name one or the other.

Maybe someday we can support some sort of hie= > >rarchy that automatically maps to/from the file system hierarchy...

= > >I'll try to reproduce the problem.

All targets?
Workaround with d= > >ifferent cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?)

 =3B- Jay >>

>=3B To: jay.krell at cornell.edu
>=3B Date: Mon=2C 27 Dec 201= > >0 02:38:10 -0800
>=3B From: mika at async.caltech.edu
>=3B CC: m3dev= > >el at elegosoft.com
>=3B Subject: Re: [M3devel] compiler problems on Snow= > > Leopard
>=3B
>=3B Jay K writes:
>=3B >=3B--_6f82bcb2-663= > >f-4046-87f2-073a1528a819_
>=3B >=3BContent-Type: text/plain=3B chars= > >et=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encoding: quoted-printab= > >le
>=3B >=3B
>=3B >=3B
>=3B >=3BCan you put all your c= > >ode in our CVS repository?
>=3B >=3B
>=3B
>=3B I can't pu= > >t all the code I work with in m3devel's repository: some of
>=3B it i= > >s proprietary.
>=3B
>=3B The Scheme code however I have no restr= > >ictions on distributing (that's
>=3B what's got problems in this case)= > >. It is however large and unwieldy and
>=3B I'd like to have other pe= > >ople's suggestions for how to submit/incorporate
>=3B it with CM3 befo= > >re I just dump it in the repository. It also overlaps a bit
>=3B with= > > "caltech-parser"=2C so there should probably be a "caltech-common"
>= > >=3B package for the overlaps?
>=3B
>=3B If you run the following= > > commands in a fresh directory=2C you should get
>=3B to the error I e= > >mailed:
>=3B
>=3B setenv CM3 1
>=3B cvs -d :pserver:anonymo= > >us at pluto.gcapltd.com:/home/gcap-public-cvs up -d .
>=3B make regress = > > # GNU make : 'gmake regress' on BSD
>=3B cd mscheme/sstubgen/example= > >
>=3B cm3 -x
>=3B
>=3B Mika
>=3B
>=3B
= > > > >= > > > >--_9ece0c56-2524-4879-9a65-2407b1dbf664_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Dec 27 12:16:00 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 11:16:00 +0000 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>,,, , <20101227101421.38A6A1A205B@async.async.caltech.edu>, ,,, , , <20101227103810.94DF21A205B@async.async.caltech.edu>, , , , , <20101227105859.8E1F21A205B@async.async.caltech.edu>, Message-ID: something wanted cit_util. --- building in AMD64_DARWIN --- ignoring ../src/m3overrides "/Users/jay/dev2/gcap-public-cvs/cit_util/src/texthack.tmpl", line 2: quake runtime error: undefined variable: TOP --procedure-- -line- -file--- template 2 /Users/jay/dev2/gcap-public-cvs/cit_util/src/texthack.tmpl include_dir 13 /Users/jay/dev2/gcap-public-cvs/cit_util/src/m3makefile 4 /Users/jay/dev2/gcap-public-cvs/cit_util/AMD64_DARWIN/m3make.args % $Id: texthack.tmpl,v 1.7 2002/12/13 22:20:12 kp Exp $ _M3TEXTHACK = TOP & "/m3texthack/" & BUILD_DIR & "/m3texthack" _DERIVGEN = TOP & "/m3texthack/src/derivgen.sh" I don't have m3texthack anywhere I think. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu Date: Mon, 27 Dec 2010 11:04:11 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] compiler problems on Snow Leopard Yes, overrides and standalone is a problem. Maybe I'll get around to addressing this for the next release. A proposed solution is: go back to mostly the old method: hard coded runpaths, with much overlap for global builds (to be shipped/installed), monstrously long paths for local builds (not to be shipped), AND link upon install Some systems allow for "slight relinking", including Solaris and Darwin, where just the paths get edited. That would be nicer. The old approach had problems too. If you build the system yourself, I think you automatically already today get what is described -- hardcoded run paths, with much overlap for global builds. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] compiler problems on Snow Leopard > Date: Mon, 27 Dec 2010 02:58:59 -0800 > From: mika at async.caltech.edu > > Run cm3 -x instead of just cm3. > > Did you get an error compiling package "mscheme"? I certainly have a > libmscheme.a in there. > > /m3overrides has build_standalone() in it. > > I normally didn't use build_standalone() but something has changed in > how the system searches for shared libs when building with overrides > and this was the easiest solution (at least for now). > > Mika > > Jay K writes: > >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >I can't quite reproduce it=2C but I can compile a bunch of your code. > > > > > >new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-lib.a" = > >-> archiving libsstubgen.a > > > >=3D=3D=3D> mscheme/sstubgen/program > >--- building in I386_DARWIN --- > > > > -> linking sstubgen > >i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/lib= > >mscheme.a: No such file or directory > > m3_link =3D> 1 > >linker failed linking: sstubgen > >Fatal Error: package build failed > > > >jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example > >jbook2:example jay$ c=2C3 > >-bash: c=2C3: command not found > >jbook2:example jay$ cm3 > >--- building in I386_DARWIN --- > > > >ignoring ../src/m3overrides > > > >"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3makefile"= > >=2C line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/I386_DARW= > >IN/.M3EXPORTS" for reading > > > >--procedure-- -line- -file--- > >import -- > >include_dir 3 /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/exa= > >mple/src/m3makefile > > > > > > - Jay > > > > > > > > > > > > > >From: jay.krell at cornell.edu > >To: mika at async.caltech.edu > >Date: Mon=2C 27 Dec 2010 10:46:55 +0000 > >CC: m3devel at elegosoft.com > >Subject: Re: [M3devel] compiler problems on Snow Leopard > > > > > > > > > > > > > > > > > >aside: overlap with caltech_parser: > >if you can come up with a merged version that works with both=2C good > >If you can't=2C I think you have to rename one or the other. > > > >Maybe someday we can support some sort of hierarchy that automatically maps= > > to/from the file system hierarchy... > > > >I'll try to reproduce the problem. > > > >All targets? > >Workaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) > > > > - Jay > > > > > >> To: jay.krell at cornell.edu > >> Date: Mon=2C 27 Dec 2010 02:38:10 -0800 > >> From: mika at async.caltech.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] compiler problems on Snow Leopard > >>=20 > >> Jay K writes: > >> >--_6f82bcb2-663f-4046-87f2-073a1528a819_ > >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> >Can you put all your code in our CVS repository? > >> > > >>=20 > >> I can't put all the code I work with in m3devel's repository: some of=20 > >> it is proprietary. > >>=20 > >> The Scheme code however I have no restrictions on distributing (that's > >> what's got problems in this case). It is however large and unwieldy and > >> I'd like to have other people's suggestions for how to submit/incorporate > >> it with CM3 before I just dump it in the repository. It also overlaps a = > >bit > >> with "caltech-parser"=2C so there should probably be a "caltech-common" > >> package for the overlaps? > >>=20 > >> If you run the following commands in a fresh directory=2C you should get > >> to the error I emailed: > >>=20 > >> setenv CM3 1 > >> cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -d . > >> make regress # GNU make : 'gmake regress' on BSD > >> cd mscheme/sstubgen/example > >> cm3 -x > >>=20 > >> Mika > >>=20 > >>=20 > > = > > > >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >I can't quite reproduce it=2C but I can compile a bunch of your code.
>r>
new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-l= > >ib.a" ->=3B archiving libsstubgen.a

=3D=3D=3D>=3B mscheme/sstubg= > >en/program
--- building in I386_DARWIN ---

 =3B->=3B linkin= > >g sstubgen
i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I= > >386_DARWIN/libmscheme.a: No such file or directory
 =3B m3_link =3D&= > >gt=3B 1
linker failed linking: sstubgen
Fatal Error: package build fa= > >iled

jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example
jboo= > >k2:example jay$ c=2C3
-bash: c=2C3: command not found
jbook2:example = > >jay$ cm3
--- building in I386_DARWIN ---

ignoring ../src/m3overri= > >des

"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3= > >makefile"=2C line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/= > >I386_DARWIN/.M3EXPORTS" for reading

--procedure-- =3B -line-&nbs= > >p=3B -file---
import =3B =3B =3B =3B =3B =3B&nbs= > >p=3B =3B =3B =3B =3B =3B -- =3B <=3Bbuiltin>=3B= > >
include_dir =3B =3B =3B =3B =3B =3B =3B&nbs= > >p=3B 3 =3B /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src= > >/m3makefile


 =3B- Jay






>topSpelling">From: jay.krell at cornell.edu
To: mika at async.caltech.edu
D= > >ate: Mon=2C 27 Dec 2010 10:46:55 +0000
CC: m3devel at elegosoft.com
Subj= > >ect: Re: [M3devel] compiler problems on Snow Leopard

> > > > >"> > > > > > > > > > >aside: overlap with caltech_parser:
if you can come up with a merged ver= > >sion that works with both=2C good
If you can't=2C I think you have to re= > >name one or the other.

Maybe someday we can support some sort of hie= > >rarchy that automatically maps to/from the file system hierarchy...

= > >I'll try to reproduce the problem.

All targets?
Workaround with d= > >ifferent cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?)

 =3B- Jay >>

>=3B To: jay.krell at cornell.edu
>=3B Date: Mon=2C 27 Dec 201= > >0 02:38:10 -0800
>=3B From: mika at async.caltech.edu
>=3B CC: m3dev= > >el at elegosoft.com
>=3B Subject: Re: [M3devel] compiler problems on Snow= > > Leopard
>=3B
>=3B Jay K writes:
>=3B >=3B--_6f82bcb2-663= > >f-4046-87f2-073a1528a819_
>=3B >=3BContent-Type: text/plain=3B chars= > >et=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encoding: quoted-printab= > >le
>=3B >=3B
>=3B >=3B
>=3B >=3BCan you put all your c= > >ode in our CVS repository?
>=3B >=3B
>=3B
>=3B I can't pu= > >t all the code I work with in m3devel's repository: some of
>=3B it i= > >s proprietary.
>=3B
>=3B The Scheme code however I have no restr= > >ictions on distributing (that's
>=3B what's got problems in this case)= > >. It is however large and unwieldy and
>=3B I'd like to have other pe= > >ople's suggestions for how to submit/incorporate
>=3B it with CM3 befo= > >re I just dump it in the repository. It also overlaps a bit
>=3B with= > > "caltech-parser"=2C so there should probably be a "caltech-common"
>= > >=3B package for the overlaps?
>=3B
>=3B If you run the following= > > commands in a fresh directory=2C you should get
>=3B to the error I e= > >mailed:
>=3B
>=3B setenv CM3 1
>=3B cvs -d :pserver:anonymo= > >us at pluto.gcapltd.com:/home/gcap-public-cvs up -d .
>=3B make regress = > > # GNU make : 'gmake regress' on BSD
>=3B cd mscheme/sstubgen/example= > >
>=3B cm3 -x
>=3B
>=3B Mika
>=3B
>=3B
= > > > >= > > > >--_9ece0c56-2524-4879-9a65-2407b1dbf664_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Dec 27 12:24:24 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Dec 2010 03:24:24 -0800 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , , , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , , , , , <20101227103810.94DF21A205B@async.async.caltech.edu>, , , , , <20101227105859.8E1F21A205B@async.async.caltech.edu>, Message-ID: <20101227112424.C13401A205B@async.async.caltech.edu> Don't think you need m3texthack. The first thing that happens when you run make ought to be that a file called ".top" is created at the top level of the repository, with a definition of TOP. This file is included by the top-level m3overrides, which is included by every m3overrides when you run with -x. Mika Jay K writes: >--_d61e805f-545e-4b3d-abe7-a20c582bec2e_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >something wanted cit_util. > > > >--- building in AMD64_DARWIN --- > > > >ignoring ../src/m3overrides > > > >"/Users/jay/dev2/gcap-public-cvs/cit_util/src/texthack.tmpl"=2C line 2: qua= >ke runtime error: undefined variable: TOP > > > >--procedure-- -line- -file--- > >template 2 /Users/jay/dev2/gcap-public-cvs/cit_util/src/texthac= >k.tmpl > >include_dir 13 /Users/jay/dev2/gcap-public-cvs/cit_util/src/m3makef= >ile > > 4 /Users/jay/dev2/gcap-public-cvs/cit_util/AMD64_DARWI= >N/m3make.args > > > > > >% $Id: texthack.tmpl=2Cv 1.7 2002/12/13 22:20:12 kp Exp $ > >_M3TEXTHACK =3D TOP & "/m3texthack/" & BUILD_DIR & "/m3texthack" > >_DERIVGEN =3D TOP & "/m3texthack/src/derivgen.sh" > > >I don't have m3texthack anywhere I think. > > - Jay > >From: jay.krell at cornell.edu >To: mika at async.caltech.edu >Date: Mon=2C 27 Dec 2010 11:04:11 +0000 >CC: m3devel at elegosoft.com >Subject: Re: [M3devel] compiler problems on Snow Leopard > > > > > > > > >Yes=2C overrides and standalone is a problem. > >Maybe I'll get around to addressing this for the next release. > >A proposed solution is: > go back to mostly the old method: hard coded runpaths=2C with much overla= >p for global builds (to be shipped/installed)=2C monstrously long paths for= > local builds (not to be shipped)=2C AND link upon install > Some systems allow for "slight relinking"=2C including Solaris and Darwin= >=2C where just the paths get edited. That would be nicer. > > The old approach had problems too. > > If you build the system yourself=2C I think you automatically already to= >day get what is described -- hardcoded run paths=2C with much overlap for g= >lobal builds. > > > - Jay > >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] compiler problems on Snow Leopard=20 >> Date: Mon=2C 27 Dec 2010 02:58:59 -0800 >> From: mika at async.caltech.edu >>=20 >> Run cm3 -x instead of just cm3. >>=20 >> Did you get an error compiling package "mscheme"? I certainly have a >> libmscheme.a in there. >>=20 >> /m3overrides has build_standalone() in it. >>=20 >> I normally didn't use build_standalone() but something has changed in >> how the system searches for shared libs when building with overrides >> and this was the easiest solution (at least for now). >>=20 >> Mika >>=20 >> Jay K writes: >> >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> >I can't quite reproduce it=3D2C but I can compile a bunch of your code. >> > >> > >> >new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-lib.= >a" =3D >> >-> archiving libsstubgen.a >> > >> >=3D3D=3D3D=3D3D> mscheme/sstubgen/program >> >--- building in I386_DARWIN --- >> > >> > -> linking sstubgen >> >i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/= >lib=3D >> >mscheme.a: No such file or directory >> > m3_link =3D3D> 1 >> >linker failed linking: sstubgen >> >Fatal Error: package build failed >> > >> >jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example >> >jbook2:example jay$ c=3D2C3 >> >-bash: c=3D2C3: command not found >> >jbook2:example jay$ cm3 >> >--- building in I386_DARWIN --- >> > >> >ignoring ../src/m3overrides >> > >> >"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3makefile= >"=3D >> >=3D2C line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/I386= >_DARW=3D >> >IN/.M3EXPORTS" for reading >> > >> >--procedure-- -line- -file--- >> >import -- >> >include_dir 3 /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/= >exa=3D >> >mple/src/m3makefile >> > >> > >> > - Jay >> > >> > >> > >> > >> > >> > >> >From: jay.krell at cornell.edu >> >To: mika at async.caltech.edu >> >Date: Mon=3D2C 27 Dec 2010 10:46:55 +0000 >> >CC: m3devel at elegosoft.com >> >Subject: Re: [M3devel] compiler problems on Snow Leopard >> > >> > >> > >> > >> > >> > >> > >> > >> >aside: overlap with caltech_parser: >> >if you can come up with a merged version that works with both=3D2C good >> >If you can't=3D2C I think you have to rename one or the other. >> > >> >Maybe someday we can support some sort of hierarchy that automatically m= >aps=3D >> > to/from the file system hierarchy... >> > >> >I'll try to reproduce the problem. >> > >> >All targets? >> >Workaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) >> > >> > - Jay >> > >> > >> >> To: jay.krell at cornell.edu >> >> Date: Mon=3D2C 27 Dec 2010 02:38:10 -0800 >> >> From: mika at async.caltech.edu >> >> CC: m3devel at elegosoft.com >> >> Subject: Re: [M3devel] compiler problems on Snow Leopard >> >>=3D20 >> >> Jay K writes: >> >> >--_6f82bcb2-663f-4046-87f2-073a1528a819_ >> >> >Content-Type: text/plain=3D3B charset=3D3D"iso-8859-1" >> >> >Content-Transfer-Encoding: quoted-printable >> >> > >> >> > >> >> >Can you put all your code in our CVS repository? >> >> > >> >>=3D20 >> >> I can't put all the code I work with in m3devel's repository: some of= >=3D20 >> >> it is proprietary. >> >>=3D20 >> >> The Scheme code however I have no restrictions on distributing (that's >> >> what's got problems in this case). It is however large and unwieldy a= >nd >> >> I'd like to have other people's suggestions for how to submit/incorpor= >ate >> >> it with CM3 before I just dump it in the repository. It also overlaps= > a =3D >> >bit >> >> with "caltech-parser"=3D2C so there should probably be a "caltech-comm= >on" >> >> package for the overlaps? >> >>=3D20 >> >> If you run the following commands in a fresh directory=3D2C you should= > get >> >> to the error I emailed: >> >>=3D20 >> >> setenv CM3 1 >> >> cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -= >d . >> >> make regress # GNU make : 'gmake regress' on BSD >> >> cd mscheme/sstubgen/example >> >> cm3 -x >> >>=3D20 >> >> Mika >> >>=3D20 >> >>=3D20 >> > =3D >> > >> >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ >> >Content-Type: text/html=3B charset=3D"iso-8859-1" >> >Content-Transfer-Encoding: quoted-printable >> > >> > >> > >> > >> > >> > >> >I can't quite reproduce it=3D2C but I can compile a bunch of your code.<= >br>> >r>
new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libschem= >e-l=3D >> >ib.a" ->=3D3B archiving libsstubgen.a

=3D3D=3D3D=3D3D>=3D3B m= >scheme/sstubg=3D >> >en/program
--- building in I386_DARWIN ---

 =3D3B->=3D3B= > linkin=3D >> >g sstubgen
i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mschem= >e/I=3D >> >386_DARWIN/libmscheme.a: No such file or directory
 =3D3B m3_link= > =3D3D&=3D >> >gt=3D3B 1
linker failed linking: sstubgen
Fatal Error: package bui= >ld fa=3D >> >iled

jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example
j= >boo=3D >> >k2:example jay$ c=3D2C3
-bash: c=3D2C3: command not found
jbook2:e= >xample =3D >> >jay$ cm3
--- building in I386_DARWIN ---

ignoring ../src/m3ove= >rri=3D >> >des

"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src= >/m3=3D >> >makefile"=3D2C line 3: quake runtime error: unable to open "/cm3/pkg/msc= >heme/=3D >> >I386_DARWIN/.M3EXPORTS" for reading

--procedure-- =3D3B -line= >-&nbs=3D >> >p=3D3B -file---
import =3D3B =3D3B =3D3B =3D3B = >=3D3B =3D3B&nbs=3D >> >p=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B -- =3D3B &l= >t=3D3Bbuiltin>=3D3B=3D >> >
include_dir =3D3B =3D3B =3D3B =3D3B =3D3B = >=3D3B =3D3B&nbs=3D >> >p=3D3B 3 =3D3B /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/exam= >ple/src=3D >> >/m3makefile


 =3D3B- Jay






=3D3D"s=3D >> >topSpelling">From: jay.krell at cornell.edu
To: mika at async.caltech.edur>D=3D >> >ate: Mon=3D2C 27 Dec 2010 10:46:55 +0000
CC: m3devel at elegosoft.com>Subj=3D >> >ect: Re: [M3devel] compiler problems on Snow Leopard

>> > >> >=3D3Dunicode=3D >> >"> >> > >> > >> > >> > >> >aside: overlap with caltech_parser:
if you can come up with a merged = >ver=3D >> >sion that works with both=3D2C good
If you can't=3D2C I think you hav= >e to re=3D >> >name one or the other.

Maybe someday we can support some sort of = >hie=3D >> >rarchy that automatically maps to/from the file system hierarchy...
<= >br>=3D >> >I'll try to reproduce the problem.

All targets?
Workaround wit= >h d=3D >> >ifferent cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?)

 =3D3B- J= >ay> >>

>=3D3B To: jay.krell at cornell.edu
>=3D3B Date: Mon=3D2C 2= >7 Dec 201=3D >> >0 02:38:10 -0800
>=3D3B From: mika at async.caltech.edu
>=3D3B CC= >: m3dev=3D >> >el at elegosoft.com
>=3D3B Subject: Re: [M3devel] compiler problems on= > Snow=3D >> > Leopard
>=3D3B
>=3D3B Jay K writes:
>=3D3B >=3D3B--_6= >f82bcb2-663=3D >> >f-4046-87f2-073a1528a819_
>=3D3B >=3D3BContent-Type: text/plain= >=3D3B chars=3D >> >et=3D3D"iso-8859-1"
>=3D3B >=3D3BContent-Transfer-Encoding: quote= >d-printab=3D >> >le
>=3D3B >=3D3B
>=3D3B >=3D3B
>=3D3B >=3D3BCan you= > put all your c=3D >> >ode in our CVS repository?
>=3D3B >=3D3B
>=3D3B
>=3D3B= > I can't pu=3D >> >t all the code I work with in m3devel's repository: some of
>=3D3B= > it i=3D >> >s proprietary.
>=3D3B
>=3D3B The Scheme code however I have n= >o restr=3D >> >ictions on distributing (that's
>=3D3B what's got problems in this = >case)=3D >> >. It is however large and unwieldy and
>=3D3B I'd like to have oth= >er pe=3D >> >ople's suggestions for how to submit/incorporate
>=3D3B it with CM3= > befo=3D >> >re I just dump it in the repository. It also overlaps a bit
>=3D3B= > with=3D >> > "caltech-parser"=3D2C so there should probably be a "caltech-common">>=3D >> >=3D3B package for the overlaps?
>=3D3B
>=3D3B If you run the = >following=3D >> > commands in a fresh directory=3D2C you should get
>=3D3B to the er= >ror I e=3D >> >mailed:
>=3D3B
>=3D3B setenv CM3 1
>=3D3B cvs -d :pserve= >r:anonymo=3D >> >us at pluto.gcapltd.com:/home/gcap-public-cvs up -d .
>=3D3B make regr= >ess =3D >> > # GNU make : 'gmake regress' on BSD
>=3D3B cd mscheme/sstubgen/ex= >ample=3D >> >
>=3D3B cm3 -x
>=3D3B
>=3D3B Mika
>=3D3B
&= >gt=3D3B
=3D >> > >> >=3D >> > >> >--_9ece0c56-2524-4879-9a65-2407b1dbf664_-- > = > >--_d61e805f-545e-4b3d-abe7-a20c582bec2e_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >something wanted cit_util.
>
>--- building in AMD64_DARWIN ---
>
>ignoring ../src/m3overrides
>
>"/Users/jay/dev2/gcap-public-cvs/cit_util/src/texthack.tmpl"=2C line 2: qua= >ke runtime error: undefined variable: TOP
>
>--procedure-- =3B -line- =3B -file---
>template =3B =3B =3B =3B =3B =3B =3B =3B&nb= >sp=3B =3B =3B 2 =3B /Users/jay/dev2/gcap-public-cvs/cit_util/sr= >c/texthack.tmpl
>include_dir =3B =3B =3B =3B =3B =3B =3B 13 = >=3B /Users/jay/dev2/gcap-public-cvs/cit_util/src/m3makefile
> =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= >sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = >=3B 4 =3B /Users/jay/dev2/gcap-public-cvs/cit_util/AMD64_DARWIN/m3make.= >args
>
>
>% $Id: texthack.tmpl=2Cv 1.7 2002/12/13 22:20:12 kp Exp $
>_M3TEXTHACK =3D TOP &=3B "/m3texthack/" &=3B BUILD_DIR &=3B "/m3te= >xthack"
>_DERIVGEN =3B =3B =3D TOP &=3B "/m3texthack/src/derivgen.sh"
>
I don't have m3texthack anywhere I think.

 =3B- Jay

<= >hr id=3D"stopSpelling">From: jay.krell at cornell.edu
To: mika at async.caltec= >h.edu
Date: Mon=2C 27 Dec 2010 11:04:11 +0000
CC: m3devel at elegosoft.c= >om
Subject: Re: [M3devel] compiler problems on Snow Leopard

> >"> > > > > >Yes=2C overrides and standalone is a problem.

Maybe I'll get around = >to addressing this for the next release.

A proposed solution is:
= > =3B go back to mostly the old method: hard coded runpaths=2C with much= > overlap for global builds (to be shipped/installed)=2C monstrously long pa= >ths for local builds (not to be shipped)=2C AND link upon install
 = >=3B Some systems allow for "slight relinking"=2C including Solaris and Darw= >in=2C where just the paths get edited. That would be nicer.

 =3B= > The old approach had problems too.

 =3B =3B If you build th= >e system yourself=2C I think you automatically already today get what is de= >scribed -- hardcoded run paths=2C with much overlap for global builds.
<= >br>
 =3B- Jay

>=3B To: jay.krell at cornell.edu
>=3B CC: = >m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] compiler problems on= > Snow Leopard
>=3B Date: Mon=2C 27 Dec 2010 02:58:59 -0800
>=3B = >From: mika at async.caltech.edu
>=3B
>=3B Run cm3 -x instead of jus= >t cm3.
>=3B
>=3B Did you get an error compiling package "mscheme= >"? I certainly have a
>=3B libmscheme.a in there.
>=3B
>= >=3B <=3Btop>=3B/m3overrides has build_standalone() in it.
>=3B >>=3B I normally didn't use build_standalone() but something has changed = >in
>=3B how the system searches for shared libs when building with ove= >rrides
>=3B and this was the easiest solution (at least for now).
&= >gt=3B
>=3B Mika
>=3B
>=3B Jay K writes:
>=3B >= >=3B--_9ece0c56-2524-4879-9a65-2407b1dbf664_
>=3B >=3BContent-Type: t= >ext/plain=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encodi= >ng: quoted-printable
>=3B >=3B
>=3B >=3B
>=3B >=3BI ca= >n't quite reproduce it=3D2C but I can compile a bunch of your code.
>= >=3B >=3B
>=3B >=3B
>=3B >=3Bnew "/dev2/gcap-public-cvs/msch= >eme/scheme-lib/I386_DARWIN/libscheme-lib.a" =3D
>=3B >=3B->=3B arc= >hiving libsstubgen.a
>=3B >=3B
>=3B >=3B=3D3D=3D3D=3D3D>=3B= > mscheme/sstubgen/program
>=3B >=3B--- building in I386_DARWIN ---r>>=3B >=3B
>=3B >=3B ->=3B linking sstubgen
>=3B >=3Bi= >686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/lib= >=3D
>=3B >=3Bmscheme.a: No such file or directory
>=3B >=3B = >m3_link =3D3D>=3B 1
>=3B >=3Blinker failed linking: sstubgen
&g= >t=3B >=3BFatal Error: package build failed
>=3B >=3B
>=3B >= >=3Bjbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example
>=3B >=3B= >jbook2:example jay$ c=3D2C3
>=3B >=3B-bash: c=3D2C3: command not fou= >nd
>=3B >=3Bjbook2:example jay$ cm3
>=3B >=3B--- building in = >I386_DARWIN ---
>=3B >=3B
>=3B >=3Bignoring ../src/m3override= >s
>=3B >=3B
>=3B >=3B"/Users/jay/dev2/gcap-public-cvs/mscheme= >/sstubgen/example/src/m3makefile"=3D
>=3B >=3B=3D2C line 3: quake ru= >ntime error: unable to open "/cm3/pkg/mscheme/I386_DARW=3D
>=3B >=3B= >IN/.M3EXPORTS" for reading
>=3B >=3B
>=3B >=3B--procedure-- = >-line- -file---
>=3B >=3Bimport -- <=3Bbuiltin>=3B= >
>=3B >=3Binclude_dir 3 /Users/jay/dev2/gcap-public-cvs/msc= >heme/sstubgen/exa=3D
>=3B >=3Bmple/src/m3makefile
>=3B >=3Br>>=3B >=3B
>=3B >=3B - Jay
>=3B >=3B
>=3B >=3B>>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B= > >=3BFrom: jay.krell at cornell.edu
>=3B >=3BTo: mika at async.caltech.e= >du
>=3B >=3BDate: Mon=3D2C 27 Dec 2010 10:46:55 +0000
>=3B >= >=3BCC: m3devel at elegosoft.com
>=3B >=3BSubject: Re: [M3devel] compile= >r problems on Snow Leopard
>=3B >=3B
>=3B >=3B
>=3B >= >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
= >>=3B >=3B
>=3B >=3Baside: overlap with caltech_parser:
>=3B= > >=3Bif you can come up with a merged version that works with both=3D2C g= >ood
>=3B >=3BIf you can't=3D2C I think you have to rename one or the= > other.
>=3B >=3B
>=3B >=3BMaybe someday we can support some = >sort of hierarchy that automatically maps=3D
>=3B >=3B to/from the f= >ile system hierarchy...
>=3B >=3B
>=3B >=3BI'll try to reprod= >uce the problem.
>=3B >=3B
>=3B >=3BAll targets?
>=3B &g= >t=3BWorkaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?)>>=3B >=3B
>=3B >=3B - Jay
>=3B >=3B
>=3B >=3B
= >>=3B >=3B>=3B To: jay.krell at cornell.edu
>=3B >=3B>=3B Date: = >Mon=3D2C 27 Dec 2010 02:38:10 -0800
>=3B >=3B>=3B From: mika at async= >.caltech.edu
>=3B >=3B>=3B CC: m3devel at elegosoft.com
>=3B >= >=3B>=3B Subject: Re: [M3devel] compiler problems on Snow Leopard
>= >=3B >=3B>=3B=3D20
>=3B >=3B>=3B Jay K writes:
>=3B >=3B= >>=3B >=3B--_6f82bcb2-663f-4046-87f2-073a1528a819_
>=3B >=3B>= >=3B >=3BContent-Type: text/plain=3D3B charset=3D3D"iso-8859-1"
>=3B = >>=3B>=3B >=3BContent-Transfer-Encoding: quoted-printable
>=3B &g= >t=3B>=3B >=3B
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= >=3BCan you put all your code in our CVS repository?
>=3B >=3B>=3B = >>=3B
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B I can't put all t= >he code I work with in m3devel's repository: some of=3D20
>=3B >=3B&= >gt=3B it is proprietary.
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B= > The Scheme code however I have no restrictions on distributing (that's
= >>=3B >=3B>=3B what's got problems in this case). It is however large= > and unwieldy and
>=3B >=3B>=3B I'd like to have other people's su= >ggestions for how to submit/incorporate
>=3B >=3B>=3B it with CM3 = >before I just dump it in the repository. It also overlaps a =3D
>=3B = >>=3Bbit
>=3B >=3B>=3B with "caltech-parser"=3D2C so there should= > probably be a "caltech-common"
>=3B >=3B>=3B package for the over= >laps?
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B If you run the fol= >lowing commands in a fresh directory=3D2C you should get
>=3B >=3B&g= >t=3B to the error I emailed:
>=3B >=3B>=3B=3D20
>=3B >=3B&g= >t=3B setenv CM3 1
>=3B >=3B>=3B cvs -d :pserver:anonymous at pluto.gc= >apltd.com:/home/gcap-public-cvs up -d .
>=3B >=3B>=3B make regress= > # GNU make : 'gmake regress' on BSD
>=3B >=3B>=3B cd mscheme/s= >stubgen/example
>=3B >=3B>=3B cm3 -x
>=3B >=3B>=3B=3D20r>>=3B >=3B>=3B Mika
>=3B >=3B>=3B=3D20
>=3B >= >=3B>=3B=3D20
>=3B >=3B =3Dr>>=3B >=3B
>=3B &= >gt=3B--_9ece0c56-2524-4879-9a65-2407b1dbf664_
>=3B >=3BContent-Type:= > text/html=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encod= >ing: quoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>=3B
= >>=3B >=3B<=3Bhead>=3B
>=3B >=3B<=3Bstyle>=3B<=3B!-->>=3B >=3B.hmmessage P
>=3B >=3B{
>=3B >=3Bmargin:0px=3D3= >B
>=3B >=3Bpadding:0px
>=3B >=3B}
>=3B >=3Bbody.hmmess= >age
>=3B >=3B{
>=3B >=3Bfont-size: 10pt=3D3B
>=3B >=3B= >font-family:Tahoma
>=3B >=3B}
>=3B >=3B-->=3B<=3B/style&g= >t=3B
>=3B >=3B<=3B/head>=3B
>=3B >=3B<=3Bbody class=3D3= >D'hmmessage'>=3B
>=3B >=3BI can't quite reproduce it=3D2C but I ca= >n compile a bunch of your code.<=3Bbr>=3B<=3Bb=3D
>=3B >=3Br&g= >t=3B<=3Bbr>=3Bnew "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN= >/libscheme-l=3D
>=3B >=3Bib.a" -&=3Bgt=3D3B archiving libsstubgen= >.a<=3Bbr>=3B<=3Bbr>=3B=3D3D=3D3D=3D3D&=3Bgt=3D3B mscheme/sstubg= >=3D
>=3B >=3Ben/program<=3Bbr>=3B--- building in I386_DARWIN ---= ><=3Bbr>=3B<=3Bbr>=3B&=3Bnbsp=3D3B-&=3Bgt=3D3B linkin=3D
&g= >t=3B >=3Bg sstubgen<=3Bbr>=3Bi686-apple-darwin9-gcc-4.0.1: /dev2/gcap= >-public-cvs/mscheme/I=3D
>=3B >=3B386_DARWIN/libmscheme.a: No such f= >ile or directory<=3Bbr>=3B&=3Bnbsp=3D3B m3_link =3D3D&=3B=3D
&= >gt=3B >=3Bgt=3D3B 1<=3Bbr>=3Blinker failed linking: sstubgen<=3Bbr&= >gt=3BFatal Error: package build fa=3D
>=3B >=3Biled<=3Bbr>=3B<= >=3Bbr>=3Bjbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example<=3Bbr&= >gt=3Bjboo=3D
>=3B >=3Bk2:example jay$ c=3D2C3<=3Bbr>=3B-bash: c= >=3D2C3: command not found<=3Bbr>=3Bjbook2:example =3D
>=3B >=3Bj= >ay$ cm3<=3Bbr>=3B--- building in I386_DARWIN ---<=3Bbr>=3B<=3Bbr&= >gt=3Bignoring ../src/m3overri=3D
>=3B >=3Bdes<=3Bbr>=3B<=3Bbr&= >gt=3B"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3=3D>>=3B >=3Bmakefile"=3D2C line 3: quake runtime error: unable to open "/= >cm3/pkg/mscheme/=3D
>=3B >=3BI386_DARWIN/.M3EXPORTS" for reading<= >=3Bbr>=3B<=3Bbr>=3B--procedure--&=3Bnbsp=3D3B -line-&=3Bnbs=3D<= >br>>=3B >=3Bp=3D3B -file---<=3Bbr>=3Bimport&=3Bnbsp=3D3B&=3Bn= >bsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&am= >p=3Bnbs=3D
>=3B >=3Bp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbs= >p=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B --&=3Bnbsp=3D3B &=3Blt=3D3Bbui= >ltin&=3Bgt=3D3B=3D
>=3B >=3B<=3Bbr>=3Binclude_dir&=3Bnbsp= >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&= >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbs=3D
>=3B >=3Bp=3D3B 3&=3Bnb= >sp=3D3B /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src=3D
= >>=3B >=3B/m3makefile<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B&=3Bnb= >sp=3D3B- Jay<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bb= >r>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bhr id=3D3D"s=3D
>=3B >=3Bto= >pSpelling">=3BFrom: jay.krell at cornell.edu<=3Bbr>=3BTo: mika at async.cal= >tech.edu<=3Bbr>=3BD=3D
>=3B >=3Bate: Mon=3D2C 27 Dec 2010 10:46:= >55 +0000<=3Bbr>=3BCC: m3devel at elegosoft.com<=3Bbr>=3BSubj=3D
>= >=3B >=3Bect: Re: [M3devel] compiler problems on Snow Leopard<=3Bbr>= >=3B<=3Bbr>=3B
>=3B >=3B
>=3B >=3B<=3Bmeta http-equiv=3D= >3D"Content-Type" content=3D3D"text/html=3D3B charset=3D3Dunicode=3D
>= >=3B >=3B">=3B
>=3B >=3B<=3Bmeta name=3D3D"Generator" content= >=3D3D"Microsoft SafeHTML">=3B
>=3B >=3B<=3Bstyle>=3B
>=3B= > >=3B.ExternalClass .ecxhmmessage P
>=3B >=3B{padding:0px=3D3B}>>=3B >=3B.ExternalClass body.ecxhmmessage
>=3B >=3B{font-size:1= >0pt=3D3Bfont-family:Tahoma=3D3B}
>=3B >=3B
>=3B >=3B<=3B/st= >yle>=3B
>=3B >=3B
>=3B >=3B
>=3B >=3Baside: overlap = >with caltech_parser:<=3Bbr>=3Bif you can come up with a merged ver=3Dr>>=3B >=3Bsion that works with both=3D2C good<=3Bbr>=3BIf you can'= >t=3D2C I think you have to re=3D
>=3B >=3Bname one or the other.<= >=3Bbr>=3B<=3Bbr>=3BMaybe someday we can support some sort of hie=3Dr>>=3B >=3Brarchy that automatically maps to/from the file system hiera= >rchy...<=3Bbr>=3B<=3Bbr>=3B=3D
>=3B >=3BI'll try to reproduc= >e the problem.<=3Bbr>=3B<=3Bbr>=3BAll targets?<=3Bbr>=3BWorkaro= >und with d=3D
>=3B >=3Bifferent cm3cg switches (e.g. -O0 vs. -O1 vs.= > -O2?)<=3Bbr>=3B<=3Bbr>=3B&=3Bnbsp=3D3B- Jay<=3Bbr=3D
>= >=3B >=3B>=3B<=3Bbr>=3B<=3Bbr>=3B&=3Bgt=3D3B To: jay.krell at co= >rnell.edu<=3Bbr>=3B&=3Bgt=3D3B Date: Mon=3D2C 27 Dec 201=3D
>= >=3B >=3B0 02:38:10 -0800<=3Bbr>=3B&=3Bgt=3D3B From: mika at async.cal= >tech.edu<=3Bbr>=3B&=3Bgt=3D3B CC: m3dev=3D
>=3B >=3Bel at elegos= >oft.com<=3Bbr>=3B&=3Bgt=3D3B Subject: Re: [M3devel] compiler problem= >s on Snow=3D
>=3B >=3B Leopard<=3Bbr>=3B&=3Bgt=3D3B <=3Bbr&= >gt=3B&=3Bgt=3D3B Jay K writes:<=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3= >B--_6f82bcb2-663=3D
>=3B >=3Bf-4046-87f2-073a1528a819_<=3Bbr>=3B= >&=3Bgt=3D3B &=3Bgt=3D3BContent-Type: text/plain=3D3B chars=3D
>= >=3B >=3Bet=3D3D"iso-8859-1"<=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3BCon= >tent-Transfer-Encoding: quoted-printab=3D
>=3B >=3Ble<=3Bbr>=3B&= >amp=3Bgt=3D3B &=3Bgt=3D3B<=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3B<= >=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3BCan you put all your c=3D
>=3B= > >=3Bode in our CVS repository?<=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3= >B<=3Bbr>=3B&=3Bgt=3D3B <=3Bbr>=3B&=3Bgt=3D3B I can't pu=3D>>=3B >=3Bt all the code I work with in m3devel's repository: some of &= >lt=3Bbr>=3B&=3Bgt=3D3B it i=3D
>=3B >=3Bs proprietary.<=3Bbr&= >gt=3B&=3Bgt=3D3B <=3Bbr>=3B&=3Bgt=3D3B The Scheme code however I = >have no restr=3D
>=3B >=3Bictions on distributing (that's<=3Bbr>= >=3B&=3Bgt=3D3B what's got problems in this case)=3D
>=3B >=3B. I= >t is however large and unwieldy and<=3Bbr>=3B&=3Bgt=3D3B I'd like to= > have other pe=3D
>=3B >=3Bople's suggestions for how to submit/inco= >rporate<=3Bbr>=3B&=3Bgt=3D3B it with CM3 befo=3D
>=3B >=3Bre = >I just dump it in the repository. It also overlaps a bit<=3Bbr>=3B&= >=3Bgt=3D3B with=3D
>=3B >=3B "caltech-parser"=3D2C so there should p= >robably be a "caltech-common"<=3Bbr>=3B&=3Bgt=3D
>=3B >=3B=3D= >3B package for the overlaps?<=3Bbr>=3B&=3Bgt=3D3B <=3Bbr>=3B&= >=3Bgt=3D3B If you run the following=3D
>=3B >=3B commands in a fresh= > directory=3D2C you should get<=3Bbr>=3B&=3Bgt=3D3B to the error I e= >=3D
>=3B >=3Bmailed:<=3Bbr>=3B&=3Bgt=3D3B <=3Bbr>=3B&= >=3Bgt=3D3B setenv CM3 1<=3Bbr>=3B&=3Bgt=3D3B cvs -d :pserver:anonymo= >=3D
>=3B >=3Bus at pluto.gcapltd.com:/home/gcap-public-cvs up -d .<= >=3Bbr>=3B&=3Bgt=3D3B make regress =3D
>=3B >=3B # GNU make : = >'gmake regress' on BSD<=3Bbr>=3B&=3Bgt=3D3B cd mscheme/sstubgen/exam= >ple=3D
>=3B >=3B<=3Bbr>=3B&=3Bgt=3D3B cm3 -x<=3Bbr>=3B&am= >p=3Bgt=3D3B <=3Bbr>=3B&=3Bgt=3D3B Mika<=3Bbr>=3B&=3Bgt= >=3D3B <=3Bbr>=3B&=3Bgt=3D3B <=3Bbr>=3B =3D
>=3B >=3B > = > <=3B/body>=3B
>=3B >=3B<=3B/html>=3B=3D
> >=3B >= >=3B
>=3B >=3B--_9ece0c56-2524-4879-9a65-2407b1dbf664_--
> = > >= > >--_d61e805f-545e-4b3d-abe7-a20c582bec2e_-- From jay.krell at cornell.edu Mon Dec 27 12:34:09 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 11:34:09 +0000 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: <20101227112424.C13401A205B@async.async.caltech.edu> References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , , ,,<20101227101421.38A6A1A205B@async.async.caltech.edu>, , ,,, , ,,<20101227103810.94DF21A205B@async.async.caltech.edu>, , , , , , , , <20101227105859.8E1F21A205B@async.async.caltech.edu>, , , , <20101227112424.C13401A205B@async.async.caltech.edu> Message-ID: I started over. rm -rf various changed toolset to I386_DARWIN, hopefully correctly cvs -z3 upd -dAP export CM3=1 gnumake regress .. lots of stuf compiles .. .. and then: ===> mscheme/sstubgen/program --- building in I386_DARWIN --- new source -> compiling Main.m3 -> linking sstubgen i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/libmscheme.a: No such file or directory m3_link => 1 linker failed linking: sstubgen Fatal Error: package build failed jbook2:gcap-public-cvs jay$ cd mscheme/ jbook2:mscheme jay$ ls CVS doc interactive modula3scheme schemereadline src threads I386_DARWIN examples interactive_r scheme-lib schemesig sstubgen jbook2:mscheme jay$ cm3 --- building in I386_DARWIN --- ignoring ../src/m3overrides "/Users/jay/dev2/gcap-public-cvs/mscheme/src/sgenerics.tmpl", line 3: quake runtime error: undefined variable: TOP --procedure-- -line- -file--- template 3 /Users/jay/dev2/gcap-public-cvs/mscheme/src/sgenerics.tmpl include_dir 69 /Users/jay/dev2/gcap-public-cvs/mscheme/src/m3makefile 4 /Users/jay/dev2/gcap-public-cvs/mscheme/I386_DARWIN/m3make.args Fatal Error: package build failed jbook2:mscheme jay$ jbook2:mscheme jay$ cm3 -DTOP=/dev2/gcap-public-cvs --- building in I386_DARWIN --- ignoring ../src/m3overrides "/Users/jay/dev2/gcap-public-cvs/mscheme/src/m3makefile", line 73: quake runtime error: undefined variable: Netobj --procedure-- -line- -file--- include_dir 73 /Users/jay/dev2/gcap-public-cvs/mscheme/src/m3makefile 5 /Users/jay/dev2/gcap-public-cvs/mscheme/I386_DARWIN/m3make.args Fatal Error: package build failed j jbook2:mscheme jay$ cm3 -DTOP=/dev2/gcap-public-cvs -x --- building in I386_DARWIN --- ignoring override("mscheme", "/dev2/gcap-public-cvs") new source -> compiling SchemeEnvironment_Public_v1.m3 "../I386_DARWIN/SchemeEnvironment_Public_v1.m3", line 546: illegal INTEGER literal, zero used "../I386_DARWIN/SchemeEnvironment_Public_v1.m3", line 547: illegal INTEGER literal, zero used 2 errors encountered compilation failed => not building library "libmscheme.a" Fatal Error: package build failed jbook2:mscheme jay$ minArgs_arg := StubLib.InInteger(c, rep, 0, 9223372036854775807); maxArgs_arg := StubLib.InInteger(c, rep, 0, 9223372036854775807); > To: jay.krell at cornell.edu > Date: Mon, 27 Dec 2010 03:24:24 -0800 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] compiler problems on Snow Leopard > > Don't think you need m3texthack. > > The first thing that happens when you run make ought to be that a file > called ".top" is created at the top level of the repository, with a > definition of TOP. This file is included by the top-level m3overrides, > which is included by every m3overrides when you run with -x. > > Mika > > Jay K writes: > >--_d61e805f-545e-4b3d-abe7-a20c582bec2e_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > >something wanted cit_util. > > > > > > > >--- building in AMD64_DARWIN --- > > > > > > > >ignoring ../src/m3overrides > > > > > > > >"/Users/jay/dev2/gcap-public-cvs/cit_util/src/texthack.tmpl"=2C line 2: qua= > >ke runtime error: undefined variable: TOP > > > > > > > >--procedure-- -line- -file--- > > > >template 2 /Users/jay/dev2/gcap-public-cvs/cit_util/src/texthac= > >k.tmpl > > > >include_dir 13 /Users/jay/dev2/gcap-public-cvs/cit_util/src/m3makef= > >ile > > > > 4 /Users/jay/dev2/gcap-public-cvs/cit_util/AMD64_DARWI= > >N/m3make.args > > > > > > > > > > > >% $Id: texthack.tmpl=2Cv 1.7 2002/12/13 22:20:12 kp Exp $ > > > >_M3TEXTHACK =3D TOP & "/m3texthack/" & BUILD_DIR & "/m3texthack" > > > >_DERIVGEN =3D TOP & "/m3texthack/src/derivgen.sh" > > > > > >I don't have m3texthack anywhere I think. > > > > - Jay > > > >From: jay.krell at cornell.edu > >To: mika at async.caltech.edu > >Date: Mon=2C 27 Dec 2010 11:04:11 +0000 > >CC: m3devel at elegosoft.com > >Subject: Re: [M3devel] compiler problems on Snow Leopard > > > > > > > > > > > > > > > > > >Yes=2C overrides and standalone is a problem. > > > >Maybe I'll get around to addressing this for the next release. > > > >A proposed solution is: > > go back to mostly the old method: hard coded runpaths=2C with much overla= > >p for global builds (to be shipped/installed)=2C monstrously long paths for= > > local builds (not to be shipped)=2C AND link upon install > > Some systems allow for "slight relinking"=2C including Solaris and Darwin= > >=2C where just the paths get edited. That would be nicer. > > > > The old approach had problems too. > > > > If you build the system yourself=2C I think you automatically already to= > >day get what is described -- hardcoded run paths=2C with much overlap for g= > >lobal builds. > > > > > > - Jay > > > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] compiler problems on Snow Leopard=20 > >> Date: Mon=2C 27 Dec 2010 02:58:59 -0800 > >> From: mika at async.caltech.edu > >>=20 > >> Run cm3 -x instead of just cm3. > >>=20 > >> Did you get an error compiling package "mscheme"? I certainly have a > >> libmscheme.a in there. > >>=20 > >> /m3overrides has build_standalone() in it. > >>=20 > >> I normally didn't use build_standalone() but something has changed in > >> how the system searches for shared libs when building with overrides > >> and this was the easiest solution (at least for now). > >>=20 > >> Mika > >>=20 > >> Jay K writes: > >> >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ > >> >Content-Type: text/plain=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> >I can't quite reproduce it=3D2C but I can compile a bunch of your code. > >> > > >> > > >> >new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libscheme-lib.= > >a" =3D > >> >-> archiving libsstubgen.a > >> > > >> >=3D3D=3D3D=3D3D> mscheme/sstubgen/program > >> >--- building in I386_DARWIN --- > >> > > >> > -> linking sstubgen > >> >i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/= > >lib=3D > >> >mscheme.a: No such file or directory > >> > m3_link =3D3D> 1 > >> >linker failed linking: sstubgen > >> >Fatal Error: package build failed > >> > > >> >jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example > >> >jbook2:example jay$ c=3D2C3 > >> >-bash: c=3D2C3: command not found > >> >jbook2:example jay$ cm3 > >> >--- building in I386_DARWIN --- > >> > > >> >ignoring ../src/m3overrides > >> > > >> >"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3makefile= > >"=3D > >> >=3D2C line 3: quake runtime error: unable to open "/cm3/pkg/mscheme/I386= > >_DARW=3D > >> >IN/.M3EXPORTS" for reading > >> > > >> >--procedure-- -line- -file--- > >> >import -- > >> >include_dir 3 /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/= > >exa=3D > >> >mple/src/m3makefile > >> > > >> > > >> > - Jay > >> > > >> > > >> > > >> > > >> > > >> > > >> >From: jay.krell at cornell.edu > >> >To: mika at async.caltech.edu > >> >Date: Mon=3D2C 27 Dec 2010 10:46:55 +0000 > >> >CC: m3devel at elegosoft.com > >> >Subject: Re: [M3devel] compiler problems on Snow Leopard > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> >aside: overlap with caltech_parser: > >> >if you can come up with a merged version that works with both=3D2C good > >> >If you can't=3D2C I think you have to rename one or the other. > >> > > >> >Maybe someday we can support some sort of hierarchy that automatically m= > >aps=3D > >> > to/from the file system hierarchy... > >> > > >> >I'll try to reproduce the problem. > >> > > >> >All targets? > >> >Workaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) > >> > > >> > - Jay > >> > > >> > > >> >> To: jay.krell at cornell.edu > >> >> Date: Mon=3D2C 27 Dec 2010 02:38:10 -0800 > >> >> From: mika at async.caltech.edu > >> >> CC: m3devel at elegosoft.com > >> >> Subject: Re: [M3devel] compiler problems on Snow Leopard > >> >>=3D20 > >> >> Jay K writes: > >> >> >--_6f82bcb2-663f-4046-87f2-073a1528a819_ > >> >> >Content-Type: text/plain=3D3B charset=3D3D"iso-8859-1" > >> >> >Content-Transfer-Encoding: quoted-printable > >> >> > > >> >> > > >> >> >Can you put all your code in our CVS repository? > >> >> > > >> >>=3D20 > >> >> I can't put all the code I work with in m3devel's repository: some of= > >=3D20 > >> >> it is proprietary. > >> >>=3D20 > >> >> The Scheme code however I have no restrictions on distributing (that's > >> >> what's got problems in this case). It is however large and unwieldy a= > >nd > >> >> I'd like to have other people's suggestions for how to submit/incorpor= > >ate > >> >> it with CM3 before I just dump it in the repository. It also overlaps= > > a =3D > >> >bit > >> >> with "caltech-parser"=3D2C so there should probably be a "caltech-comm= > >on" > >> >> package for the overlaps? > >> >>=3D20 > >> >> If you run the following commands in a fresh directory=3D2C you should= > > get > >> >> to the error I emailed: > >> >>=3D20 > >> >> setenv CM3 1 > >> >> cvs -d :pserver:anonymous at pluto.gcapltd.com:/home/gcap-public-cvs up -= > >d . > >> >> make regress # GNU make : 'gmake regress' on BSD > >> >> cd mscheme/sstubgen/example > >> >> cm3 -x > >> >>=3D20 > >> >> Mika > >> >>=3D20 > >> >>=3D20 > >> > =3D > >> > > >> >--_9ece0c56-2524-4879-9a65-2407b1dbf664_ > >> >Content-Type: text/html=3B charset=3D"iso-8859-1" > >> >Content-Transfer-Encoding: quoted-printable > >> > > >> > > >> > > >> > > >> > > >> > > >> >I can't quite reproduce it=3D2C but I can compile a bunch of your code.<= > >br> >> >r>
new "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN/libschem= > >e-l=3D > >> >ib.a" ->=3D3B archiving libsstubgen.a

=3D3D=3D3D=3D3D>=3D3B m= > >scheme/sstubg=3D > >> >en/program
--- building in I386_DARWIN ---

 =3D3B->=3D3B= > > linkin=3D > >> >g sstubgen
i686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mschem= > >e/I=3D > >> >386_DARWIN/libmscheme.a: No such file or directory
 =3D3B m3_link= > > =3D3D&=3D > >> >gt=3D3B 1
linker failed linking: sstubgen
Fatal Error: package bui= > >ld fa=3D > >> >iled

jbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example
j= > >boo=3D > >> >k2:example jay$ c=3D2C3
-bash: c=3D2C3: command not found
jbook2:e= > >xample =3D > >> >jay$ cm3
--- building in I386_DARWIN ---

ignoring ../src/m3ove= > >rri=3D > >> >des

"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src= > >/m3=3D > >> >makefile"=3D2C line 3: quake runtime error: unable to open "/cm3/pkg/msc= > >heme/=3D > >> >I386_DARWIN/.M3EXPORTS" for reading

--procedure-- =3D3B -line= > >-&nbs=3D > >> >p=3D3B -file---
import =3D3B =3D3B =3D3B =3D3B = > >=3D3B =3D3B&nbs=3D > >> >p=3D3B =3D3B =3D3B =3D3B =3D3B =3D3B -- =3D3B &l= > >t=3D3Bbuiltin>=3D3B=3D > >> >
include_dir =3D3B =3D3B =3D3B =3D3B =3D3B = > >=3D3B =3D3B&nbs=3D > >> >p=3D3B 3 =3D3B /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/exam= > >ple/src=3D > >> >/m3makefile


 =3D3B- Jay






>=3D3D"s=3D > >> >topSpelling">From: jay.krell at cornell.edu
To: mika at async.caltech.edu >r>D=3D > >> >ate: Mon=3D2C 27 Dec 2010 10:46:55 +0000
CC: m3devel at elegosoft.com >>Subj=3D > >> >ect: Re: [M3devel] compiler problems on Snow Leopard

> >> > > >> > >=3D3Dunicode=3D > >> >"> > >> > > >> > > >> > > >> > > >> >aside: overlap with caltech_parser:
if you can come up with a merged = > >ver=3D > >> >sion that works with both=3D2C good
If you can't=3D2C I think you hav= > >e to re=3D > >> >name one or the other.

Maybe someday we can support some sort of = > >hie=3D > >> >rarchy that automatically maps to/from the file system hierarchy...
<= > >br>=3D > >> >I'll try to reproduce the problem.

All targets?
Workaround wit= > >h d=3D > >> >ifferent cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?)

 =3D3B- J= > >ay >> >>

>=3D3B To: jay.krell at cornell.edu
>=3D3B Date: Mon=3D2C 2= > >7 Dec 201=3D > >> >0 02:38:10 -0800
>=3D3B From: mika at async.caltech.edu
>=3D3B CC= > >: m3dev=3D > >> >el at elegosoft.com
>=3D3B Subject: Re: [M3devel] compiler problems on= > > Snow=3D > >> > Leopard
>=3D3B
>=3D3B Jay K writes:
>=3D3B >=3D3B--_6= > >f82bcb2-663=3D > >> >f-4046-87f2-073a1528a819_
>=3D3B >=3D3BContent-Type: text/plain= > >=3D3B chars=3D > >> >et=3D3D"iso-8859-1"
>=3D3B >=3D3BContent-Transfer-Encoding: quote= > >d-printab=3D > >> >le
>=3D3B >=3D3B
>=3D3B >=3D3B
>=3D3B >=3D3BCan you= > > put all your c=3D > >> >ode in our CVS repository?
>=3D3B >=3D3B
>=3D3B
>=3D3B= > > I can't pu=3D > >> >t all the code I work with in m3devel's repository: some of
>=3D3B= > > it i=3D > >> >s proprietary.
>=3D3B
>=3D3B The Scheme code however I have n= > >o restr=3D > >> >ictions on distributing (that's
>=3D3B what's got problems in this = > >case)=3D > >> >. It is however large and unwieldy and
>=3D3B I'd like to have oth= > >er pe=3D > >> >ople's suggestions for how to submit/incorporate
>=3D3B it with CM3= > > befo=3D > >> >re I just dump it in the repository. It also overlaps a bit
>=3D3B= > > with=3D > >> > "caltech-parser"=3D2C so there should probably be a "caltech-common" >>>=3D > >> >=3D3B package for the overlaps?
>=3D3B
>=3D3B If you run the = > >following=3D > >> > commands in a fresh directory=3D2C you should get
>=3D3B to the er= > >ror I e=3D > >> >mailed:
>=3D3B
>=3D3B setenv CM3 1
>=3D3B cvs -d :pserve= > >r:anonymo=3D > >> >us at pluto.gcapltd.com:/home/gcap-public-cvs up -d .
>=3D3B make regr= > >ess =3D > >> > # GNU make : 'gmake regress' on BSD
>=3D3B cd mscheme/sstubgen/ex= > >ample=3D > >> >
>=3D3B cm3 -x
>=3D3B
>=3D3B Mika
>=3D3B
&= > >gt=3D3B
=3D > >> > > >> >=3D > >> > > >> >--_9ece0c56-2524-4879-9a65-2407b1dbf664_-- > > = > > > >--_d61e805f-545e-4b3d-abe7-a20c582bec2e_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > > > > > >something wanted cit_util.
> >
> >--- building in AMD64_DARWIN ---
> >
> >ignoring ../src/m3overrides
> >
> >"/Users/jay/dev2/gcap-public-cvs/cit_util/src/texthack.tmpl"=2C line 2: qua= > >ke runtime error: undefined variable: TOP
> >
> >--procedure-- =3B -line- =3B -file---
> >template =3B =3B =3B =3B =3B =3B =3B =3B&nb= > >sp=3B =3B =3B 2 =3B /Users/jay/dev2/gcap-public-cvs/cit_util/sr= > >c/texthack.tmpl
> >include_dir =3B =3B =3B =3B =3B =3B =3B 13 = > >=3B /Users/jay/dev2/gcap-public-cvs/cit_util/src/m3makefile
> > =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= > >sp=3B =3B =3B =3B =3B =3B =3B =3B =3B = > >=3B 4 =3B /Users/jay/dev2/gcap-public-cvs/cit_util/AMD64_DARWIN/m3make.= > >args
> >
> >
> >% $Id: texthack.tmpl=2Cv 1.7 2002/12/13 22:20:12 kp Exp $
> >_M3TEXTHACK =3D TOP &=3B "/m3texthack/" &=3B BUILD_DIR &=3B "/m3te= > >xthack"
> >_DERIVGEN =3B =3B =3D TOP &=3B "/m3texthack/src/derivgen.sh"
> >
I don't have m3texthack anywhere I think.

 =3B- Jay

<= > >hr id=3D"stopSpelling">From: jay.krell at cornell.edu
To: mika at async.caltec= > >h.edu
Date: Mon=2C 27 Dec 2010 11:04:11 +0000
CC: m3devel at elegosoft.c= > >om
Subject: Re: [M3devel] compiler problems on Snow Leopard

> > > > >"> > > > > > > > > > >Yes=2C overrides and standalone is a problem.

Maybe I'll get around = > >to addressing this for the next release.

A proposed solution is:
= > > =3B go back to mostly the old method: hard coded runpaths=2C with much= > > overlap for global builds (to be shipped/installed)=2C monstrously long pa= > >ths for local builds (not to be shipped)=2C AND link upon install
 = > >=3B Some systems allow for "slight relinking"=2C including Solaris and Darw= > >in=2C where just the paths get edited. That would be nicer.

 =3B= > > The old approach had problems too.

 =3B =3B If you build th= > >e system yourself=2C I think you automatically already today get what is de= > >scribed -- hardcoded run paths=2C with much overlap for global builds.
<= > >br>
 =3B- Jay

>=3B To: jay.krell at cornell.edu
>=3B CC: = > >m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] compiler problems on= > > Snow Leopard
>=3B Date: Mon=2C 27 Dec 2010 02:58:59 -0800
>=3B = > >From: mika at async.caltech.edu
>=3B
>=3B Run cm3 -x instead of jus= > >t cm3.
>=3B
>=3B Did you get an error compiling package "mscheme= > >"? I certainly have a
>=3B libmscheme.a in there.
>=3B
>= > >=3B <=3Btop>=3B/m3overrides has build_standalone() in it.
>=3B >>>=3B I normally didn't use build_standalone() but something has changed = > >in
>=3B how the system searches for shared libs when building with ove= > >rrides
>=3B and this was the easiest solution (at least for now).
&= > >gt=3B
>=3B Mika
>=3B
>=3B Jay K writes:
>=3B >= > >=3B--_9ece0c56-2524-4879-9a65-2407b1dbf664_
>=3B >=3BContent-Type: t= > >ext/plain=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encodi= > >ng: quoted-printable
>=3B >=3B
>=3B >=3B
>=3B >=3BI ca= > >n't quite reproduce it=3D2C but I can compile a bunch of your code.
>= > >=3B >=3B
>=3B >=3B
>=3B >=3Bnew "/dev2/gcap-public-cvs/msch= > >eme/scheme-lib/I386_DARWIN/libscheme-lib.a" =3D
>=3B >=3B->=3B arc= > >hiving libsstubgen.a
>=3B >=3B
>=3B >=3B=3D3D=3D3D=3D3D>=3B= > > mscheme/sstubgen/program
>=3B >=3B--- building in I386_DARWIN --- >r>>=3B >=3B
>=3B >=3B ->=3B linking sstubgen
>=3B >=3Bi= > >686-apple-darwin9-gcc-4.0.1: /dev2/gcap-public-cvs/mscheme/I386_DARWIN/lib= > >=3D
>=3B >=3Bmscheme.a: No such file or directory
>=3B >=3B = > >m3_link =3D3D>=3B 1
>=3B >=3Blinker failed linking: sstubgen
&g= > >t=3B >=3BFatal Error: package build failed
>=3B >=3B
>=3B >= > >=3Bjbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example
>=3B >=3B= > >jbook2:example jay$ c=3D2C3
>=3B >=3B-bash: c=3D2C3: command not fou= > >nd
>=3B >=3Bjbook2:example jay$ cm3
>=3B >=3B--- building in = > >I386_DARWIN ---
>=3B >=3B
>=3B >=3Bignoring ../src/m3override= > >s
>=3B >=3B
>=3B >=3B"/Users/jay/dev2/gcap-public-cvs/mscheme= > >/sstubgen/example/src/m3makefile"=3D
>=3B >=3B=3D2C line 3: quake ru= > >ntime error: unable to open "/cm3/pkg/mscheme/I386_DARW=3D
>=3B >=3B= > >IN/.M3EXPORTS" for reading
>=3B >=3B
>=3B >=3B--procedure-- = > >-line- -file---
>=3B >=3Bimport -- <=3Bbuiltin>=3B= > >
>=3B >=3Binclude_dir 3 /Users/jay/dev2/gcap-public-cvs/msc= > >heme/sstubgen/exa=3D
>=3B >=3Bmple/src/m3makefile
>=3B >=3B >r>>=3B >=3B
>=3B >=3B - Jay
>=3B >=3B
>=3B >=3B >>>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B= > > >=3BFrom: jay.krell at cornell.edu
>=3B >=3BTo: mika at async.caltech.e= > >du
>=3B >=3BDate: Mon=3D2C 27 Dec 2010 10:46:55 +0000
>=3B >= > >=3BCC: m3devel at elegosoft.com
>=3B >=3BSubject: Re: [M3devel] compile= > >r problems on Snow Leopard
>=3B >=3B
>=3B >=3B
>=3B >= > >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B
= > >>=3B >=3B
>=3B >=3Baside: overlap with caltech_parser:
>=3B= > > >=3Bif you can come up with a merged version that works with both=3D2C g= > >ood
>=3B >=3BIf you can't=3D2C I think you have to rename one or the= > > other.
>=3B >=3B
>=3B >=3BMaybe someday we can support some = > >sort of hierarchy that automatically maps=3D
>=3B >=3B to/from the f= > >ile system hierarchy...
>=3B >=3B
>=3B >=3BI'll try to reprod= > >uce the problem.
>=3B >=3B
>=3B >=3BAll targets?
>=3B &g= > >t=3BWorkaround with different cm3cg switches (e.g. -O0 vs. -O1 vs. -O2?) >>>=3B >=3B
>=3B >=3B - Jay
>=3B >=3B
>=3B >=3B
= > >>=3B >=3B>=3B To: jay.krell at cornell.edu
>=3B >=3B>=3B Date: = > >Mon=3D2C 27 Dec 2010 02:38:10 -0800
>=3B >=3B>=3B From: mika at async= > >.caltech.edu
>=3B >=3B>=3B CC: m3devel at elegosoft.com
>=3B >= > >=3B>=3B Subject: Re: [M3devel] compiler problems on Snow Leopard
>= > >=3B >=3B>=3B=3D20
>=3B >=3B>=3B Jay K writes:
>=3B >=3B= > >>=3B >=3B--_6f82bcb2-663f-4046-87f2-073a1528a819_
>=3B >=3B>= > >=3B >=3BContent-Type: text/plain=3D3B charset=3D3D"iso-8859-1"
>=3B = > >>=3B>=3B >=3BContent-Transfer-Encoding: quoted-printable
>=3B &g= > >t=3B>=3B >=3B
>=3B >=3B>=3B >=3B
>=3B >=3B>=3B >= > >=3BCan you put all your code in our CVS repository?
>=3B >=3B>=3B = > >>=3B
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B I can't put all t= > >he code I work with in m3devel's repository: some of=3D20
>=3B >=3B&= > >gt=3B it is proprietary.
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B= > > The Scheme code however I have no restrictions on distributing (that's
= > >>=3B >=3B>=3B what's got problems in this case). It is however large= > > and unwieldy and
>=3B >=3B>=3B I'd like to have other people's su= > >ggestions for how to submit/incorporate
>=3B >=3B>=3B it with CM3 = > >before I just dump it in the repository. It also overlaps a =3D
>=3B = > >>=3Bbit
>=3B >=3B>=3B with "caltech-parser"=3D2C so there should= > > probably be a "caltech-common"
>=3B >=3B>=3B package for the over= > >laps?
>=3B >=3B>=3B=3D20
>=3B >=3B>=3B If you run the fol= > >lowing commands in a fresh directory=3D2C you should get
>=3B >=3B&g= > >t=3B to the error I emailed:
>=3B >=3B>=3B=3D20
>=3B >=3B&g= > >t=3B setenv CM3 1
>=3B >=3B>=3B cvs -d :pserver:anonymous at pluto.gc= > >apltd.com:/home/gcap-public-cvs up -d .
>=3B >=3B>=3B make regress= > > # GNU make : 'gmake regress' on BSD
>=3B >=3B>=3B cd mscheme/s= > >stubgen/example
>=3B >=3B>=3B cm3 -x
>=3B >=3B>=3B=3D20 >r>>=3B >=3B>=3B Mika
>=3B >=3B>=3B=3D20
>=3B >= > >=3B>=3B=3D20
>=3B >=3B =3D >r>>=3B >=3B
>=3B &= > >gt=3B--_9ece0c56-2524-4879-9a65-2407b1dbf664_
>=3B >=3BContent-Type:= > > text/html=3B charset=3D"iso-8859-1"
>=3B >=3BContent-Transfer-Encod= > >ing: quoted-printable
>=3B >=3B
>=3B >=3B<=3Bhtml>=3B
= > >>=3B >=3B<=3Bhead>=3B
>=3B >=3B<=3Bstyle>=3B<=3B!-- >>>=3B >=3B.hmmessage P
>=3B >=3B{
>=3B >=3Bmargin:0px=3D3= > >B
>=3B >=3Bpadding:0px
>=3B >=3B}
>=3B >=3Bbody.hmmess= > >age
>=3B >=3B{
>=3B >=3Bfont-size: 10pt=3D3B
>=3B >=3B= > >font-family:Tahoma
>=3B >=3B}
>=3B >=3B-->=3B<=3B/style&g= > >t=3B
>=3B >=3B<=3B/head>=3B
>=3B >=3B<=3Bbody class=3D3= > >D'hmmessage'>=3B
>=3B >=3BI can't quite reproduce it=3D2C but I ca= > >n compile a bunch of your code.<=3Bbr>=3B<=3Bb=3D
>=3B >=3Br&g= > >t=3B<=3Bbr>=3Bnew "/dev2/gcap-public-cvs/mscheme/scheme-lib/I386_DARWIN= > >/libscheme-l=3D
>=3B >=3Bib.a" -&=3Bgt=3D3B archiving libsstubgen= > >.a<=3Bbr>=3B<=3Bbr>=3B=3D3D=3D3D=3D3D&=3Bgt=3D3B mscheme/sstubg= > >=3D
>=3B >=3Ben/program<=3Bbr>=3B--- building in I386_DARWIN ---= > ><=3Bbr>=3B<=3Bbr>=3B&=3Bnbsp=3D3B-&=3Bgt=3D3B linkin=3D
&g= > >t=3B >=3Bg sstubgen<=3Bbr>=3Bi686-apple-darwin9-gcc-4.0.1: /dev2/gcap= > >-public-cvs/mscheme/I=3D
>=3B >=3B386_DARWIN/libmscheme.a: No such f= > >ile or directory<=3Bbr>=3B&=3Bnbsp=3D3B m3_link =3D3D&=3B=3D
&= > >gt=3B >=3Bgt=3D3B 1<=3Bbr>=3Blinker failed linking: sstubgen<=3Bbr&= > >gt=3BFatal Error: package build fa=3D
>=3B >=3Biled<=3Bbr>=3B<= > >=3Bbr>=3Bjbook2:gcap-public-cvs jay$ cd mscheme/sstubgen/example<=3Bbr&= > >gt=3Bjboo=3D
>=3B >=3Bk2:example jay$ c=3D2C3<=3Bbr>=3B-bash: c= > >=3D2C3: command not found<=3Bbr>=3Bjbook2:example =3D
>=3B >=3Bj= > >ay$ cm3<=3Bbr>=3B--- building in I386_DARWIN ---<=3Bbr>=3B<=3Bbr&= > >gt=3Bignoring ../src/m3overri=3D
>=3B >=3Bdes<=3Bbr>=3B<=3Bbr&= > >gt=3B"/Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src/m3=3D >>>=3B >=3Bmakefile"=3D2C line 3: quake runtime error: unable to open "/= > >cm3/pkg/mscheme/=3D
>=3B >=3BI386_DARWIN/.M3EXPORTS" for reading<= > >=3Bbr>=3B<=3Bbr>=3B--procedure--&=3Bnbsp=3D3B -line-&=3Bnbs=3D<= > >br>>=3B >=3Bp=3D3B -file---<=3Bbr>=3Bimport&=3Bnbsp=3D3B&=3Bn= > >bsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&am= > >p=3Bnbs=3D
>=3B >=3Bp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbs= > >p=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B --&=3Bnbsp=3D3B &=3Blt=3D3Bbui= > >ltin&=3Bgt=3D3B=3D
>=3B >=3B<=3Bbr>=3Binclude_dir&=3Bnbsp= > >=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbsp=3D3B&= > >=3Bnbsp=3D3B&=3Bnbsp=3D3B&=3Bnbs=3D
>=3B >=3Bp=3D3B 3&=3Bnb= > >sp=3D3B /Users/jay/dev2/gcap-public-cvs/mscheme/sstubgen/example/src=3D
= > >>=3B >=3B/m3makefile<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B&=3Bnb= > >sp=3D3B- Jay<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bb= > >r>=3B<=3Bbr>=3B<=3Bbr>=3B<=3Bhr id=3D3D"s=3D
>=3B >=3Bto= > >pSpelling">=3BFrom: jay.krell at cornell.edu<=3Bbr>=3BTo: mika at async.cal= > >tech.edu<=3Bbr>=3BD=3D
>=3B >=3Bate: Mon=3D2C 27 Dec 2010 10:46:= > >55 +0000<=3Bbr>=3BCC: m3devel at elegosoft.com<=3Bbr>=3BSubj=3D
>= > >=3B >=3Bect: Re: [M3devel] compiler problems on Snow Leopard<=3Bbr>= > >=3B<=3Bbr>=3B
>=3B >=3B
>=3B >=3B<=3Bmeta http-equiv=3D= > >3D"Content-Type" content=3D3D"text/html=3D3B charset=3D3Dunicode=3D
>= > >=3B >=3B">=3B
>=3B >=3B<=3Bmeta name=3D3D"Generator" content= > >=3D3D"Microsoft SafeHTML">=3B
>=3B >=3B<=3Bstyle>=3B
>=3B= > > >=3B.ExternalClass .ecxhmmessage P
>=3B >=3B{padding:0px=3D3B} >>>=3B >=3B.ExternalClass body.ecxhmmessage
>=3B >=3B{font-size:1= > >0pt=3D3Bfont-family:Tahoma=3D3B}
>=3B >=3B
>=3B >=3B<=3B/st= > >yle>=3B
>=3B >=3B
>=3B >=3B
>=3B >=3Baside: overlap = > >with caltech_parser:<=3Bbr>=3Bif you can come up with a merged ver=3D >r>>=3B >=3Bsion that works with both=3D2C good<=3Bbr>=3BIf you can'= > >t=3D2C I think you have to re=3D
>=3B >=3Bname one or the other.<= > >=3Bbr>=3B<=3Bbr>=3BMaybe someday we can support some sort of hie=3D >r>>=3B >=3Brarchy that automatically maps to/from the file system hiera= > >rchy...<=3Bbr>=3B<=3Bbr>=3B=3D
>=3B >=3BI'll try to reproduc= > >e the problem.<=3Bbr>=3B<=3Bbr>=3BAll targets?<=3Bbr>=3BWorkaro= > >und with d=3D
>=3B >=3Bifferent cm3cg switches (e.g. -O0 vs. -O1 vs.= > > -O2?)<=3Bbr>=3B<=3Bbr>=3B&=3Bnbsp=3D3B- Jay<=3Bbr=3D
>= > >=3B >=3B>=3B<=3Bbr>=3B<=3Bbr>=3B&=3Bgt=3D3B To: jay.krell at co= > >rnell.edu<=3Bbr>=3B&=3Bgt=3D3B Date: Mon=3D2C 27 Dec 201=3D
>= > >=3B >=3B0 02:38:10 -0800<=3Bbr>=3B&=3Bgt=3D3B From: mika at async.cal= > >tech.edu<=3Bbr>=3B&=3Bgt=3D3B CC: m3dev=3D
>=3B >=3Bel at elegos= > >oft.com<=3Bbr>=3B&=3Bgt=3D3B Subject: Re: [M3devel] compiler problem= > >s on Snow=3D
>=3B >=3B Leopard<=3Bbr>=3B&=3Bgt=3D3B <=3Bbr&= > >gt=3B&=3Bgt=3D3B Jay K writes:<=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3= > >B--_6f82bcb2-663=3D
>=3B >=3Bf-4046-87f2-073a1528a819_<=3Bbr>=3B= > >&=3Bgt=3D3B &=3Bgt=3D3BContent-Type: text/plain=3D3B chars=3D
>= > >=3B >=3Bet=3D3D"iso-8859-1"<=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3BCon= > >tent-Transfer-Encoding: quoted-printab=3D
>=3B >=3Ble<=3Bbr>=3B&= > >amp=3Bgt=3D3B &=3Bgt=3D3B<=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3B<= > >=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3BCan you put all your c=3D
>=3B= > > >=3Bode in our CVS repository?<=3Bbr>=3B&=3Bgt=3D3B &=3Bgt=3D3= > >B<=3Bbr>=3B&=3Bgt=3D3B <=3Bbr>=3B&=3Bgt=3D3B I can't pu=3D >>>=3B >=3Bt all the code I work with in m3devel's repository: some of &= > >lt=3Bbr>=3B&=3Bgt=3D3B it i=3D
>=3B >=3Bs proprietary.<=3Bbr&= > >gt=3B&=3Bgt=3D3B <=3Bbr>=3B&=3Bgt=3D3B The Scheme code however I = > >have no restr=3D
>=3B >=3Bictions on distributing (that's<=3Bbr>= > >=3B&=3Bgt=3D3B what's got problems in this case)=3D
>=3B >=3B. I= > >t is however large and unwieldy and<=3Bbr>=3B&=3Bgt=3D3B I'd like to= > > have other pe=3D
>=3B >=3Bople's suggestions for how to submit/inco= > >rporate<=3Bbr>=3B&=3Bgt=3D3B it with CM3 befo=3D
>=3B >=3Bre = > >I just dump it in the repository. It also overlaps a bit<=3Bbr>=3B&= > >=3Bgt=3D3B with=3D
>=3B >=3B "caltech-parser"=3D2C so there should p= > >robably be a "caltech-common"<=3Bbr>=3B&=3Bgt=3D
>=3B >=3B=3D= > >3B package for the overlaps?<=3Bbr>=3B&=3Bgt=3D3B <=3Bbr>=3B&= > >=3Bgt=3D3B If you run the following=3D
>=3B >=3B commands in a fresh= > > directory=3D2C you should get<=3Bbr>=3B&=3Bgt=3D3B to the error I e= > >=3D
>=3B >=3Bmailed:<=3Bbr>=3B&=3Bgt=3D3B <=3Bbr>=3B&= > >=3Bgt=3D3B setenv CM3 1<=3Bbr>=3B&=3Bgt=3D3B cvs -d :pserver:anonymo= > >=3D
>=3B >=3Bus at pluto.gcapltd.com:/home/gcap-public-cvs up -d .<= > >=3Bbr>=3B&=3Bgt=3D3B make regress =3D
>=3B >=3B # GNU make : = > >'gmake regress' on BSD<=3Bbr>=3B&=3Bgt=3D3B cd mscheme/sstubgen/exam= > >ple=3D
>=3B >=3B<=3Bbr>=3B&=3Bgt=3D3B cm3 -x<=3Bbr>=3B&am= > >p=3Bgt=3D3B <=3Bbr>=3B&=3Bgt=3D3B Mika<=3Bbr>=3B&=3Bgt= > >=3D3B <=3Bbr>=3B&=3Bgt=3D3B <=3Bbr>=3B =3D
>=3B >=3B > > = > > <=3B/body>=3B
>=3B >=3B<=3B/html>=3B=3D
> > >=3B >= > >=3B
>=3B >=3B--_9ece0c56-2524-4879-9a65-2407b1dbf664_--
> > = > > > >= > > > >--_d61e805f-545e-4b3d-abe7-a20c582bec2e_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 27 18:19:24 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Dec 2010 12:19:24 -0500 Subject: [M3devel] pointers/arrays? In-Reply-To: References: Message-ID: Have you played around with SUBARRAY? On Dec 26, 2010, at 11:37 PM, Jay K wrote: > I'm still wrestling with this. I have found a few options that work and they all have glaring problems. > > > VAR macho_header32_t_fields := ARRAY [0..6] OF field_t{ > field_t{ "magic", 0, 4, enum_table := EnumTable(macho_magic_names)}, > ... > field_t{ "flags", 24, 4}}; > > > 1) I shouldn't have to give the size of the array. > 2) I shouldn't have to copy the enum table to make it an indexable array. > > > Disappointing.. > > > - Jay > > > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Mon, 27 Dec 2010 02:11:28 +0000 > Subject: [M3devel] pointers/arrays? > > a: UNTRACED REF T; > i: INTEGER; > > > a[i] ? > (a + i)^ ? > > > Or I'm really stuck with > LOOPEHOLE(a + i * BYTESIZE(a^), UNTRACED REF T) > > > Seems kind of stinky. > I've got some nice efficient readable safe-enough C and it doesn't seem to translate well easily efficiently to Modula-3. > > > - Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 27 18:20:25 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Dec 2010 12:20:25 -0500 Subject: [M3devel] constants/offsetof? In-Reply-To: References: Message-ID: <69FCE67E-DA1E-46EA-BD6C-6A0F680E8628@cs.purdue.edu> I really don't understand yet what you are trying to achieve. Do you have a distilled example? Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 27, 2010, at 2:15 AM, Jay K wrote: > Is it unreasonble to expect more/all of these to be constant? > > > UNSAFE MODULE bug1; > > > TYPE T1 = RECORD i,j:INTEGER END; > > > <*NOWARN*>VAR a:T1; > <*NOWARN*>CONST b: UNTRACED REF T1 = NIL; > <*NOWARN*>CONST c: ADDRESS = ADR(a); (* line 7 *) > <*NOWARN*>CONST d: ADDRESS = ADR(a.i); > <*NOWARN*>CONST e: ADDRESS = ADR(a.j); > <*NOWARN*>CONST f: INTEGER = ADR(a.j) - NIL; > <*NOWARN*>CONST g: ADDRESS = ADR(b.i); > <*NOWARN*>CONST h: ADDRESS = ADR(b.j); > <*NOWARN*>CONST i: INTEGER = ADR(b.j) - NIL; > > <*NOWARN*>VAR vc: ADDRESS := ADR(a); > <*NOWARN*>VAR vd: ADDRESS := ADR(a.i); > <*NOWARN*>VAR ve: ADDRESS := ADR(a.j); > <*NOWARN*>VAR vf: INTEGER := ADR(a.j) - NIL; (* oops, didn't mean this one *) > <*NOWARN*>VAR vg: ADDRESS := ADR(b.i); > <*NOWARN*>VAR vh: ADDRESS := ADR(b.j); > <*NOWARN*>VAR vi: INTEGER := ADR(b.j) - NIL; > > BEGIN > END bug1. > > > "../src/bug1.m3", line 7: value is not constant > "../src/bug1.m3", line 8: value is not constant > "../src/bug1.m3", line 9: value is not constant > "../src/bug1.m3", line 10: value is not constant > "../src/bug1.m3", line 11: value is not constant > "../src/bug1.m3", line 12: value is not constant > "../src/bug1.m3", line 13: value is not constant > > It works in C... > > #include > > typedef struct { ptrdiff_t i, j;}T1; > > T1 a; > #define b ((T1*)0) > T1* const c = &a; > ptrdiff_t* const d = &a.i; > ptrdiff_t* const e = &a.j; > ptrdiff_t const f = offsetof(T1,j); > ptrdiff_t* const g = &b->i; > ptrdiff_t* const h = &b->j; > ptrdiff_t const i = &b->j - (ptrdiff_t*)0; > > > Thanks, > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 27 18:21:12 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Dec 2010 12:21:12 -0500 Subject: [M3devel] another Snow Leopard compiler crash In-Reply-To: <20101227101653.307241A205B@async.async.caltech.edu> References: <20101227101653.307241A205B@async.async.caltech.edu> Message-ID: Which version of the backend are you using? Release? There has been so much churn in the trunk lately that I have lost track of things. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 27, 2010, at 5:16 AM, Mika Nystrom wrote: > > ===> calarm/regress/ximport > --- building in I386_DARWIN --- > > new source -> compiling Main.m3 > "../src/Main.m3", line 258: warning: potentially unhandled exception: Main.ParamErr > "../src/Main.m3", line 260: warning: potentially unhandled exception: Main.ParamErr > "../src/Main.m3", line 261: warning: potentially unhandled exception: Main.ParamErr > 3 warnings encountered > ../src/Main.m3: In function 'Main__DumpMatching__DumpOne': > ../src/Main.m3:225:0: error: unable to find a register to spill in class 'CREG' > ../src/Main.m3:225:0: error: this is the insn: > (insn 5 4 6 2 ../src/Main.m3:204 (parallel [ > (set (reg:SI 0 ax [130]) > (const_int 0 [0x0])) > (set (reg:SI 1 dx [128]) > (plus:SI (ashift:SI (reg:SI 0 ax [130]) > (const_int 2 [0x2])) > (reg:SI 1 dx [128]))) > (set (reg:SI 4 si [129]) > (plus:SI (ashift:SI (reg:SI 0 ax [130]) > (const_int 2 [0x2])) > (reg:SI 4 si [129]))) > (set (mem/s/c:BLK (reg:SI 1 dx [128]) [0 trade+0 S24 A64]) > (mem/s/c:BLK (reg:SI 4 si [129]) [0 trade+0 S24 A32])) > (use (reg:SI 0 ax [130])) > ]) 838 {*rep_movsi} (expr_list:REG_UNUSED (reg:SI 0 ax [130]) > (expr_list:REG_UNUSED (reg:SI 4 si [129]) > (expr_list:REG_UNUSED (reg:SI 1 dx [128]) > (nil))))) > ../src/Main.m3:225:0: internal compiler error: in spill_failure, at reload1.c:2163 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > m3_backend => 4 > m3cc (aka cm3cg) failed compiling: Main.mc > compilation failed => not building program "ximport" > Fatal Error: package build failed > > Here is the code: > > PROCEDURE DumpMatching(tr : TickerRef; > trades, bids, asks : HFDataSSeq.T) RAISES { Wr.Failure } = > > PROCEDURE DumpOne(trade, bid, ask : HFData.S) RAISES { Wr.Failure } = > BEGIN > <* ASSERT trade.time = bid.time AND bid.time = ask.time *> > Wr.PutText(wr, Fmt.LongReal(trade.time)); > > Wr.PutChar(wr, ' '); > Wr.PutText(wr, Fmt.LongReal(aFactor*trade.pv.price)); > Wr.PutChar(wr, ' '); > Wr.PutText(wr, Fmt.LongReal(FLOAT(trade.pv.volume,LONGREAL)/aFactor)); > > Wr.PutChar(wr, ' '); > Wr.PutText(wr, Fmt.LongReal(aFactor*bid.pv.price)); > Wr.PutChar(wr, ' '); > Wr.PutText(wr, Fmt.LongReal(FLOAT(bid.pv.volume,LONGREAL)/aFactor)); > > Wr.PutChar(wr, ' '); > Wr.PutText(wr, Fmt.LongReal(aFactor*ask.pv.price)); > Wr.PutChar(wr, ' '); > Wr.PutText(wr, Fmt.LongReal(FLOAT(ask.pv.volume,LONGREAL)/aFactor)); > > Wr.PutChar(wr, '\n') > END DumpOne; > > CONST > NoTime = FIRST(Time.T); > VAR > wr := FileWr.Open(odir & "/" & tr.ticker); > tp, bp, ap := 0; > ttime, btime, atime := NoTime; > aFactor : LONGREAL := 1.0d0; > BEGIN > WHILE tp < trades.size() AND bp < bids.size() AND ap < asks.size() DO > IF ttime = NoTime THEN ttime := trades.get(tp).time END; > IF btime = NoTime THEN btime := bids.get(bp).time END; > IF atime = NoTime THEN atime := asks.get(ap).time END; > > IF ttime = btime AND btime = atime THEN > DumpOne(trades.get(tp),bids.get(bp),asks.get(ap)); > INC(tp); INC(bp); INC(ap); > ttime := NoTime; btime := NoTime; atime := NoTime > ELSIF ttime < btime OR ttime < atime THEN > INC(tp); ttime := NoTime > ELSIF btime < atime OR btime < ttime THEN > INC(bp); btime := NoTime > ELSIF atime < btime OR atime < ttime THEN > INC(ap); atime := NoTime > END > END; > Wr.Close(wr) > END DumpMatching; > > Miika From hosking at cs.purdue.edu Mon Dec 27 18:22:28 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Dec 2010 12:22:28 -0500 Subject: [M3devel] enable/disableswitching around external calls? In-Reply-To: References: Message-ID: No way! I don't understand your problem. Are you saying you have thread-unsafe C code? What is the problem. Please don't do damage here! On Dec 27, 2010, at 5:35 AM, Jay K wrote: > I noticed calls to free in M3toC missing Enable/DisableSwitching. > > I'm going to generalize this, somewhat, in m3core.h, but that still leaves a fair number of custom wrappers. > > This area seems extremely error prone and extremely difficult to get test coverage on. > > These functions only do anything for user threads. > Which we only use by default on OpenBSD. > > How about the frontend emit the calls around any external calls? > > Theory being: external calls are rare? > > Perhaps frontend/m3middle would know if user threads are in use and only emit the calls in that case. Perhaps. > I don't like sprinking much target-specific information around. > > - Jay > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Mon Dec 27 18:23:35 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Dec 2010 12:23:35 -0500 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, <20101227101421.38A6A1A205B@async.async.caltech.edu> Message-ID: Rather than cluttering up CVS, why not put it in the bug-tracker? That's what it is for! Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 27, 2010, at 5:17 AM, Jay K wrote: > Can you put all your code in our CVS repository? > > > "../I386_DARWIN/FSSchemeStubs.m3", line 434: 2 code generation errors > > There is a way to get that to show more information.. > Or does it already? > > - Jay > > > To: m3devel at elegosoft.com > > Date: Mon, 27 Dec 2010 02:14:21 -0800 > > From: mika at async.caltech.edu > > Subject: Re: [M3devel] compiler problems on Snow Leopard > > > > I upgraded to the CVS head and now I get the following: > > > > ... > > "../I386_DARWIN/FSSchemeStubs.m3", line 872: warning: unreachable statement > > "../I386_DARWIN/FSSchemeStubs.m3", line 903: warning: unreachable statement > > "../I386_DARWIN/FSSchemeStubs.m3", line 434: 2 code generation errors > > 1 error and 23 warnings encountered > > new exporters -> recompiling FSSchemeStubs.i3 > > ... > > > > The source code is: > > > > TYPE FS_Iterator_Surrogate = FS.Iterator OBJECT (* line 434 *) > > interp : Scheme.T; > > next_slot : SchemeObject.T := NIL; > > close_slot : SchemeObject.T := NIL; > > nextWithStatus_slot : SchemeObject.T := NIL; > > OVERRIDES > > next := FS_Iterator_next_default; > > close := FS_Iterator_close_default; > > nextWithStatus := FS_Iterator_nextWithStatus_default; > > END; > > > > Mika > > > > Mika Nystrom writes: > > >Hi everyone, > > > > > >Well I was able to get past all my linking issues (mostly questions > > >of dynamic vs. static linking and how to do it, which seems to change from > > >version to version...) > > > > > >But now I did hit a real problem. > > > > > >"../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** unaligne > > >d store type=6 s/o/a=32/0/32 > > >"../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** unaligne > > >d load_indirect type=6 s/a=32/32 > > > > > >Here is the code, but it's not likely to be of much help... > > > > > >PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.T RAIS > > >ES { Scheme.E } = > > > BEGIN > > > VAR res : SchemePair.T:=NIL; BEGIN > > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),T > > >oScheme_Atom_T(x.type)),res); > > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modifica > > >tionTime"),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); > > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),T > > >oScheme_VAL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) > > > RETURN res > > > END > > > END ToScheme_File_Status; > > > > > > > > >... > > > > > >PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0, LONGI > > >NT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = > > > BEGIN > > > RETURN ToScheme_LONGINT(x) (* line 981 *) > > > END ToScheme_VAL0LONGINT__VAL16778080LONGINT; > > > > > > > > >for reference, ToScheme_LONGINT is: > > > > > >PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISES { S > > >cheme.E } = > > > BEGIN > > > WITH ref = NEW(REF LONGINT) DO > > > ref^ := x; > > > RETURN SchemeModula3Types.ToScheme_LONGINT(ref) > > > END > > > END ToScheme_LONGINT; > > > > > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Dec 27 19:54:53 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Mon, 27 Dec 2010 10:54:53 -0800 Subject: [M3devel] another Snow Leopard compiler crash In-Reply-To: References: <20101227101653.307241A205B@async.async.caltech.edu> Message-ID: <20101227185453.97CE51A205B@async.async.caltech.edu> No I had to upgrade the backend to get it to work at all, it's at head too (as of 4-5 days ago). Tony Hosking writes: >Which version of the backend are you using? Release? There has been so = >much churn in the trunk lately that I have lost track of things. > > > >Antony Hosking | Associate Professor | Computer Science | Purdue = From hosking at cs.purdue.edu Mon Dec 27 20:36:14 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 27 Dec 2010 14:36:14 -0500 Subject: [M3devel] another Snow Leopard compiler crash In-Reply-To: <20101227185453.97CE51A205B@async.async.caltech.edu> References: <20101227101653.307241A205B@async.async.caltech.edu> <20101227185453.97CE51A205B@async.async.caltech.edu> Message-ID: OK. Jay? On Dec 27, 2010, at 1:54 PM, Mika Nystrom wrote: > No I had to upgrade the backend to get it to work at all, it's at head > too (as of 4-5 days ago). > > Tony Hosking writes: >> Which version of the backend are you using? Release? There has been so = >> much churn in the trunk lately that I have lost track of things. >> >> >> >> Antony Hosking | Associate Professor | Computer Science | Purdue = From jay.krell at cornell.edu Mon Dec 27 22:41:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Mon, 27 Dec 2010 21:41:31 +0000 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , Message-ID: > Rather than cluttering up CVS, why not put it in the bug-tracker? That's what it is for! It is large. It is more code that could be repeatedly tested, by building the entire "system", for a gradually growing definition of "system". We have had a number of problems that only appear in one or two or a few pieces of code. e.g. the removal of referenced nested functions. e.g. optimizations causing compilation to fail (which this appears to be as well). A smaller example would be nice, but that is more work to get. - Jay From: hosking at cs.purdue.edu Date: Mon, 27 Dec 2010 12:23:35 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] compiler problems on Snow Leopard Rather than cluttering up CVS, why not put it in the bug-tracker? That's what it is for! Antony Hosking | Associate Professor | Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 27, 2010, at 5:17 AM, Jay K wrote:Can you put all your code in our CVS repository? > "../I386_DARWIN/FSSchemeStubs.m3", line 434: 2 code generation errors There is a way to get that to show more information.. Or does it already? - Jay > To: m3devel at elegosoft.com > Date: Mon, 27 Dec 2010 02:14:21 -0800 > From: mika at async.caltech.edu > Subject: Re: [M3devel] compiler problems on Snow Leopard > > I upgraded to the CVS head and now I get the following: > > ... > "../I386_DARWIN/FSSchemeStubs.m3", line 872: warning: unreachable statement > "../I386_DARWIN/FSSchemeStubs.m3", line 903: warning: unreachable statement > "../I386_DARWIN/FSSchemeStubs.m3", line 434: 2 code generation errors > 1 error and 23 warnings encountered > new exporters -> recompiling FSSchemeStubs.i3 > ... > > The source code is: > > TYPE FS_Iterator_Surrogate = FS.Iterator OBJECT (* line 434 *) > interp : Scheme.T; > next_slot : SchemeObject.T := NIL; > close_slot : SchemeObject.T := NIL; > nextWithStatus_slot : SchemeObject.T := NIL; > OVERRIDES > next := FS_Iterator_next_default; > close := FS_Iterator_close_default; > nextWithStatus := FS_Iterator_nextWithStatus_default; > END; > > Mika > > Mika Nystrom writes: > >Hi everyone, > > > >Well I was able to get past all my linking issues (mostly questions > >of dynamic vs. static linking and how to do it, which seems to change from > >version to version...) > > > >But now I did hit a real problem. > > > >"../I386_DARWIN/FSSchemeStubs.m3", line 934: ** INTERNAL CG ERROR *** unaligne > >d store type=6 s/o/a=32/0/32 > >"../I386_DARWIN/FSSchemeStubs.m3", line 981: ** INTERNAL CG ERROR *** unaligne > >d load_indirect type=6 s/a=32/32 > > > >Here is the code, but it's not likely to be of much help... > > > >PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.T RAIS > >ES { Scheme.E } = > > BEGIN > > VAR res : SchemePair.T:=NIL; BEGIN > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"),T > >oScheme_Atom_T(x.type)),res); > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modifica > >tionTime"),SchemeModula3Types.ToScheme_LONGREAL(x.modificationTime)),res); > > res := SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"),T > >oScheme_VAL0LONGINT__VAL16778080LONGINT(x.size)),res); (* line 934 *) > > RETURN res > > END > > END ToScheme_File_Status; > > > > > >... > > > >PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0, LONGI > >NT )..VAL(16778080, LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = > > BEGIN > > RETURN ToScheme_LONGINT(x) (* line 981 *) > > END ToScheme_VAL0LONGINT__VAL16778080LONGINT; > > > > > >for reference, ToScheme_LONGINT is: > > > >PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISES { S > >cheme.E } = > > BEGIN > > WITH ref = NEW(REF LONGINT) DO > > ref^ := x; > > RETURN SchemeModula3Types.ToScheme_LONGINT(ref) > > END > > END ToScheme_LONGINT; > > > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 28 11:48:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Dec 2010 10:48:58 +0000 Subject: [M3devel] C/Modula-3 interop with smaller than word/register parameters? In-Reply-To: References: Message-ID: (same question for return values -- use INTEGER/ptrdiff_t instead of int?) - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: C/Modula-3 interop with smaller than word/register parameters? Date: Tue, 28 Dec 2010 10:47:16 +0000 Are we super confident that passing an "int" (Ctypes.int) from Modula-3 to C will handle the upper bits correctly, for systems with 64bit registers, register-passing calling conventions? That is, zero or sign extended, if the ABI mandates it? I realize, on the C side, the upper bits may or may not be ignored, depending on the ABI. Maybe I'm being too paranoid. Maybe I should stick to ptrdiff_t/INTEGER parameters? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Dec 28 11:47:16 2010 From: jay.krell at cornell.edu (Jay K) Date: Tue, 28 Dec 2010 10:47:16 +0000 Subject: [M3devel] C/Modula-3 interop with smaller than word/register parameters? Message-ID: Are we super confident that passing an "int" (Ctypes.int) from Modula-3 to C will handle the upper bits correctly, for systems with 64bit registers, register-passing calling conventions? That is, zero or sign extended, if the ABI mandates it? I realize, on the C side, the upper bits may or may not be ignored, depending on the ABI. Maybe I'm being too paranoid. Maybe I should stick to ptrdiff_t/INTEGER parameters? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 29 10:53:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Dec 2010 09:53:27 +0000 Subject: [M3devel] gui problems? BadBricks? columns? Message-ID: Could anyone look into BadBricks and columns? They see very broken -- don't seem to accept input. BadBricks occasionally does. tetris and Juno seem ok. mentor probably also though I didn't try today. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Wed Dec 29 13:45:58 2010 From: jay.krell at cornell.edu (Jay K) Date: Wed, 29 Dec 2010 12:45:58 +0000 Subject: [M3devel] ternary operator Message-ID: C code: m.swap32 = swapped ? swap32 : no_swap32; m.swap64 = swapped ? swap64 : no_swap64; m.macho_header_size = m64 ? sizeof(macho_header64_t) : sizeof(macho_header32_t); Modula-3? file.swap32 := no_swap32; file.swap64 := no_swap64; IF swapped THEN file.swap32 := swap32; file.swap64 := swap64; END; file.header_size := (ORD(m64) * BYTESIZE(header64_t)) + (ORD(NOT m64) * BYTESIZE(header32_t)); I don't like either of those forms nor IF swapped THEN file.swap32 := swap32; file.swap64 := swap64; ELSE file.swap32 := no_swap32; file.swap64 := no_swap64; END; If static type inference was more prevalent, I wouldn't mind like: m.swap32 = {no_swap32, swap32}[ORD(swapped)]; m.swap64 = {no_swap64, swap64}[ORD(swapped)]; m.macho_header_size = {sizeof(macho_header32_t), sizeof(macho_header64_t)}[ORD m64]; but I assume {no_swap32, swap32} has to be a typed constant... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Wed Dec 29 16:38:16 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 29 Dec 2010 10:38:16 -0500 Subject: [M3devel] ternary operator In-Reply-To: References: Message-ID: <20101229153816.GA17912@topoi.pooq.com> On Wed, Dec 29, 2010 at 12:45:58PM +0000, Jay K wrote: > > C code: > > m.swap32 = swapped ? swap32 : no_swap32; > m.swap64 = swapped ? swap64 : no_swap64; > m.macho_header_size = m64 ? sizeof(macho_header64_t) : sizeof(macho_header32_t); Algol 60 code: m.swap32 := IF swapped THEN swap32 ELSE no_swap32; m.swap64 := IF swapped THEN swap64 ELSE no_swap64; ...(but no such thing as sizeof)... Algol 68 code: m.swap32 := IF swapped THEN swap32 ELSE no_swap32 FI; m.swap64 := IF swapped THEN swap64 ELSE no_swap64 FI; ...(but no such thing as sizeof)... > > > Modula-3? > > > file.swap32 := no_swap32; > file.swap64 := no_swap64; > IF swapped THEN > file.swap32 := swap32; > file.swap64 := swap64; > END; > file.header_size := (ORD(m64) * BYTESIZE(header64_t)) + (ORD(NOT m64) * BYTESIZE(header32_t)); > > > > I don't like either of those forms nor > > > IF swapped THEN > > file.swap32 := swap32; > > file.swap64 := swap64; > > ELSE > > file.swap32 := no_swap32; > > > file.swap64 := no_swap64; > > > END; > > > > If static type inference was more prevalent, I wouldn't mind like: > > > m.swap32 = {no_swap32, swap32}[ORD(swapped)]; > > m.swap64 = {no_swap64, swap64}[ORD(swapped)]; > > m.macho_header_size = {sizeof(macho_header32_t), sizeof(macho_header64_t)}[ORD m64]; > > > > but I assume {no_swap32, swap32} has to be a typed constant... Abd if it no_awap32 and swap32 were como,licated expressions, it would waste time evaluating things never used. > > > - Jay > From hosking at cs.purdue.edu Wed Dec 29 17:36:40 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 29 Dec 2010 11:36:40 -0500 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: References: Message-ID: These used to work perfectly well. This is a regression. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 29, 2010, at 4:53 AM, Jay K wrote: > Could anyone look into BadBricks and columns? > They see very broken -- don't seem to accept input. > BadBricks occasionally does. > > > tetris and Juno seem ok. > mentor probably also though I didn't try today. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Wed Dec 29 20:06:57 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 29 Dec 2010 19:06:57 +0000 (GMT) Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: Message-ID: <472423.41361.qm@web29708.mail.ird.yahoo.com> Hi all: It seemes to me they should, but currently are not in the standard build package list? Besides could be a problem in the threading? That's why I still like the traditional package, the scheduler might need adjustments, but still it has some nice things like @M3nopreemption, it seems John Polstra wrote something about using it on Digital Unix to run cvsup, see: Are there any cases of test no this runtime parameter? http://www.mavetju.org/mail/view_message.php?list=freebsd-hubs&id=551523 Thanks in advance --- El mi?, 29/12/10, Tony Hosking escribi?: De: Tony Hosking Asunto: Re: [M3devel] gui problems? BadBricks? columns? Para: "Jay K" CC: "m3devel" Fecha: mi?rcoles, 29 de diciembre, 2010 11:36 These used to work perfectly well. ?This is a regression. Antony Hosking?|?Associate Professor?| Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice?+1 765 494 6001 |?Mobile?+1 765 427 5484 On Dec 29, 2010, at 4:53 AM, Jay K wrote: Could anyone look into BadBricks and columns? They see very broken -- don't seem to accept input. BadBricks occasionally does. tetris and Juno seem ok. mentor probably also though I didn't try today. ?- Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dabenavidesd at yahoo.es Thu Dec 30 00:51:35 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Wed, 29 Dec 2010 23:51:35 +0000 (GMT) Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: <472423.41361.qm@web29708.mail.ird.yahoo.com> Message-ID: <60437.40903.qm@web29717.mail.ird.yahoo.com> Hi all: this reminds me that we need anyway to proof the system on errors like locking and anything else, I guess we can try again of the folks in the HP research lab if they would have the sources of the ESC/Modula-3 checker compile them for us and if they agree like before they did with the ESC/Java to make a release for us. I think they planned to do it, just that, nobody gave any new version DEC SRC M3, and it was one of the last things to be scheduled to be released. The original post explaining this same reason is here inside DEC: http://groups.google.com/group/comp.lang.modula3/browse_thread/thread/246542d2609608c7/6e9f7b0a0dd35ce9?hl=en&ie=UTF-8&q=modula3+release+3.6#6e9f7b0a0dd35ce9 Perhaps if we enough petitions we will have some day, what do you think? Perhaps is worth the time, the most difficult thing is finding it, but I guess it would be in the same part they worked or a file server over there, if they allow someone a permission to seek in their files, is just that, we can try to find it. I hope so. I mean what is the reason for keeping it if they did it to use it and explore it, and just because of time they didn't published. Have a nice and happy new year folks! --- El mi?, 29/12/10, Daniel Alejandro Benavides D. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] gui problems? BadBricks? columns? Para: "Jay K" , "Tony Hosking" CC: "m3devel" Fecha: mi?rcoles, 29 de diciembre, 2010 14:06 Hi all: It seemes to me they should, but currently are not in the standard build package list? Besides could be a problem in the threading? That's why I still like the traditional package, the scheduler might need adjustments, but still it has some nice things like @M3nopreemption, it seems John Polstra wrote something about using it on Digital Unix to run cvsup, see: Are there any cases of test no this runtime parameter? http://www.mavetju.org/mail/view_message.php?list=freebsd-hubs&id=551523 Thanks in advance --- El mi?, 29/12/10, Tony Hosking escribi?: De: Tony Hosking Asunto: Re: [M3devel] gui problems? BadBricks? columns? Para: "Jay K" CC: "m3devel" Fecha: mi?rcoles, 29 de diciembre, 2010 11:36 These used to work perfectly well. ?This is a regression. Antony Hosking?|?Associate Professor?| Computer Science | Purdue University305 N. University Street | West Lafayette | IN 47907 | USAOffice?+1 765 494 6001 |?Mobile?+1 765 427 5484 On Dec 29, 2010, at 4:53 AM, Jay K wrote: Could anyone look into BadBricks and columns? They see very broken -- don't seem to accept input. BadBricks occasionally does. tetris and Juno seem ok. mentor probably also though I didn't try today. ?- Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 30 01:27:43 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 00:27:43 +0000 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: <60437.40903.qm@web29717.mail.ird.yahoo.com> References: <472423.41361.qm@web29708.mail.ird.yahoo.com>, <60437.40903.qm@web29717.mail.ird.yahoo.com> Message-ID: >These used to work perfectly well. This is a regression. I think not in a long time. Can anyone dig around? > It seemes to me they should, but currently are not in the standard build package list? Yes they are. > @M3nopreemption Probably something to do with user threads and not possible these days. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Thu Dec 30 02:23:12 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 29 Dec 2010 20:23:12 -0500 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: <60437.40903.qm@web29717.mail.ird.yahoo.com> References: <472423.41361.qm@web29708.mail.ird.yahoo.com> <60437.40903.qm@web29717.mail.ird.yahoo.com> Message-ID: Daniel et al: I tried a year or so ago to pursue getting the sources for the ESC. I'd have to dig up my old emails, but my recollection is that I ran into a dead end getting the sources and the permission to put them in our repository. I don't think the Modula-3 edition was kept up when the project moved on to other languages. Regards, Randy Coleburn From: Daniel Alejandro Benavides D. [mailto:dabenavidesd at yahoo.es] Sent: Wednesday, December 29, 2010 6:52 PM To: Jay K; Tony Hosking Cc: m3devel Subject: Re: [M3devel] gui problems? BadBricks? columns? Hi all: this reminds me that we need anyway to proof the system on errors like locking and anything else, I guess we can try again of the folks in the HP research lab if they would have the sources of the ESC/Modula-3 checker compile them for us and if they agree like before they did with the ESC/Java to make a release for us. I think they planned to do it, just that, nobody gave any new version DEC SRC M3, and it was one of the last things to be scheduled to be released. The original post explaining this same reason is here inside DEC: http://groups.google.com/group/comp.lang.modula3/browse_thread/thread/246542d2609608c7/6e9f7b0a0dd35ce9?hl=en&ie=UTF-8&q=modula3+release+3.6#6e9f7b0a0dd35ce9 Perhaps if we enough petitions we will have some day, what do you think? Perhaps is worth the time, the most difficult thing is finding it, but I guess it would be in the same part they worked or a file server over there, if they allow someone a permission to seek in their files, is just that, we can try to find it. I hope so. I mean what is the reason for keeping it if they did it to use it and explore it, and just because of time they didn't published. Have a nice and happy new year folks! --- El mi?, 29/12/10, Daniel Alejandro Benavides D. escribi?: De: Daniel Alejandro Benavides D. Asunto: Re: [M3devel] gui problems? BadBricks? columns? Para: "Jay K" , "Tony Hosking" CC: "m3devel" Fecha: mi?rcoles, 29 de diciembre, 2010 14:06 Hi all: It seemes to me they should, but currently are not in the standard build package list? Besides could be a problem in the threading? That's why I still like the traditional package, the scheduler might need adjustments, but still it has some nice things like @M3nopreemption, it seems John Polstra wrote something about using it on Digital Unix to run cvsup, see: Are there any cases of test no this runtime parameter? http://www.mavetju.org/mail/view_message.php?list=freebsd-hubs&id=551523 Thanks in advance --- El mi?, 29/12/10, Tony Hosking escribi?: De: Tony Hosking Asunto: Re: [M3devel] gui problems? BadBricks? columns? Para: "Jay K" CC: "m3devel" Fecha: mi?rcoles, 29 de diciembre, 2010 11:36 These used to work perfectly well. This is a regression. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Office +1 765 494 6001 | Mobile +1 765 427 5484 On Dec 29, 2010, at 4:53 AM, Jay K wrote: Could anyone look into BadBricks and columns? They see very broken -- don't seem to accept input. BadBricks occasionally does. tetris and Juno seem ok. mentor probably also though I didn't try today. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Thu Dec 30 02:26:38 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 29 Dec 2010 20:26:38 -0500 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: References: <472423.41361.qm@web29708.mail.ird.yahoo.com>, <60437.40903.qm@web29717.mail.ird.yahoo.com> Message-ID: Both badbricks and columns seem to be working for me on Windows 7. Regards, Randy Coleburn From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Wednesday, December 29, 2010 7:28 PM To: dabenavidesd at yahoo.es; Tony Cc: m3devel Subject: Re: [M3devel] gui problems? BadBricks? columns? >These used to work perfectly well. This is a regression. I think not in a long time. Can anyone dig around? > It seemes to me they should, but currently are not in the standard build package list? Yes they are. > @M3nopreemption Probably something to do with user threads and not possible these days. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Thu Dec 30 04:26:37 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Wed, 29 Dec 2010 22:26:37 -0500 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: References: <472423.41361.qm@web29708.mail.ird.yahoo.com> <60437.40903.qm@web29717.mail.ird.yahoo.com> Message-ID: <20101230032636.GA31254@topoi.pooq.com> On Wed, Dec 29, 2010 at 08:23:12PM -0500, Coleburn, Randy wrote: > Daniel et al: > > I tried a year or so ago to pursue getting the sources for the ESC. > I'd have to dig up my old emails, but my recollection is that I ran into a dead end getting the sources and the permission to put them in our repository. > I don't think the Modula-3 edition was kept up when the project moved on to other languages. What does the ESC do that's relevant to threading? I mean, not just an answer like "deadlock and race detection", but what algorithms does it use to accomplish it? Does the Modula 3 compiler construct the proper data structures that could provide the raw data those algorithms would need? How much work would it be to reimplement this from scratch? -- hendrik From hosking at cs.purdue.edu Thu Dec 30 07:39:16 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Thu, 30 Dec 2010 01:39:16 -0500 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: References: <472423.41361.qm@web29708.mail.ird.yahoo.com>, <60437.40903.qm@web29717.mail.ird.yahoo.com> Message-ID: <40D2C08F-4A14-43DE-B3DF-660BC2266001@cs.purdue.edu> I know I have used them in the last year or so. On Dec 29, 2010, at 7:27 PM, Jay K wrote: > >These used to work perfectly well. This is a regression. > > I think not in a long time. Can anyone dig around? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 30 10:45:51 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 09:45:51 +0000 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: <40D2C08F-4A14-43DE-B3DF-660BC2266001@cs.purdue.edu> References: <472423.41361.qm@web29708.mail.ird.yahoo.com>, , <60437.40903.qm@web29717.mail.ird.yahoo.com>, , <40D2C08F-4A14-43DE-B3DF-660BC2266001@cs.purdue.edu> Message-ID: Release 5.8.6 I386_DARWIN BadBricks and columns run locally don't work on MacOSX 10.5. They come up and draw reasonably, but they don't accept any mouse or keyboard input. I'll try some other versions, platforms, X servers, though I know several current don't work remotely to MacOSX 10.5. I'd be curious to hear from others. - Jay From: hosking at cs.purdue.edu Date: Thu, 30 Dec 2010 01:39:16 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] gui problems? BadBricks? columns? I know I have used them in the last year or so. On Dec 29, 2010, at 7:27 PM, Jay K wrote: >These used to work perfectly well. This is a regression. I think not in a long time. Can anyone dig around? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 30 11:13:47 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 10:13:47 +0000 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: References: <472423.41361.qm@web29708.mail.ird.yahoo.com>, , , <60437.40903.qm@web29717.mail.ird.yahoo.com>, , , , <40D2C08F-4A14-43DE-B3DF-660BC2266001@cs.purdue.edu>, Message-ID: LINUXLIBC6 5.4.0 just doesn't work -- its m3bundle segfaults right away.. cm3-min-POSIX-FreeBSD4-5.4.0.tgz on FreeBSD 4 the cminstall and cm3 right away hit bad syscall.. I might try bootstrapping the modern tree to FreeBSD 4 and try building 5.4.0 there... - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Thu, 30 Dec 2010 09:45:51 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] gui problems? BadBricks? columns? Release 5.8.6 I386_DARWIN BadBricks and columns run locally don't work on MacOSX 10.5. They come up and draw reasonably, but they don't accept any mouse or keyboard input. I'll try some other versions, platforms, X servers, though I know several current don't work remotely to MacOSX 10.5. I'd be curious to hear from others. - Jay From: hosking at cs.purdue.edu Date: Thu, 30 Dec 2010 01:39:16 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] gui problems? BadBricks? columns? I know I have used them in the last year or so. On Dec 29, 2010, at 7:27 PM, Jay K wrote: >These used to work perfectly well. This is a regression. I think not in a long time. Can anyone dig around? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Dec 30 12:23:14 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Dec 2010 12:23:14 +0100 Subject: [M3devel] CM3 status Message-ID: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com> Hi all, after reading a couple of Modula-3 mails again after some time of 'abstinence' I'm a little bit confused about the state of the code and the direction of development. I see that several different failures and ideas are discussed, but don't seem to get resolved; none of them is documented in our Trac instance as far as I know. Some things I remember offhand: o at least 2 different compiler/assembler problems on Darwin/Snow Leopard o current gcc not working on Solaris (?!) o stack walker code abandoned o possibly unsafe OS calls in new C code (this may be a wrong deduction from my side) o GUI input not working for BadBricks and other games (only on Darwin?) o no clean way for exception handling with current gcc o still alignment issues I'm concerned that things get tried out, don't work properly for all our target platforms, but are left then and not cleaned up and something else gets tried. I'm not sure this is correct, it is just me feeling unwell after reading all those mails. Hudson and Tinderbox status seem to be mostly OK though, but I haven't checked in detail (FreeBSD failing was a disk failure on my system recently). But the tests don't cover all the things we should check. I think it would be good to have an overview of the projects/work that is in progress or pending and its status. For example, we've imported a new gcc version, but that doesn't seem to work well on all targets, or does it? If not, how are we going to address this? Use older versions on some platforms? Can I read up on that somewhere? I'd like to suggest to simply use our Trac WiKi to document the ongoing work (everybody can get write access to that on request) and to record all errors, failures and major tasks there as issues. This should help everybody to participate and make me much more relaxed if I consider the M3 emails (if anybody should care about my personal discomfort at all :-) Just for reference: the trac instance can be found at https://projects.elego.de/cm3 Several of the committers should already have access, and using the WiKi and the issue tracker should not be much more work than writing emails. But the information will be easier to access then. I hope to have offended nobody by this; I just wanted to make a suggestion how to improve collaboration and discussion. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Dec 30 12:42:13 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 11:42:13 +0000 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: References: <472423.41361.qm@web29708.mail.ird.yahoo.com>,,, , <60437.40903.qm@web29717.mail.ird.yahoo.com>, ,,, , , <40D2C08F-4A14-43DE-B3DF-660BC2266001@cs.purdue.edu>, , , Message-ID: ok, well, I386_DARWIN head remoted to Cygwin/X works. Something about Mac X Server maybe. - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Thu, 30 Dec 2010 10:13:47 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] gui problems? BadBricks? columns? LINUXLIBC6 5.4.0 just doesn't work -- its m3bundle segfaults right away.. cm3-min-POSIX-FreeBSD4-5.4.0.tgz on FreeBSD 4 the cminstall and cm3 right away hit bad syscall.. I might try bootstrapping the modern tree to FreeBSD 4 and try building 5.4.0 there... - Jay From: jay.krell at cornell.edu To: hosking at cs.purdue.edu Date: Thu, 30 Dec 2010 09:45:51 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] gui problems? BadBricks? columns? Release 5.8.6 I386_DARWIN BadBricks and columns run locally don't work on MacOSX 10.5. They come up and draw reasonably, but they don't accept any mouse or keyboard input. I'll try some other versions, platforms, X servers, though I know several current don't work remotely to MacOSX 10.5. I'd be curious to hear from others. - Jay From: hosking at cs.purdue.edu Date: Thu, 30 Dec 2010 01:39:16 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] gui problems? BadBricks? columns? I know I have used them in the last year or so. On Dec 29, 2010, at 7:27 PM, Jay K wrote: >These used to work perfectly well. This is a regression. I think not in a long time. Can anyone dig around? -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagner at elegosoft.com Thu Dec 30 13:04:11 2010 From: wagner at elegosoft.com (Olaf Wagner) Date: Thu, 30 Dec 2010 13:04:11 +0100 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: References: <472423.41361.qm@web29708.mail.ird.yahoo.com>,,, , <60437.40903.qm@web29717.mail.ird.yahoo.com>, ,,, , , <40D2C08F-4A14-43DE-B3DF-660BC2266001@cs.purdue.edu>, , , Message-ID: <20101230130411.mgdi3tjdioocg40g@mail.elegosoft.com> Quoting Jay K : > > ok, well, I386_DARWIN head remoted to Cygwin/X works. > Something about Mac X Server maybe. My 2 cent (tries): % ll /usr/local/cm3/bin/BadBricks -rwxrwxr-x 1 wagner m3 3380338 19 Nov 20:37 /usr/local/cm3/bin/BadBricks* works OK. % ll /ad0e/home/hudson/work/cm3-inst/luthien/current--all-pkgs/bin/BadBricks -rwxr-xr-x 1 hudson hudson 90590 29 Dec 13:46 /ad0e/home/hudson/work/cm3-inst/luthien/current--all-pkgs/bin/BadBricks* runs, but incorrectly displays 0 for all bricks :-( Olaf > - Jay > > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Thu, 30 Dec 2010 10:13:47 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] gui problems? BadBricks? columns? > > > > > > > > > LINUXLIBC6 5.4.0 just doesn't work -- its m3bundle segfaults right away.. > cm3-min-POSIX-FreeBSD4-5.4.0.tgz on FreeBSD 4 the cminstall and cm3 > right away hit bad syscall.. > I might try bootstrapping the modern tree to FreeBSD 4 and try > building 5.4.0 there... > > - Jay > > From: jay.krell at cornell.edu > To: hosking at cs.purdue.edu > Date: Thu, 30 Dec 2010 09:45:51 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] gui problems? BadBricks? columns? > > > > > > > > > Release 5.8.6 I386_DARWIN BadBricks and columns run locally don't > work on MacOSX 10.5. > They come up and draw reasonably, but they don't accept any mouse or > keyboard input. > I'll try some other versions, platforms, X servers, though I know > several current don't work remotely to MacOSX 10.5. > I'd be curious to hear from others. > > - Jay > > From: hosking at cs.purdue.edu > Date: Thu, 30 Dec 2010 01:39:16 -0500 > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] gui problems? BadBricks? columns? > > > > I know I have used them in the last year or so. > > > On Dec 29, 2010, at 7:27 PM, Jay K wrote: >These used to work > perfectly well. This is a regression. > > I think not in a long time. Can anyone dig around? > -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From jay.krell at cornell.edu Thu Dec 30 13:01:39 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 12:01:39 +0000 Subject: [M3devel] CM3 status In-Reply-To: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com> References: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com> Message-ID: > o at least 2 different compiler/assembler problems on Darwin/Snow Leopard Needs more investigation. Occurs in code not in our tree, with optimization. The error message fyi is one that people occasionally see with mainline gcc also, though hopefully not in recent releases. Something about a shortage of registers. A significant codebase, not easily built, no small reproduction case yet presented or in hand. Some of the problems are in release 5.8.6 but fixed in head. But not all understood. I suggest the code be added to our CVS and be made buildable and regularly built there. > o current gcc not working on Solaris (?!) I don't know what this is referring to. Do you mean 4.5 vs. 4.3? Well, sort of but really. Keep reading. > o stack walker code abandoned Tony ok'ed this for Solaris/sparc32 a few months ago. I couldn't get it working with gcc 4.5, not even without optimization. That was the last step in moving off of gcc 4.3 backend. Alpha/OSF also doesn't work. I didn't look much into it, and I really don't think it matters. It is an extremely little used platform. This year I saw it work on 4.0 and 5.1 but otherwise it had been unused for several years I believe, and I don't see its use continuing much. Upgrade of Solaris/sparc32 from gcc 4.3 to 4.5: 2010-10-13 11:18 jkrell * m3-sys/cminstall/src/config-no-install/SPARC32_SOLARIS.common, m3-sys/m3cc/gcc/gcc/m3cg/parse.c, m3-sys/m3cc/src/clean_marker.txt, m3-sys/m3cc/src/m3makefile, m3-libs/m3core/src/runtime/m3makefile, m3-sys/m3middle/src/Target.m3, m3-libs/m3core/src/runtime/SOLgnu/m3makefile, m3-libs/m3core/src/runtime/SOLgnu/m3makefile-old, m3-libs/m3core/src/runtime/SOLsun/m3makefile, m3-libs/m3core/src/runtime/SOLsun/m3makefile-old: disable Solaris/sparc32 stack walker switch Solaris/sparc32 to gcc 4.5 backend function.c: make failure to volatilize when setjmp/vfork present an error instead of a warning add missing volatilization pin Solaris/sparc32 at -O1 in the config file as -O2/-O3 were seen to hit internal compiler errors (assertion failures) remove the "all volatile" paths from parse.c (since they were only for Solaris/sparc32's stack walker) Tony ok'ing (in my interpretation) the abandonment of our stack walker: https://mail.elegosoft.com/pipermail/m3devel/2010-October/008019.html At least that was my interpretation. Using gcc's exception handling support and *its* stack walker (libgcc/libunwind) should provide the better and more portable functionality on many platforms. I'm not certain what'd it look like on systems where gcc isn't the usual C compiler (e.g. Solaris) but it's bound to work well on Linux, NetBSD, FreeBSD, OpenBSD, and Solaris using gcc. "more portable" as in, across all architectures. Perhaps I should have stuck back with 4.3 until implementing this however. It is definitely a step backward to not have the stack walker on Solaris/sparc32, but that is the only platform in years that has had one, and it is not terrible to have every platform on gcc 4.5.2 and not sprinkling volatile around. There are some backward steps but definitely a lot forward. I tried using 5.4.0 tonight and I didn't get far. > o possibly unsafe OS calls in new C code (this may be a wrong deduction > from my side) I don't know what this is referring to. The Enable/DisableScheduling? I all but undid that. It should be in a few functions, e.g. malloc/free/realloc/calloc/opendir/readdir/closedir/fopen/fclose. Some of those it already is in. With OpenBSD moving to pthreads it matters less. It only matters for user threads. > o GUI input not working for BadBricks and other games (only on Darwin?) Yes this is still a problem, and occurs in 5.8.6 release, on Darwin local X Server. Doesn't reproduce when remoted to Cygwin/X. Other X apps do work locally. Not understood. It'd be good to get confirmation if/when they ever worked. > o no clean way for exception handling with current gcc This is how things have *always* been, *except* on Alpha/OSF and Solaris/sparc32. Those two platforms have "regressed", but for Solaris/sparc32 it was discussed and Alpha/OSF I really don't think is important. Exception handling has always been very inefficient on all but approx. those two platforms. It has always been desirable to fix. The inefficiency has a few parts. Mainly that "try" costs pthread_getspecific and setjmp. The inefficiency of the actual throw/catch is not as worrisome. > o still alignment issues Details? > I'm concerned that things get tried out, don't work properly for all > our target platforms, but are left then and not cleaned up and something > else gets tried. I'm not sure this is correct, it is just me feeling > unwell after reading all those mails. Not really. > Hudson and Tinderbox status seem to be mostly OK though, but I haven't > checked in detail (FreeBSD failing was a disk failure on my system > recently). But the tests don't cover all the things we should check. Yep I try to remember to check Hudson fairly regularly. I never look at Tinderbox though. > I think it would be good to have an overview of the projects/work that > is in progress or pending and its status. For example, we've imported > a new gcc version, but that doesn't seem to work well on all targets, > or does it? If not, how are we going to address this? Use older versions > on some platforms? Can I read up on that somewhere? All platforms (except NT386) use gcc 4.5.2 for the backend. (I did the upgrade after the release was made but before it was announced; they delay announcement while it propagates to mirrors.) Ok, also ARM_DARWIN hypothetically uses 4.2. Apple forks gcc fairly aggressively. Perhaps we should merge the two forks. Perhaps. ARM_DARWIN isn't really supported currently. Probably that should be worked on. It'd also be interesting to see what Apple did to 4.2 for ppc/x86... > I'd like to suggest to simply use our Trac WiKi to document the ongoing Agreed but I'm lazy. I just throw "bombs" around.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 30 13:19:08 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 12:19:08 +0000 Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: <20101230130411.mgdi3tjdioocg40g@mail.elegosoft.com> References: <472423.41361.qm@web29708.mail.ird.yahoo.com>,,, , , <60437.40903.qm@web29717.mail.ird.yahoo.com>, , , , , , ,,<40D2C08F-4A14-43DE-B3DF-660BC2266001@cs.purdue.edu>, , , , , , , <20101230130411.mgdi3tjdioocg40g@mail.elegosoft.com> Message-ID: > % ll /usr/local/cm3/bin/BadBricks > -rwxrwxr-x 1 wagner m3 3380338 19 Nov 20:37 /usr/local/cm3/bin/BadBricks* > > works OK. > > % ll /ad0e/home/hudson/work/cm3-inst/luthien/current--all-pkgs/bin/BadBricks > -rwxr-xr-x 1 hudson hudson 90590 29 Dec 13:46 > /ad0e/home/hudson/work/cm3-inst/luthien/current--all-pkgs/bin/BadBricks* > > runs, but incorrectly displays 0 for all bricks :-( > Thanks. uname -a ? AMD64_FREEBSD I assume? Huh, wierd, a different seemingly recent regression. That doesn't occur for me I386_DARWIN remoted to Cygwin/X. Need to isolate it...try other platforms...? Maybe I turned optimization off on my system (lately I've been doing everything with -O3 via a local edit, but occasionally I undo that). Imho the problem I'm seeing might have been there forever. Definitely not fully understood yet. I'll try PPC_DARWIN 10.4 as that is handy... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 30 13:14:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 12:14:21 +0000 Subject: [M3devel] m3-libs/m3core/src/runtime/common/Compiler.tmpl? Message-ID: So..I spent a few minutes tonight trying to use/build an old release: 5.4.0. One of the problems I hit was building the 5.4.0 release with a current "I386_FREEBSD" compiler. One of the problems in the system, just a small number of occurences, is m3makefiles having lists of platforms, that don't have current platforms. In some ways this might be inevitable. I have however reduced the problem by using lists of OS (Linux, FreeBSD, etc.) and processor architecture (x86, AMD64, SPARC32, etc.). So new combinations thereof don't require visiting so many places. However this reminded me of something that has bugged me a bit. In m3core: INTERFACE Compiler; (* this is generated by quake code *) enum OS = { POSIX, WIN32} not so bad, hasn't changed in over 10 years enum Platform = { big list of all targets } changes whenever a target is added, fairly often CONST ThisOS = OS.POSIX or OS.WIN32 not so bad CONST ThisPlatform:Platform = ... a small problem, the subject here CONST ThisPlatform_String:TEXT = "..."; not a problem I'd like to remove the enum Platform and ThisPlatform. This increases portability in terms of the ability of older/newer cm3 to build newer/older cm3. i.e...I guess...just...for a cm3 hosted on a renamed platform (I386_LINUX vs. LINUXLIBC6, etc.) It also is one less file to edit when adding a new target. Ideally that number is just one file, though currently it is a few. I'll try it out, see if anything in our tree uses it. Any uses are probably suspicious anyway. Perhaps we should provide the two smaller "composed" enums rename ThisOS to ThisOSType then ThisOS in {Linux, OpenBSD, FreeBSD, Solaris, etc.} and ThisProcessorArchitecture in {x86, AMD64, sparc32, etc.} (possibly x86, sparc, powerpc, and then can check BITSIZE(INTEGER) to get 32/64). The one place I knew of that used this stuff I changed to do something else -- use quake code to produce true/false. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 30 13:26:26 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 12:26:26 +0000 Subject: [M3devel] CM3 status In-Reply-To: References: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com>, Message-ID: > Alpha/OSF also doesn't work Clarification -- the target works, but not its stack walker. I moved it back to setjmp/longjmp a few months ago when an Alpha/OSF machine was presented to me, when the stack walker didn't work on the first try. This stuff is fairly difficult to debug, reading the Alpha or Sparc assembly to find the mistakes in it, and the payoff is very small... - Jay From: jay.krell at cornell.edu To: wagner at elegosoft.com; m3devel at elegosoft.com Date: Thu, 30 Dec 2010 12:01:39 +0000 Subject: Re: [M3devel] CM3 status > o at least 2 different compiler/assembler problems on Darwin/Snow Leopard Needs more investigation. Occurs in code not in our tree, with optimization. The error message fyi is one that people occasionally see with mainline gcc also, though hopefully not in recent releases. Something about a shortage of registers. A significant codebase, not easily built, no small reproduction case yet presented or in hand. Some of the problems are in release 5.8.6 but fixed in head. But not all understood. I suggest the code be added to our CVS and be made buildable and regularly built there. > o current gcc not working on Solaris (?!) I don't know what this is referring to. Do you mean 4.5 vs. 4.3? Well, sort of but really. Keep reading. > o stack walker code abandoned Tony ok'ed this for Solaris/sparc32 a few months ago. I couldn't get it working with gcc 4.5, not even without optimization. That was the last step in moving off of gcc 4.3 backend. Alpha/OSF also doesn't work. I didn't look much into it, and I really don't think it matters. It is an extremely little used platform. This year I saw it work on 4.0 and 5.1 but otherwise it had been unused for several years I believe, and I don't see its use continuing much. Upgrade of Solaris/sparc32 from gcc 4.3 to 4.5: 2010-10-13 11:18 jkrell * m3-sys/cminstall/src/config-no-install/SPARC32_SOLARIS.common, m3-sys/m3cc/gcc/gcc/m3cg/parse.c, m3-sys/m3cc/src/clean_marker.txt, m3-sys/m3cc/src/m3makefile, m3-libs/m3core/src/runtime/m3makefile, m3-sys/m3middle/src/Target.m3, m3-libs/m3core/src/runtime/SOLgnu/m3makefile, m3-libs/m3core/src/runtime/SOLgnu/m3makefile-old, m3-libs/m3core/src/runtime/SOLsun/m3makefile, m3-libs/m3core/src/runtime/SOLsun/m3makefile-old: disable Solaris/sparc32 stack walker switch Solaris/sparc32 to gcc 4.5 backend function.c: make failure to volatilize when setjmp/vfork present an error instead of a warning add missing volatilization pin Solaris/sparc32 at -O1 in the config file as -O2/-O3 were seen to hit internal compiler errors (assertion failures) remove the "all volatile" paths from parse.c (since they were only for Solaris/sparc32's stack walker) Tony ok'ing (in my interpretation) the abandonment of our stack walker: https://mail.elegosoft.com/pipermail/m3devel/2010-October/008019.html At least that was my interpretation. Using gcc's exception handling support and *its* stack walker (libgcc/libunwind) should provide the better and more portable functionality on many platforms. I'm not certain what'd it look like on systems where gcc isn't the usual C compiler (e.g. Solaris) but it's bound to work well on Linux, NetBSD, FreeBSD, OpenBSD, and Solaris using gcc. "more portable" as in, across all architectures. Perhaps I should have stuck back with 4.3 until implementing this however. It is definitely a step backward to not have the stack walker on Solaris/sparc32, but that is the only platform in years that has had one, and it is not terrible to have every platform on gcc 4.5.2 and not sprinkling volatile around. There are some backward steps but definitely a lot forward. I tried using 5.4.0 tonight and I didn't get far. > o possibly unsafe OS calls in new C code (this may be a wrong deduction > from my side) I don't know what this is referring to. The Enable/DisableScheduling? I all but undid that. It should be in a few functions, e.g. malloc/free/realloc/calloc/opendir/readdir/closedir/fopen/fclose. Some of those it already is in. With OpenBSD moving to pthreads it matters less. It only matters for user threads. > o GUI input not working for BadBricks and other games (only on Darwin?) Yes this is still a problem, and occurs in 5.8.6 release, on Darwin local X Server. Doesn't reproduce when remoted to Cygwin/X. Other X apps do work locally. Not understood. It'd be good to get confirmation if/when they ever worked. > o no clean way for exception handling with current gcc This is how things have *always* been, *except* on Alpha/OSF and Solaris/sparc32. Those two platforms have "regressed", but for Solaris/sparc32 it was discussed and Alpha/OSF I really don't think is important. Exception handling has always been very inefficient on all but approx. those two platforms. It has always been desirable to fix. The inefficiency has a few parts. Mainly that "try" costs pthread_getspecific and setjmp. The inefficiency of the actual throw/catch is not as worrisome. > o still alignment issues Details? > I'm concerned that things get tried out, don't work properly for all > our target platforms, but are left then and not cleaned up and something > else gets tried. I'm not sure this is correct, it is just me feeling > unwell after reading all those mails. Not really. > Hudson and Tinderbox status seem to be mostly OK though, but I haven't > checked in detail (FreeBSD failing was a disk failure on my system > recently). But the tests don't cover all the things we should check. Yep I try to remember to check Hudson fairly regularly. I never look at Tinderbox though. > I think it would be good to have an overview of the projects/work that > is in progress or pending and its status. For example, we've imported > a new gcc version, but that doesn't seem to work well on all targets, > or does it? If not, how are we going to address this? Use older versions > on some platforms? Can I read up on that somewhere? All platforms (except NT386) use gcc 4.5.2 for the backend. (I did the upgrade after the release was made but before it was announced; they delay announcement while it propagates to mirrors.) Ok, also ARM_DARWIN hypothetically uses 4.2. Apple forks gcc fairly aggressively. Perhaps we should merge the two forks. Perhaps. ARM_DARWIN isn't really supported currently. Probably that should be worked on. It'd also be interesting to see what Apple did to 4.2 for ppc/x86... > I'd like to suggest to simply use our Trac WiKi to document the ongoing Agreed but I'm lazy. I just throw "bombs" around.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 30 13:55:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 12:55:31 +0000 Subject: [M3devel] cross builds and netobj/proxy generation Message-ID: I found this problem trying to build Mika's Scheme implementation I hadn't rebuilt all tools to be I386_DARWIN -- some were still AMD64_DARWIN. It seems the proxy code got values for LAST(INTEGER) in it, but they were for the host, not the target. Tools need to not assume they are the same... - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Thu Dec 30 15:28:31 2010 From: jay.krell at cornell.edu (Jay K) Date: Thu, 30 Dec 2010 14:28:31 +0000 Subject: [M3devel] factoring jmpbuf size via alloca(global constant)? Message-ID: factoring out jmpbuf size? Hey, um, how about something like this: somefile.c: #include extern const int sizeof_jmpbuf = sizeof(jmp_buf); where the frontend would allocate a local jmp_buf, instead issue a call to alloca(sizeof_jmpbuf), actually reading the constant out of the global. Yes I know this is a deoptimization. It is already slow. We hope hope hope to replace it all anyway. This would remove lots of target-specific code in Target.m3. Related, I'm again trying removing from m3core the knowledge of the size/alignment of jmpbuf. Or rather, to see if it really needs it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From dknoto at next.com.pl Thu Dec 30 20:09:53 2010 From: dknoto at next.com.pl (Dariusz =?ISO-8859-2?Q?Knoci=F1ski?=) Date: Thu, 30 Dec 2010 20:09:53 +0100 Subject: [M3devel] Array indexing Message-ID: <20101230200953.1b229a27.dknoto@next.com.pl> Hi all, my name is Dariusz Knoci?ski, I am new in this list, it is my first letter. Best wishes for New Year to all. I have a problem with two-dimensional arrays. In my simple source code I can't get value from array indexed by two variables. But, I can get these values by indexing by constants. The program compile successfully but generates idiotic output. Source: MODULE aib EXPORTS Main; IMPORT IO, Fmt; CONST tab = ARRAY [0..2], [0..15] OF CARDINAL { ARRAY OF CARDINAL { 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17 }, ARRAY OF CARDINAL { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 17, 17, 17, 17, 17, 17 }, ARRAY OF CARDINAL { 17, 11, 12, 13, 14, 15, 16, 17, 17, 17, 17, 17, 17, 17, 17, 17 } }; VAR k, l : CARDINAL; BEGIN k := 1; l := 9; IO.Put( "k = " & Fmt.Int(k) & ", " ); IO.Put( "l = " & Fmt.Int(l) & "\n" ); k := tab[k][l]; IO.Put( "k = tab[k][l] => 0x" & Fmt.F( "%02s", Fmt.Unsigned(k)) & "\n" ); k := tab[1][9]; IO.Put( "k = tab[1][9] => 0x" & Fmt.F( "%02s", Fmt.Unsigned(k)) & "\n" ); FOR i := 0 TO 2 DO FOR j := 0 TO 15 DO IO.Put( Fmt.F( " %02s", Fmt.Int( tab[i][j] ) ) ); END; IO.Put( "\n" ); END; END aib. Output: k = 1, l = 9 k = tab[k][l] => 0x00 k = tab[1][9] => 0x0a 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 My system and compiler version is: $ uname -a Linux wenus.next.com.pl 2.6.35.10-74.fc14.x86_64 #1 SMP Thu Dec 23 16:04:50\ UTC 2010 x86_64 x86_64 x86_64 GNU/Linux $ cm3 -version Critical Mass Modula-3 version 5.8.6 last updated: 2010-04-11 compiled: 2010-07-12 20:10:34 configuration: /usr/local/cm3/bin/cm3.cfg host: AMD64_LINUX target: AMD64_LINUX or Critical Mass Modula-3 version d5.9.0 last updated: 2010-07-21 compiled: 2010-12-16 03:15:26 configuration: /usr/local/cm3/bin/cm3.cfg host: AMD64_LINUX quake runtime error: "/usr/local/cm3/bin/cm3.cfg", line 2: quake runtime error:\ undefined variable: SL --procedure-- -line- -file--- 2 /usr/local/cm3/bin/cm3.cfg target: Both compilers generate same results. Best regards DKnoto. From rodney_bates at lcwb.coop Thu Dec 30 21:12:22 2010 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Thu, 30 Dec 2010 14:12:22 -0600 Subject: [M3devel] Array indexing In-Reply-To: <20101230200953.1b229a27.dknoto@next.com.pl> References: <20101230200953.1b229a27.dknoto@next.com.pl> Message-ID: <4D1CE7A6.4050409@lcwb.coop> I reproduced this immediately on LINUXLIBC6 and AMD64_LINUX. It's a compiler bug. A version of cm3 several years old, and an old pm3, both with the (much older) gcc backend and the x86 internal backend also all show the same problem. The memory area for each row of tab is getting initialized with dope for an open array, instead of the actual values. Moreover, the dope is not right either, though it's recognizable. Since the open array row constructor is assignable to the fixed array row of tab, the code is correct and the compiler should take care of the representation change. Making tab a VAR instead of CONST shows the same bad behavior. As a workaround, you can change the row constructors to fixed array constructors: CONST tab = ARRAY [0..2], [0..15] OF CARDINAL { ARRAY [0..15] OF CARDINAL { 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17 }, ARRAY [0..15] OF CARDINAL { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 17, 17, 17, 17, 17, 17 }, ARRAY [0..15] OF CARDINAL { 17, 11, 12, 13, 14, 15, 16, 17, 17, 17, 17, 17, 17, 17, 17, 17 } }; and this works as expected: (m3gdb) run Starting program: /home/rodney/proj/m3/exp/dknoto/AMD64_LINUX/prog Can't disable VM GC. Signal Stop Print Pass to program Description SIG64 No No Yes Real-time event 64 [Thread debugging using libthread_db enabled] [New LWP 9108] k = 1, l = 9 k = tab[k][l] => 0x0a k = tab[1][9] => 0x0a 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 01 02 03 04 05 06 07 08 09 10 17 17 17 17 17 17 17 11 12 13 14 15 16 17 17 17 17 17 17 17 17 17 Program exited normally. (m3gdb) Amazing that in all these years, nobody has coded a 2-D array constructor this way before, or at least didn't complain. Rodney Bates Dariusz Knoci?ski wrote: > Hi all, > > my name is Dariusz Knoci?ski, I am new in this list, it is my first letter. > Best wishes for New Year to all. > > I have a problem with two-dimensional arrays. In my simple source code I can't > get value from array indexed by two variables. But, I can get these values by > indexing by constants. The program compile successfully but generates idiotic > output. > > Source: > > MODULE aib EXPORTS Main; > > IMPORT IO, Fmt; > > CONST > tab = ARRAY [0..2], [0..15] OF CARDINAL { > ARRAY OF CARDINAL > { 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17 }, > ARRAY OF CARDINAL > { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 17, 17, 17, 17, 17, 17 }, > ARRAY OF CARDINAL > { 17, 11, 12, 13, 14, 15, 16, 17, 17, 17, 17, 17, 17, 17, 17, 17 } > }; > > VAR > k, l : CARDINAL; > > BEGIN > > k := 1; > l := 9; > > IO.Put( "k = " & Fmt.Int(k) & ", " ); > IO.Put( "l = " & Fmt.Int(l) & "\n" ); > k := tab[k][l]; > IO.Put( "k = tab[k][l] => 0x" & > Fmt.F( "%02s", Fmt.Unsigned(k)) & "\n" ); > > k := tab[1][9]; > IO.Put( "k = tab[1][9] => 0x" & > Fmt.F( "%02s", Fmt.Unsigned(k)) & "\n" ); > > FOR i := 0 TO 2 DO > FOR j := 0 TO 15 DO > IO.Put( Fmt.F( " %02s", Fmt.Int( tab[i][j] ) ) ); > END; > IO.Put( "\n" ); > END; > > END aib. > > Output: > > k = 1, l = 9 > k = tab[k][l] => 0x00 > k = tab[1][9] => 0x0a > 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > My system and compiler version is: > > $ uname -a > > Linux wenus.next.com.pl 2.6.35.10-74.fc14.x86_64 #1 SMP Thu Dec 23 16:04:50\ > UTC 2010 x86_64 x86_64 x86_64 GNU/Linux > > $ cm3 -version > > Critical Mass Modula-3 version 5.8.6 > last updated: 2010-04-11 > compiled: 2010-07-12 20:10:34 > configuration: /usr/local/cm3/bin/cm3.cfg > host: AMD64_LINUX > target: AMD64_LINUX > > or > > Critical Mass Modula-3 version d5.9.0 > last updated: 2010-07-21 > compiled: 2010-12-16 03:15:26 > configuration: /usr/local/cm3/bin/cm3.cfg > host: AMD64_LINUX > quake runtime error: "/usr/local/cm3/bin/cm3.cfg", line 2: quake runtime error:\ > undefined variable: SL > > --procedure-- -line- -file--- > 2 /usr/local/cm3/bin/cm3.cfg > target: > > Both compilers generate same results. > > Best regards > DKnoto. > From dknoto at next.com.pl Thu Dec 30 22:17:19 2010 From: dknoto at next.com.pl (Dariusz =?ISO-8859-2?Q?Knoci=F1ski?=) Date: Thu, 30 Dec 2010 22:17:19 +0100 Subject: [M3devel] Array indexing In-Reply-To: <4D1CE7A6.4050409@lcwb.coop> References: <20101230200953.1b229a27.dknoto@next.com.pl> <4D1CE7A6.4050409@lcwb.coop> Message-ID: <20101230221719.85e9d885.dknoto@next.com.pl> On Thu, 30 Dec 2010 14:12:22 -0600 "Rodney M. Bates" wrote: [...] > As a workaround, you can change the row constructors to fixed array constructors: > > CONST > tab = ARRAY [0..2], [0..15] OF CARDINAL { > ARRAY [0..15] OF CARDINAL > { 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17 }, > ARRAY [0..15] OF CARDINAL > { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 17, 17, 17, 17, 17, 17 }, > ARRAY [0..15] OF CARDINAL > { 17, 11, 12, 13, 14, 15, 16, 17, 17, 17, 17, 17, 17, 17, 17, 17 } > }; > Thankyou very much for workaround. > Amazing that in all these years, nobody has coded a 2-D array constructor this > way before, or at least didn't complain. > > Code similar to this I found on pages in tutorial, in chapter "Array Constructor": tictactoe := ARRAY [1..3], [1..3] OF CHAR{ ARRAY OF CHAR{' ', ' ', ' '}, ARRAY OF CHAR{' ', ' ', ' '}, ARRAY OF CHAR{' ', ' ', ' '} }; Best regards Dariusz Knoci?ski. From dabenavidesd at yahoo.es Thu Dec 30 22:31:04 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 30 Dec 2010 21:31:04 +0000 (GMT) Subject: [M3devel] Array indexing In-Reply-To: <4D1CE7A6.4050409@lcwb.coop> Message-ID: <280842.77354.qm@web29702.mail.ird.yahoo.com> Hi all: it seems the same to me, perhaps this uncovered bug has been there for years or a systematic problem, we would need to apply verification for the compiler intermediate code generation, though might be a problem in the code generation, we don't know, it should be provable that for a given input the Modula-3 compiler will gave the same intermediate code, this would open also a door for optimization, like in HP, was built a compiler like that, it will take some time, but eventually, before we can believe it, we may have the compiler specified front end (still if it were 100000 lines verifying would take 60 years/man, if its 10000, 6 years/man), like the Hoare utopia was to built itself. So between more correct more efficient! --- El jue, 30/12/10, Rodney M. Bates escribi?: > De: Rodney M. Bates > Asunto: Re: [M3devel] Array indexing > Para: "Dariusz Knoci?ski" > CC: m3devel at elegosoft.com > Fecha: jueves, 30 de diciembre, 2010 15:12 > I reproduced this immediately on > LINUXLIBC6 and AMD64_LINUX. It's a compiler bug. > A version of cm3 several years old, and an old pm3, both > with the (much older) > gcc backend and the x86 internal backend also all show the > same problem. > > The memory area for each row of tab is getting initialized > with dope for an > open array, instead of the actual values. Moreover, > the dope is not right > either, though it's recognizable. Since the open > array row constructor is > assignable to the fixed array row of tab, the code is > correct and the compiler > should take care of the representation change. > > Making tab a VAR instead of CONST shows the same bad > behavior. > > As a workaround, you can change the row constructors to > fixed array constructors: > > CONST > tab = ARRAY [0..2], [0..15] OF CARDINAL { > ARRAY [0..15] OF CARDINAL > { 17, 17, 17, 17, 17, 17, > 17, 17, 17, 17, 17, 17, 17, 17, 17, 17 }, > ARRAY [0..15] OF CARDINAL > { 1, 2, > 3, 4, 5, 6, 7, 8, 9, 10, > 17, 17, 17, 17, 17, 17 }, > ARRAY [0..15] OF CARDINAL > { 17, 11, 12, 13, 14, 15, > 16, 17, 17, 17, 17, 17, 17, 17, 17, 17 } > }; > > and this works as expected: > > (m3gdb) run > Starting program: > /home/rodney/proj/m3/exp/dknoto/AMD64_LINUX/prog > Can't disable VM GC. > Signal Stop > Print Pass to program Description > SIG64 No > No Yes > Real-time event 64 > [Thread debugging using libthread_db enabled] > [New LWP 9108] > k = 1, l = 9 > k = tab[k][l] => 0x0a > k = tab[1][9] => 0x0a > 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 17 > 01 02 03 04 05 06 07 08 09 10 17 17 17 17 17 17 > 17 11 12 13 14 15 16 17 17 17 17 17 17 17 17 17 > > Program exited normally. > (m3gdb) > > Amazing that in all these years, nobody has coded a 2-D > array constructor this > way before, or at least didn't complain. > > > Rodney Bates > > > Dariusz Knoci?ski wrote: > > Hi all, > > > > my name is Dariusz Knoci?ski, I am new in this list, > it is my first letter. > > Best wishes for New Year to all. > > > > I have a problem with two-dimensional arrays. In my > simple source code I can't > > get value from array indexed by two variables. But, I > can get these values by > > indexing by constants. The program compile > successfully but generates idiotic > > output. > > > > Source: > > > > MODULE aib EXPORTS Main; > > > > IMPORT IO, Fmt; > > > > CONST > > tab = ARRAY [0..2], [0..15] OF > CARDINAL { > > ARRAY OF CARDINAL > > { 17, 17, 17, 17, 17, > 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17 }, > > ARRAY OF CARDINAL > { 1, 2, > 3, 4, 5, 6, 7, 8, 9, 10, > 17, 17, 17, 17, 17, 17 }, > > ARRAY OF CARDINAL > { 17, 11, 12, 13, 14, 15, > 16, 17, 17, 17, 17, 17, 17, 17, 17, 17 } > > }; > > > > VAR > > k, l : CARDINAL; > > > > BEGIN > > > > k := 1; > > l := 9; > > > > IO.Put( "k = " & > Fmt.Int(k) & ", " ); > > IO.Put( "l = " & > Fmt.Int(l) & "\n" ); > > k := > tab[k][l]; > > IO.Put( "k = tab[k][l] => > 0x" & Fmt.F( "%02s", Fmt.Unsigned(k)) > & "\n" ); > > > > k := tab[1][9]; > > IO.Put( "k = > tab[1][9] => 0x" & > Fmt.F( "%02s", Fmt.Unsigned(k)) & > "\n" ); > > > > FOR i := 0 TO 2 DO > > FOR j := 0 TO 15 DO > > IO.Put( Fmt.F( " > %02s", Fmt.Int( tab[i][j] ) ) ); > > END; > > IO.Put( "\n" ); > > END; > > > > END aib. > > > > Output: > > > > k = 1, l = 9 > > k = tab[k][l] => 0x00 > > k = tab[1][9] => 0x0a > > 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 > > 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 > > 6296864 16 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 > > > > My system and compiler version is: > > > > $ uname -a > > > > Linux wenus.next.com.pl 2.6.35.10-74.fc14.x86_64 #1 > SMP Thu Dec 23 16:04:50\ > > UTC 2010 x86_64 x86_64 x86_64 > GNU/Linux > > $ cm3 -version > > > > Critical Mass Modula-3 version 5.8.6 > > last updated: 2010-04-11 > > compiled: 2010-07-12 20:10:34 > > configuration: > /usr/local/cm3/bin/cm3.cfg > > host: AMD64_LINUX > > target: AMD64_LINUX > > > > or > > > > Critical Mass Modula-3 version d5.9.0 > > last updated: 2010-07-21 > > compiled: 2010-12-16 03:15:26 > > configuration: > /usr/local/cm3/bin/cm3.cfg > > host: AMD64_LINUX > > quake runtime error: "/usr/local/cm3/bin/cm3.cfg", > line 2: quake runtime error:\ > > undefined variable: SL > > > > --procedure-- -line- -file--- > > > 2 /usr/local/cm3/bin/cm3.cfg > > target: > > Both compilers generate same results. > > > > Best regards > > DKnoto. > > > From dknoto at next.com.pl Thu Dec 30 23:14:42 2010 From: dknoto at next.com.pl (Dariusz =?UTF-8?B?S25vY2nFhHNraQ==?=) Date: Thu, 30 Dec 2010 23:14:42 +0100 Subject: [M3devel] Interpretation of numbers Message-ID: <20101230231442.2f3ee9a3.dknoto@next.com.pl> Hi all, in my spare time I write a lexer to Modula-3 for Scintilla library and I found mistake in numeric constants with explicitly given base number system, eg. octal numbers. This simple program in C generates compiler error: #include int main( void ) { unsigned o; o = 0787; printf( "o = %u\n", o ); return 0; } in gcc 4.5.1 20100924 (Red Hat 4.5.1-4) this is: Numbers.c: In function ?main?: Numbers.c:7:6: error: invalid digit "8" in octal constant but CM3 with analogical program: MODULE Numbers EXPORTS Main; IMPORT IO, Fmt; VAR o : CARDINAL; BEGIN o := 8_787; IO.Put( "o = 8_" & Fmt.Unsigned( o, 8 ) & "\n" ); END Numbers. compiles his properly and the program generate output: o = 8_1007 This is correct number, 519 decimal, but similar mistakes can be difficult to find. Best regards Dariusz Knoci?ski. From rcolebur at SCIRES.COM Thu Dec 30 23:29:50 2010 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Thu, 30 Dec 2010 17:29:50 -0500 Subject: [M3devel] CM3 status In-Reply-To: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com> References: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com> Message-ID: Olaf et al: I think I share the concern you've voiced. My observation from the M3COMMIT log emails is that Jay seems to be the most prolific these days with changes, but I find it impossible to keep track of what problem he is trying to solve. Indeed, it seems he is working on multiple issues at the same time, but it is difficult from the posts to differentiate which issue goes with which posting, and this problem is compounded by the fact that my M3COMMIT/M3DEVEL e-mails don't always seem to be received in chronological order. Thus, it is extremely difficult to know how to channel the limited time I have available into helping cooperate to solve a particular problem. Maybe it would be a good idea when each person posts something to M3COMMIT or M3DEVEL that they tag it up front with a comment or reference to the problem the post is addressing. Another idea, and perhaps your TRAC system supports it, is to assign certain problems to specific individuals who work the problem and report back their solution approach for some type of concurrence before going off on a tangent to solve. This might cut down on some of the subsequent backtracking and reverting changes. It would also allow others to offer constructive comments on the solution approach, even if they don't have time to actually implement the solution. [In reading the posts, I'm seeing many places where work is done, then later someone disagrees with it, and wants the changes reverted.] Even if one person is assigned as the lead for a particular problem, perhaps others could join in on helping solve it, coordinating their effort thru the lead person. I really do want to help as much as I can, and we definitely need to grow the development support base, so anything we can do to foster teamwork and an up-to-date awareness of the major problem areas and proposed solution paths would be helpful I think. I certainly don't want to squash anyone's individual efforts, but right now I don't think we're maximizing our use of the team concept. Regards, Randy Coleburn -----Original Message----- From: Olaf Wagner [mailto:wagner at elegosoft.com] Sent: Thursday, December 30, 2010 6:23 AM To: m3devel at elegosoft.com Subject: [M3devel] CM3 status Hi all, after reading a couple of Modula-3 mails again after some time of 'abstinence' I'm a little bit confused about the state of the code and the direction of development. I see that several different failures and ideas are discussed, but don't seem to get resolved; none of them is documented in our Trac instance as far as I know. Some things I remember offhand: o at least 2 different compiler/assembler problems on Darwin/Snow Leopard o current gcc not working on Solaris (?!) o stack walker code abandoned o possibly unsafe OS calls in new C code (this may be a wrong deduction from my side) o GUI input not working for BadBricks and other games (only on Darwin?) o no clean way for exception handling with current gcc o still alignment issues I'm concerned that things get tried out, don't work properly for all our target platforms, but are left then and not cleaned up and something else gets tried. I'm not sure this is correct, it is just me feeling unwell after reading all those mails. Hudson and Tinderbox status seem to be mostly OK though, but I haven't checked in detail (FreeBSD failing was a disk failure on my system recently). But the tests don't cover all the things we should check. I think it would be good to have an overview of the projects/work that is in progress or pending and its status. For example, we've imported a new gcc version, but that doesn't seem to work well on all targets, or does it? If not, how are we going to address this? Use older versions on some platforms? Can I read up on that somewhere? I'd like to suggest to simply use our Trac WiKi to document the ongoing work (everybody can get write access to that on request) and to record all errors, failures and major tasks there as issues. This should help everybody to participate and make me much more relaxed if I consider the M3 emails (if anybody should care about my personal discomfort at all :-) Just for reference: the trac instance can be found at https://projects.elego.de/cm3 Several of the committers should already have access, and using the WiKi and the issue tracker should not be much more work than writing emails. But the information will be easier to access then. I hope to have offended nobody by this; I just wanted to make a suggestion how to improve collaboration and discussion. Olaf -- Olaf Wagner -- elego Software Solutions GmbH Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From mika at async.caltech.edu Thu Dec 30 23:55:39 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 30 Dec 2010 14:55:39 -0800 Subject: [M3devel] cross builds and netobj/proxy generation In-Reply-To: References: Message-ID: <20101230225539.0B9A91A205B@async.async.caltech.edu> This is probably a bug in my code, actually. I should represent LAST(INTEGER) as LAST(INTEGER) and not as whatever it evaluates to. Although hm the evaluation probably comes from inside m3tk. That is how m3tk represents subranges (including the "subrange" FIRST(INTEGER)..LAST(INTEGER)). Mika Jay K writes: >--_a816f733-bbaf-451a-ba85-0ff058a4a08f_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > >I found this problem trying to build Mika's Scheme implementation >I hadn't rebuilt all tools to be I386_DARWIN -- some were still AMD64_DARWI= >N. >It seems the proxy code got values for LAST(INTEGER) in it=2C but they >were for the host=2C not the target. >Tools need to not assume they are the same... > > > - Jay > = > >--_a816f733-bbaf-451a-ba85-0ff058a4a08f_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >I found this problem trying to build Mika's Scheme implementation
I hadn= >'t rebuilt all tools to be I386_DARWIN -- some were still AMD64_DARWIN.
= >It seems the proxy code got values for LAST(INTEGER) in it=2C but they
w= >ere for the host=2C not the target.
Tools need to not assume they are th= >e same...


 =3B- Jay
> >= > >--_a816f733-bbaf-451a-ba85-0ff058a4a08f_-- From mika at async.caltech.edu Thu Dec 30 23:58:27 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Thu, 30 Dec 2010 14:58:27 -0800 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , , Message-ID: <20101230225827.B99371A205B@async.async.caltech.edu> All right, I have been able to whittle down a test for the "code generation error": INTERFACE CG_Error; END CG_Error. MODULE CG_Error; TYPE SchemeObject_T = REFANY; EXCEPTION Scheme_E; PROCEDURE ToScheme_VAL0LONGINT__VAL0LONGINT(READONLY x : [ VAL(0, LONGINT )..VAL(0, LONGINT ) ]) : SchemeObject_T RAISES { Scheme_E } = BEGIN RETURN ToScheme_LONGINT(x) END ToScheme_VAL0LONGINT__VAL0LONGINT; PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject_T RAISES { Scheme_E } = BEGIN WITH ref = NEW(REF LONGINT) DO ref^ := x; END END ToScheme_LONGINT; BEGIN END CG_Error. new source -> compiling CG_Error.i3 new source -> compiling CG_Error.m3 "../src/CG_Error.m3", line 12: warning: exception is never raised: CG_Error.Scheme_E "../src/CG_Error.m3", line 6: warning: not used (ToScheme_VAL0LONGINT__VAL0LONGINT) "../src/CG_Error.m3", line 15: warning: function may not return a value (ToScheme_LONGINT) "../src/CG_Error.m3", line 1: 1 code generation error 1 error and 3 warnings encountered Mika From dabenavidesd at yahoo.es Fri Dec 31 00:13:57 2010 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Thu, 30 Dec 2010 23:13:57 +0000 (GMT) Subject: [M3devel] gui problems? BadBricks? columns? In-Reply-To: <20101230032636.GA31254@topoi.pooq.com> Message-ID: <206460.28608.qm@web29714.mail.ird.yahoo.com> Hi all: it makes and abstraction of the code in terms of Guarded commands of Dijkstra, then applies the static checking of the calculus of weakest preconditions type checking as a normal program too the code and then translates to first order logic formulae, if the annotated program can be satisfied then it will give no output, but if does prove that the program doesn't produce the anottated output, it will complain on where it fails, wherever it doesn't like the proof. The important thing is that if the checker satisfies all of his conditions, it doesn't mean it does not break, i.e it could be that the checker will no complain but still can't prove absolutely that is not to crash, is a kind of liberal, perhaps because of its logic calculus. There is also the case of possible false alarms, which could be triggered, but this is almost the case in any compiler and here too, even the M3 compiler (something called completeness, just very simple known type systems have), so we can't expect to type check in the semantic analyser it wrong and to accept it in the checker, but we could instead just to make that a unsound program, lets say unsafe, will not lock or crash because and specific error because of the non-completeness issue. However the ESC didn't accept some special kind of almost safe programs, recursive, partly I believe because of a problem exposed below, is perhaps that the program doesn't end, unlike a for loop. There is also the need of a efficient and smarter automatic theorem prover, Simplify is one of the best available for some time now, but still, the same problems arise on it, it could be that because of the first order logic, the program could not terminate but the prover believe it will and it apparently does it, but that its proofs will be not totally proved for all cases, if so, then we would need to take care of those by applying hand formal verification measures like below I explain a case. Also Simplify could rise that he can't prove that something is not provable by itself, but turn that it is doable, just that it can't by its own, so we need to also verify those cases. In the end, the best case our checks will end, but sometimes, the first order logic could be an endless proof or undefined, in those cases we would need a threshold given by the experience, so we might start sooner than later to make our own. The best of this is that are many things that have room for improvement as Dr Greg Nelson told me some time ago, would be nice thing to have the TODO list from him. My personal wish is to make Modula-3 totally verifiable, learning this by hand would be harder, but by the tools we could make it for using its internal logic, the most critical part, the Professor Greg Nelson did some work on that part of that I believe. Then the important parts are the semantic checker which it self is built on its internal logic, e.g a biased logic (i.e an unsound one, the proofs could not end or be too large to finish and unable to realize that after it spends time on it) it could be that never ends a proof or check it badly as good, the most perfect it checks it would be less efficient at some point (perhaps this was the reason to not check the total correctness besides the effort needed) so might be easier to pass the checks but less profitable in the checking. I really would like the most inner parts to be self provable, like more functional style programming then, but those are not verifiable by the ESC checker, it just doesn't do that, similar to when I had a problem on the checker I used sasylf.org, it had unimplemented the mutual induction proving part by that time of a course back in 2008, this is a theorem proof technique you need to use in advanced type theory of type system soundness proofs, sasylf is a programming language by itself to proof it is sound, so it turns out that if we can trust on them more than in any part of the checker we could move on from there to more advanced techniques, also this is harder I believe based on my small experience of type systems proofing. ESC developers say, the most provable source of those mis-checkings is automatic theorem prover, not in checker, then it might be more valuable to start there than in the checker's logic by itself, being more practical, more pragmatic. I have some experience with the use of automatic theorem provers part use by hand with sasylf, writing the proofs and let it check for one (say I was the ESC checker and sasylf was the automatic theorem prover), and it turns out not to be so difficult to use after some work and time of use, still there are many challenges open in the checkers for now, so the room for improvements there is also too big (i.e we can check more things, say, the Modula-3 arithmetic over and/or under flow, recurrence, by improving the core logic calculus and later working on the "second pass" or backend first order logic prover). A special feature was the Locking level notation developed by writing the Trestle library, as it was coded threaded, it is perhaps the most advanced part of it, more details than that I don't now, but more probably coming on the way. I just know its logic is more advanced from what I recall, it requires some clever reasoning and calculus too I guess. So we can have a lot discussion, perhaps the first kick is given now. I also hope its not too much blah, ... sorry for the long message Thanks in advance --- El mi?, 29/12/10, Hendrik Boom escribi?: > De: Hendrik Boom > Asunto: Re: [M3devel] gui problems? BadBricks? columns? > Para: m3devel at elegosoft.com > Fecha: mi?rcoles, 29 de diciembre, 2010 22:26 > On Wed, Dec 29, 2010 at 08:23:12PM > -0500, Coleburn, Randy wrote: > > Daniel et al: > > > > I tried a year or so ago to pursue getting the sources > for the ESC. > > I'd have to dig up my old emails, but my recollection > is that I ran into a dead end getting the sources and the > permission to put them in our repository. > > I don't think the Modula-3 edition was kept up when > the project moved on to other languages. > > What does the ESC do that's relevant to threading? I > mean, not just an > answer like "deadlock and race detection", but what > algorithms does it > use to accomplish it? Does the Modula 3 compiler > construct the proper > data structures that could provide the raw data those > algorithms would > need? How much work would it be to reimplement this > from scratch? > > -- hendrik > From hendrik at topoi.pooq.com Fri Dec 31 02:57:43 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 30 Dec 2010 20:57:43 -0500 Subject: [M3devel] ESC In-Reply-To: <206460.28608.qm@web29714.mail.ird.yahoo.com> References: <20101230032636.GA31254@topoi.pooq.com> <206460.28608.qm@web29714.mail.ird.yahoo.com> Message-ID: <20101231015743.GA17628@topoi.pooq.com> On Thu, Dec 30, 2010 at 11:13:57PM +0000, Daniel Alejandro Benavides D. wrote: > Hi all: > it makes and abstraction of the code in terms of Guarded commands of > Dijkstra, then applies the static checking of the calculus of weakest > preconditions type checking as a normal program too the code This will be difficult for loops. Dijkstra's formalism more or less requires a variant to decrease around the loop. In fact, in his "A Discipline of Programming", he shows multiple examples where the choice of variant and invariant that are used to prove the program correct more -r less determines the program itself. A lovely book. > and then translates to first order logic formulae, if the annotated > program can be satisfied then it will give no output, but if does > prove that the program doesn't produce the anottated output, it will > complain on where it fails, wherever it doesn't like the proof. > The important thing is that if the checker satisfies all of his > conditions, it doesn't mean it does not break, i.e it could be that > the checker will no complain but still can't prove absolutely that is > not to crash, is a kind of liberal, perhaps because of its logic > calculus. That's definitely not Dijkstra's weakest preconditions, then, but something similar. > There is also the case of possible false alarms, which could be > triggered, but this is almost the case in any compiler and here too, > even the M3 compiler (something called completeness, just very simple > known type systems have), so we can't expect to type check in the > semantic analyser it wrong and to accept it in the checker, but we > could instead just to make that a unsound program, lets say unsafe, > will not lock or crash because and specific error because of the > non-completeness issue. However the ESC didn't accept some special > kind of almost safe programs, recursive, partly I believe because of a > problem exposed below, is perhaps that the program doesn't end, unlike > a for loop. Dijkstra in his calculus in "A Discipline of Programming" didn't consider recursion. So far I get the impression that ESC didn't guarantee that the program would run properly if it passed all the checks, nor that failure to pass the checks implied invalidity. It just sort of points put things that may need attention. Kind of like a formal verificatin system that's implemented half-heartedly. > There is also the need of a efficient and smarter automatic theorem > prover, Simplify is one of the best available for some time now, Is it? Got references? I recall that formula simplification was a basic technique in one of the first formal-verification systems back in the late 60's, and that it solved a lot of complicated cases. They originated by substituting into standard formulas that expressed particular predicate transformations. You got a lot of things like i > 0 & i >= 0 & i < 2, which can be simplified to i = 0 if you know i is in integer. There were a huge number of these simplifications, trivial and tedious, and often they sufficed to shos one formula was equivalend to another. > but still, the same problems arise on it, it could be that because > of the first order logic, the program could not terminate but the > prover believe it will and it apparently does it, but that its > proofs will be not totally proved for all cases, if so, then we would > need to take care of those by applying hand formal verification > measures like below I explain a case. > Also Simplify could rise that he can't prove that something is not > provable by itself, but turn that it is doable, just that it can't by > its own, so we need to also verify those cases. > In the end, the best case our checks will end, but sometimes, the > first order logic could be an endless proof or undefined, in those > cases we would need a threshold given by the experience, so we might > start sooner than later to make our own. > The best of this is that are many things that have room for > improvement as Dr Greg Nelson told me some time ago, would be nice > thing to have the TODO list from him. > My personal wish is to make Modula-3 totally verifiable, learning this > by hand would be harder, but by the tools we could make it for using > its internal logic, the most critical part, the Professor Greg Nelson > did some work on that part of that I believe. Formal verification is a hard problem. > Then the important parts are the semantic checker which it self is > built on its internal logic, e.g a biased logic (i.e an unsound one, > the proofs could not end or be too large to finish and unable to > realize that after it spends time on it) it could be that never ends a > proof or check it badly as good, the most perfect it checks it would > be less efficient at some point (perhaps this was the reason to not > check the total correctness besides the effort needed) so might be > easier to pass the checks but less profitable in the checking. I > really would like the most inner parts to be self provable, like more > functional style programming then, but those are not verifiable by the > ESC checker, it just doesn't do that, similar to when I had a problem > on the checker I used sasylf.org, I'll have to look into that. > it had unimplemented the mutual > induction proving part by that time of a course back in 2008, this is > a theorem proof technique you need to use in advanced type theory of > type system soundness proofs, sasylf is a programming language by > itself to proof it is sound, so it turns out that if we can trust on > them more than in any part of the checker we could move on from there > to more advanced techniques, also this is harder I believe based on my > small experience of type systems proofing. I was working with Martin-Lof's type theory in the eighties. I ended up with a verifier, and manages to mechanically proof-check a merge-sort, written in the lazy functional language that's implicit in the logic. It was difficult to use, and really taxed the resources of our Vax 780, even though it has a whole 5 megabytes of memory! And the first verified sort had a bug -- not that it didn't sort; that had been proved, but that it wasn't the merge sort I had intended; it took quadratic time. That verifier is where I learned you have to debug the specifications as well as the code. Right now, the most sophisticated poof-checker of this kind seems to be coq, but some users of coq find they have to more-or-less rewrite coq to achieve efficiency of effort. > ESC developers say, the most provable source of those mis-checkings is > automatic theorem prover, not in checker, then it might be more > valuable to start there than in the checker's logic by itself, being > more practical, more pragmatic. I have some experience with the use of > automatic theorem provers part use by hand with sasylf, writing the > proofs and let it check for one (say I was the ESC checker and sasylf > was the automatic theorem prover), and it turns out not to be so > difficult to use after some work and time of use, still there are many > challenges open in the checkers for now, so the room for improvements > there is also too big (i.e we can check more things, say, the Modula-3 > arithmetic over and/or under flow, recurrence, by improving the core > logic calculus and later working on the "second pass" or backend first > order logic prover). > A special feature was the Locking level notation developed by writing > the Trestle library, Those locking levels were something special. I remember thinking deeply about the way those assertions worked, deciding that they were the right kind of assertions to base proofs on, and proceeded to ignore them when I read the rest of the code. > as it was coded threaded, it is perhaps the most > advanced part of it, more details than that I don't now, but more > probably coming on the way. I just know its logic is more advanced > from what I recall, it requires some clever reasoning and calculus too > I guess. Yeah... this is what we'd need to catch races and deadlocks and such. And it does seem to be mostly independent of the partial-correctness theorem proving described above. Deadlock and races are global issues. > So we can have a lot discussion, perhaps the first kick is given now. > I also hope its not too much blah, ... sorry for the long message Mostly you've outlined some traditional verification technology. ESC seems to use that, possibly with a restricted class of assertions (not clear just which ones), and has the limitations of the same. But the locking levels in trestle do seem to be something else. > Thanks in advance You're welcome. It seems to be a big project. to answer one of my original questions. The question is, whether there are smaller subprojects that are more feasible and will lead to a checker with code structure that can be easily grown. Without small successes, the motivation is often absent to proceed on to the large successes. That's especially true with FLOSS. Once you have something that actually does something useful, people start to use it, and suddenly your users realise how it could be improved, tell you, and if you're lucky, start to make the improvements themselves. --- My view of formal verification is that the proof has to be primary. You write a proof that there is some code that satisfies a spec, and the details of the proof reveal the program. This is completely different from the inductive-assertion method, in that you can use general theorems about particular loop structures, for example, and specialize then as necessary. In fact, I suspect that the theoretical feasibility of this approach is possibly the only reason why people can understand programs at all. You look at some code, decide after a while that there's a nest of six corecursive procedures, look at how parameters are passed down, and realize that it's recursion on a particulat tree structure -- at least you hope it's a tree structure, because its finite, noncyclic structure is nowhere explicit in the code. You reason backwards from patterns in the code to the reasoning the original programmer must have had in mind when he wrote it -- reasoning which rarely appears in the code, rarely even in comments. But using any of these methods for formal verification is still impractical except where the requirements for reliability justify extreme efforts. And I suspect strongly that the logic -- and the particular easy-to-use theorems about synthesizing program structures -- should dictate the structure of the programming language, which quite possibly won't end up being Modula 3. But who knows? The logic people use to decompose problems into implementable program components are largely independent of the pangauge they use, except for * restrictions of parameterization * absenes of convenient coding patterns for desired code structures * reliance on the particular properties that the language implementation guarantees (and therefore needs less explicit thought). I can imagine that the higher-order logics involved are similar for many programming languages, just as things like the Deduction Theorem are similar in many quite different formal logics (though the details of the proofs can be quite different). -- hendrik > > --- El mi?, 29/12/10, Hendrik Boom escribi?: > > > De: Hendrik Boom > > Asunto: Re: [M3devel] gui problems? BadBricks? columns? > > Para: m3devel at elegosoft.com > > Fecha: mi?rcoles, 29 de diciembre, 2010 22:26 > > On Wed, Dec 29, 2010 at 08:23:12PM > > -0500, Coleburn, Randy wrote: > > > Daniel et al: > > > > > > I tried a year or so ago to pursue getting the sources > > for the ESC. > > > I'd have to dig up my old emails, but my recollection > > is that I ran into a dead end getting the sources and the > > permission to put them in our repository. > > > I don't think the Modula-3 edition was kept up when > > the project moved on to other languages. > > > > What does the ESC do that's relevant to threading? I > > mean, not just an > > answer like "deadlock and race detection", but what > > algorithms does it > > use to accomplish it? Does the Modula 3 compiler > > construct the proper > > data structures that could provide the raw data those > > algorithms would > > need? How much work would it be to reimplement this > > from scratch? > > > > -- hendrik > > > > > From jay.krell at cornell.edu Fri Dec 31 07:51:21 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Dec 2010 06:51:21 +0000 Subject: [M3devel] CM3 status In-Reply-To: References: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com>, Message-ID: The system works fairly well, but also could use some obvious improvement. What do people want to work on that I am in the way of? If you do actually work on the same file as I do, you can still merge. Source control is not mutual exclusion. Granted, CVS doesn't help nearly as much as other source control systems. Perforce is the best I have used, by far, among just a few. Some of the possible future directions moot others. For example, enabling/fixing the typinfo in the gcc backend would be nice, but replacing it with LLVM and/or C++ and/or integrated backends moots that. Ditto for using the gcc exception handling infrastructure. Anything anyone is interested in doing, please speak up, and/or send diffs, and/or commit changes. Please don't be offended or discouraged if changes are backed out, if they don't work for some people. If there is target-dependence, consider some way to enable/disable based on target, and only enabling what you can test, waiting for others to test/enable others. I agree we have too little contribution from too few people, but not clear why. There are possibilities other than blaming me. The system has its interesting characteristics asis, but competition from other languages and libraries are probably more the cause (be careful not to confuse them!): C, C++, Qt, Java, GWT, C#, Perl, Python, Ruby, Tcl, Bash, "HTML", PHP, JavaScript, wxWindows, LUA, etc. It is indeed unusual to have a system with optional safety and native code generation (vs. interpreter or JIT). Just optional safety is rare, and present mainly only C#. I can't think of another language with optional safety and native code generation (granted, I can only name two languages with optional safety: Modula-3 and C#). Having a proper module system is also great, as it makes compilation very fast, on NT386 (similar to Java and C#). - Jay > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Thu, 30 Dec 2010 17:29:50 -0500 > Subject: Re: [M3devel] CM3 status > > Olaf et al: > > I think I share the concern you've voiced. > > My observation from the M3COMMIT log emails is that Jay seems to be the most prolific these days with changes, but I find it impossible to keep track of what problem he is trying to solve. Indeed, it seems he is working on multiple issues at the same time, but it is difficult from the posts to differentiate which issue goes with which posting, and this problem is compounded by the fact that my M3COMMIT/M3DEVEL e-mails don't always seem to be received in chronological order. > > Thus, it is extremely difficult to know how to channel the limited time I have available into helping cooperate to solve a particular problem. > > Maybe it would be a good idea when each person posts something to M3COMMIT or M3DEVEL that they tag it up front with a comment or reference to the problem the post is addressing. > > Another idea, and perhaps your TRAC system supports it, is to assign certain problems to specific individuals who work the problem and report back their solution approach for some type of concurrence before going off on a tangent to solve. This might cut down on some of the subsequent backtracking and reverting changes. It would also allow others to offer constructive comments on the solution approach, even if they don't have time to actually implement the solution. [In reading the posts, I'm seeing many places where work is done, then later someone disagrees with it, and wants the changes reverted.] > > Even if one person is assigned as the lead for a particular problem, perhaps others could join in on helping solve it, coordinating their effort thru the lead person. > > I really do want to help as much as I can, and we definitely need to grow the development support base, so anything we can do to foster teamwork and an up-to-date awareness of the major problem areas and proposed solution paths would be helpful I think. > > I certainly don't want to squash anyone's individual efforts, but right now I don't think we're maximizing our use of the team concept. > > Regards, > Randy Coleburn > > -----Original Message----- > From: Olaf Wagner [mailto:wagner at elegosoft.com] > Sent: Thursday, December 30, 2010 6:23 AM > To: m3devel at elegosoft.com > Subject: [M3devel] CM3 status > > Hi all, > > after reading a couple of Modula-3 mails again after some time of > 'abstinence' I'm a little bit confused about the state of the code > and the direction of development. I see that several different failures > and ideas are discussed, but don't seem to get resolved; none of them > is documented in our Trac instance as far as I know. Some things I > remember offhand: > > o at least 2 different compiler/assembler problems on Darwin/Snow Leopard > o current gcc not working on Solaris (?!) > o stack walker code abandoned > o possibly unsafe OS calls in new C code (this may be a wrong deduction > from my side) > o GUI input not working for BadBricks and other games (only on Darwin?) > o no clean way for exception handling with current gcc > o still alignment issues > > I'm concerned that things get tried out, don't work properly for all > our target platforms, but are left then and not cleaned up and something > else gets tried. I'm not sure this is correct, it is just me feeling > unwell after reading all those mails. > > Hudson and Tinderbox status seem to be mostly OK though, but I haven't > checked in detail (FreeBSD failing was a disk failure on my system > recently). But the tests don't cover all the things we should check. > > I think it would be good to have an overview of the projects/work that > is in progress or pending and its status. For example, we've imported > a new gcc version, but that doesn't seem to work well on all targets, > or does it? If not, how are we going to address this? Use older versions > on some platforms? Can I read up on that somewhere? > > I'd like to suggest to simply use our Trac WiKi to document the ongoing > work (everybody can get write access to that on request) and to record > all errors, failures and major tasks there as issues. This should help > everybody to participate and make me much more relaxed if I consider > the M3 emails (if anybody should care about my personal discomfort > at all :-) > > Just for reference: the trac instance can be found at > https://projects.elego.de/cm3 > > Several of the committers should already have access, and using > the WiKi and the issue tracker should not be much more work than > writing emails. But the information will be easier to access then. > > I hope to have offended nobody by this; I just wanted to make a suggestion > how to improve collaboration and discussion. > > Olaf > -- > Olaf Wagner -- elego Software Solutions GmbH > Gustav-Meyer-Allee 25 / Geb?ude 12, 13355 Berlin, Germany > phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95 > http://www.elegosoft.com | Gesch?ftsf?hrer: Olaf Wagner | Sitz: Berlin > Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 31 08:11:24 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Dec 2010 07:11:24 +0000 Subject: [M3devel] factoring jmpbuf size via alloca(global constant)? In-Reply-To: References: Message-ID: The more I think about this, the more I like it. However there might be a better option. Gcc has some notion of built-in setjmp. For that matter, maybe using the gcc exception handling mechanism isn't difficult? - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Subject: factoring jmpbuf size via alloca(global constant)? Date: Thu, 30 Dec 2010 14:28:31 +0000 factoring out jmpbuf size? Hey, um, how about something like this: somefile.c: #include extern const int sizeof_jmpbuf = sizeof(jmp_buf); where the frontend would allocate a local jmp_buf, instead issue a call to alloca(sizeof_jmpbuf), actually reading the constant out of the global. Yes I know this is a deoptimization. It is already slow. We hope hope hope to replace it all anyway. This would remove lots of target-specific code in Target.m3. Related, I'm again trying removing from m3core the knowledge of the size/alignment of jmpbuf. Or rather, to see if it really needs it. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Fri Dec 31 14:52:27 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Dec 2010 13:52:27 +0000 Subject: [M3devel] expressing 128 bit alignment? Message-ID: The alignment of jmpbuf is 128 bits for some targets. It seems like a hole in the language that this can't be expressed. Or maybe I just don't know how. Or maybe Target.max_align gets in the way?? I'd like to soon remove an accurately described jmpbuf from m3core, making this maybe moot. Linux/powerpc: /usr/include/bits/setjmp.h #ifndef _ASM # if __WORDSIZE == 64 typedef long int __jmp_buf[64] __attribute__ ((__aligned__ (16))); # else /* The alignment is not essential, i.e.the buffer can be copied to a 4 byte aligned buffer as per the ABI it is just added for performance reasons. */ typedef long int __jmp_buf[64 + (12 * 4)] __attribute__ ((__aligned__ (16))); # endif #endif Notice that the 128bit alignment on powerpc64 is not commented as being unessential, only for powerpc32. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Fri Dec 31 19:50:01 2010 From: mika at async.caltech.edu (Mika Nystrom) Date: Fri, 31 Dec 2010 10:50:01 -0800 Subject: [M3devel] compiler problems on Snow Leopard In-Reply-To: References: <20101212201458.BEFA41A2079@async.async.caltech.edu>, , <20101227101421.38A6A1A205B@async.async.caltech.edu>, , , Message-ID: <20101231185001.2E77A1A205B@async.async.caltech.edu> I reported two compiler crashes on Snow Leopard. Earlier I provided a distilled version of the code that produces one crash. Here is the other one: MODULE Main; IMPORT FileWr, Wr; IMPORT Fmt; TYPE PV = RECORD price : LONGREAL; volume : CARDINAL; END; HFData_S = RECORD time : LONGREAL; pv : PV; END; PROCEDURE DumpMatching() = PROCEDURE DumpOne(trade : HFData_S) RAISES { Wr.Failure } = BEGIN Wr.PutText(wr, Fmt.LongReal(trade.time)); END DumpOne; VAR wr := FileWr.Open("out"); BEGIN END DumpMatching; BEGIN END Main. [hal:regress/ximport2/src] mika% cm3 -x --- building in ../I386_DARWIN --- new source -> compiling Main.m3 "../src/Main.m3", line 28: warning: potentially unhandled exception: OSError.E "../src/Main.m3", line 24: warning: potentially unhandled exception: Thread.Alerted "../src/Main.m3", line 22: warning: not used (DumpOne) "../src/Main.m3", line 20: warning: not used (DumpMatching) 4 warnings encountered ../src/Main.m3: In function 'Main__DumpMatching__DumpOne': ../src/Main.m3:25:0: error: unable to find a register to spill in class 'CREG' ../src/Main.m3:25:0: error: this is the insn: (insn 5 4 6 2 ../src/Main.m3:22 (parallel [ (set (reg:SI 0 ax [66]) (const_int 0 [0x0])) (set (reg:SI 1 dx [64]) (plus:SI (ashift:SI (reg:SI 0 ax [66]) (const_int 2 [0x2])) (reg:SI 1 dx [64]))) (set (reg:SI 4 si [65]) (plus:SI (ashift:SI (reg:SI 0 ax [66]) (const_int 2 [0x2])) (reg:SI 4 si [65]))) (set (mem/s/c:BLK (reg:SI 1 dx [64]) [0 trade+0 S24 A64]) (mem/s/c:BLK (reg:SI 4 si [65]) [0 trade+0 S24 A32])) (use (reg:SI 0 ax [66])) ]) 838 {*rep_movsi} (expr_list:REG_UNUSED (reg:SI 0 ax [66]) (expr_list:REG_UNUSED (reg:SI 4 si [65]) (expr_list:REG_UNUSED (reg:SI 1 dx [64]) (nil))))) ../src/Main.m3:25:0: internal compiler error: in spill_failure, at reload1.c:2163 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. m3_backend => 4 m3cc (aka cm3cg) failed compiling: Main.mc compilation failed => not building program "ximport" Fatal Error: package build failed [hal:regress/ximport2/src] mika% Happy New Year! Mika Jay K writes: >--_2d6969dc-a0fa-42e3-85e1-71600a2e9b7d_ >Content-Type: multipart/alternative; > boundary="_4765c0a9-911e-4b00-a171-d643958a7caa_" > >--_4765c0a9-911e-4b00-a171-d643958a7caa_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > >From: jay.krell at cornell.edu >To: hosking at cs.purdue.edu >CC: m3devel at elegosoft.com >Subject: RE: [M3devel] compiler problems on Snow Leopard >Date: Mon=2C 27 Dec 2010 21:41:31 +0000 > > > > > > > > > > Rather than cluttering up CVS=2C why not put it in the bug-tracker? Tha= >t's what it is for! > >It is large. >It is more code that could be repeatedly tested=2C by building the entire "= >system"=2C for a gradually growing >definition of "system". > >We have had a number of problems that only appear in one or two or a few pi= >eces of code. >e.g. the removal of referenced nested functions. >e.g. optimizations causing compilation to fail (which this appears to be as= > well). > >A smaller example would be nice=2C but that is more work to get. > > - Jay > >From: hosking at cs.purdue.edu >Date: Mon=2C 27 Dec 2010 12:23:35 -0500 >To: jay.krell at cornell.edu >CC: m3devel at elegosoft.com >Subject: Re: [M3devel] compiler problems on Snow Leopard > > > >Rather than cluttering up CVS=2C why not put it in the bug-tracker? That's= > what it is for! > >Antony Hosking | Associate Professor | Computer Science | Purdue University= >305 N. University Street | West Lafayette | IN 47907 | USAOffice +1 765 494= > 6001 | Mobile +1 765 427 5484 > > >On Dec 27=2C 2010=2C at 5:17 AM=2C Jay K wrote:Can you put all your code in= > our CVS repository? > >> "../I386_DARWIN/FSSchemeStubs.m3"=2C line 434: 2 code generation errors > >There is a way to get that to show more information.. >Or does it already? > > - Jay > >> To: m3devel at elegosoft.com >> Date: Mon=2C 27 Dec 2010 02:14:21 -0800 >> From: mika at async.caltech.edu >> Subject: Re: [M3devel] compiler problems on Snow Leopard >>=20 >> I upgraded to the CVS head and now I get the following: >>=20 >> ... >> "../I386_DARWIN/FSSchemeStubs.m3"=2C line 872: warning: unreachable state= >ment >> "../I386_DARWIN/FSSchemeStubs.m3"=2C line 903: warning: unreachable state= >ment >> "../I386_DARWIN/FSSchemeStubs.m3"=2C line 434: 2 code generation errors >> 1 error and 23 warnings encountered >> new exporters -> recompiling FSSchemeStubs.i3 >> ... >>=20 >> The source code is: >>=20 >> TYPE FS_Iterator_Surrogate =3D FS.Iterator OBJECT (* line 434 *) >> interp : Scheme.T=3B >> next_slot : SchemeObject.T :=3D NIL=3B >> close_slot : SchemeObject.T :=3D NIL=3B >> nextWithStatus_slot : SchemeObject.T :=3D NIL=3B >> OVERRIDES >> next :=3D FS_Iterator_next_default=3B >> close :=3D FS_Iterator_close_default=3B >> nextWithStatus :=3D FS_Iterator_nextWithStatus_default=3B >> END=3B >>=20 >> Mika >>=20 >> Mika Nystrom writes: >> >Hi everyone=2C >> > >> >Well I was able to get past all my linking issues (mostly questions >> >of dynamic vs. static linking and how to do it=2C which seems to change = >from >> >version to version...) >> > >> >But now I did hit a real problem. >> > >> >"../I386_DARWIN/FSSchemeStubs.m3"=2C line 934: ** INTERNAL CG ERROR *** = >unaligne >> >d store type=3D6 s/o/a=3D32/0/32 >> >"../I386_DARWIN/FSSchemeStubs.m3"=2C line 981: ** INTERNAL CG ERROR *** = >unaligne >> >d load_indirect type=3D6 s/a=3D32/32 >> > >> >Here is the code=2C but it's not likely to be of much help... >> > >> >PROCEDURE ToScheme_File_Status(READONLY x : File.Status) : SchemeObject.= >T RAIS >> >ES { Scheme.E } =3D >> > BEGIN >> > VAR res : SchemePair.T:=3DNIL=3B BEGIN >> > res :=3D SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("type"= >)=2CT >> >oScheme_Atom_T(x.type))=2Cres)=3B >> > res :=3D SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("modif= >ica >> >tionTime")=2CSchemeModula3Types.ToScheme_LONGREAL(x.modificationTime))= >=2Cres)=3B >> > res :=3D SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size"= >)=2CT >> >oScheme_VAL0LONGINT__VAL16778080LONGINT(x.size))=2Cres)=3B (* line 934 *= >) >> > RETURN res >> > END >> > END ToScheme_File_Status=3B >> > >> > >> >... >> > >> >PROCEDURE ToScheme_VAL0LONGINT__VAL16778080LONGINT(READONLY x : [ VAL(0= >=2C LONGI >> >NT )..VAL(16778080=2C LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } = >=3D >> > BEGIN >> > RETURN ToScheme_LONGINT(x) (* line 981 *) >> > END ToScheme_VAL0LONGINT__VAL16778080LONGINT=3B >> > >> > >> >for reference=2C ToScheme_LONGINT is: >> > >> >PROCEDURE ToScheme_LONGINT(READONLY x : LONGINT ) : SchemeObject.T RAISE= >S { S >> >cheme.E } =3D >> > BEGIN >> > WITH ref =3D NEW(REF LONGINT) DO >> > ref^ :=3D x=3B >> > RETURN SchemeModula3Types.ToScheme_LONGINT(ref) >> > END >> > END ToScheme_LONGINT=3B >> > >> > Mika > > = > >--_4765c0a9-911e-4b00-a171-d643958a7caa_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > > > >


From: jay.krell at cornell.edu
To: hosk= >ing at cs.purdue.edu
CC: m3devel at elegosoft.com
Subject: RE: [M3devel] co= >mpiler problems on Snow Leopard
Date: Mon=2C 27 Dec 2010 21:41:31 +0000<= >br>
> >"> > > > > > =3B>=3B Rather than cluttering up CVS=2C why not put it in the bug-t= >racker?  =3BThat's what it is for!

It is large.
It is more co= >de that could be repeatedly tested=2C by building the entire "system"=2C fo= >r a gradually growing
definition of "system".

We have had a numbe= >r of problems that only appear in one or two or a few pieces of code.
e.= >g. the removal of referenced nested functions.
e.g. optimizations causin= >g compilation to fail (which this appears to be as well).

A smaller = >example would be nice=2C but that is more work to get.

 =3B- Jay= >

From: hosking at cs.purdue.edu
Date: Mon= >=2C 27 Dec 2010 12:23:35 -0500
To: jay.krell at cornell.edu
CC: m3devel@= >elegosoft.com
Subject: Re: [M3devel] compiler problems on Snow Leopardr>
> >Rather than cluttering up CVS=2C why not put it in the bug-tracker?  = >=3BThat's what it is for!

>olor: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font= >-style: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spa= >cing: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: = >none=3B white-space: normal=3B word-spacing: 0px=3B">e-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)= >=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font= >-variant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-h= >eight: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: n= >ormal=3B word-spacing: 0px=3B">
n class=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B color= >: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-sty= >le: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spacing= >: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: none= >=3B white-space: normal=3B word-spacing: 0px=3B">yle-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B = >font-family: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-var= >iant: normal=3B font-weight: normal=3B letter-spacing: normal=3B line-heigh= >t: normal=3B text-indent: 0px=3B text-transform: none=3B white-space: norma= >l=3B word-spacing: 0px=3B">der-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica= >=3B font-size: 12px=3B font-style: normal=3B font-variant: normal=3B font-w= >eight: normal=3B letter-spacing: normal=3B line-height: normal=3B text-inde= >nt: 0px=3B text-transform: none=3B white-space: normal=3B word-spacing: 0px= >=3B">=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B= > font-style: normal=3B font-variant: normal=3B font-weight: normal=3B lette= >r-spacing: normal=3B line-height: normal=3B text-indent: 0px=3B text-transf= >orm: none=3B white-space: normal=3B word-spacing: 0px=3B">xApple-style-span" style=3D"border-collapse: separate=3B color: rgb(0=2C 0= >=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-style: normal= >=3B font-variant: normal=3B font-weight: normal=3B letter-spacing: normal= >=3B line-height: normal=3B text-indent: 0px=3B text-transform: none=3B whit= >e-space: normal=3B word-spacing: 0px=3B">" style=3D"border-collapse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-fam= >ily: Helvetica=3B font-size: 12px=3B font-style: normal=3B font-variant: no= >rmal=3B font-weight: normal=3B letter-spacing: normal=3B line-height: norma= >l=3B text-indent: 0px=3B text-transform: none=3B white-space: normal=3B wor= >d-spacing: 0px=3B">apse: separate=3B color: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font= >-size: 12px=3B font-style: normal=3B font-variant: normal=3B font-weight: n= >ormal=3B letter-spacing: normal=3B line-height: normal=3B text-indent: 0px= >=3B text-transform: none=3B white-space: normal=3B word-spacing: 0px=3B">pan class=3D"ecxApple-style-span" style=3D"border-collapse: separate=3B col= >or: rgb(0=2C 0=2C 0)=3B font-family: Helvetica=3B font-size: 12px=3B font-s= >tyle: normal=3B font-variant: normal=3B font-weight: normal=3B letter-spaci= >ng: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform: no= >ne=3B white-space: normal=3B word-spacing: 0px=3B">
pple-style-span" color=3D"#0000ff">=3D"Gill Sans"> 0=2C 255)=3B font-family: 'Gill Sans'=3B">an" style=3D"color: rgb(0=2C 0=2C 255)=3B font-family: 'Gill Sans'=3B">Anto= >ny Hoskingace=3D"Gill Sans"> 'Gill Sans'=3B">'Gill Sans'=3B"> =3B|pan class=3D"ecxApple-converted-space"> =3Blass=3D"ecxApple-style-span" style=3D"font-family: 'Gill Sans'=3B">ass=3D"ecxApple-style-span" style=3D"font-family: 'Gill Sans'=3B">Associate= > Professoramily: 'Gill Sans'=3B">mily: 'Gill Sans'=3B"> =3B| Computer Science | Purdue University= >
ns-Light">s-Light=3B">305 N. University Street | West Lafayette | IN 47907 | USAn>
ace=3D"Gill Sans">=2C 0=2C 255)=3B font-family: 'Gill Sans'=3B">-span" style=3D"color: rgb(0=2C 0=2C 255)=3B font-family: 'Gill Sans'=3B">O= >fficeans-Light">ns-Light=3B">Sans-Light=3B"> =3B+1 765 494 6001 |pace"> =3Bn" color=3D"#0000ff" face=3D"Gill Sans"> style=3D"color: rgb(0=2C 0=2C 255)=3B font-family: 'Gill Sans'=3B">lass=3D"ecxApple-style-span" style=3D"color: rgb(0=2C 0=2C 255)=3B font-fam= >ily: 'Gill Sans'=3B">Mobilele-span" face=3D"GillSans-Light">=3D"font-family: GillSans-Light=3B">le=3D"font-family: GillSans-Light=3B">ce"> =3B+1 765 427 5484
ss=3D"ecxApple-style-span" face=3D"GillSans-Light">
ock-placeholder">
pan>
<= >br class=3D"ecxApple-interchange-newline"> >
>
On Dec 27=2C 2010=2C at 5:17 AM=2C Jay K wrote:

s=3D"ecxApple-interchange-newline">
e-span" style=3D"border-collapse: separate=3B font-family: Helvetica=3B fon= >t-style: normal=3B font-variant: normal=3B font-weight: normal=3B letter-sp= >acing: normal=3B line-height: normal=3B text-indent: 0px=3B text-transform:= > none=3B white-space: normal=3B word-spacing: 0px=3B font-size: medium=3B">= >
=3B">Can you put all your code in our CVS repository?

>=3B "../I38= >6_DARWIN/FSSchemeStubs.m3"=2C line 434: 2 code generation errors

The= >re is a way to get that to show more information..
Or does it already?r>
 =3B- Jay

>=3B To:e"> =3Bm3devel at elegosof= >t.com
>=3B Date: Mon=2C 27 Dec 2010 02:14:21 -0800
>=3B From:= > =3Bika at async.caltech.edu">mika at async.caltech.edu
>=3B Subject: Re: [M= >3devel] compiler problems on Snow Leopard
>=3Bconverted-space"> =3B
>=3B I upgraded to the CVS head and n= >ow I get the following:
>=3B&= >nbsp=3B
>=3B ...
>=3B "../I386_DARWIN/FSSchemeStubs.m3"=2C= > line 872: warning: unreachable statement
>=3B "../I386_DARWIN/FSSchem= >eStubs.m3"=2C line 903: warning: unreachable statement
>=3B "../I386_D= >ARWIN/FSSchemeStubs.m3"=2C line 434: 2 code generation errors
>=3B 1 e= >rror and 23 warnings encountered
>=3B new exporters ->=3B recompilin= >g FSSchemeStubs.i3
>=3B ...
>=3B-space"> =3B
>=3B The source code is:
>=3B=3D"ecxApple-converted-space"> =3B
>=3B TYPE FS_Iterator_Su= >rrogate =3D FS.Iterator OBJECT (* line 434 *)
>=3B interp : Scheme.T= >=3B
>=3B next_slot : SchemeObject.T :=3D NIL=3B
>=3B close_slot := > SchemeObject.T :=3D NIL=3B
>=3B nextWithStatus_slot : SchemeObject.T = >:=3D NIL=3B
>=3B OVERRIDES
>=3B next :=3D FS_Iterator_next_defaul= >t=3B
>=3B close :=3D FS_Iterator_close_default=3B
>=3B nextWithSt= >atus :=3D FS_Iterator_nextWithStatus_default=3B
>=3B END=3B
>=3B<= >span class=3D"ecxApple-converted-space"> =3B
>=3B Mika
&= >gt=3B =3B
>=3B Mik= >a Nystrom writes:
>=3B >=3BHi everyone=2C
>=3B >=3B
>=3B= > >=3BWell I was able to get past all my linking issues (mostly questions<= >br>>=3B >=3Bof dynamic vs. static linking and how to do it=2C which see= >ms to change from
>=3B >=3Bversion to version...)
>=3B >=3Br>>=3B >=3BBut now I did hit a real problem.
>=3B >=3B
>=3B= > >=3B"../I386_DARWIN/FSSchemeStubs.m3"=2C line 934: ** INTERNAL CG ERROR = >*** unaligne
>=3B >=3Bd store type=3D6 s/o/a=3D32/0/32
>=3B >= >=3B"../I386_DARWIN/FSSchemeStubs.m3"=2C line 981: ** INTERNAL CG ERROR *** = >unaligne
>=3B >=3Bd load_indirect type=3D6 s/a=3D32/32
>=3B >= >=3B
>=3B >=3BHere is the code=2C but it's not likely to be of much h= >elp...
>=3B >=3B
>=3B >=3BPROCEDURE ToScheme_File_Status(READ= >ONLY x : File.Status) : SchemeObject.T RAIS
>=3B >=3BES { Scheme.E }= > =3D
>=3B >=3B BEGIN
>=3B >=3B VAR res : SchemePair.T:=3DNIL= >=3B BEGIN
>=3B >=3B res :=3D SchemeUtils.Cons(SchemeUtils.Cons(Schem= >eSymbol.FromText("type")=2CT
>=3B >=3BoScheme_Atom_T(x.type))=2Cres)= >=3B
>=3B >=3B res :=3D SchemeUtils.Cons(SchemeUtils.Cons(SchemeSymbo= >l.FromText("modifica
>=3B >=3BtionTime")=2CSchemeModula3Types.ToSche= >me_LONGREAL(x.modificationTime))=2Cres)=3B
>=3B >=3B res :=3D Scheme= >Utils.Cons(SchemeUtils.Cons(SchemeSymbol.FromText("size")=2CT
>=3B >= >=3BoScheme_VAL0LONGINT__VAL16778080LONGINT(x.size))=2Cres)=3B (* line 934 *= >)
>=3B >=3B RETURN res
>=3B >=3B END
>=3B >=3B END ToS= >cheme_File_Status=3B
>=3B >=3B
>=3B >=3B
>=3B >=3B...<= >br>>=3B >=3B
>=3B >=3BPROCEDURE ToScheme_VAL0LONGINT__VAL1677808= >0LONGINT(READONLY x : [ VAL(0=2C LONGI
>=3B >=3BNT )..VAL(16778080= >=2C LONGINT ) ]) : SchemeObject.T RAISES { Scheme.E } =3D
>=3B >=3B = >BEGIN
>=3B >=3B RETURN ToScheme_LONGINT(x) (* line 981 *)
>=3B = >>=3B END ToScheme_VAL0LONGINT__VAL16778080LONGINT=3B
>=3B >=3B
= >>=3B >=3B
>=3B >=3Bfor reference=2C ToScheme_LONGINT is:
>= >=3B >=3B
>=3B >=3BPROCEDURE ToScheme_LONGINT(READONLY x : LONGINT = >) : SchemeObject.T RAISES { S
>=3B >=3Bcheme.E } =3D
>=3B >= >=3B BEGIN
>=3B >=3B WITH ref =3D NEW(REF LONGINT) DO
>=3B >= >=3B ref^ :=3D x=3B
>=3B >=3B RETURN SchemeModula3Types.ToScheme_LONG= >INT(ref)
>=3B >=3B END
>=3B >=3B END ToScheme_LONGINT=3B
&= >gt=3B >=3B
>=3B >=3B Mika

<= >/div>
>= > >--_4765c0a9-911e-4b00-a171-d643958a7caa_-- > >--_2d6969dc-a0fa-42e3-85e1-71600a2e9b7d_ >Content-Type: application/octet-stream >Content-Transfer-Encoding: base64 >Content-Disposition: attachment; filename="FSSchemeStubs.i3" > >SU5URVJGQUNFIEZTU2NoZW1lU3R1YnM7CigqIEFVVE9NQVRJQ0FMTFkgR0VORVJBVEVEIERPIE5P >VCBFRElUICopCklNUE9SVCBTY2hlbWU7CklNUE9SVCBTY2hlbWVPYmplY3Q7CklNUE9SVCBTY2hl >bWVQYWlyOwpJTVBPUlQgU2NoZW1lTW9kdWxhM1R5cGVzOwpJTVBPUlQgT1NFcnJvcjsKSU1QT1JU >IEZpbGU7CklNUE9SVCBGUzsKSU1QT1JUIFNjaGVtZVN5bWJvbDsKSU1QT1JUIFNjaGVtZVV0aWxz >OwpJTVBPUlQgU2NoZW1lQXBwbHk7CklNUE9SVCBBdG9tTGlzdDsKSU1QT1JUIFNjaGVtZUJvb2xl >YW47CklNUE9SVCBBdG9tOwoKUFJPQ0VEVVJFIFJlZ2lzdGVyU3R1YnMoKTsKClBST0NFRFVSRSBU >b1NjaGVtZV9BdG9tTGlzdF9UKFJFQURPTkxZIHggOiBBdG9tTGlzdC5UKSA6IFNjaGVtZU9iamVj >dC5UIFJBSVNFUyB7IH07CgpQUk9DRURVUkUgVG9TY2hlbWVfRlNfSXRlcmF0b3IoUkVBRE9OTFkg >eCA6IEZTLkl0ZXJhdG9yKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IH07CgpQUk9DRURVUkUg >VG9TY2hlbWVfRmlsZV9UKFJFQURPTkxZIHggOiBGaWxlLlQpIDogU2NoZW1lT2JqZWN0LlQgUkFJ >U0VTIHsgfTsKClBST0NFRFVSRSBUb1NjaGVtZV9GaWxlX1N0YXR1cyhSRUFET05MWSB4IDogRmls >ZS5TdGF0dXMpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUgfTsKClBST0NFRFVS >RSBUb01vZHVsYV9GU19DcmVhdGVPcHRpb24oeCA6IFNjaGVtZU9iamVjdC5UKSA6IChGUy5DcmVh >dGVPcHRpb24pIFJBSVNFUyB7IFNjaGVtZS5FIH07CgpQUk9DRURVUkUgVG9Nb2R1bGFfRlNfQWNj >ZXNzT3B0aW9uKHggOiBTY2hlbWVPYmplY3QuVCkgOiAoRlMuQWNjZXNzT3B0aW9uKSBSQUlTRVMg >eyBTY2hlbWUuRSB9OwoKUFJPQ0VEVVJFIFRvTW9kdWxhX0ZpbGVfVCh4IDogU2NoZW1lT2JqZWN0 >LlQpIDogKEZpbGUuVCkgUkFJU0VTIHsgU2NoZW1lLkUgfTsKClBST0NFRFVSRSBUb1NjaGVtZV9W >QUwwTE9OR0lOVF9fVkFMMTA3Mzc0NTExMkxPTkdJTlQoUkVBRE9OTFkgeCA6IFsgVkFMKDAsIExP >TkdJTlQgKS4uVkFMKC0xMDczNzQ1MTEyLCBMT05HSU5UICkgXSkgOiBTY2hlbWVPYmplY3QuVCBS >QUlTRVMgeyBTY2hlbWUuRSB9OwoKUFJPQ0VEVVJFIFRvU2NoZW1lX0F0b21fVChSRUFET05MWSB4 >IDogQXRvbS5UKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IH07CgpQUk9DRURVUkUgVG9TY2hl >bWVfTE9OR0lOVChSRUFET05MWSB4IDogIExPTkdJTlQgKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNF >UyB7IFNjaGVtZS5FIH07CkNPTlNUIEJyYW5kID0gIkZTU2NoZW1lU3R1YnMiOwoKRU5EIEZTU2No >ZW1lU3R1YnMuCg== > >--_2d6969dc-a0fa-42e3-85e1-71600a2e9b7d_ >Content-Type: application/octet-stream >Content-Transfer-Encoding: base64 >Content-Disposition: attachment; filename="FSSchemeStubs.m3" > >TU9EVUxFIEZTU2NoZW1lU3R1YnM7CigqIEFVVE9NQVRJQ0FMTFkgR0VORVJBVEVEIERPIE5PVCBF >RElUICopCklNUE9SVCBTY2hlbWU7CklNUE9SVCBTY2hlbWVPYmplY3Q7CklNUE9SVCBTY2hlbWVQ >YWlyOwpJTVBPUlQgU2NoZW1lTW9kdWxhM1R5cGVzOwpJTVBPUlQgT1NFcnJvcjsKSU1QT1JUIEZp >bGU7CklNUE9SVCBTY2hlbWVQcm9jZWR1cmVTdHViczsKSU1QT1JUIEZTOwpJTVBPUlQgU2NoZW1l >U3ltYm9sOwpJTVBPUlQgU2NoZW1lVXRpbHM7CklNUE9SVCBTY2hlbWVBcHBseTsKSU1QT1JUIFJU >MDsKSU1QT1JUIEF0b21MaXN0OwpJTVBPUlQgU2NoZW1lQm9vbGVhbjsKSU1QT1JUIEF0b207CgpQ >Uk9DRURVUkUgQ2FsbFN0dWJfRlNfR2V0QWJzb2x1dGVQYXRobmFtZShpbnRlcnAgOiBTY2hlbWUu >VDsKICAgICAgICAgICAgICAgICAgICAgIGFyZ3MgOiBTY2hlbWVPYmplY3QuVDsKICAgICAgICAg >ICAgICAgICAgICAgIGV4Y0hhbmRsZXIgOiBTY2hlbWVPYmplY3QuVCkgOiBTY2hlbWVPYmplY3Qu >VAogIFJBSVNFUyB7IFNjaGVtZS5FIH0gPSAKIAogIFBST0NFRFVSRSBOZXh0KCkgOiBTY2hlbWVP >YmplY3QuVCBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAgICBCRUdJTgogICAgICBUUlkgUkVUVVJO >IFNjaGVtZVV0aWxzLkZpcnN0KHBfXykgRklOQUxMWSBwX18gOj0gU2NoZW1lUGFpci5QYWlyKFNj >aGVtZVV0aWxzLlJlc3QocF9fKSkgRU5ECiAgICBFTkQgTmV4dDsKIAogIFZBUiBwX18gOj0gU2No >ZW1lUGFpci5QYWlyKGFyZ3MpOwogIEJFR0lOCiAgICBUUlkKICAgICAgKCogdW5wYWNrIGZvcm1h >bHMgKikKICAgICAgVkFSIDwqTk9XQVJOKj5qdW5rX18gOj0gMDsKICAgICAgICAgICBmb3JtYWxf >cCA6PSBTY2hlbWVNb2R1bGEzVHlwZXMuVG9Nb2R1bGFfVEVYVChOZXh0KCkpOyBCRUdJTgogICAg >ICAgICgqIGNhcnJ5IG91dCBOSUwgY2hlY2tzIGZvciBvcGVuIGFycmF5cyAqKQoKICAgICAgICAo >KiBtYWtlIHByb2NlZHVyZSBjYWxsICopCiAgICAgICAgV0lUSCByZXMgPSBTY2hlbWVNb2R1bGEz >VHlwZXMuVG9TY2hlbWVfVEVYVChGUy5HZXRBYnNvbHV0ZVBhdGhuYW1lKGZvcm1hbF9wKSkgRE8K >ICAgICAgICAoKiB1bnBhY2sgVkFSIHBhcmFtcyAqKQogICAgICAgIHBfXyA6PSBTY2hlbWVQYWly >LlBhaXIoYXJncyk7CiAgICAgICAgRVZBTCBOZXh0KCk7CgogICAgICAgICgqIHJldHVybiBwcm9j >ZWR1cmUgcmVzdWx0ICopCiAgICAgICAgUkVUVVJOIHJlcwogICAgICAgIEVORAogICAgICBFTkQo >KldJVEgqKQogICAgRVhDRVBUCiAgICAgIHwgT1NFcnJvci5FKHhhcmcpID0+IEVWQUwgU2NoZW1l >QXBwbHkuT25lQXJnKGludGVycCxleGNIYW5kbGVyLFNjaGVtZVV0aWxzLkxpc3QyKFNjaGVtZVN5 >bWJvbC5Gcm9tVGV4dCgicXVvdGUiKSxTY2hlbWVVdGlscy5Db25zKFNjaGVtZVN5bWJvbC5Gcm9t >VGV4dCgiT1NFcnJvci5FIiksIFRvU2NoZW1lX0F0b21MaXN0X1QoeGFyZykpKSkKICAgIEVORDsK >ICAgIDwqTk9XQVJOKj5SRVRVUk4gU2NoZW1lQm9vbGVhbi5GYWxzZSgpCiAgRU5EIENhbGxTdHVi >X0ZTX0dldEFic29sdXRlUGF0aG5hbWU7CgpQUk9DRURVUkUgQ2FsbFN0dWJfRlNfT3BlbkZpbGUo >aW50ZXJwIDogU2NoZW1lLlQ7CiAgICAgICAgICAgICAgICAgICAgICBhcmdzIDogU2NoZW1lT2Jq >ZWN0LlQ7CiAgICAgICAgICAgICAgICAgICAgICBleGNIYW5kbGVyIDogU2NoZW1lT2JqZWN0LlQp >IDogU2NoZW1lT2JqZWN0LlQKICBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAKICBQUk9DRURVUkUg >TmV4dCgpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUgfSA9IAogICAgQkVHSU4K >ICAgICAgVFJZIFJFVFVSTiBTY2hlbWVVdGlscy5GaXJzdChwX18pIEZJTkFMTFkgcF9fIDo9IFNj >aGVtZVBhaXIuUGFpcihTY2hlbWVVdGlscy5SZXN0KHBfXykpIEVORAogICAgRU5EIE5leHQ7CiAK >ICBWQVIgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICBCRUdJTgogICAgVFJZCiAgICAg >ICgqIHVucGFjayBmb3JtYWxzICopCiAgICAgIFZBUiA8Kk5PV0FSTio+anVua19fIDo9IDA7CiAg >ICAgICAgICAgZm9ybWFsX3AgOj0gU2NoZW1lTW9kdWxhM1R5cGVzLlRvTW9kdWxhX1RFWFQoTmV4 >dCgpKTsKICAgICAgICAgICBmb3JtYWxfdHJ1bmNhdGUgOj0gU2NoZW1lTW9kdWxhM1R5cGVzLlRv >TW9kdWxhX0JPT0xFQU4oTmV4dCgpKTsKICAgICAgICAgICBmb3JtYWxfY3JlYXRlIDo9IFRvTW9k >dWxhX0ZTX0NyZWF0ZU9wdGlvbihOZXh0KCkpOwogICAgICAgICAgIGZvcm1hbF90ZW1wbGF0ZSA6 >PSBUb01vZHVsYV9GaWxlX1QoTmV4dCgpKTsKICAgICAgICAgICBmb3JtYWxfYWNjZXNzIDo9IFRv >TW9kdWxhX0ZTX0FjY2Vzc09wdGlvbihOZXh0KCkpOyBCRUdJTgogICAgICAgICgqIGNhcnJ5IG91 >dCBOSUwgY2hlY2tzIGZvciBvcGVuIGFycmF5cyAqKQoKICAgICAgICAoKiBtYWtlIHByb2NlZHVy >ZSBjYWxsICopCiAgICAgICAgV0lUSCByZXMgPSBUb1NjaGVtZV9GaWxlX1QoRlMuT3BlbkZpbGUo >Zm9ybWFsX3AsIGZvcm1hbF90cnVuY2F0ZSwgZm9ybWFsX2NyZWF0ZSwgZm9ybWFsX3RlbXBsYXRl >LCBmb3JtYWxfYWNjZXNzKSkgRE8KICAgICAgICAoKiB1bnBhY2sgVkFSIHBhcmFtcyAqKQogICAg >ICAgIHBfXyA6PSBTY2hlbWVQYWlyLlBhaXIoYXJncyk7CiAgICAgICAgRVZBTCBOZXh0KCk7CiAg >ICAgICAgRVZBTCBOZXh0KCk7CiAgICAgICAgRVZBTCBOZXh0KCk7CiAgICAgICAgRVZBTCBOZXh0 >KCk7CiAgICAgICAgRVZBTCBOZXh0KCk7CgogICAgICAgICgqIHJldHVybiBwcm9jZWR1cmUgcmVz >dWx0ICopCiAgICAgICAgUkVUVVJOIHJlcwogICAgICAgIEVORAogICAgICBFTkQoKldJVEgqKQog >ICAgRVhDRVBUCiAgICAgIHwgT1NFcnJvci5FKHhhcmcpID0+IEVWQUwgU2NoZW1lQXBwbHkuT25l >QXJnKGludGVycCxleGNIYW5kbGVyLFNjaGVtZVV0aWxzLkxpc3QyKFNjaGVtZVN5bWJvbC5Gcm9t >VGV4dCgicXVvdGUiKSxTY2hlbWVVdGlscy5Db25zKFNjaGVtZVN5bWJvbC5Gcm9tVGV4dCgiT1NF >cnJvci5FIiksIFRvU2NoZW1lX0F0b21MaXN0X1QoeGFyZykpKSkKICAgIEVORDsKICAgIDwqTk9X >QVJOKj5SRVRVUk4gU2NoZW1lQm9vbGVhbi5GYWxzZSgpCiAgRU5EIENhbGxTdHViX0ZTX09wZW5G >aWxlOwoKUFJPQ0VEVVJFIENhbGxTdHViX0ZTX09wZW5GaWxlUmVhZG9ubHkoaW50ZXJwIDogU2No >ZW1lLlQ7CiAgICAgICAgICAgICAgICAgICAgICBhcmdzIDogU2NoZW1lT2JqZWN0LlQ7CiAgICAg >ICAgICAgICAgICAgICAgICBleGNIYW5kbGVyIDogU2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2Jq >ZWN0LlQKICBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAKICBQUk9DRURVUkUgTmV4dCgpIDogU2No >ZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUgfSA9IAogICAgQkVHSU4KICAgICAgVFJZIFJF >VFVSTiBTY2hlbWVVdGlscy5GaXJzdChwX18pIEZJTkFMTFkgcF9fIDo9IFNjaGVtZVBhaXIuUGFp >cihTY2hlbWVVdGlscy5SZXN0KHBfXykpIEVORAogICAgRU5EIE5leHQ7CiAKICBWQVIgcF9fIDo9 >IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICBCRUdJTgogICAgVFJZCiAgICAgICgqIHVucGFjayBm >b3JtYWxzICopCiAgICAgIFZBUiA8Kk5PV0FSTio+anVua19fIDo9IDA7CiAgICAgICAgICAgZm9y >bWFsX3AgOj0gU2NoZW1lTW9kdWxhM1R5cGVzLlRvTW9kdWxhX1RFWFQoTmV4dCgpKTsgQkVHSU4K >ICAgICAgICAoKiBjYXJyeSBvdXQgTklMIGNoZWNrcyBmb3Igb3BlbiBhcnJheXMgKikKCiAgICAg >ICAgKCogbWFrZSBwcm9jZWR1cmUgY2FsbCAqKQogICAgICAgIFdJVEggcmVzID0gVG9TY2hlbWVf >RmlsZV9UKEZTLk9wZW5GaWxlUmVhZG9ubHkoZm9ybWFsX3ApKSBETwogICAgICAgICgqIHVucGFj >ayBWQVIgcGFyYW1zICopCiAgICAgICAgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICAg >ICAgICBFVkFMIE5leHQoKTsKCiAgICAgICAgKCogcmV0dXJuIHByb2NlZHVyZSByZXN1bHQgKikK >ICAgICAgICBSRVRVUk4gcmVzCiAgICAgICAgRU5ECiAgICAgIEVORCgqV0lUSCopCiAgICBFWENF >UFQKICAgICAgfCBPU0Vycm9yLkUoeGFyZykgPT4gRVZBTCBTY2hlbWVBcHBseS5PbmVBcmcoaW50 >ZXJwLGV4Y0hhbmRsZXIsU2NoZW1lVXRpbHMuTGlzdDIoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJx >dW90ZSIpLFNjaGVtZVV0aWxzLkNvbnMoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJPU0Vycm9yLkUi >KSwgVG9TY2hlbWVfQXRvbUxpc3RfVCh4YXJnKSkpKQogICAgRU5EOwogICAgPCpOT1dBUk4qPlJF >VFVSTiBTY2hlbWVCb29sZWFuLkZhbHNlKCkKICBFTkQgQ2FsbFN0dWJfRlNfT3BlbkZpbGVSZWFk >b25seTsKClBST0NFRFVSRSBDYWxsU3R1Yl9GU19DcmVhdGVEaXJlY3RvcnkoaW50ZXJwIDogU2No >ZW1lLlQ7CiAgICAgICAgICAgICAgICAgICAgICBhcmdzIDogU2NoZW1lT2JqZWN0LlQ7CiAgICAg >ICAgICAgICAgICAgICAgICBleGNIYW5kbGVyIDogU2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2Jq >ZWN0LlQKICBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAKICBQUk9DRURVUkUgTmV4dCgpIDogU2No >ZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUgfSA9IAogICAgQkVHSU4KICAgICAgVFJZIFJF >VFVSTiBTY2hlbWVVdGlscy5GaXJzdChwX18pIEZJTkFMTFkgcF9fIDo9IFNjaGVtZVBhaXIuUGFp >cihTY2hlbWVVdGlscy5SZXN0KHBfXykpIEVORAogICAgRU5EIE5leHQ7CiAKICBWQVIgcF9fIDo9 >IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICBCRUdJTgogICAgVFJZCiAgICAgICgqIHVucGFjayBm >b3JtYWxzICopCiAgICAgIFZBUiA8Kk5PV0FSTio+anVua19fIDo9IDA7CiAgICAgICAgICAgZm9y >bWFsX3AgOj0gU2NoZW1lTW9kdWxhM1R5cGVzLlRvTW9kdWxhX1RFWFQoTmV4dCgpKTsgQkVHSU4K >ICAgICAgICAoKiBjYXJyeSBvdXQgTklMIGNoZWNrcyBmb3Igb3BlbiBhcnJheXMgKikKCiAgICAg >ICAgKCogbWFrZSBwcm9jZWR1cmUgY2FsbCAqKQogICAgICAgIEZTLkNyZWF0ZURpcmVjdG9yeShm >b3JtYWxfcCk7CiAgICAgICAgKCogdW5wYWNrIFZBUiBwYXJhbXMgKikKICAgICAgICBwX18gOj0g >U2NoZW1lUGFpci5QYWlyKGFyZ3MpOwogICAgICAgIEVWQUwgTmV4dCgpOwoKICAgICAgICAoKiBw >cm9wZXIgcHJvY2VkdXJlIDogcmV0dXJuIFRSVUUgKikKICAgICAgICBSRVRVUk4gU2NoZW1lQm9v >bGVhbi5UcnVlKCkKICAgICAgRU5EKCpXSVRIKikKICAgIEVYQ0VQVAogICAgICB8IE9TRXJyb3Iu >RSh4YXJnKSA9PiBFVkFMIFNjaGVtZUFwcGx5Lk9uZUFyZyhpbnRlcnAsZXhjSGFuZGxlcixTY2hl >bWVVdGlscy5MaXN0MihTY2hlbWVTeW1ib2wuRnJvbVRleHQoInF1b3RlIiksU2NoZW1lVXRpbHMu >Q29ucyhTY2hlbWVTeW1ib2wuRnJvbVRleHQoIk9TRXJyb3IuRSIpLCBUb1NjaGVtZV9BdG9tTGlz >dF9UKHhhcmcpKSkpCiAgICBFTkQ7CiAgICA8Kk5PV0FSTio+UkVUVVJOIFNjaGVtZUJvb2xlYW4u >RmFsc2UoKQogIEVORCBDYWxsU3R1Yl9GU19DcmVhdGVEaXJlY3Rvcnk7CgpQUk9DRURVUkUgQ2Fs >bFN0dWJfRlNfRGVsZXRlRGlyZWN0b3J5KGludGVycCA6IFNjaGVtZS5UOwogICAgICAgICAgICAg >ICAgICAgICAgYXJncyA6IFNjaGVtZU9iamVjdC5UOwogICAgICAgICAgICAgICAgICAgICAgZXhj >SGFuZGxlciA6IFNjaGVtZU9iamVjdC5UKSA6IFNjaGVtZU9iamVjdC5UCiAgUkFJU0VTIHsgU2No >ZW1lLkUgfSA9IAogCiAgUFJPQ0VEVVJFIE5leHQoKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7 >IFNjaGVtZS5FIH0gPSAKICAgIEJFR0lOCiAgICAgIFRSWSBSRVRVUk4gU2NoZW1lVXRpbHMuRmly >c3QocF9fKSBGSU5BTExZIHBfXyA6PSBTY2hlbWVQYWlyLlBhaXIoU2NoZW1lVXRpbHMuUmVzdChw >X18pKSBFTkQKICAgIEVORCBOZXh0OwogCiAgVkFSIHBfXyA6PSBTY2hlbWVQYWlyLlBhaXIoYXJn >cyk7CiAgQkVHSU4KICAgIFRSWQogICAgICAoKiB1bnBhY2sgZm9ybWFscyAqKQogICAgICBWQVIg >PCpOT1dBUk4qPmp1bmtfXyA6PSAwOwogICAgICAgICAgIGZvcm1hbF9wIDo9IFNjaGVtZU1vZHVs >YTNUeXBlcy5Ub01vZHVsYV9URVhUKE5leHQoKSk7IEJFR0lOCiAgICAgICAgKCogY2Fycnkgb3V0 >IE5JTCBjaGVja3MgZm9yIG9wZW4gYXJyYXlzICopCgogICAgICAgICgqIG1ha2UgcHJvY2VkdXJl >IGNhbGwgKikKICAgICAgICBGUy5EZWxldGVEaXJlY3RvcnkoZm9ybWFsX3ApOwogICAgICAgICgq >IHVucGFjayBWQVIgcGFyYW1zICopCiAgICAgICAgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdz >KTsKICAgICAgICBFVkFMIE5leHQoKTsKCiAgICAgICAgKCogcHJvcGVyIHByb2NlZHVyZSA6IHJl >dHVybiBUUlVFICopCiAgICAgICAgUkVUVVJOIFNjaGVtZUJvb2xlYW4uVHJ1ZSgpCiAgICAgIEVO >RCgqV0lUSCopCiAgICBFWENFUFQKICAgICAgfCBPU0Vycm9yLkUoeGFyZykgPT4gRVZBTCBTY2hl >bWVBcHBseS5PbmVBcmcoaW50ZXJwLGV4Y0hhbmRsZXIsU2NoZW1lVXRpbHMuTGlzdDIoU2NoZW1l >U3ltYm9sLkZyb21UZXh0KCJxdW90ZSIpLFNjaGVtZVV0aWxzLkNvbnMoU2NoZW1lU3ltYm9sLkZy >b21UZXh0KCJPU0Vycm9yLkUiKSwgVG9TY2hlbWVfQXRvbUxpc3RfVCh4YXJnKSkpKQogICAgRU5E >OwogICAgPCpOT1dBUk4qPlJFVFVSTiBTY2hlbWVCb29sZWFuLkZhbHNlKCkKICBFTkQgQ2FsbFN0 >dWJfRlNfRGVsZXRlRGlyZWN0b3J5OwoKUFJPQ0VEVVJFIENhbGxTdHViX0ZTX0RlbGV0ZUZpbGUo >aW50ZXJwIDogU2NoZW1lLlQ7CiAgICAgICAgICAgICAgICAgICAgICBhcmdzIDogU2NoZW1lT2Jq >ZWN0LlQ7CiAgICAgICAgICAgICAgICAgICAgICBleGNIYW5kbGVyIDogU2NoZW1lT2JqZWN0LlQp >IDogU2NoZW1lT2JqZWN0LlQKICBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAKICBQUk9DRURVUkUg >TmV4dCgpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUgfSA9IAogICAgQkVHSU4K >ICAgICAgVFJZIFJFVFVSTiBTY2hlbWVVdGlscy5GaXJzdChwX18pIEZJTkFMTFkgcF9fIDo9IFNj >aGVtZVBhaXIuUGFpcihTY2hlbWVVdGlscy5SZXN0KHBfXykpIEVORAogICAgRU5EIE5leHQ7CiAK >ICBWQVIgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICBCRUdJTgogICAgVFJZCiAgICAg >ICgqIHVucGFjayBmb3JtYWxzICopCiAgICAgIFZBUiA8Kk5PV0FSTio+anVua19fIDo9IDA7CiAg >ICAgICAgICAgZm9ybWFsX3AgOj0gU2NoZW1lTW9kdWxhM1R5cGVzLlRvTW9kdWxhX1RFWFQoTmV4 >dCgpKTsgQkVHSU4KICAgICAgICAoKiBjYXJyeSBvdXQgTklMIGNoZWNrcyBmb3Igb3BlbiBhcnJh >eXMgKikKCiAgICAgICAgKCogbWFrZSBwcm9jZWR1cmUgY2FsbCAqKQogICAgICAgIEZTLkRlbGV0 >ZUZpbGUoZm9ybWFsX3ApOwogICAgICAgICgqIHVucGFjayBWQVIgcGFyYW1zICopCiAgICAgICAg >cF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICAgICAgICBFVkFMIE5leHQoKTsKCiAgICAg >ICAgKCogcHJvcGVyIHByb2NlZHVyZSA6IHJldHVybiBUUlVFICopCiAgICAgICAgUkVUVVJOIFNj >aGVtZUJvb2xlYW4uVHJ1ZSgpCiAgICAgIEVORCgqV0lUSCopCiAgICBFWENFUFQKICAgICAgfCBP >U0Vycm9yLkUoeGFyZykgPT4gRVZBTCBTY2hlbWVBcHBseS5PbmVBcmcoaW50ZXJwLGV4Y0hhbmRs >ZXIsU2NoZW1lVXRpbHMuTGlzdDIoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJxdW90ZSIpLFNjaGVt >ZVV0aWxzLkNvbnMoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJPU0Vycm9yLkUiKSwgVG9TY2hlbWVf >QXRvbUxpc3RfVCh4YXJnKSkpKQogICAgRU5EOwogICAgPCpOT1dBUk4qPlJFVFVSTiBTY2hlbWVC >b29sZWFuLkZhbHNlKCkKICBFTkQgQ2FsbFN0dWJfRlNfRGVsZXRlRmlsZTsKClBST0NFRFVSRSBD >YWxsU3R1Yl9GU19SZW5hbWUoaW50ZXJwIDogU2NoZW1lLlQ7CiAgICAgICAgICAgICAgICAgICAg >ICBhcmdzIDogU2NoZW1lT2JqZWN0LlQ7CiAgICAgICAgICAgICAgICAgICAgICBleGNIYW5kbGVy >IDogU2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQKICBSQUlTRVMgeyBTY2hlbWUuRSB9 >ID0gCiAKICBQUk9DRURVUkUgTmV4dCgpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1l >LkUgfSA9IAogICAgQkVHSU4KICAgICAgVFJZIFJFVFVSTiBTY2hlbWVVdGlscy5GaXJzdChwX18p >IEZJTkFMTFkgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihTY2hlbWVVdGlscy5SZXN0KHBfXykpIEVO >RAogICAgRU5EIE5leHQ7CiAKICBWQVIgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICBC >RUdJTgogICAgVFJZCiAgICAgICgqIHVucGFjayBmb3JtYWxzICopCiAgICAgIFZBUiA8Kk5PV0FS >Tio+anVua19fIDo9IDA7CiAgICAgICAgICAgZm9ybWFsX3AwIDo9IFNjaGVtZU1vZHVsYTNUeXBl >cy5Ub01vZHVsYV9URVhUKE5leHQoKSk7CiAgICAgICAgICAgZm9ybWFsX3AxIDo9IFNjaGVtZU1v >ZHVsYTNUeXBlcy5Ub01vZHVsYV9URVhUKE5leHQoKSk7IEJFR0lOCiAgICAgICAgKCogY2Fycnkg >b3V0IE5JTCBjaGVja3MgZm9yIG9wZW4gYXJyYXlzICopCgogICAgICAgICgqIG1ha2UgcHJvY2Vk >dXJlIGNhbGwgKikKICAgICAgICBGUy5SZW5hbWUoZm9ybWFsX3AwLCBmb3JtYWxfcDEpOwogICAg >ICAgICgqIHVucGFjayBWQVIgcGFyYW1zICopCiAgICAgICAgcF9fIDo9IFNjaGVtZVBhaXIuUGFp >cihhcmdzKTsKICAgICAgICBFVkFMIE5leHQoKTsKICAgICAgICBFVkFMIE5leHQoKTsKCiAgICAg >ICAgKCogcHJvcGVyIHByb2NlZHVyZSA6IHJldHVybiBUUlVFICopCiAgICAgICAgUkVUVVJOIFNj >aGVtZUJvb2xlYW4uVHJ1ZSgpCiAgICAgIEVORCgqV0lUSCopCiAgICBFWENFUFQKICAgICAgfCBP >U0Vycm9yLkUoeGFyZykgPT4gRVZBTCBTY2hlbWVBcHBseS5PbmVBcmcoaW50ZXJwLGV4Y0hhbmRs >ZXIsU2NoZW1lVXRpbHMuTGlzdDIoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJxdW90ZSIpLFNjaGVt >ZVV0aWxzLkNvbnMoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJPU0Vycm9yLkUiKSwgVG9TY2hlbWVf >QXRvbUxpc3RfVCh4YXJnKSkpKQogICAgRU5EOwogICAgPCpOT1dBUk4qPlJFVFVSTiBTY2hlbWVC >b29sZWFuLkZhbHNlKCkKICBFTkQgQ2FsbFN0dWJfRlNfUmVuYW1lOwoKUFJPQ0VEVVJFIENhbGxT >dHViX0ZTX0l0ZXJhdGUoaW50ZXJwIDogU2NoZW1lLlQ7CiAgICAgICAgICAgICAgICAgICAgICBh >cmdzIDogU2NoZW1lT2JqZWN0LlQ7CiAgICAgICAgICAgICAgICAgICAgICBleGNIYW5kbGVyIDog >U2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQKICBSQUlTRVMgeyBTY2hlbWUuRSB9ID0g >CiAKICBQUk9DRURVUkUgTmV4dCgpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUg >fSA9IAogICAgQkVHSU4KICAgICAgVFJZIFJFVFVSTiBTY2hlbWVVdGlscy5GaXJzdChwX18pIEZJ >TkFMTFkgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihTY2hlbWVVdGlscy5SZXN0KHBfXykpIEVORAog >ICAgRU5EIE5leHQ7CiAKICBWQVIgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICBCRUdJ >TgogICAgVFJZCiAgICAgICgqIHVucGFjayBmb3JtYWxzICopCiAgICAgIFZBUiA8Kk5PV0FSTio+ >anVua19fIDo9IDA7CiAgICAgICAgICAgZm9ybWFsX3AgOj0gU2NoZW1lTW9kdWxhM1R5cGVzLlRv >TW9kdWxhX1RFWFQoTmV4dCgpKTsgQkVHSU4KICAgICAgICAoKiBjYXJyeSBvdXQgTklMIGNoZWNr >cyBmb3Igb3BlbiBhcnJheXMgKikKCiAgICAgICAgKCogbWFrZSBwcm9jZWR1cmUgY2FsbCAqKQog >ICAgICAgIFdJVEggcmVzID0gVG9TY2hlbWVfRlNfSXRlcmF0b3IoRlMuSXRlcmF0ZShmb3JtYWxf >cCkpIERPCiAgICAgICAgKCogdW5wYWNrIFZBUiBwYXJhbXMgKikKICAgICAgICBwX18gOj0gU2No >ZW1lUGFpci5QYWlyKGFyZ3MpOwogICAgICAgIEVWQUwgTmV4dCgpOwoKICAgICAgICAoKiByZXR1 >cm4gcHJvY2VkdXJlIHJlc3VsdCAqKQogICAgICAgIFJFVFVSTiByZXMKICAgICAgICBFTkQKICAg >ICAgRU5EKCpXSVRIKikKICAgIEVYQ0VQVAogICAgICB8IE9TRXJyb3IuRSh4YXJnKSA9PiBFVkFM >IFNjaGVtZUFwcGx5Lk9uZUFyZyhpbnRlcnAsZXhjSGFuZGxlcixTY2hlbWVVdGlscy5MaXN0MihT >Y2hlbWVTeW1ib2wuRnJvbVRleHQoInF1b3RlIiksU2NoZW1lVXRpbHMuQ29ucyhTY2hlbWVTeW1i >b2wuRnJvbVRleHQoIk9TRXJyb3IuRSIpLCBUb1NjaGVtZV9BdG9tTGlzdF9UKHhhcmcpKSkpCiAg >ICBFTkQ7CiAgICA8Kk5PV0FSTio+UkVUVVJOIFNjaGVtZUJvb2xlYW4uRmFsc2UoKQogIEVORCBD >YWxsU3R1Yl9GU19JdGVyYXRlOwoKUFJPQ0VEVVJFIENhbGxTdHViX0ZTX1N0YXR1cyhpbnRlcnAg >OiBTY2hlbWUuVDsKICAgICAgICAgICAgICAgICAgICAgIGFyZ3MgOiBTY2hlbWVPYmplY3QuVDsK >ICAgICAgICAgICAgICAgICAgICAgIGV4Y0hhbmRsZXIgOiBTY2hlbWVPYmplY3QuVCkgOiBTY2hl >bWVPYmplY3QuVAogIFJBSVNFUyB7IFNjaGVtZS5FIH0gPSAKIAogIFBST0NFRFVSRSBOZXh0KCkg >OiBTY2hlbWVPYmplY3QuVCBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAgICBCRUdJTgogICAgICBU >UlkgUkVUVVJOIFNjaGVtZVV0aWxzLkZpcnN0KHBfXykgRklOQUxMWSBwX18gOj0gU2NoZW1lUGFp >ci5QYWlyKFNjaGVtZVV0aWxzLlJlc3QocF9fKSkgRU5ECiAgICBFTkQgTmV4dDsKIAogIFZBUiBw >X18gOj0gU2NoZW1lUGFpci5QYWlyKGFyZ3MpOwogIEJFR0lOCiAgICBUUlkKICAgICAgKCogdW5w >YWNrIGZvcm1hbHMgKikKICAgICAgVkFSIDwqTk9XQVJOKj5qdW5rX18gOj0gMDsKICAgICAgICAg >ICBmb3JtYWxfcCA6PSBTY2hlbWVNb2R1bGEzVHlwZXMuVG9Nb2R1bGFfVEVYVChOZXh0KCkpOyBC >RUdJTgogICAgICAgICgqIGNhcnJ5IG91dCBOSUwgY2hlY2tzIGZvciBvcGVuIGFycmF5cyAqKQoK >ICAgICAgICAoKiBtYWtlIHByb2NlZHVyZSBjYWxsICopCiAgICAgICAgV0lUSCByZXMgPSBUb1Nj >aGVtZV9GaWxlX1N0YXR1cyhGUy5TdGF0dXMoZm9ybWFsX3ApKSBETwogICAgICAgICgqIHVucGFj >ayBWQVIgcGFyYW1zICopCiAgICAgICAgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICAg >ICAgICBFVkFMIE5leHQoKTsKCiAgICAgICAgKCogcmV0dXJuIHByb2NlZHVyZSByZXN1bHQgKikK >ICAgICAgICBSRVRVUk4gcmVzCiAgICAgICAgRU5ECiAgICAgIEVORCgqV0lUSCopCiAgICBFWENF >UFQKICAgICAgfCBPU0Vycm9yLkUoeGFyZykgPT4gRVZBTCBTY2hlbWVBcHBseS5PbmVBcmcoaW50 >ZXJwLGV4Y0hhbmRsZXIsU2NoZW1lVXRpbHMuTGlzdDIoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJx >dW90ZSIpLFNjaGVtZVV0aWxzLkNvbnMoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJPU0Vycm9yLkUi >KSwgVG9TY2hlbWVfQXRvbUxpc3RfVCh4YXJnKSkpKQogICAgRU5EOwogICAgPCpOT1dBUk4qPlJF >VFVSTiBTY2hlbWVCb29sZWFuLkZhbHNlKCkKICBFTkQgQ2FsbFN0dWJfRlNfU3RhdHVzOwoKUFJP >Q0VEVVJFIENhbGxTdHViX0ZTX1NldE1vZGlmaWNhdGlvblRpbWUoaW50ZXJwIDogU2NoZW1lLlQ7 >CiAgICAgICAgICAgICAgICAgICAgICBhcmdzIDogU2NoZW1lT2JqZWN0LlQ7CiAgICAgICAgICAg >ICAgICAgICAgICBleGNIYW5kbGVyIDogU2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQK >ICBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAKICBQUk9DRURVUkUgTmV4dCgpIDogU2NoZW1lT2Jq >ZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUgfSA9IAogICAgQkVHSU4KICAgICAgVFJZIFJFVFVSTiBT >Y2hlbWVVdGlscy5GaXJzdChwX18pIEZJTkFMTFkgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihTY2hl >bWVVdGlscy5SZXN0KHBfXykpIEVORAogICAgRU5EIE5leHQ7CiAKICBWQVIgcF9fIDo9IFNjaGVt >ZVBhaXIuUGFpcihhcmdzKTsKICBCRUdJTgogICAgVFJZCiAgICAgICgqIHVucGFjayBmb3JtYWxz >ICopCiAgICAgIFZBUiA8Kk5PV0FSTio+anVua19fIDo9IDA7CiAgICAgICAgICAgZm9ybWFsX3Ag >Oj0gU2NoZW1lTW9kdWxhM1R5cGVzLlRvTW9kdWxhX1RFWFQoTmV4dCgpKTsKICAgICAgICAgICBm >b3JtYWxfdCA6PSBTY2hlbWVNb2R1bGEzVHlwZXMuVG9Nb2R1bGFfTE9OR1JFQUwoTmV4dCgpKTsg >QkVHSU4KICAgICAgICAoKiBjYXJyeSBvdXQgTklMIGNoZWNrcyBmb3Igb3BlbiBhcnJheXMgKikK >CiAgICAgICAgKCogbWFrZSBwcm9jZWR1cmUgY2FsbCAqKQogICAgICAgIEZTLlNldE1vZGlmaWNh >dGlvblRpbWUoZm9ybWFsX3AsIGZvcm1hbF90KTsKICAgICAgICAoKiB1bnBhY2sgVkFSIHBhcmFt >cyAqKQogICAgICAgIHBfXyA6PSBTY2hlbWVQYWlyLlBhaXIoYXJncyk7CiAgICAgICAgRVZBTCBO >ZXh0KCk7CiAgICAgICAgRVZBTCBOZXh0KCk7CgogICAgICAgICgqIHByb3BlciBwcm9jZWR1cmUg >OiByZXR1cm4gVFJVRSAqKQogICAgICAgIFJFVFVSTiBTY2hlbWVCb29sZWFuLlRydWUoKQogICAg >ICBFTkQoKldJVEgqKQogICAgRVhDRVBUCiAgICAgIHwgT1NFcnJvci5FKHhhcmcpID0+IEVWQUwg >U2NoZW1lQXBwbHkuT25lQXJnKGludGVycCxleGNIYW5kbGVyLFNjaGVtZVV0aWxzLkxpc3QyKFNj >aGVtZVN5bWJvbC5Gcm9tVGV4dCgicXVvdGUiKSxTY2hlbWVVdGlscy5Db25zKFNjaGVtZVN5bWJv >bC5Gcm9tVGV4dCgiT1NFcnJvci5FIiksIFRvU2NoZW1lX0F0b21MaXN0X1QoeGFyZykpKSkKICAg >IEVORDsKICAgIDwqTk9XQVJOKj5SRVRVUk4gU2NoZW1lQm9vbGVhbi5GYWxzZSgpCiAgRU5EIENh >bGxTdHViX0ZTX1NldE1vZGlmaWNhdGlvblRpbWU7CgoKUFJPQ0VEVVJFIFJlZ2lzdGVyU3R1YnMo >KSA9IAogIEJFR0lOCiAgICBTY2hlbWVQcm9jZWR1cmVTdHVicy5SZWdpc3Rlck9wKFRZUEVDT0RF >KEZTLkl0ZXJhdG9yKSwiY2FsbC1tZXRob2QiLE1ldGhvZERpc3BhdGNoZXJfRlNfSXRlcmF0b3Ip >OwogICAgU2NoZW1lUHJvY2VkdXJlU3R1YnMuUmVnaXN0ZXJOZXcoTkVXKFNjaGVtZVByb2NlZHVy >ZVN0dWJzLlFpZCwgaW50ZiA6PSBBdG9tLkZyb21UZXh0KCJGUyIpLCBpdGVtIDo9IEF0b20uRnJv >bVRleHQoIkl0ZXJhdG9yIikpLCBOZXdfRlNfSXRlcmF0b3IpOwogICAgU2NoZW1lUHJvY2VkdXJl >U3R1YnMuUmVnaXN0ZXJPcChUWVBFQ09ERShGUy5JdGVyYXRvciksIm5ldyIsR2VuTmV3X0ZTX0l0 >ZXJhdG9yKTsKICAgIFNjaGVtZVByb2NlZHVyZVN0dWJzLlJlZ2lzdGVyT3AoVFlQRUNPREUoRlMu >SXRlcmF0b3IpLCJnZXQtZmllbGQiLEZpZWxkR2V0X0ZTX0l0ZXJhdG9yKTsKICAgIFNjaGVtZVBy >b2NlZHVyZVN0dWJzLlJlZ2lzdGVyT3AoVFlQRUNPREUoRlMuSXRlcmF0b3IpLCJzZXQtZmllbGQh >IixGaWVsZFNldF9GU19JdGVyYXRvcik7CiAgICBTY2hlbWVQcm9jZWR1cmVTdHVicy5SZWdpc3Rl >clRDKFRZUEVDT0RFKEZTLkl0ZXJhdG9yKSwiRlMuSXRlcmF0b3IiKTsKICAgIFNjaGVtZVByb2Nl >ZHVyZVN0dWJzLlJlZ2lzdGVyT3AoVFlQRUNPREUoRlMuUHVibGljSXRlcmF0b3IpLCJjYWxsLW1l >dGhvZCIsTWV0aG9kRGlzcGF0Y2hlcl9GU19QdWJsaWNJdGVyYXRvcik7CiAgICBTY2hlbWVQcm9j >ZWR1cmVTdHVicy5SZWdpc3Rlck5ldyhORVcoU2NoZW1lUHJvY2VkdXJlU3R1YnMuUWlkLCBpbnRm >IDo9IEF0b20uRnJvbVRleHQoIkZTIiksIGl0ZW0gOj0gQXRvbS5Gcm9tVGV4dCgiUHVibGljSXRl >cmF0b3IiKSksIE5ld19GU19QdWJsaWNJdGVyYXRvcik7CiAgICBTY2hlbWVQcm9jZWR1cmVTdHVi >cy5SZWdpc3Rlck9wKFRZUEVDT0RFKEZTLlB1YmxpY0l0ZXJhdG9yKSwibmV3IixHZW5OZXdfRlNf >UHVibGljSXRlcmF0b3IpOwogICAgU2NoZW1lUHJvY2VkdXJlU3R1YnMuUmVnaXN0ZXJPcChUWVBF >Q09ERShGUy5QdWJsaWNJdGVyYXRvciksImdldC1maWVsZCIsRmllbGRHZXRfRlNfUHVibGljSXRl >cmF0b3IpOwogICAgU2NoZW1lUHJvY2VkdXJlU3R1YnMuUmVnaXN0ZXJPcChUWVBFQ09ERShGUy5Q >dWJsaWNJdGVyYXRvciksInNldC1maWVsZCEiLEZpZWxkU2V0X0ZTX1B1YmxpY0l0ZXJhdG9yKTsK >ICAgIFNjaGVtZVByb2NlZHVyZVN0dWJzLlJlZ2lzdGVyVEMoVFlQRUNPREUoRlMuUHVibGljSXRl >cmF0b3IpLCJGUy5QdWJsaWNJdGVyYXRvciIpOwogICAgVkFSCiAgICAgIEFyZ19UQyA6PSBBUlJB >WSBbMC4uM10gT0YgWy0xLi5MQVNUKFJUMC5UeXBlY29kZSldIHsgLTEsIC0xLCBUWVBFQ09ERShG >Uy5JdGVyYXRvciksIFRZUEVDT0RFKEZTLlB1YmxpY0l0ZXJhdG9yKX07CiAgICBDT05TVAogICAg >ICBBcmdfTmFtZXMgPSBBUlJBWSBPRiBURVhUIHsgIkZTLkNyZWF0ZU9wdGlvbiIsICJGUy5BY2Nl >c3NPcHRpb24iLCAiRlMuSXRlcmF0b3IiLCAiRlMuUHVibGljSXRlcmF0b3IifTsKICAgICAgQXJn >X1BpY2tsZSA9IEFSUkFZIE9GIENIQVIgeyBWQUwoMzgsQ0hBUiksIFZBTCgzNyxDSEFSKSwgVkFM >KDUwLENIQVIpLCBWQUwoNzMsQ0hBUiksIFZBTCg3NixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >NzgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgxMTAsQ0hBUiksIFZBTCgx >MTcsQ0hBUiksIFZBTCgxMDgsQ0hBUiksIFZBTCgxMDgsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDEyOCxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDIy >MCxDSEFSKSwgVkFMKDE5NCxDSEFSKSwgVkFMKDU1LENIQVIpLCBWQUwoMjE3LENIQVIpLCBWQUwo >MTUsQ0hBUiksIFZBTCgyMDUsQ0hBUiksIFZBTCg4OCxDSEFSKSwgVkFMKDMwLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDIyOSxDSEFSKSwgVkFMKDYzLENIQVIpLCBWQUwoMzcsQ0hBUiksIFZBTCgxOTMs >Q0hBUiksIFZBTCgyMSxDSEFSKSwgVkFMKDU5LENIQVIpLCBWQUwoMjE3LENIQVIpLCBWQUwoMTgs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgyMjcsQ0hBUiksIFZBTCgyMTEs >Q0hBUiksIFZBTCgxNjEsQ0hBUiksIFZBTCg5OCxDSEFSKSwgVkFMKDQxLENIQVIpLCBWQUwoNDAs >Q0hBUiksIFZBTCgyNixDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwoMTEsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg4NSxDSEFSKSwgVkFMKDExNSxDSEFS >KSwgVkFMKDEwMSxDSEFSKSwgVkFMKDExNCxDSEFSKSwgVkFMKDY4LENIQVIpLCBWQUwoMTAxLENI >QVIpLCBWQUwoMTAyLENIQVIpLCBWQUwoMTA1LENIQVIpLCBWQUwoMTEwLENIQVIpLCBWQUwoMTAx >LENIQVIpLCBWQUwoMTAwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCg1LENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgx >MDgsQ0hBUiksIFZBTCgxMDUsQ0hBUiksIFZBTCg5NyxDSEFSKSwgVkFMKDExNSxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoODEsQ0hBUiksIFZBTCgxMDUsQ0hBUiks >IFZBTCgxMDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgxMDUsQ0hBUiksIFZBTCgxMTAsQ0hB >UiksIFZBTCgxMTYsQ0hBUiksIFZBTCgxMDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hB >UiksIFZBTCg1MyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgxNTYsQ0hBUiksIFZBTCgyMTIsQ0hB >UiksIFZBTCgxNyxDSEFSKSwgVkFMKDE2NCxDSEFSKSwgVkFMKDE3OCxDSEFSKSwgVkFMKDE5NixD >SEFSKSwgVkFMKDU4LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNzAsQ0hBUiksIFZBTCg4MyxDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDEwNSxDSEFSKSwgVkFMKDExNixDSEFSKSwgVkFMKDEwMSxDSEFS >KSwgVkFMKDEwOSxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg4OCxDSEFSKSwgVkFMKDU4LENIQVIpLCBW >QUwoNDQsQ0hBUiksIFZBTCgyMzAsQ0hBUiksIFZBTCgxODQsQ0hBUiksIFZBTCgxMzMsQ0hBUiks >IFZBTCg4NyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCgxMixDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDY3LENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwo >MTAxLENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMTYsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZB >TCg3OSxDSEFSKSwgVkFMKDExMixDSEFSKSwgVkFMKDExNixDSEFSKSwgVkFMKDEwNSxDSEFSKSwg >VkFMKDExMSxDSEFSKSwgVkFMKDExMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIp >LCBWQUwoNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDExMCxDSEFSKSwgVkFMKDk3LENIQVIpLCBWQUwoMTA5LENIQVIpLCBWQUwoMTAxLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >OSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTUsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDQ5LENIQVIpLCBWQUwoMTksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDIxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFM >KDcsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgxMTgs >Q0hBUiksIFZBTCgxMDUsQ0hBUiksIFZBTCgxMTUsQ0hBUiksIFZBTCgxMDUsQ0hBUiksIFZBTCgx >MTYsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZBTCgxMDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgxODcsQ0hBUiksIFZBTCgxNCxDSEFSKSwgVkFMKDQ2LENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgyMjcsQ0hBUiksIFZBTCgxOTIsQ0hBUiksIFZBTCgyNixDSEFSKSwgVkFM >KDE5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoOCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDk4LENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwoOTcs >Q0hBUiksIFZBTCgxMTAsQ0hBUiksIFZBTCgxMDAsQ0hBUiksIFZBTCgxMTUsQ0hBUiksIFZBTCg3 >OSxDSEFSKSwgVkFMKDc1LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg3LENIQVIpLCBWQUwoMSxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0 >LENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDEwMSxDSEFSKSwgVkFMKDEwOCxDSEFSKSwgVkFMKDExNixDSEFSKSwgVkFMKDExNSxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCg2LENIQVIpLCBW >QUwoNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDc4 >LENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoMTE4LENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwo >MTE0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCgxLENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg3OSxDSEFSKSwgVkFMKDEwNyxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDYsQ0hB >UiksIFZBTCg2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNjUsQ0hBUiksIFZBTCgxMDgsQ0hBUiksIFZBTCgxMTksQ0hBUiksIFZBTCg5NyxDSEFSKSwg >VkFMKDEyMSxDSEFSKSwgVkFMKDExNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFS >KSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDIsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MTMsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDE1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE5LENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDEyLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNjUsQ0hBUiksIFZB >TCg5OSxDSEFSKSwgVkFMKDk5LENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoMTE1LENIQVIpLCBW >QUwoMTE1LENIQVIpLCBWQUwoNzksQ0hBUiksIFZBTCgxMTIsQ0hBUiksIFZBTCgxMTYsQ0hBUiks >IFZBTCgxMDUsQ0hBUiksIFZBTCgxMTEsQ0hBUiksIFZBTCgxMTAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDEzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNDksQ0hBUiksIFZBTCgxNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOSxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBW >QUwoNjQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0 >OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzNCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBW >QUwoMzYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzksQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDQxLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDQ0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgyNDUsQ0hBUiksIFZBTCgyMjksQ0hBUiksIFZBTCgxMTQsQ0hBUiksIFZBTCg4 >MyxDSEFSKSwgVkFMKDIwMixDSEFSKSwgVkFMKDEzLENIQVIpLCBWQUwoMTY2LENIQVIpLCBWQUwo >MjYsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMjMs >Q0hBUiksIFZBTCgxMTQsQ0hBUiksIFZBTCg3OSxDSEFSKSwgVkFMKDE1OCxDSEFSKSwgVkFMKDE1 >OSxDSEFSKSwgVkFMKDE1NSxDSEFSKSwgVkFMKDE5NixDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwo >MTcsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg3OSxD >SEFSKSwgVkFMKDExMCxDSEFSKSwgVkFMKDEwOCxDSEFSKSwgVkFMKDEyMSxDSEFSKSwgVkFMKDc5 >LENIQVIpLCBWQUwoMTE5LENIQVIpLCBWQUwoMTEwLENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwo >MTE0LENIQVIpLCBWQUwoNjcsQ0hBUiksIFZBTCg5NyxDSEFSKSwgVkFMKDExMCxDSEFSKSwgVkFM >KDgyLENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDYsQ0hB >UiksIFZBTCg4LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoODIsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZBTCg5NyxDSEFSKSwgVkFMKDEwMCxDSEFSKSwg >VkFMKDc5LENIQVIpLCBWQUwoMTEwLENIQVIpLCBWQUwoMTA4LENIQVIpLCBWQUwoMTIxLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDcsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg2OCxDSEFSKSwgVkFMKDEw >MSxDSEFSKSwgVkFMKDEwMixDSEFSKSwgVkFMKDk3LENIQVIpLCBWQUwoMTE3LENIQVIpLCBWQUwo >MTA4LENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDc5LENIQVIpLCBWQUwoMTEyLENIQVIpLCBWQUwoOTcsQ0hBUiks >IFZBTCgxMTMsQ0hBUiksIFZBTCgxMTcsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTMs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDE1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE5LENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDgsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg3MyxDSEFSKSwgVkFMKDEx >NixDSEFSKSwgVkFMKDEwMSxDSEFSKSwgVkFMKDExNCxDSEFSKSwgVkFMKDk3LENIQVIpLCBWQUwo >MTE2LENIQVIpLCBWQUwoMTExLENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTMs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDE1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE5LENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzNCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzYsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDQxLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCg2LENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMTE2LENIQVIp >LCBWQUwoMTE0LENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCg5OSxDSEFSKSwgVkFMKDEwMSxDSEFS >KSwgVkFMKDEwMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzYsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDcsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg5OCxDSEFSKSwg >VkFMKDExNCxDSEFSKSwgVkFMKDk3LENIQVIpLCBWQUwoMTEwLENIQVIpLCBWQUwoMTAwLENIQVIp >LCBWQUwoMTAxLENIQVIpLCBWQUwoMTAwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzNixDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENI >QVIpLCBWQUwoNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDk4LENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMTAsQ0hBUiks >IFZBTCgxMDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNyxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDExNCxDSEFS >KSwgVkFMKDEwMSxDSEFSKSwgVkFMKDExOCxDSEFSKSwgVkFMKDczLENIQVIpLCBWQUwoMTEwLENI >QVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoMTAyLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoNCxDSEFSKSwgVkFMKDE3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoMTE4LENIQVIpLCBWQUwo >MTAxLENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMDgsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZB >TCgxMDAsQ0hBUiksIFZBTCg4MyxDSEFSKSwgVkFMKDExNyxDSEFSKSwgVkFMKDExMixDSEFSKSwg >VkFMKDEwMSxDSEFSKSwgVkFMKDExNCxDSEFSKSwgVkFMKDg0LENIQVIpLCBWQUwoMTIxLENIQVIp >LCBWQUwoMTEyLENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoNCxDSEFSKSwgVkFMKDYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCg3OSxDSEFSKSwgVkFMKDk4LENIQVIpLCBWQUwoMTA2LENIQVIpLCBWQUwoMTAx >LENIQVIpLCBWQUwoOTksQ0hBUiksIFZBTCgxMTYsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NDksQ0hBUiksIFZBTCg5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDEzLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgx >NSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDYsQ0hBUiksIFZBTCgxNCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDgwLENIQVIpLCBWQUwoMTE3LENIQVIp >LCBWQUwoOTgsQ0hBUiksIFZBTCgxMDgsQ0hBUiksIFZBTCgxMDUsQ0hBUiksIFZBTCg5OSxDSEFS >KSwgVkFMKDczLENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoMTE0LENI >QVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMTYsQ0hBUiksIFZBTCgxMTEsQ0hBUiksIFZBTCgxMTQs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzNixDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNDksQ0hBUiksIFZBTCgzOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoNDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBW >QUwoMTE1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >NDksQ0hBUiksIFZBTCgzNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMTksQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDEyMyxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDEyNyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCg1 >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMTE1LENI >QVIpLCBWQUwoMTE3LENIQVIpLCBWQUwoMTEyLENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoMTE0 >LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDYsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgxMDIsQ0hBUiksIFZBTCgx >MDUsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZBTCgxMDgsQ0hBUiksIFZBTCgxMDAsQ0hBUiksIFZB >TCgxMTUsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFM >KDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNyxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDEwOSxDSEFSKSwg >VkFMKDEwMSxDSEFSKSwgVkFMKDExNixDSEFSKSwgVkFMKDEwNCxDSEFSKSwgVkFMKDExMSxDSEFS >KSwgVkFMKDEwMCxDSEFSKSwgVkFMKDExNSxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwo >NixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDc3LENI >QVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoMTA0LENIQVIpLCBWQUwoMTEx >LENIQVIpLCBWQUwoMTAwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDI1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwo >NCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDExMCxD >SEFSKSwgVkFMKDEwMSxDSEFSKSwgVkFMKDEyMCxDSEFSKSwgVkFMKDExNixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiks >IFZBTCg0LENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDExNSxDSEFSKSwgVkFMKDEwNSxDSEFSKSwgVkFMKDEwMyxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCg5LENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoODMsQ0hBUiksIFZBTCgxMDUsQ0hBUiks >IFZBTCgxMDMsQ0hBUiksIFZBTCgxMTAsQ0hBUiksIFZBTCg5NyxDSEFSKSwgVkFMKDExNixDSEFS >KSwgVkFMKDExNyxDSEFSKSwgVkFMKDExNCxDSEFSKSwgVkFMKDEwMSxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCg0LENIQVIpLCBWQUwoNyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDEwMixDSEFSKSwgVkFMKDExMSxDSEFSKSwgVkFMKDExNCxDSEFSKSwgVkFMKDEw >OSxDSEFSKSwgVkFMKDk3LENIQVIpLCBWQUwoMTA4LENIQVIpLCBWQUwoMTE1LENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxD >SEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDQsQ0hBUiksIFZBTCg2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoNzAsQ0hBUiksIFZBTCgxMTEsQ0hBUiksIFZBTCgxMTQsQ0hBUiksIFZB >TCgxMDksQ0hBUiksIFZBTCg5NyxDSEFSKSwgVkFMKDEwOCxDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENI >QVIpLCBWQUwoNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDEwOSxDSEFSKSwgVkFMKDExMSxDSEFSKSwgVkFMKDEwMCxDSEFSKSwgVkFMKDEwMSxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwg >VkFMKDgsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg3 >NyxDSEFSKSwgVkFMKDExMSxDSEFSKSwgVkFMKDEwMCxDSEFSKSwgVkFMKDEwMSxDSEFSKSwgVkFM >KDQ2LENIQVIpLCBWQUwoODYsQ0hBUiksIFZBTCg5NyxDSEFSKSwgVkFMKDExNCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCg0LENIQVIpLCBWQUwoNyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDExMSxDSEFSKSwgVkFMKDExNyxDSEFSKSwgVkFMKDExNixDSEFSKSwg >VkFMKDc5LENIQVIpLCBWQUwoMTEwLENIQVIpLCBWQUwoMTA4LENIQVIpLCBWQUwoMTIxLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCgzNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoMjUsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoNCxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgxMTYsQ0hBUiksIFZBTCgxMjEsQ0hBUiksIFZBTCgxMTIsQ0hBUiks >IFZBTCgxMDEsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNDksQ0hBUiksIFZBTCg5MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDksQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDQ5LENIQVIpLCBWQUwoMTMsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE5LENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDg0LENIQVIpLCBWQUwoNjksQ0hBUiksIFZB >TCg4OCxDSEFSKSwgVkFMKDg0LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDM5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCg0MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMTUs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDExOSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzYsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTIzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDQ5LENIQVIpLCBWQUwoMTI3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENI >QVIpLCBWQUwoMTMxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDksQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg4MixDSEFSKSwgVkFMKDEwMSxD >SEFSKSwgVkFMKDEwMixDSEFSKSwgVkFMKDEwMSxDSEFSKSwgVkFMKDExNCxDSEFSKSwgVkFMKDEw >MSxDSEFSKSwgVkFMKDExMCxDSEFSKSwgVkFMKDk5LENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxD >SEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiks >IFZBTCgxMyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDQ5LENIQVIpLCBWQUwoMjE0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE5LENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDgyLENIQVIpLCBWQUwoNjksQ0hB >UiksIFZBTCg3MCxDSEFSKSwgVkFMKDY1LENIQVIpLCBWQUwoNzgsQ0hBUiksIFZBTCg4OSxDSEFS >KSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDM0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDks >Q0hBUiksIFZBTCgzNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzOSxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoNDEs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTE1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0MSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNDksQ0hBUiksIFZBTCgxMTksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDEyMyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDEyNyxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4LENIQVIp >LCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNyxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDEwMCxDSEFS >KSwgVkFMKDEwMSxDSEFSKSwgVkFMKDEwMixDSEFSKSwgVkFMKDk3LENIQVIpLCBWQUwoMTE3LENI >QVIpLCBWQUwoMTA4LENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxD >SEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCg2LENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwoMTAx >LENIQVIpLCBWQUwoMTE1LENIQVIpLCBWQUwoMTE3LENIQVIpLCBWQUwoMTA4LENIQVIpLCBWQUwo >MTE2LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxD >SEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDksQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMTMsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDIxNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgx >OSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDcsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg2NixDSEFSKSwgVkFM >KDc5LENIQVIpLCBWQUwoNzksQ0hBUiksIFZBTCg3NixDSEFSKSwgVkFMKDY5LENIQVIpLCBWQUwo >NjUsQ0hBUiksIFZBTCg3OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDM0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCgzOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDQ5LENIQVIpLCBWQUwoNDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoNDQsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDcwLENIQVIpLCBWQUwoNjUsQ0hBUiksIFZBTCg3NixDSEFS >KSwgVkFMKDgzLENIQVIpLCBWQUwoNjksQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCg0LENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDg0LENIQVIpLCBWQUwoODIsQ0hBUiksIFZBTCg4NSxDSEFSKSwgVkFMKDY5LENI >QVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwo >NixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDExNCxD >SEFSKSwgVkFMKDk3LENIQVIpLCBWQUwoMTA1LENIQVIpLCBWQUwoMTE1LENIQVIpLCBWQUwoMTAx >LENIQVIpLCBWQUwoMTE1LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxNzEsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCg2LENIQVIpLCBWQUwoMTQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgxMTAsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZBTCgxMjAsQ0hBUiksIFZB >TCgxMTYsQ0hBUiksIFZBTCg4NyxDSEFSKSwgVkFMKDEwNSxDSEFSKSwgVkFMKDExNixDSEFSKSwg >VkFMKDEwNCxDSEFSKSwgVkFMKDgzLENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoOTcsQ0hBUiks >IFZBTCgxMTYsQ0hBUiksIFZBTCgxMTcsQ0hBUiksIFZBTCgxMTUsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgx >NzksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxODIsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTg2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDE5MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOTQsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE5NixDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyMDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0 >OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgy >MDYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDIwOCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOTAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTk0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOTYsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMjAwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgy >NSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDYsQ0hBUiks >IFZBTCg0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MTE1LENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMTYsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjA2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFM >KDYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg4MixD >SEFSKSwgVkFMKDEwMSxDSEFSKSwgVkFMKDk5LENIQVIpLCBWQUwoMTExLENIQVIpLCBWQUwoMTE0 >LENIQVIpLCBWQUwoMTAwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDI1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >OSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDYsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNzAsQ0hBUiksIFZBTCgxMDUsQ0hBUiks >IFZBTCgxMDgsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MTksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCg2LENIQVIp >LCBWQUwoNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDgzLENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMTYsQ0hBUiksIFZB >TCgxMTcsQ0hBUiksIFZBTCgxMTUsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiks >IFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzQsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiks >IFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFM >KDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0MSxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NDksQ0hBUiksIFZBTCgxNjMsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDUsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg3MCxDSEFSKSwgVkFMKDEwNSxDSEFSKSwgVkFMKDEw >MSxDSEFSKSwgVkFMKDEwOCxDSEFSKSwgVkFMKDEwMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjA2LENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDIwNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDkxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxD >SEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiks >IFZBTCgxMyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDYs >Q0hBUiksIFZBTCg0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNjUsQ0hBUiksIFZBTCgxMTYsQ0hBUiksIFZBTCgxMTEsQ0hBUiksIFZBTCgxMDksQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCg2LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDg0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoMzQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM5LENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZB >TCg0MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMTUsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDExOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzYsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENI >QVIpLCBWQUwoMTIzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MTI3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTMxLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZB >TCgyMzQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0 >OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0LENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZB >TCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5NixD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCg5LENIQVIpLCBWQUwoMTcsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgxMDksQ0hBUiksIFZBTCgxMTEsQ0hBUiksIFZBTCgxMDAsQ0hBUiksIFZB >TCgxMDUsQ0hBUiksIFZBTCgxMDIsQ0hBUiksIFZBTCgxMDUsQ0hBUiksIFZBTCg5OSxDSEFSKSwg >VkFMKDk3LENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoMTA1LENIQVIpLCBWQUwoMTExLENIQVIp >LCBWQUwoMTEwLENIQVIpLCBWQUwoODQsQ0hBUiksIFZBTCgxMDUsQ0hBUiksIFZBTCgxMDksQ0hB >UiksIFZBTCgxMDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg0OSxDSEFSKSwgVkFMKDIwNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCg4LENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNzYsQ0hBUiksIFZB >TCgxMTEsQ0hBUiksIFZBTCgxMTAsQ0hBUiksIFZBTCgxMDMsQ0hBUiksIFZBTCg4MixDSEFSKSwg >VkFMKDEwMSxDSEFSKSwgVkFMKDk3LENIQVIpLCBWQUwoMTA4LENIQVIpLCBWQUwoNTMsQ0hBUiks >IFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFM >KDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDQ5LENIQVIpLCBWQUwoOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMyxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoMjE0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE5LENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoOCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDc2LENIQVIpLCBWQUwoNzksQ0hBUiksIFZBTCg3 >OCxDSEFSKSwgVkFMKDcxLENIQVIpLCBWQUwoODIsQ0hBUiksIFZBTCg2OSxDSEFSKSwgVkFMKDY1 >LENIQVIpLCBWQUwoNzYsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxD >SEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCgzNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoMzksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg0OSxDSEFSKSwgVkFMKDQxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoNCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENI >QVIpLCBWQUwoOTYsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hB >UiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMTE1LENIQVIpLCBWQUwoMTA1LENIQVIpLCBW >QUwoMTIyLENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0 >OSxDSEFSKSwgVkFMKDIwNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCg4LENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoODMsQ0hBUiksIFZBTCgx >MTcsQ0hBUiksIFZBTCg5OCxDSEFSKSwgVkFMKDExNCxDSEFSKSwgVkFMKDk3LENIQVIpLCBWQUwo >MTEwLENIQVIpLCBWQUwoMTAzLENIQVIpLCBWQUwoMTAxLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFM >KDQ5LENIQVIpLCBWQUwoMzQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDM5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDks >Q0hBUiksIFZBTCg0MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDk4LENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMTUsQ0hB >UiksIFZBTCgxMDEsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCgxNjYsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5LENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDEzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyMTQsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENI >QVIpLCBWQUwoMTksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZB >TCg3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNzYs >Q0hBUiksIFZBTCg3OSxDSEFSKSwgVkFMKDc4LENIQVIpLCBWQUwoNzEsQ0hBUiksIFZBTCg3MyxD >SEFSKSwgVkFMKDc4LENIQVIpLCBWQUwoODQsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzNCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzYsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDQ5LENIQVIpLCBWQUwoMzksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDQxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDE3NixDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDQ5LENIQVIpLCBWQUwoMTc4LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hBUiks >IFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMTA5LENIQVIpLCBWQUwoMTA1LENIQVIpLCBWQUwo >MTEwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDcsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg3NixDSEFSKSwg >VkFMKDExMSxDSEFSKSwgVkFMKDExMCxDSEFSKSwgVkFMKDEwMyxDSEFSKSwgVkFMKDEwNSxDSEFS >KSwgVkFMKDExMCxDSEFSKSwgVkFMKDExNixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgxNCxDSEFSKSwgVkFMKDQ2LENIQVIpLCBWQUwoMjQwLENIQVIp >LCBWQUwoNzcsQ0hBUiksIFZBTCgxNSxDSEFSKSwgVkFMKDE1MyxDSEFSKSwgVkFMKDc2LENIQVIp >LCBWQUwoMjMsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgyMjQsQ0hBUiksIFZBTCgx >OTUsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgxMDksQ0hBUiksIFZBTCg5NyxDSEFSKSwgVkFM >KDEyMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0 >OSxDSEFSKSwgVkFMKDE5OSxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDEwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMjI0LENIQVIpLCBWQUwoNjcsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOTYsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCg0LENIQVIpLCBWQUwoNyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDc5LENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwoMTAwLENIQVIpLCBWQUwoMTA1 >LENIQVIpLCBWQUwoMTEwLENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMDgsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgxMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDIwNCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDIxMSxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDEwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMTM0LENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgyMDgsQ0hBUiksIFZBTCgxOTMsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4 >LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoNCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNDksQ0hBUiksIFZBTCg4LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCgzNCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFS >KSwgVkFMKDksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg2OSxDSEFSKSwgVkFMKDEyMCxDSEFSKSwgVkFMKDk5LENIQVIpLCBWQUwoMTAxLENIQVIpLCBW >QUwoMTEyLENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoMTA1LENIQVIpLCBWQUwoMTExLENIQVIp >LCBWQUwoMTEwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMTEzLENIQVIpLCBWQUwoMTA1LENI >QVIpLCBWQUwoMTAwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDQ5LENIQVIpLCBWQUwoOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMyxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMyxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDYsQ0hBUiksIFZB >TCg3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNzks >Q0hBUiksIFZBTCg4MyxDSEFSKSwgVkFMKDY5LENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwoMTE0 >LENIQVIpLCBWQUwoMTExLENIQVIpLCBWQUwoMTE0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiks >IFZBTCgxLENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg2OSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMTQsQ0hB >UiksIFZBTCgxMDMsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCgxMzQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5LENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDEzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDgsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg2NSxDSEFSKSwgVkFMKDExNixDSEFSKSwgVkFMKDExMSxD >SEFSKSwgVkFMKDEwOSxDSEFSKSwgVkFMKDc2LENIQVIpLCBWQUwoMTA1LENIQVIpLCBWQUwoMTE1 >LENIQVIpLCBWQUwoMTE2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTks >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDExMixDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM0 >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCgzNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzOSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoNDEsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwg >VkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTE1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgzNixDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NDksQ0hBUiksIFZBTCgxMTksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDEyMyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4 >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDEyNyxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE1OSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE2MyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCg5NixDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDYsQ0hBUiksIFZBTCg0LENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMTA0LENIQVIpLCBWQUwo >MTAxLENIQVIpLCBWQUwoOTcsQ0hBUiksIFZBTCgxMDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENI >QVIpLCBWQUwoMjA2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCgxMDIsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoNCxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4LENIQVIp >LCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >OTYsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCg2LENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDExNixDSEFSKSwgVkFMKDk3LENIQVIp >LCBWQUwoMTA1LENIQVIpLCBWQUwoMTA4LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDIwNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMjQ4LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDQsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4 >LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoMTY3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMyxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDksQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgxMTEsQ0hBUiksIFZBTCgxMTgsQ0hBUiks >IFZBTCgxMDEsQ0hBUiksIFZBTCgxMTQsQ0hBUiksIFZBTCgxMTQsQ0hBUiksIFZBTCgxMDUsQ0hB >UiksIFZBTCgxMDAsQ0hBUiksIFZBTCgxMDEsQ0hBUiksIFZBTCgxMTUsQ0hBUiksIFZBTCg0OCxD >SEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENI >QVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBW >QUwoNCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ4 >LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoMTcxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgzLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoNixDSEFSKSwgVkFMKDUsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg5OSxDSEFSKSwgVkFMKDEw >OCxDSEFSKSwgVkFMKDExMSxDSEFSKSwgVkFMKDExNSxDSEFSKSwgVkFMKDEwMSxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDE3OSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDE4MixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxODYsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg4LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDQ5LENIQVIpLCBWQUwoMzQsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDgs >Q0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiks >IFZBTCg0OSxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoNDIsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBW >QUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTM0 >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDEz >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCgxNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTQzLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiks >IFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5LENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDEzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCgxNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOSxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoMTQzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzQs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM5LENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0MSxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMTUsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0 >OSxDSEFSKSwgVkFMKDExOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MTIzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTI3LENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTU5LENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTYzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDQ5LENIQVIpLCBWQUwoMTY3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE3 >MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTc1LENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiks >IFZBTCg0OSxDSEFSKSwgVkFMKDE3OSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0 >OSxDSEFSKSwgVkFMKDE4MixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxODYsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTkwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDE5NCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMTk2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDIwMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MzYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiks >IFZBTCg0OSxDSEFSKSwgVkFMKDIwNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjA4LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDQsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoOCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTAsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENI >QVIpLCBWQUwoMzQsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZB >TCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0 >OSxDSEFSKSwgVkFMKDE3MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >NDMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTc5LENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTgyLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDE4NixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOTAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFM >KDQ5LENIQVIpLCBWQUwoMTk0LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOTYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBW >QUwoMjAwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >NDksQ0hBUiksIFZBTCgzNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MjUsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjA2LENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyMDgsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDQ5LENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTkwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDE5NCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMTk2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDIwMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MzYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIp >LCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDcwLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiks >IFZBTCg0OSxDSEFSKSwgVkFMKDIwNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0 >OSxDSEFSKSwgVkFMKDc1LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoOSxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NDksQ0hBUiksIFZBTCgxMyxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoODIsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MTksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDg2LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwo >MzQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM5LENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0MSxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxNjMsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoOTYsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDIwNixDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyMDYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCg5MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDksQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDQ5LENIQVIpLCBWQUwoMTMsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDEwOCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCgxOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDQ5LENIQVIpLCBWQUwoMTEyLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENI >QVIpLCBWQUwoMzQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM5LENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiks >IFZBTCg0MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxMTUsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDExOSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzYsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMTIzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBW >QUwoMTI3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwo >NDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTMxLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiks >IFZBTCgyMzQsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0LENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiks >IFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5 >NixDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTM0LENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiks >IFZBTCg0OSxDSEFSKSwgVkFMKDIwNixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTM5LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDQsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwo >MixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxD >SEFSKSwgVkFMKDk2LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxNjEs >Q0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjA2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTY2LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDI1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzQsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM5LENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0MSxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxD >SEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCgxNzYsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE3OCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCgxOTYsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZB >TCgyMTEsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0 >OSxDSEFSKSwgVkFMKDIxMyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyMDQsQ0hBUiks >IFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyMTEsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgxMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDExMCxDSEFSKSwgVkFMKDMsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMjA4LENIQVIpLCBW >QUwoMTkzLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoNCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDQsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENI >QVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBW >QUwoOCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMTAsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiks >IFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzQsQ0hBUiksIFZB >TCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDIyOSxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyMzMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixD >SEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDEzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNDksQ0hBUiksIFZBTCgyMzgsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMs >Q0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTksQ0hB >UiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwg >VkFMKDI0MixDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDQ4LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDI0NixD >SEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDEzNCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg0OSxDSEFSKSwgVkFMKDksQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTMsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFM >KDI1NCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxOSxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTEyLENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENI >QVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzQsQ0hBUiksIFZBTCgwLENIQVIp >LCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDM5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0MSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCgxMTUsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg0OSxDSEFSKSwgVkFMKDM2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUz >LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDExOSxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoMzYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTIzLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFS >KSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBW >QUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMTI3LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEs >Q0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFS >KSwgVkFMKDQ5LENIQVIpLCBWQUwoMTU5LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZB >TCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5 >LENIQVIpLCBWQUwoMTYzLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIp >LCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDk2LENIQVIpLCBW >QUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgx >LENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hB >UiksIFZBTCg0OSxDSEFSKSwgVkFMKDI1LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyMixDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hB >UiksIFZBTCgyMDYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg0OSxDSEFSKSwgVkFMKDE3OSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1 >MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg0LENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgsQ0hBUiks >IFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZB >TCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCg5 >NixDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiks >IFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzIsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hB >UiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwg >VkFMKDQ5LENIQVIpLCBWQUwoMjA2LENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZB >TCgwLENIQVIpLCBWQUwoNDksQ0hBUiksIFZBTCgyNTMsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >MCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIp >LCBWQUwoNCxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFM >KDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENI >QVIpLCBWQUwoNDksQ0hBUiksIFZBTCgxNjcsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFS >KSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwg >VkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NDksQ0hBUiksIFZBTCg0MixDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxD >SEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENI >QVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBW >QUwoNDksQ0hBUiksIFZBTCg0LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgw >LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxD >SEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIp >LCBWQUwoNDksQ0hBUiksIFZBTCgxNzEsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwg >VkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwo >NTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMjUs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OSxDSEFS >KSwgVkFMKDUwLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBW >QUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwo >MSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE3OSxDSEFSKSwgVkFMKDAs >Q0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFS >KSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDE4MixDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFM >KDIsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDks >Q0hBUiksIFZBTCgxODYsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hB >UiksIFZBTCg0OCxDSEFSKSwgVkFMKDUzLENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiks >IFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDksQ0hBUiksIFZB >TCg4LENIQVIpLCBWQUwoMSxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCgwLENIQVIpLCBWQUwoNDgs >Q0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNTMsQ0hB >UiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENIQVIpLCBWQUwoMzQsQ0hBUiks >IFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFM >KDEsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFMKDQ4 >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDUzLENI >QVIpLCBWQUwoMSxDSEFSKSwgVkFMKDIsQ0hBUiksIFZBTCg0OSxDSEFSKSwgVkFMKDQsQ0hBUiks >IFZBTCgxLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiksIFZBTCg0OCxDSEFSKSwgVkFM >KDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MyxDSEFSKSwgVkFMKDEsQ0hBUiksIFZBTCgy >LENIQVIpLCBWQUwoNTMsQ0hBUiksIFZBTCgxLENIQVIpLCBWQUwoMixDSEFSKSwgVkFMKDQ5LENI >QVIpLCBWQUwoNDIsQ0hBUiksIFZBTCgyLENIQVIpLCBWQUwoMCxDSEFSKSwgVkFMKDAsQ0hBUiks >IFZBTCg0OCxDSEFSKSwgVkFMKDQ4LENIQVIpLCBWQUwoNDgsQ0hBUiksIFZBTCg1MixDSEFSKSwg >VkFMKDEwLENIQVIpIH07CiAgICBCRUdJTgogICAgICBTY2hlbWVQcm9jZWR1cmVTdHVicy5SZWdp >c3RlclR5cGVQaWNrbGUoQXJnX1RDLCBBcmdfTmFtZXMsIEFyZ19QaWNrbGUpCiAgICBFTkQ7CiAg >ICBTY2hlbWVQcm9jZWR1cmVTdHVicy5SZWdpc3RlcihORVcoU2NoZW1lUHJvY2VkdXJlU3R1YnMu >UWlkLCBpbnRmIDo9IEF0b20uRnJvbVRleHQoIkZTIiksIGl0ZW0gOj0gQXRvbS5Gcm9tVGV4dCgi >R2V0QWJzb2x1dGVQYXRobmFtZSIpKSwgQ2FsbFN0dWJfRlNfR2V0QWJzb2x1dGVQYXRobmFtZSk7 >CiAgICBTY2hlbWVQcm9jZWR1cmVTdHVicy5SZWdpc3RlcihORVcoU2NoZW1lUHJvY2VkdXJlU3R1 >YnMuUWlkLCBpbnRmIDo9IEF0b20uRnJvbVRleHQoIkZTIiksIGl0ZW0gOj0gQXRvbS5Gcm9tVGV4 >dCgiT3BlbkZpbGUiKSksIENhbGxTdHViX0ZTX09wZW5GaWxlKTsKICAgIFNjaGVtZVByb2NlZHVy >ZVN0dWJzLlJlZ2lzdGVyKE5FVyhTY2hlbWVQcm9jZWR1cmVTdHVicy5RaWQsIGludGYgOj0gQXRv >bS5Gcm9tVGV4dCgiRlMiKSwgaXRlbSA6PSBBdG9tLkZyb21UZXh0KCJPcGVuRmlsZVJlYWRvbmx5 >IikpLCBDYWxsU3R1Yl9GU19PcGVuRmlsZVJlYWRvbmx5KTsKICAgIFNjaGVtZVByb2NlZHVyZVN0 >dWJzLlJlZ2lzdGVyKE5FVyhTY2hlbWVQcm9jZWR1cmVTdHVicy5RaWQsIGludGYgOj0gQXRvbS5G >cm9tVGV4dCgiRlMiKSwgaXRlbSA6PSBBdG9tLkZyb21UZXh0KCJDcmVhdGVEaXJlY3RvcnkiKSks >IENhbGxTdHViX0ZTX0NyZWF0ZURpcmVjdG9yeSk7CiAgICBTY2hlbWVQcm9jZWR1cmVTdHVicy5S >ZWdpc3RlcihORVcoU2NoZW1lUHJvY2VkdXJlU3R1YnMuUWlkLCBpbnRmIDo9IEF0b20uRnJvbVRl >eHQoIkZTIiksIGl0ZW0gOj0gQXRvbS5Gcm9tVGV4dCgiRGVsZXRlRGlyZWN0b3J5IikpLCBDYWxs >U3R1Yl9GU19EZWxldGVEaXJlY3RvcnkpOwogICAgU2NoZW1lUHJvY2VkdXJlU3R1YnMuUmVnaXN0 >ZXIoTkVXKFNjaGVtZVByb2NlZHVyZVN0dWJzLlFpZCwgaW50ZiA6PSBBdG9tLkZyb21UZXh0KCJG >UyIpLCBpdGVtIDo9IEF0b20uRnJvbVRleHQoIkRlbGV0ZUZpbGUiKSksIENhbGxTdHViX0ZTX0Rl >bGV0ZUZpbGUpOwogICAgU2NoZW1lUHJvY2VkdXJlU3R1YnMuUmVnaXN0ZXIoTkVXKFNjaGVtZVBy >b2NlZHVyZVN0dWJzLlFpZCwgaW50ZiA6PSBBdG9tLkZyb21UZXh0KCJGUyIpLCBpdGVtIDo9IEF0 >b20uRnJvbVRleHQoIlJlbmFtZSIpKSwgQ2FsbFN0dWJfRlNfUmVuYW1lKTsKICAgIFNjaGVtZVBy >b2NlZHVyZVN0dWJzLlJlZ2lzdGVyKE5FVyhTY2hlbWVQcm9jZWR1cmVTdHVicy5RaWQsIGludGYg >Oj0gQXRvbS5Gcm9tVGV4dCgiRlMiKSwgaXRlbSA6PSBBdG9tLkZyb21UZXh0KCJJdGVyYXRlIikp >LCBDYWxsU3R1Yl9GU19JdGVyYXRlKTsKICAgIFNjaGVtZVByb2NlZHVyZVN0dWJzLlJlZ2lzdGVy >KE5FVyhTY2hlbWVQcm9jZWR1cmVTdHVicy5RaWQsIGludGYgOj0gQXRvbS5Gcm9tVGV4dCgiRlMi >KSwgaXRlbSA6PSBBdG9tLkZyb21UZXh0KCJTdGF0dXMiKSksIENhbGxTdHViX0ZTX1N0YXR1cyk7 >CiAgICBTY2hlbWVQcm9jZWR1cmVTdHVicy5SZWdpc3RlcihORVcoU2NoZW1lUHJvY2VkdXJlU3R1 >YnMuUWlkLCBpbnRmIDo9IEF0b20uRnJvbVRleHQoIkZTIiksIGl0ZW0gOj0gQXRvbS5Gcm9tVGV4 >dCgiU2V0TW9kaWZpY2F0aW9uVGltZSIpKSwgQ2FsbFN0dWJfRlNfU2V0TW9kaWZpY2F0aW9uVGlt >ZSk7CiAgRU5EIFJlZ2lzdGVyU3R1YnM7CgpQUk9DRURVUkUgTmV3X0ZTX0l0ZXJhdG9yKGludGVy >cCA6IFNjaGVtZS5UOyBpbml0cyA6IFNjaGVtZU9iamVjdC5UKSA6IFNjaGVtZU9iamVjdC5UIFJB >SVNFUyB7IFNjaGVtZS5FIH0gPQogIFZBUgogICAgcCA6PSBTY2hlbWVQYWlyLlBhaXIoaW5pdHMp >OwogICAgZ29iYmxlZCA6IEJPT0xFQU47CiAgQkVHSU4KICAgIFdJVEggcmVzID0gTkVXKEZTX0l0 >ZXJhdG9yX1N1cnJvZ2F0ZSwgaW50ZXJwIDo9IGludGVycCkgRE8KICAgICAgV0hJTEUgcCAjIE5J >TCBETwogICAgICAgIFdJVEggciA9IFNjaGVtZVBhaXIuUGFpcihwLmZpcnN0KSBETwogICAgICAg >ICAgZ29iYmxlZCA6PSBGQUxTRTsKICAgICAgICAgIElGIHIgIyBOSUwgVEhFTgogICAgICAgICAg >ICBJRiByLmZpcnN0ID0gU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJuZXh0IikgVEhFTgogICAgICAg >ICAgICAgICByZXMubmV4dF9zbG90IDo9IHIucmVzdDsgZ29iYmxlZCA6PSBUUlVFCiAgICAgICAg >ICAgIEVORDsKICAgICAgICAgICAgSUYgci5maXJzdCA9IFNjaGVtZVN5bWJvbC5Gcm9tVGV4dCgi >Y2xvc2UiKSBUSEVOCiAgICAgICAgICAgICAgIHJlcy5jbG9zZV9zbG90IDo9IHIucmVzdDsgZ29i >YmxlZCA6PSBUUlVFCiAgICAgICAgICAgIEVORDsKICAgICAgICAgICAgSUYgci5maXJzdCA9IFNj >aGVtZVN5bWJvbC5Gcm9tVGV4dCgibmV4dFdpdGhTdGF0dXMiKSBUSEVOCiAgICAgICAgICAgICAg >IHJlcy5uZXh0V2l0aFN0YXR1c19zbG90IDo9IHIucmVzdDsgZ29iYmxlZCA6PSBUUlVFCiAgICAg >ICAgICAgIEVORDsKICAgICAgICAgIEVORDsKICAgICAgICAgIElGIE5PVCBnb2JibGVkIFRIRU4K >ICAgICAgICAgICAgUkFJU0UgU2NoZW1lLkUoIkZTX0l0ZXJhdG9yOiBVbmtub3duIGZpZWxkL21l >dGhvZCAiICYgU2NoZW1lVXRpbHMuU3RyaW5naWZ5KHIuZmlyc3QpICYgIiBpbiAiICYgU2NoZW1l >VXRpbHMuU3RyaW5naWZ5KGluaXRzKSkKICAgICAgICAgIEVORAogICAgICAgIEVORDsKICAgICAg >ICBwIDo9IFNjaGVtZVBhaXIuUGFpcihwLnJlc3QpCiAgICAgIEVORDsKICAgICAgUkVUVVJOIHJl >cwogICAgRU5ECiAgRU5EIE5ld19GU19JdGVyYXRvcjsKClBST0NFRFVSRSBHZW5OZXdfRlNfSXRl >cmF0b3IoaW50ZXJwIDogU2NoZW1lLlQ7IDwqVU5VU0VEKj5vYmogOiBTY2hlbWVPYmplY3QuVDsg >aW5pdHMgOiBTY2hlbWVPYmplY3QuVCkgOiBTY2hlbWVPYmplY3QuVCBSQUlTRVMgeyBTY2hlbWUu >RSB9ID0KICBCRUdJTiBSRVRVUk4gTmV3X0ZTX0l0ZXJhdG9yKGludGVycCxpbml0cykgRU5EIEdl >bk5ld19GU19JdGVyYXRvcjsKClRZUEUgRlNfSXRlcmF0b3JfU3Vycm9nYXRlID0gRlMuSXRlcmF0 >b3IgT0JKRUNUIAogICAgaW50ZXJwIDogU2NoZW1lLlQ7CiAgICBuZXh0X3Nsb3QgOiBTY2hlbWVP >YmplY3QuVCA6PSBOSUw7IAogICAgY2xvc2Vfc2xvdCA6IFNjaGVtZU9iamVjdC5UIDo9IE5JTDsg >CiAgICBuZXh0V2l0aFN0YXR1c19zbG90IDogU2NoZW1lT2JqZWN0LlQgOj0gTklMOyAKICBPVkVS >UklERVMKICAgIG5leHQgOj0gRlNfSXRlcmF0b3JfbmV4dF9kZWZhdWx0OwogICAgY2xvc2UgOj0g >RlNfSXRlcmF0b3JfY2xvc2VfZGVmYXVsdDsKICAgIG5leHRXaXRoU3RhdHVzIDo9IEZTX0l0ZXJh >dG9yX25leHRXaXRoU3RhdHVzX2RlZmF1bHQ7CiAgRU5EOwoKUFJPQ0VEVVJFIE1ldGhvZERpc3Bh >dGNoZXJfRlNfSXRlcmF0b3IoaW50ZXJwIDogU2NoZW1lLlQ7IG9iaiA6IFNjaGVtZU9iamVjdC5U >OyBhcmdzIDogU2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1l >LkUgfSA9CiAgVkFSCiAgICBtZXRoTmFtZSA6PSBTY2hlbWUuU3ltYm9sQ2hlY2soU2NoZW1lVXRp >bHMuRmlyc3QoYXJncykpOwogICAgbWV0aEFyZ3MgOj0gU2NoZW1lVXRpbHMuQ29ucyhvYmosU2No >ZW1lVXRpbHMuU2Vjb25kKGFyZ3MpKTsKICAgIG1ldGhFeGNIYW5kbGVyIDo9IFNjaGVtZVV0aWxz >LlRoaXJkKGFyZ3MpOwogIEJFR0lOCiAgICBJRiBGQUxTRSBUSEVOIDwqQVNTRVJUIEZBTFNFKj4K >ICAgIEVMU0lGIG1ldGhOYW1lID0gU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJuZXh0IikgVEhFTgog >ICAgICBSRVRVUk4gTWV0aG9kU3R1Yl9GU19JdGVyYXRvcl9uZXh0KGludGVycCxtZXRoQXJncyxt >ZXRoRXhjSGFuZGxlcikKICAgIEVMU0lGIG1ldGhOYW1lID0gU2NoZW1lU3ltYm9sLkZyb21UZXh0 >KCJjbG9zZSIpIFRIRU4KICAgICAgUkVUVVJOIE1ldGhvZFN0dWJfRlNfSXRlcmF0b3JfY2xvc2Uo >aW50ZXJwLG1ldGhBcmdzLG1ldGhFeGNIYW5kbGVyKQogICAgRUxTSUYgbWV0aE5hbWUgPSBTY2hl >bWVTeW1ib2wuRnJvbVRleHQoIm5leHRXaXRoU3RhdHVzIikgVEhFTgogICAgICBSRVRVUk4gTWV0 >aG9kU3R1Yl9GU19JdGVyYXRvcl9uZXh0V2l0aFN0YXR1cyhpbnRlcnAsbWV0aEFyZ3MsbWV0aEV4 >Y0hhbmRsZXIpCiAgICBFTFNFCiAgICAgIFJBSVNFIFNjaGVtZS5FKCJ1bmtub3duIG1ldGhvZCAi >JlNjaGVtZVN5bWJvbC5Ub1RleHQobWV0aE5hbWUpJiIgZm9yIHR5cGUgRlMuSXRlcmF0b3IiKTsK >ICAgIEVORAogIEVORCBNZXRob2REaXNwYXRjaGVyX0ZTX0l0ZXJhdG9yOwoKUFJPQ0VEVVJFIEZT >X0l0ZXJhdG9yX25leHRfZGVmYXVsdChvYmplY3RfXyA6IEZTX0l0ZXJhdG9yX1N1cnJvZ2F0ZTsg >VkFSIGZvcm1hbF9uYW1lIDogIFRFWFQgKSA6ICBCT09MRUFOICA9IAogIEJFR0lOCiAgICBJRiBv >YmplY3RfXy5uZXh0X3Nsb3QgPSBOSUwgVEhFTgogICAgICAoKiBwdW50IHRvIE1vZHVsYS0zIG9i >amVjdCB0eXBlIGRlZm4gKikKICAgICAgUkVUVVJOIEZTLkl0ZXJhdG9yLm5leHQob2JqZWN0X18s >IGZvcm1hbF9uYW1lKQogICAgRUxTRQogICAgICAoKiBtZXRob2Qgb3ZlcnJpZGVuIGJ5IFNjaGVt >ZSBjb2RlICopCiAgICAgIFZBUgogICAgICAgIGFyZ3NfXyA6IFNjaGVtZVBhaXIuVCA6PSBORVco >U2NoZW1lUGFpci5ULCBmaXJzdCA6PSBvYmplY3RfXywgcmVzdCA6PSBOSUwpOwogICAgICBCRUdJ >TgogICAgICAgIGFyZ3NfXyA6PSBTY2hlbWVVdGlscy5Db25zKFNjaGVtZU1vZHVsYTNUeXBlcy5U >b1NjaGVtZV9URVhUKGZvcm1hbF9uYW1lKSxhcmdzX18pOwogICAgICAgIGFyZ3NfXyA6PSBTY2hl >bWVVdGlscy5SZXZlcnNlKGFyZ3NfXyk7CiAgICAgICAgUkVUVVJOIFNjaGVtZU1vZHVsYTNUeXBl >cy5Ub01vZHVsYV9CT09MRUFOKFNjaGVtZVByb2NlZHVyZVN0dWJzLkNhbGxTY2hlbWUob2JqZWN0 >X18uaW50ZXJwLCBvYmplY3RfXy5uZXh0X3Nsb3QsIGFyZ3NfXykpCiAgICAgICAgKCogYW5kIHRo >aXMgaXMgd2hlcmUgd2UgbmVlZCB0byB1bnBhY2sgVkFSIHBhcmFtcyAqKQogICAgICBFTkQKICAg >IEVORAogIEVORCBGU19JdGVyYXRvcl9uZXh0X2RlZmF1bHQ7CgpQUk9DRURVUkUgRlNfSXRlcmF0 >b3JfY2xvc2VfZGVmYXVsdChvYmplY3RfXyA6IEZTX0l0ZXJhdG9yX1N1cnJvZ2F0ZSkgPSAKICBC >RUdJTgogICAgSUYgb2JqZWN0X18uY2xvc2Vfc2xvdCA9IE5JTCBUSEVOCiAgICAgICgqIHB1bnQg >dG8gTW9kdWxhLTMgb2JqZWN0IHR5cGUgZGVmbiAqKQogICAgICBGUy5JdGVyYXRvci5jbG9zZShv >YmplY3RfXykKICAgIEVMU0UKICAgICAgKCogbWV0aG9kIG92ZXJyaWRlbiBieSBTY2hlbWUgY29k >ZSAqKQogICAgICBWQVIKICAgICAgICBhcmdzX18gOiBTY2hlbWVQYWlyLlQgOj0gTkVXKFNjaGVt >ZVBhaXIuVCwgZmlyc3QgOj0gb2JqZWN0X18sIHJlc3QgOj0gTklMKTsKICAgICAgQkVHSU4KICAg >ICAgICBhcmdzX18gOj0gU2NoZW1lVXRpbHMuUmV2ZXJzZShhcmdzX18pOwogICAgICAgIEVWQUwg >KFNjaGVtZVByb2NlZHVyZVN0dWJzLkNhbGxTY2hlbWUob2JqZWN0X18uaW50ZXJwLCBvYmplY3Rf >Xy5jbG9zZV9zbG90LCBhcmdzX18pKQogICAgICAgICgqIGFuZCB0aGlzIGlzIHdoZXJlIHdlIG5l >ZWQgdG8gdW5wYWNrIFZBUiBwYXJhbXMgKikKICAgICAgRU5ECiAgICBFTkQKICBFTkQgRlNfSXRl >cmF0b3JfY2xvc2VfZGVmYXVsdDsKClBST0NFRFVSRSBGU19JdGVyYXRvcl9uZXh0V2l0aFN0YXR1 >c19kZWZhdWx0KG9iamVjdF9fIDogRlNfSXRlcmF0b3JfU3Vycm9nYXRlOyBWQVIgZm9ybWFsX25h >bWUgOiAgVEVYVCA7IFZBUiBmb3JtYWxfc3RhdCA6IEZpbGUuU3RhdHVzKSA6ICBCT09MRUFOICBS >QUlTRVMgeyBPU0Vycm9yLkUgfSA9IAogIEJFR0lOCiAgICBJRiBvYmplY3RfXy5uZXh0V2l0aFN0 >YXR1c19zbG90ID0gTklMIFRIRU4KICAgICAgKCogcHVudCB0byBNb2R1bGEtMyBvYmplY3QgdHlw >ZSBkZWZuICopCiAgICAgIFJFVFVSTiBGUy5JdGVyYXRvci5uZXh0V2l0aFN0YXR1cyhvYmplY3Rf >XywgZm9ybWFsX25hbWUsIGZvcm1hbF9zdGF0KQogICAgRUxTRQogICAgICAoKiBtZXRob2Qgb3Zl >cnJpZGVuIGJ5IFNjaGVtZSBjb2RlICopCiAgICAgIFZBUgogICAgICAgIGFyZ3NfXyA6IFNjaGVt >ZVBhaXIuVCA6PSBORVcoU2NoZW1lUGFpci5ULCBmaXJzdCA6PSBvYmplY3RfXywgcmVzdCA6PSBO >SUwpOwogICAgICBCRUdJTgogICAgICAgIGFyZ3NfXyA6PSBTY2hlbWVVdGlscy5Db25zKFNjaGVt >ZU1vZHVsYTNUeXBlcy5Ub1NjaGVtZV9URVhUKGZvcm1hbF9uYW1lKSxhcmdzX18pOwogICAgICAg >IGFyZ3NfXyA6PSBTY2hlbWVVdGlscy5Db25zKFRvU2NoZW1lX0ZpbGVfU3RhdHVzKGZvcm1hbF9z >dGF0KSxhcmdzX18pOwogICAgICAgIGFyZ3NfXyA6PSBTY2hlbWVVdGlscy5SZXZlcnNlKGFyZ3Nf >Xyk7CiAgICAgICAgUkVUVVJOIFNjaGVtZU1vZHVsYTNUeXBlcy5Ub01vZHVsYV9CT09MRUFOKFNj >aGVtZVByb2NlZHVyZVN0dWJzLkNhbGxTY2hlbWUob2JqZWN0X18uaW50ZXJwLCBvYmplY3RfXy5u >ZXh0V2l0aFN0YXR1c19zbG90LCBhcmdzX18pKQogICAgICAgICgqIGFuZCB0aGlzIGlzIHdoZXJl >IHdlIG5lZWQgdG8gdW5wYWNrIFZBUiBwYXJhbXMgKikKICAgICAgRU5ECiAgICBFTkQKICBFTkQg >RlNfSXRlcmF0b3JfbmV4dFdpdGhTdGF0dXNfZGVmYXVsdDsKClBST0NFRFVSRSBNZXRob2RTdHVi >X0ZTX0l0ZXJhdG9yX25leHQoaW50ZXJwIDogU2NoZW1lLlQ7CiAgICAgICAgICAgICAgICAgICAg >ICBhcmdzIDogU2NoZW1lT2JqZWN0LlQ7CiAgICAgICAgICAgICAgICAgICAgICBleGNIYW5kbGVy >IDogU2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQKICBSQUlTRVMgeyBTY2hlbWUuRSB9 >ID0gCiAKICBQUk9DRURVUkUgTmV4dCgpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1l >LkUgfSA9IAogICAgQkVHSU4KICAgICAgVFJZIFJFVFVSTiBTY2hlbWVVdGlscy5GaXJzdChwX18p >IEZJTkFMTFkgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihTY2hlbWVVdGlscy5SZXN0KHBfXykpIEVO >RAogICAgRU5EIE5leHQ7CiAKICBWQVIgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICBC >RUdJTgogICAgVFJZCiAgICAgICgqIHVucGFjayBmb3JtYWxzICopCiAgICAgIFZBUiA8Kk5PV0FS >Tio+anVua19fIDo9IDA7CiAgICAgICAgICAgdGhpcyA6PSBUb01vZHVsYV9GU19JdGVyYXRvcihO >ZXh0KCkpOwogICAgICAgICAgIGZvcm1hbF9uYW1lIDo9IFNjaGVtZU1vZHVsYTNUeXBlcy5Ub01v >ZHVsYV9URVhUKE5leHQoKSk7IEJFR0lOCiAgICAgICAgKCogY2Fycnkgb3V0IE5JTCBjaGVja3Mg >Zm9yIG9wZW4gYXJyYXlzICopCgogICAgICAgICgqIG1ha2UgcHJvY2VkdXJlIGNhbGwgKikKICAg >ICAgICBXSVRIIHJlcyA9IFNjaGVtZU1vZHVsYTNUeXBlcy5Ub1NjaGVtZV9CT09MRUFOKHRoaXMu >bmV4dChmb3JtYWxfbmFtZSkpIERPCiAgICAgICAgKCogdW5wYWNrIFZBUiBwYXJhbXMgKikKICAg >ICAgICBwX18gOj0gU2NoZW1lUGFpci5QYWlyKGFyZ3MpOwogICAgICAgIEVWQUwgTmV4dCgpOwog >ICAgICAgIEVWQUwgU2NoZW1lVXRpbHMuU2V0Rmlyc3QocF9fLFNjaGVtZU1vZHVsYTNUeXBlcy5U >b1NjaGVtZV9URVhUKGZvcm1hbF9uYW1lKSk7CiAgICAgICAgRVZBTCBOZXh0KCk7CgogICAgICAg >ICgqIHJldHVybiBwcm9jZWR1cmUgcmVzdWx0ICopCiAgICAgICAgUkVUVVJOIHJlcwogICAgICAg >IEVORAogICAgICBFTkQoKldJVEgqKQogICAgRVhDRVBUCiAgICBFTkQ7CiAgICA8Kk5PV0FSTio+ >UkVUVVJOIFNjaGVtZUJvb2xlYW4uRmFsc2UoKQogIEVORCBNZXRob2RTdHViX0ZTX0l0ZXJhdG9y >X25leHQ7ClBST0NFRFVSRSBNZXRob2RTdHViX0ZTX0l0ZXJhdG9yX2Nsb3NlKGludGVycCA6IFNj >aGVtZS5UOwogICAgICAgICAgICAgICAgICAgICAgYXJncyA6IFNjaGVtZU9iamVjdC5UOwogICAg >ICAgICAgICAgICAgICAgICAgZXhjSGFuZGxlciA6IFNjaGVtZU9iamVjdC5UKSA6IFNjaGVtZU9i >amVjdC5UCiAgUkFJU0VTIHsgU2NoZW1lLkUgfSA9IAogCiAgUFJPQ0VEVVJFIE5leHQoKSA6IFNj >aGVtZU9iamVjdC5UIFJBSVNFUyB7IFNjaGVtZS5FIH0gPSAKICAgIEJFR0lOCiAgICAgIFRSWSBS >RVRVUk4gU2NoZW1lVXRpbHMuRmlyc3QocF9fKSBGSU5BTExZIHBfXyA6PSBTY2hlbWVQYWlyLlBh >aXIoU2NoZW1lVXRpbHMuUmVzdChwX18pKSBFTkQKICAgIEVORCBOZXh0OwogCiAgVkFSIHBfXyA6 >PSBTY2hlbWVQYWlyLlBhaXIoYXJncyk7CiAgQkVHSU4KICAgIFRSWQogICAgICAoKiB1bnBhY2sg >Zm9ybWFscyAqKQogICAgICBWQVIgPCpOT1dBUk4qPmp1bmtfXyA6PSAwOwogICAgICAgICAgIHRo >aXMgOj0gVG9Nb2R1bGFfRlNfSXRlcmF0b3IoTmV4dCgpKTsgQkVHSU4KICAgICAgICAoKiBjYXJy >eSBvdXQgTklMIGNoZWNrcyBmb3Igb3BlbiBhcnJheXMgKikKCiAgICAgICAgKCogbWFrZSBwcm9j >ZWR1cmUgY2FsbCAqKQogICAgICAgIHRoaXMuY2xvc2UoKTsKICAgICAgICAoKiB1bnBhY2sgVkFS >IHBhcmFtcyAqKQogICAgICAgIHBfXyA6PSBTY2hlbWVQYWlyLlBhaXIoYXJncyk7CiAgICAgICAg >RVZBTCBOZXh0KCk7CgogICAgICAgICgqIHByb3BlciBwcm9jZWR1cmUgOiByZXR1cm4gVFJVRSAq >KQogICAgICAgIFJFVFVSTiBTY2hlbWVCb29sZWFuLlRydWUoKQogICAgICBFTkQoKldJVEgqKQog >ICAgRVhDRVBUCiAgICBFTkQ7CiAgICA8Kk5PV0FSTio+UkVUVVJOIFNjaGVtZUJvb2xlYW4uRmFs >c2UoKQogIEVORCBNZXRob2RTdHViX0ZTX0l0ZXJhdG9yX2Nsb3NlOwpQUk9DRURVUkUgTWV0aG9k >U3R1Yl9GU19JdGVyYXRvcl9uZXh0V2l0aFN0YXR1cyhpbnRlcnAgOiBTY2hlbWUuVDsKICAgICAg >ICAgICAgICAgICAgICAgIGFyZ3MgOiBTY2hlbWVPYmplY3QuVDsKICAgICAgICAgICAgICAgICAg >ICAgIGV4Y0hhbmRsZXIgOiBTY2hlbWVPYmplY3QuVCkgOiBTY2hlbWVPYmplY3QuVAogIFJBSVNF >UyB7IFNjaGVtZS5FIH0gPSAKIAogIFBST0NFRFVSRSBOZXh0KCkgOiBTY2hlbWVPYmplY3QuVCBS >QUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAgICBCRUdJTgogICAgICBUUlkgUkVUVVJOIFNjaGVtZVV0 >aWxzLkZpcnN0KHBfXykgRklOQUxMWSBwX18gOj0gU2NoZW1lUGFpci5QYWlyKFNjaGVtZVV0aWxz >LlJlc3QocF9fKSkgRU5ECiAgICBFTkQgTmV4dDsKIAogIFZBUiBwX18gOj0gU2NoZW1lUGFpci5Q >YWlyKGFyZ3MpOwogIEJFR0lOCiAgICBUUlkKICAgICAgKCogdW5wYWNrIGZvcm1hbHMgKikKICAg >ICAgVkFSIDwqTk9XQVJOKj5qdW5rX18gOj0gMDsKICAgICAgICAgICB0aGlzIDo9IFRvTW9kdWxh >X0ZTX0l0ZXJhdG9yKE5leHQoKSk7CiAgICAgICAgICAgZm9ybWFsX25hbWUgOj0gU2NoZW1lTW9k >dWxhM1R5cGVzLlRvTW9kdWxhX1RFWFQoTmV4dCgpKTsKICAgICAgICAgICBmb3JtYWxfc3RhdCA6 >PSBUb01vZHVsYV9GaWxlX1N0YXR1cyhOZXh0KCkpOyBCRUdJTgogICAgICAgICgqIGNhcnJ5IG91 >dCBOSUwgY2hlY2tzIGZvciBvcGVuIGFycmF5cyAqKQoKICAgICAgICAoKiBtYWtlIHByb2NlZHVy ZSBjYWxsICopCiAgICAgICAgV0lUSCByZXMgPSBTY2hlbWVNb2R1bGEzVHlwZXMuVG9TY2hlbWVf >Qk9PTEVBTih0aGlzLm5leHRXaXRoU3RhdHVzKGZvcm1hbF9uYW1lLCBmb3JtYWxfc3RhdCkpIERP >CiAgICAgICAgKCogdW5wYWNrIFZBUiBwYXJhbXMgKikKICAgICAgICBwX18gOj0gU2NoZW1lUGFp >ci5QYWlyKGFyZ3MpOwogICAgICAgIEVWQUwgTmV4dCgpOwogICAgICAgIEVWQUwgU2NoZW1lVXRp >bHMuU2V0Rmlyc3QocF9fLFNjaGVtZU1vZHVsYTNUeXBlcy5Ub1NjaGVtZV9URVhUKGZvcm1hbF9u >YW1lKSk7CiAgICAgICAgRVZBTCBOZXh0KCk7CiAgICAgICAgRVZBTCBTY2hlbWVVdGlscy5TZXRG >aXJzdChwX18sVG9TY2hlbWVfRmlsZV9TdGF0dXMoZm9ybWFsX3N0YXQpKTsKICAgICAgICBFVkFM >IE5leHQoKTsKCiAgICAgICAgKCogcmV0dXJuIHByb2NlZHVyZSByZXN1bHQgKikKICAgICAgICBS >RVRVUk4gcmVzCiAgICAgICAgRU5ECiAgICAgIEVORCgqV0lUSCopCiAgICBFWENFUFQKICAgICAg >fCBPU0Vycm9yLkUoeGFyZykgPT4gRVZBTCBTY2hlbWVBcHBseS5PbmVBcmcoaW50ZXJwLGV4Y0hh >bmRsZXIsU2NoZW1lVXRpbHMuTGlzdDIoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJxdW90ZSIpLFNj >aGVtZVV0aWxzLkNvbnMoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJPU0Vycm9yLkUiKSwgVG9TY2hl >bWVfQXRvbUxpc3RfVCh4YXJnKSkpKQogICAgRU5EOwogICAgPCpOT1dBUk4qPlJFVFVSTiBTY2hl >bWVCb29sZWFuLkZhbHNlKCkKICBFTkQgTWV0aG9kU3R1Yl9GU19JdGVyYXRvcl9uZXh0V2l0aFN0 >YXR1czsKUFJPQ0VEVVJFIE5ld19GU19QdWJsaWNJdGVyYXRvcihpbnRlcnAgOiBTY2hlbWUuVDsg >aW5pdHMgOiBTY2hlbWVPYmplY3QuVCkgOiBTY2hlbWVPYmplY3QuVCBSQUlTRVMgeyBTY2hlbWUu >RSB9ID0KICBWQVIKICAgIHAgOj0gU2NoZW1lUGFpci5QYWlyKGluaXRzKTsKICAgIGdvYmJsZWQg >OiBCT09MRUFOOwogIEJFR0lOCiAgICBXSVRIIHJlcyA9IE5FVyhGU19QdWJsaWNJdGVyYXRvcl9T >dXJyb2dhdGUsIGludGVycCA6PSBpbnRlcnApIERPCiAgICAgIFdISUxFIHAgIyBOSUwgRE8KICAg >ICAgICBXSVRIIHIgPSBTY2hlbWVQYWlyLlBhaXIocC5maXJzdCkgRE8KICAgICAgICAgIGdvYmJs >ZWQgOj0gRkFMU0U7CiAgICAgICAgICBJRiByICMgTklMIFRIRU4KICAgICAgICAgICAgSUYgci5m >aXJzdCA9IFNjaGVtZVN5bWJvbC5Gcm9tVGV4dCgibmV4dCIpIFRIRU4KICAgICAgICAgICAgICAg >cmVzLm5leHRfc2xvdCA6PSByLnJlc3Q7IGdvYmJsZWQgOj0gVFJVRQogICAgICAgICAgICBFTkQ7 >CiAgICAgICAgICAgIElGIHIuZmlyc3QgPSBTY2hlbWVTeW1ib2wuRnJvbVRleHQoImNsb3NlIikg >VEhFTgogICAgICAgICAgICAgICByZXMuY2xvc2Vfc2xvdCA6PSByLnJlc3Q7IGdvYmJsZWQgOj0g >VFJVRQogICAgICAgICAgICBFTkQ7CiAgICAgICAgICAgIElGIHIuZmlyc3QgPSBTY2hlbWVTeW1i >b2wuRnJvbVRleHQoIm5leHRXaXRoU3RhdHVzIikgVEhFTgogICAgICAgICAgICAgICByZXMubmV4 >dFdpdGhTdGF0dXNfc2xvdCA6PSByLnJlc3Q7IGdvYmJsZWQgOj0gVFJVRQogICAgICAgICAgICBF >TkQ7CiAgICAgICAgICBFTkQ7CiAgICAgICAgICBJRiBOT1QgZ29iYmxlZCBUSEVOCiAgICAgICAg >ICAgIFJBSVNFIFNjaGVtZS5FKCJGU19QdWJsaWNJdGVyYXRvcjogVW5rbm93biBmaWVsZC9tZXRo >b2QgIiAmIFNjaGVtZVV0aWxzLlN0cmluZ2lmeShyLmZpcnN0KSAmICIgaW4gIiAmIFNjaGVtZVV0 >aWxzLlN0cmluZ2lmeShpbml0cykpCiAgICAgICAgICBFTkQKICAgICAgICBFTkQ7CiAgICAgICAg >cCA6PSBTY2hlbWVQYWlyLlBhaXIocC5yZXN0KQogICAgICBFTkQ7CiAgICAgIFJFVFVSTiByZXMK >ICAgIEVORAogIEVORCBOZXdfRlNfUHVibGljSXRlcmF0b3I7CgpQUk9DRURVUkUgR2VuTmV3X0ZT >X1B1YmxpY0l0ZXJhdG9yKGludGVycCA6IFNjaGVtZS5UOyA8KlVOVVNFRCo+b2JqIDogU2NoZW1l >T2JqZWN0LlQ7IGluaXRzIDogU2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VT >IHsgU2NoZW1lLkUgfSA9CiAgQkVHSU4gUkVUVVJOIE5ld19GU19QdWJsaWNJdGVyYXRvcihpbnRl >cnAsaW5pdHMpIEVORCBHZW5OZXdfRlNfUHVibGljSXRlcmF0b3I7CgpUWVBFIEZTX1B1YmxpY0l0 >ZXJhdG9yX1N1cnJvZ2F0ZSA9IEZTLlB1YmxpY0l0ZXJhdG9yIE9CSkVDVCAKICAgIGludGVycCA6 >IFNjaGVtZS5UOwogICAgbmV4dF9zbG90IDogU2NoZW1lT2JqZWN0LlQgOj0gTklMOyAKICAgIGNs >b3NlX3Nsb3QgOiBTY2hlbWVPYmplY3QuVCA6PSBOSUw7IAogICAgbmV4dFdpdGhTdGF0dXNfc2xv >dCA6IFNjaGVtZU9iamVjdC5UIDo9IE5JTDsgCiAgT1ZFUlJJREVTCiAgICBuZXh0IDo9IEZTX1B1 >YmxpY0l0ZXJhdG9yX25leHRfZGVmYXVsdDsKICAgIGNsb3NlIDo9IEZTX1B1YmxpY0l0ZXJhdG9y >X2Nsb3NlX2RlZmF1bHQ7CiAgICBuZXh0V2l0aFN0YXR1cyA6PSBGU19QdWJsaWNJdGVyYXRvcl9u >ZXh0V2l0aFN0YXR1c19kZWZhdWx0OwogIEVORDsKClBST0NFRFVSRSBNZXRob2REaXNwYXRjaGVy >X0ZTX1B1YmxpY0l0ZXJhdG9yKGludGVycCA6IFNjaGVtZS5UOyBvYmogOiBTY2hlbWVPYmplY3Qu >VDsgYXJncyA6IFNjaGVtZU9iamVjdC5UKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IFNjaGVt >ZS5FIH0gPQogIFZBUgogICAgbWV0aE5hbWUgOj0gU2NoZW1lLlN5bWJvbENoZWNrKFNjaGVtZVV0 >aWxzLkZpcnN0KGFyZ3MpKTsKICAgIG1ldGhBcmdzIDo9IFNjaGVtZVV0aWxzLkNvbnMob2JqLFNj >aGVtZVV0aWxzLlNlY29uZChhcmdzKSk7CiAgICBtZXRoRXhjSGFuZGxlciA6PSBTY2hlbWVVdGls >cy5UaGlyZChhcmdzKTsKICBCRUdJTgogICAgSUYgRkFMU0UgVEhFTiA8KkFTU0VSVCBGQUxTRSo+ >CiAgICBFTFNJRiBtZXRoTmFtZSA9IFNjaGVtZVN5bWJvbC5Gcm9tVGV4dCgibmV4dCIpIFRIRU4K >ICAgICAgUkVUVVJOIE1ldGhvZFN0dWJfRlNfUHVibGljSXRlcmF0b3JfbmV4dChpbnRlcnAsbWV0 >aEFyZ3MsbWV0aEV4Y0hhbmRsZXIpCiAgICBFTFNJRiBtZXRoTmFtZSA9IFNjaGVtZVN5bWJvbC5G >cm9tVGV4dCgiY2xvc2UiKSBUSEVOCiAgICAgIFJFVFVSTiBNZXRob2RTdHViX0ZTX1B1YmxpY0l0 >ZXJhdG9yX2Nsb3NlKGludGVycCxtZXRoQXJncyxtZXRoRXhjSGFuZGxlcikKICAgIEVMU0lGIG1l >dGhOYW1lID0gU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJuZXh0V2l0aFN0YXR1cyIpIFRIRU4KICAg >ICAgUkVUVVJOIE1ldGhvZFN0dWJfRlNfUHVibGljSXRlcmF0b3JfbmV4dFdpdGhTdGF0dXMoaW50 >ZXJwLG1ldGhBcmdzLG1ldGhFeGNIYW5kbGVyKQogICAgRUxTRQogICAgICBSQUlTRSBTY2hlbWUu >RSgidW5rbm93biBtZXRob2QgIiZTY2hlbWVTeW1ib2wuVG9UZXh0KG1ldGhOYW1lKSYiIGZvciB0 >eXBlIEZTLlB1YmxpY0l0ZXJhdG9yIik7CiAgICBFTkQKICBFTkQgTWV0aG9kRGlzcGF0Y2hlcl9G >U19QdWJsaWNJdGVyYXRvcjsKClBST0NFRFVSRSBGU19QdWJsaWNJdGVyYXRvcl9uZXh0X2RlZmF1 >bHQob2JqZWN0X18gOiBGU19QdWJsaWNJdGVyYXRvcl9TdXJyb2dhdGU7IFZBUiBmb3JtYWxfbmFt >ZSA6ICBURVhUICkgOiAgQk9PTEVBTiAgPSAKICBCRUdJTgogICAgSUYgb2JqZWN0X18ubmV4dF9z >bG90ID0gTklMIFRIRU4KICAgICAgKCogcHVudCB0byBNb2R1bGEtMyBvYmplY3QgdHlwZSBkZWZu >ICopCiAgICAgIFJFVFVSTiBGUy5QdWJsaWNJdGVyYXRvci5uZXh0KG9iamVjdF9fLCBmb3JtYWxf >bmFtZSkKICAgIEVMU0UKICAgICAgKCogbWV0aG9kIG92ZXJyaWRlbiBieSBTY2hlbWUgY29kZSAq >KQogICAgICBWQVIKICAgICAgICBhcmdzX18gOiBTY2hlbWVQYWlyLlQgOj0gTkVXKFNjaGVtZVBh >aXIuVCwgZmlyc3QgOj0gb2JqZWN0X18sIHJlc3QgOj0gTklMKTsKICAgICAgQkVHSU4KICAgICAg >ICBhcmdzX18gOj0gU2NoZW1lVXRpbHMuQ29ucyhTY2hlbWVNb2R1bGEzVHlwZXMuVG9TY2hlbWVf >VEVYVChmb3JtYWxfbmFtZSksYXJnc19fKTsKICAgICAgICBhcmdzX18gOj0gU2NoZW1lVXRpbHMu >UmV2ZXJzZShhcmdzX18pOwogICAgICAgIFJFVFVSTiBTY2hlbWVNb2R1bGEzVHlwZXMuVG9Nb2R1 >bGFfQk9PTEVBTihTY2hlbWVQcm9jZWR1cmVTdHVicy5DYWxsU2NoZW1lKG9iamVjdF9fLmludGVy >cCwgb2JqZWN0X18ubmV4dF9zbG90LCBhcmdzX18pKQogICAgICAgICgqIGFuZCB0aGlzIGlzIHdo >ZXJlIHdlIG5lZWQgdG8gdW5wYWNrIFZBUiBwYXJhbXMgKikKICAgICAgRU5ECiAgICBFTkQKICBF >TkQgRlNfUHVibGljSXRlcmF0b3JfbmV4dF9kZWZhdWx0OwoKUFJPQ0VEVVJFIEZTX1B1YmxpY0l0 >ZXJhdG9yX2Nsb3NlX2RlZmF1bHQob2JqZWN0X18gOiBGU19QdWJsaWNJdGVyYXRvcl9TdXJyb2dh >dGUpID0gCiAgQkVHSU4KICAgIElGIG9iamVjdF9fLmNsb3NlX3Nsb3QgPSBOSUwgVEhFTgogICAg >ICAoKiBwdW50IHRvIE1vZHVsYS0zIG9iamVjdCB0eXBlIGRlZm4gKikKICAgICAgRlMuUHVibGlj >SXRlcmF0b3IuY2xvc2Uob2JqZWN0X18pCiAgICBFTFNFCiAgICAgICgqIG1ldGhvZCBvdmVycmlk >ZW4gYnkgU2NoZW1lIGNvZGUgKikKICAgICAgVkFSCiAgICAgICAgYXJnc19fIDogU2NoZW1lUGFp >ci5UIDo9IE5FVyhTY2hlbWVQYWlyLlQsIGZpcnN0IDo9IG9iamVjdF9fLCByZXN0IDo9IE5JTCk7 >CiAgICAgIEJFR0lOCiAgICAgICAgYXJnc19fIDo9IFNjaGVtZVV0aWxzLlJldmVyc2UoYXJnc19f >KTsKICAgICAgICBFVkFMIChTY2hlbWVQcm9jZWR1cmVTdHVicy5DYWxsU2NoZW1lKG9iamVjdF9f >LmludGVycCwgb2JqZWN0X18uY2xvc2Vfc2xvdCwgYXJnc19fKSkKICAgICAgICAoKiBhbmQgdGhp >cyBpcyB3aGVyZSB3ZSBuZWVkIHRvIHVucGFjayBWQVIgcGFyYW1zICopCiAgICAgIEVORAogICAg >RU5ECiAgRU5EIEZTX1B1YmxpY0l0ZXJhdG9yX2Nsb3NlX2RlZmF1bHQ7CgpQUk9DRURVUkUgRlNf >UHVibGljSXRlcmF0b3JfbmV4dFdpdGhTdGF0dXNfZGVmYXVsdChvYmplY3RfXyA6IEZTX1B1Ymxp >Y0l0ZXJhdG9yX1N1cnJvZ2F0ZTsgVkFSIGZvcm1hbF9uYW1lIDogIFRFWFQgOyBWQVIgZm9ybWFs >X3N0YXQgOiBGaWxlLlN0YXR1cykgOiAgQk9PTEVBTiAgUkFJU0VTIHsgT1NFcnJvci5FIH0gPSAK >ICBCRUdJTgogICAgSUYgb2JqZWN0X18ubmV4dFdpdGhTdGF0dXNfc2xvdCA9IE5JTCBUSEVOCiAg >ICAgICgqIHB1bnQgdG8gTW9kdWxhLTMgb2JqZWN0IHR5cGUgZGVmbiAqKQogICAgICBSRVRVUk4g >RlMuUHVibGljSXRlcmF0b3IubmV4dFdpdGhTdGF0dXMob2JqZWN0X18sIGZvcm1hbF9uYW1lLCBm >b3JtYWxfc3RhdCkKICAgIEVMU0UKICAgICAgKCogbWV0aG9kIG92ZXJyaWRlbiBieSBTY2hlbWUg >Y29kZSAqKQogICAgICBWQVIKICAgICAgICBhcmdzX18gOiBTY2hlbWVQYWlyLlQgOj0gTkVXKFNj >aGVtZVBhaXIuVCwgZmlyc3QgOj0gb2JqZWN0X18sIHJlc3QgOj0gTklMKTsKICAgICAgQkVHSU4K >ICAgICAgICBhcmdzX18gOj0gU2NoZW1lVXRpbHMuQ29ucyhTY2hlbWVNb2R1bGEzVHlwZXMuVG9T >Y2hlbWVfVEVYVChmb3JtYWxfbmFtZSksYXJnc19fKTsKICAgICAgICBhcmdzX18gOj0gU2NoZW1l >VXRpbHMuQ29ucyhUb1NjaGVtZV9GaWxlX1N0YXR1cyhmb3JtYWxfc3RhdCksYXJnc19fKTsKICAg >ICAgICBhcmdzX18gOj0gU2NoZW1lVXRpbHMuUmV2ZXJzZShhcmdzX18pOwogICAgICAgIFJFVFVS >TiBTY2hlbWVNb2R1bGEzVHlwZXMuVG9Nb2R1bGFfQk9PTEVBTihTY2hlbWVQcm9jZWR1cmVTdHVi >cy5DYWxsU2NoZW1lKG9iamVjdF9fLmludGVycCwgb2JqZWN0X18ubmV4dFdpdGhTdGF0dXNfc2xv >dCwgYXJnc19fKSkKICAgICAgICAoKiBhbmQgdGhpcyBpcyB3aGVyZSB3ZSBuZWVkIHRvIHVucGFj >ayBWQVIgcGFyYW1zICopCiAgICAgIEVORAogICAgRU5ECiAgRU5EIEZTX1B1YmxpY0l0ZXJhdG9y >X25leHRXaXRoU3RhdHVzX2RlZmF1bHQ7CgpQUk9DRURVUkUgTWV0aG9kU3R1Yl9GU19QdWJsaWNJ >dGVyYXRvcl9uZXh0KGludGVycCA6IFNjaGVtZS5UOwogICAgICAgICAgICAgICAgICAgICAgYXJn >cyA6IFNjaGVtZU9iamVjdC5UOwogICAgICAgICAgICAgICAgICAgICAgZXhjSGFuZGxlciA6IFNj >aGVtZU9iamVjdC5UKSA6IFNjaGVtZU9iamVjdC5UCiAgUkFJU0VTIHsgU2NoZW1lLkUgfSA9IAog >CiAgUFJPQ0VEVVJFIE5leHQoKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IFNjaGVtZS5FIH0g >PSAKICAgIEJFR0lOCiAgICAgIFRSWSBSRVRVUk4gU2NoZW1lVXRpbHMuRmlyc3QocF9fKSBGSU5B >TExZIHBfXyA6PSBTY2hlbWVQYWlyLlBhaXIoU2NoZW1lVXRpbHMuUmVzdChwX18pKSBFTkQKICAg >IEVORCBOZXh0OwogCiAgVkFSIHBfXyA6PSBTY2hlbWVQYWlyLlBhaXIoYXJncyk7CiAgQkVHSU4K >ICAgIFRSWQogICAgICAoKiB1bnBhY2sgZm9ybWFscyAqKQogICAgICBWQVIgPCpOT1dBUk4qPmp1 >bmtfXyA6PSAwOwogICAgICAgICAgIHRoaXMgOj0gVG9Nb2R1bGFfRlNfUHVibGljSXRlcmF0b3Io >TmV4dCgpKTsKICAgICAgICAgICBmb3JtYWxfbmFtZSA6PSBTY2hlbWVNb2R1bGEzVHlwZXMuVG9N >b2R1bGFfVEVYVChOZXh0KCkpOyBCRUdJTgogICAgICAgICgqIGNhcnJ5IG91dCBOSUwgY2hlY2tz >IGZvciBvcGVuIGFycmF5cyAqKQoKICAgICAgICAoKiBtYWtlIHByb2NlZHVyZSBjYWxsICopCiAg >ICAgICAgV0lUSCByZXMgPSBTY2hlbWVNb2R1bGEzVHlwZXMuVG9TY2hlbWVfQk9PTEVBTih0aGlz >Lm5leHQoZm9ybWFsX25hbWUpKSBETwogICAgICAgICgqIHVucGFjayBWQVIgcGFyYW1zICopCiAg >ICAgICAgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICAgICAgICBFVkFMIE5leHQoKTsK >ICAgICAgICBFVkFMIFNjaGVtZVV0aWxzLlNldEZpcnN0KHBfXyxTY2hlbWVNb2R1bGEzVHlwZXMu >VG9TY2hlbWVfVEVYVChmb3JtYWxfbmFtZSkpOwogICAgICAgIEVWQUwgTmV4dCgpOwoKICAgICAg >ICAoKiByZXR1cm4gcHJvY2VkdXJlIHJlc3VsdCAqKQogICAgICAgIFJFVFVSTiByZXMKICAgICAg >ICBFTkQKICAgICAgRU5EKCpXSVRIKikKICAgIEVYQ0VQVAogICAgRU5EOwogICAgPCpOT1dBUk4q >PlJFVFVSTiBTY2hlbWVCb29sZWFuLkZhbHNlKCkKICBFTkQgTWV0aG9kU3R1Yl9GU19QdWJsaWNJ >dGVyYXRvcl9uZXh0OwpQUk9DRURVUkUgTWV0aG9kU3R1Yl9GU19QdWJsaWNJdGVyYXRvcl9jbG9z >ZShpbnRlcnAgOiBTY2hlbWUuVDsKICAgICAgICAgICAgICAgICAgICAgIGFyZ3MgOiBTY2hlbWVP >YmplY3QuVDsKICAgICAgICAgICAgICAgICAgICAgIGV4Y0hhbmRsZXIgOiBTY2hlbWVPYmplY3Qu >VCkgOiBTY2hlbWVPYmplY3QuVAogIFJBSVNFUyB7IFNjaGVtZS5FIH0gPSAKIAogIFBST0NFRFVS >RSBOZXh0KCkgOiBTY2hlbWVPYmplY3QuVCBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAgICBCRUdJ >TgogICAgICBUUlkgUkVUVVJOIFNjaGVtZVV0aWxzLkZpcnN0KHBfXykgRklOQUxMWSBwX18gOj0g >U2NoZW1lUGFpci5QYWlyKFNjaGVtZVV0aWxzLlJlc3QocF9fKSkgRU5ECiAgICBFTkQgTmV4dDsK >IAogIFZBUiBwX18gOj0gU2NoZW1lUGFpci5QYWlyKGFyZ3MpOwogIEJFR0lOCiAgICBUUlkKICAg >ICAgKCogdW5wYWNrIGZvcm1hbHMgKikKICAgICAgVkFSIDwqTk9XQVJOKj5qdW5rX18gOj0gMDsK >ICAgICAgICAgICB0aGlzIDo9IFRvTW9kdWxhX0ZTX1B1YmxpY0l0ZXJhdG9yKE5leHQoKSk7IEJF >R0lOCiAgICAgICAgKCogY2Fycnkgb3V0IE5JTCBjaGVja3MgZm9yIG9wZW4gYXJyYXlzICopCgog >ICAgICAgICgqIG1ha2UgcHJvY2VkdXJlIGNhbGwgKikKICAgICAgICB0aGlzLmNsb3NlKCk7CiAg >ICAgICAgKCogdW5wYWNrIFZBUiBwYXJhbXMgKikKICAgICAgICBwX18gOj0gU2NoZW1lUGFpci5Q >YWlyKGFyZ3MpOwogICAgICAgIEVWQUwgTmV4dCgpOwoKICAgICAgICAoKiBwcm9wZXIgcHJvY2Vk >dXJlIDogcmV0dXJuIFRSVUUgKikKICAgICAgICBSRVRVUk4gU2NoZW1lQm9vbGVhbi5UcnVlKCkK >ICAgICAgRU5EKCpXSVRIKikKICAgIEVYQ0VQVAogICAgRU5EOwogICAgPCpOT1dBUk4qPlJFVFVS >TiBTY2hlbWVCb29sZWFuLkZhbHNlKCkKICBFTkQgTWV0aG9kU3R1Yl9GU19QdWJsaWNJdGVyYXRv >cl9jbG9zZTsKUFJPQ0VEVVJFIE1ldGhvZFN0dWJfRlNfUHVibGljSXRlcmF0b3JfbmV4dFdpdGhT >dGF0dXMoaW50ZXJwIDogU2NoZW1lLlQ7CiAgICAgICAgICAgICAgICAgICAgICBhcmdzIDogU2No >ZW1lT2JqZWN0LlQ7CiAgICAgICAgICAgICAgICAgICAgICBleGNIYW5kbGVyIDogU2NoZW1lT2Jq >ZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQKICBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAKICBQUk9D >RURVUkUgTmV4dCgpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUgfSA9IAogICAg >QkVHSU4KICAgICAgVFJZIFJFVFVSTiBTY2hlbWVVdGlscy5GaXJzdChwX18pIEZJTkFMTFkgcF9f >IDo9IFNjaGVtZVBhaXIuUGFpcihTY2hlbWVVdGlscy5SZXN0KHBfXykpIEVORAogICAgRU5EIE5l >eHQ7CiAKICBWQVIgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICBCRUdJTgogICAgVFJZ >CiAgICAgICgqIHVucGFjayBmb3JtYWxzICopCiAgICAgIFZBUiA8Kk5PV0FSTio+anVua19fIDo9 >IDA7CiAgICAgICAgICAgdGhpcyA6PSBUb01vZHVsYV9GU19QdWJsaWNJdGVyYXRvcihOZXh0KCkp >OwogICAgICAgICAgIGZvcm1hbF9uYW1lIDo9IFNjaGVtZU1vZHVsYTNUeXBlcy5Ub01vZHVsYV9U >RVhUKE5leHQoKSk7CiAgICAgICAgICAgZm9ybWFsX3N0YXQgOj0gVG9Nb2R1bGFfRmlsZV9TdGF0 >dXMoTmV4dCgpKTsgQkVHSU4KICAgICAgICAoKiBjYXJyeSBvdXQgTklMIGNoZWNrcyBmb3Igb3Bl >biBhcnJheXMgKikKCiAgICAgICAgKCogbWFrZSBwcm9jZWR1cmUgY2FsbCAqKQogICAgICAgIFdJ >VEggcmVzID0gU2NoZW1lTW9kdWxhM1R5cGVzLlRvU2NoZW1lX0JPT0xFQU4odGhpcy5uZXh0V2l0 >aFN0YXR1cyhmb3JtYWxfbmFtZSwgZm9ybWFsX3N0YXQpKSBETwogICAgICAgICgqIHVucGFjayBW >QVIgcGFyYW1zICopCiAgICAgICAgcF9fIDo9IFNjaGVtZVBhaXIuUGFpcihhcmdzKTsKICAgICAg >ICBFVkFMIE5leHQoKTsKICAgICAgICBFVkFMIFNjaGVtZVV0aWxzLlNldEZpcnN0KHBfXyxTY2hl >bWVNb2R1bGEzVHlwZXMuVG9TY2hlbWVfVEVYVChmb3JtYWxfbmFtZSkpOwogICAgICAgIEVWQUwg >TmV4dCgpOwogICAgICAgIEVWQUwgU2NoZW1lVXRpbHMuU2V0Rmlyc3QocF9fLFRvU2NoZW1lX0Zp >bGVfU3RhdHVzKGZvcm1hbF9zdGF0KSk7CiAgICAgICAgRVZBTCBOZXh0KCk7CgogICAgICAgICgq >IHJldHVybiBwcm9jZWR1cmUgcmVzdWx0ICopCiAgICAgICAgUkVUVVJOIHJlcwogICAgICAgIEVO >RAogICAgICBFTkQoKldJVEgqKQogICAgRVhDRVBUCiAgICAgIHwgT1NFcnJvci5FKHhhcmcpID0+ >IEVWQUwgU2NoZW1lQXBwbHkuT25lQXJnKGludGVycCxleGNIYW5kbGVyLFNjaGVtZVV0aWxzLkxp >c3QyKFNjaGVtZVN5bWJvbC5Gcm9tVGV4dCgicXVvdGUiKSxTY2hlbWVVdGlscy5Db25zKFNjaGVt >ZVN5bWJvbC5Gcm9tVGV4dCgiT1NFcnJvci5FIiksIFRvU2NoZW1lX0F0b21MaXN0X1QoeGFyZykp >KSkKICAgIEVORDsKICAgIDwqTk9XQVJOKj5SRVRVUk4gU2NoZW1lQm9vbGVhbi5GYWxzZSgpCiAg >RU5EIE1ldGhvZFN0dWJfRlNfUHVibGljSXRlcmF0b3JfbmV4dFdpdGhTdGF0dXM7CgpQUk9DRURV >UkUgRmllbGRHZXRfRlNfSXRlcmF0b3IoaW50ZXJwIDogU2NoZW1lLlQ7IG9iaiA6IFNjaGVtZU9i >amVjdC5UOyBhcmdzIDogU2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsg >U2NoZW1lLkUgfSA9CiAgVkFSCiAgICBmaWVsZCAgIDo9IFNjaGVtZVV0aWxzLkZpcnN0KGFyZ3Mp >OwogICAgbmFycm93IDogRlMuSXRlcmF0b3I7CiAgQkVHSU4KICAgIElGIE5PVCBJU1RZUEUob2Jq >LEZTLkl0ZXJhdG9yKSBPUiBvYmo9TklMIFRIRU4KICAgICAgUkFJU0UgU2NoZW1lLkUoIk5vdCBv >ZiB0eXBlIEZTLkl0ZXJhdG9yIDogIiAmIFNjaGVtZVV0aWxzLlN0cmluZ2lmeShvYmopKQogICAg >RU5EOwogICAgbmFycm93IDo9IE5BUlJPVyhvYmosRlMuSXRlcmF0b3IpOwogICAgSUYgRkFMU0Ug >VEhFTiA8KkFTU0VSVCBGQUxTRSo+CiAgICBFTFNFIFJBSVNFIFNjaGVtZS5FKCJVbmtub3duIGZp >ZWxkICIgJiBTY2hlbWVVdGlscy5TdHJpbmdpZnkoZmllbGQpKQogICAgRU5ECiAgRU5EIEZpZWxk >R2V0X0ZTX0l0ZXJhdG9yOwoKUFJPQ0VEVVJFIEZpZWxkU2V0X0ZTX0l0ZXJhdG9yKGludGVycCA6 >IFNjaGVtZS5UOyBvYmogOiBTY2hlbWVPYmplY3QuVDsgYXJncyA6IFNjaGVtZU9iamVjdC5UKSA6 >IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IFNjaGVtZS5FIH0gPQogIFZBUgogICAgZmllbGQgICA6 >PSBTY2hlbWVVdGlscy5GaXJzdChhcmdzKTsKICAgIHZhbHVlICAgOj0gU2NoZW1lVXRpbHMuRmly >c3QoU2NoZW1lVXRpbHMuUmVzdChhcmdzKSk7CiAgICBuYXJyb3cgOiBGUy5JdGVyYXRvcjsKICAg >IHJlcyA6IFNjaGVtZU9iamVjdC5UOwogIEJFR0lOCiAgICBJRiBOT1QgSVNUWVBFKG9iaixGUy5J >dGVyYXRvcikgT1Igb2JqPU5JTCBUSEVOCiAgICAgIFJBSVNFIFNjaGVtZS5FKCJOb3Qgb2YgdHlw >ZSBGUy5JdGVyYXRvciA6ICIgJiBTY2hlbWVVdGlscy5TdHJpbmdpZnkob2JqKSkKICAgIEVORDsK >ICAgIG5hcnJvdyA6PSBOQVJST1cob2JqLEZTLkl0ZXJhdG9yKTsKICAgIElGIEZBTFNFIFRIRU4g >PCpBU1NFUlQgRkFMU0UqPgogICAgRUxTRSBSQUlTRSBTY2hlbWUuRSgiVW5rbm93biBmaWVsZCAi >ICYgU2NoZW1lVXRpbHMuU3RyaW5naWZ5KGZpZWxkKSkKICAgIEVORDsKICAgIFJFVFVSTiByZXMK >ICBFTkQgRmllbGRTZXRfRlNfSXRlcmF0b3I7CgpQUk9DRURVUkUgRmllbGRHZXRfRlNfUHVibGlj >SXRlcmF0b3IoaW50ZXJwIDogU2NoZW1lLlQ7IG9iaiA6IFNjaGVtZU9iamVjdC5UOyBhcmdzIDog >U2NoZW1lT2JqZWN0LlQpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2NoZW1lLkUgfSA9CiAg >VkFSCiAgICBmaWVsZCAgIDo9IFNjaGVtZVV0aWxzLkZpcnN0KGFyZ3MpOwogICAgbmFycm93IDog >RlMuUHVibGljSXRlcmF0b3I7CiAgQkVHSU4KICAgIElGIE5PVCBJU1RZUEUob2JqLEZTLlB1Ymxp >Y0l0ZXJhdG9yKSBPUiBvYmo9TklMIFRIRU4KICAgICAgUkFJU0UgU2NoZW1lLkUoIk5vdCBvZiB0 >eXBlIEZTLlB1YmxpY0l0ZXJhdG9yIDogIiAmIFNjaGVtZVV0aWxzLlN0cmluZ2lmeShvYmopKQog >ICAgRU5EOwogICAgbmFycm93IDo9IE5BUlJPVyhvYmosRlMuUHVibGljSXRlcmF0b3IpOwogICAg >SUYgRkFMU0UgVEhFTiA8KkFTU0VSVCBGQUxTRSo+CiAgICBFTFNFIFJBSVNFIFNjaGVtZS5FKCJV >bmtub3duIGZpZWxkICIgJiBTY2hlbWVVdGlscy5TdHJpbmdpZnkoZmllbGQpKQogICAgRU5ECiAg >RU5EIEZpZWxkR2V0X0ZTX1B1YmxpY0l0ZXJhdG9yOwoKUFJPQ0VEVVJFIEZpZWxkU2V0X0ZTX1B1 >YmxpY0l0ZXJhdG9yKGludGVycCA6IFNjaGVtZS5UOyBvYmogOiBTY2hlbWVPYmplY3QuVDsgYXJn >cyA6IFNjaGVtZU9iamVjdC5UKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IFNjaGVtZS5FIH0g >PQogIFZBUgogICAgZmllbGQgICA6PSBTY2hlbWVVdGlscy5GaXJzdChhcmdzKTsKICAgIHZhbHVl >ICAgOj0gU2NoZW1lVXRpbHMuRmlyc3QoU2NoZW1lVXRpbHMuUmVzdChhcmdzKSk7CiAgICBuYXJy >b3cgOiBGUy5QdWJsaWNJdGVyYXRvcjsKICAgIHJlcyA6IFNjaGVtZU9iamVjdC5UOwogIEJFR0lO >CiAgICBJRiBOT1QgSVNUWVBFKG9iaixGUy5QdWJsaWNJdGVyYXRvcikgT1Igb2JqPU5JTCBUSEVO >CiAgICAgIFJBSVNFIFNjaGVtZS5FKCJOb3Qgb2YgdHlwZSBGUy5QdWJsaWNJdGVyYXRvciA6ICIg >JiBTY2hlbWVVdGlscy5TdHJpbmdpZnkob2JqKSkKICAgIEVORDsKICAgIG5hcnJvdyA6PSBOQVJS >T1cob2JqLEZTLlB1YmxpY0l0ZXJhdG9yKTsKICAgIElGIEZBTFNFIFRIRU4gPCpBU1NFUlQgRkFM >U0UqPgogICAgRUxTRSBSQUlTRSBTY2hlbWUuRSgiVW5rbm93biBmaWVsZCAiICYgU2NoZW1lVXRp >bHMuU3RyaW5naWZ5KGZpZWxkKSkKICAgIEVORDsKICAgIFJFVFVSTiByZXMKICBFTkQgRmllbGRT >ZXRfRlNfUHVibGljSXRlcmF0b3I7CgoKCgoKClBST0NFRFVSRSBUb1NjaGVtZV9BdG9tTGlzdF9U >KFJFQURPTkxZIHggOiBBdG9tTGlzdC5UKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IH0gPSAK >ICBCRUdJTgogICAgUkVUVVJOIHgKICBFTkQgVG9TY2hlbWVfQXRvbUxpc3RfVDsKCgpQUk9DRURV >UkUgVG9TY2hlbWVfRlNfSXRlcmF0b3IoUkVBRE9OTFkgeCA6IEZTLkl0ZXJhdG9yKSA6IFNjaGVt >ZU9iamVjdC5UIFJBSVNFUyB7IH0gPSAKICBCRUdJTgogICAgUkVUVVJOIHgKICBFTkQgVG9TY2hl >bWVfRlNfSXRlcmF0b3I7CgoKUFJPQ0VEVVJFIFRvU2NoZW1lX0ZpbGVfVChSRUFET05MWSB4IDog >RmlsZS5UKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IH0gPSAKICBCRUdJTgogICAgUkVUVVJO >IHgKICBFTkQgVG9TY2hlbWVfRmlsZV9UOwoKClBST0NFRFVSRSBUb1NjaGVtZV9GaWxlX1N0YXR1 >cyhSRUFET05MWSB4IDogRmlsZS5TdGF0dXMpIDogU2NoZW1lT2JqZWN0LlQgUkFJU0VTIHsgU2No >ZW1lLkUgfSA9IAogIEJFR0lOCiAgICBWQVIgcmVzIDogU2NoZW1lUGFpci5UOj1OSUw7IEJFR0lO >CiAgICAgIHJlcyA6PSBTY2hlbWVVdGlscy5Db25zKFNjaGVtZVV0aWxzLkNvbnMoU2NoZW1lU3lt >Ym9sLkZyb21UZXh0KCJ0eXBlIiksVG9TY2hlbWVfQXRvbV9UKHgudHlwZSkpLHJlcyk7CiAgICAg >IHJlcyA6PSBTY2hlbWVVdGlscy5Db25zKFNjaGVtZVV0aWxzLkNvbnMoU2NoZW1lU3ltYm9sLkZy >b21UZXh0KCJtb2RpZmljYXRpb25UaW1lIiksU2NoZW1lTW9kdWxhM1R5cGVzLlRvU2NoZW1lX0xP >TkdSRUFMKHgubW9kaWZpY2F0aW9uVGltZSkpLHJlcyk7CiAgICAgIHJlcyA6PSBTY2hlbWVVdGls >cy5Db25zKFNjaGVtZVV0aWxzLkNvbnMoU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJzaXplIiksVG9T >Y2hlbWVfVkFMMExPTkdJTlRfX1ZBTDEwNzM3NDUxMTJMT05HSU5UKHguc2l6ZSkpLHJlcyk7CiAg >ICAgIFJFVFVSTiByZXMKICAgIEVORAogIEVORCBUb1NjaGVtZV9GaWxlX1N0YXR1czsKCgpQUk9D >RURVUkUgVG9Nb2R1bGFfRlNfQ3JlYXRlT3B0aW9uKHggOiBTY2hlbWVPYmplY3QuVCkgOiAoRlMu >Q3JlYXRlT3B0aW9uKSBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAgQkVHSU4KQ09OU1QKICAgICAg >TmFtZSA9IEFSUkFZIEZTLkNyZWF0ZU9wdGlvbiBPRiBURVhUIHsgIk5ldmVyIiwgIk9rIiwgIkFs >d2F5cyIgfTsgCiAgICBCRUdJTgogICAgICBGT1IgaSA6PSBGSVJTVChOYW1lKSBUTyBMQVNUKE5h >bWUpIERPCiAgICAgICAgSUYgU2NoZW1lU3ltYm9sLkZyb21UZXh0KE5hbWVbaV0pID0geCBUSEVO >CiAgICAgICAgICBSRVRVUk4gaQogICAgICAgIEVORAogICAgICBFTkQ7CiAgICAgIFJBSVNFIFNj >aGVtZS5FKCJOb3QgYSB2YWx1ZSBvZiBGUy5DcmVhdGVPcHRpb24gOiAiICYgU2NoZW1lVXRpbHMu >U3RyaW5naWZ5KHgpKQogICAgRU5ECiAgRU5EIFRvTW9kdWxhX0ZTX0NyZWF0ZU9wdGlvbjsKCgpQ >Uk9DRURVUkUgVG9Nb2R1bGFfRlNfQWNjZXNzT3B0aW9uKHggOiBTY2hlbWVPYmplY3QuVCkgOiAo >RlMuQWNjZXNzT3B0aW9uKSBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAgQkVHSU4KQ09OU1QKICAg >ICAgTmFtZSA9IEFSUkFZIEZTLkFjY2Vzc09wdGlvbiBPRiBURVhUIHsgIk9ubHlPd25lckNhblJl >YWQiLCAiUmVhZE9ubHkiLCAiRGVmYXVsdCIgfTsgCiAgICBCRUdJTgogICAgICBGT1IgaSA6PSBG >SVJTVChOYW1lKSBUTyBMQVNUKE5hbWUpIERPCiAgICAgICAgSUYgU2NoZW1lU3ltYm9sLkZyb21U >ZXh0KE5hbWVbaV0pID0geCBUSEVOCiAgICAgICAgICBSRVRVUk4gaQogICAgICAgIEVORAogICAg >ICBFTkQ7CiAgICAgIFJBSVNFIFNjaGVtZS5FKCJOb3QgYSB2YWx1ZSBvZiBGUy5BY2Nlc3NPcHRp >b24gOiAiICYgU2NoZW1lVXRpbHMuU3RyaW5naWZ5KHgpKQogICAgRU5ECiAgRU5EIFRvTW9kdWxh >X0ZTX0FjY2Vzc09wdGlvbjsKCgpQUk9DRURVUkUgVG9Nb2R1bGFfRmlsZV9UKHggOiBTY2hlbWVP >YmplY3QuVCkgOiAoRmlsZS5UKSBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAgQkVHSU4KICAgIElG >IE5PVCBJU1RZUEUoeCxGaWxlLlQpIFRIRU4KICAgICAgUkFJU0UgU2NoZW1lLkUoIk5vdCBvZiB0 >eXBlIEZpbGUuVCA6ICIgJiBTY2hlbWVVdGlscy5TdHJpbmdpZnkoeCkpCiAgICBFTkQ7CiAgICBS >RVRVUk4geAogIEVORCBUb01vZHVsYV9GaWxlX1Q7CgoKUFJPQ0VEVVJFIFRvU2NoZW1lX1ZBTDBM >T05HSU5UX19WQUwxMDczNzQ1MTEyTE9OR0lOVChSRUFET05MWSB4IDogWyBWQUwoMCwgTE9OR0lO >VCApLi5WQUwoLTEwNzM3NDUxMTIsIExPTkdJTlQgKSBdKSA6IFNjaGVtZU9iamVjdC5UIFJBSVNF >UyB7IFNjaGVtZS5FIH0gPSAKICBCRUdJTgogICAgUkVUVVJOIFRvU2NoZW1lX0xPTkdJTlQoeCkK >ICBFTkQgVG9TY2hlbWVfVkFMMExPTkdJTlRfX1ZBTDEwNzM3NDUxMTJMT05HSU5UOwoKClBST0NF >RFVSRSBUb1NjaGVtZV9BdG9tX1QoUkVBRE9OTFkgeCA6IEF0b20uVCkgOiBTY2hlbWVPYmplY3Qu >VCBSQUlTRVMgeyB9ID0gCiAgQkVHSU4KICAgIFJFVFVSTiB4CiAgRU5EIFRvU2NoZW1lX0F0b21f >VDsKCgpQUk9DRURVUkUgVG9TY2hlbWVfTE9OR0lOVChSRUFET05MWSB4IDogIExPTkdJTlQgKSA6 >IFNjaGVtZU9iamVjdC5UIFJBSVNFUyB7IFNjaGVtZS5FIH0gPSAKICBCRUdJTgogICAgV0lUSCBy >ZWYgPSBORVcoUkVGIExPTkdJTlQpIERPCiAgICAgIHJlZl4gOj0geDsKICAgICAgUkVUVVJOIFNj >aGVtZU1vZHVsYTNUeXBlcy5Ub1NjaGVtZV9MT05HSU5UKHJlZikKICAgIEVORAogIEVORCBUb1Nj >aGVtZV9MT05HSU5UOwoKUFJPQ0VEVVJFIFRvTW9kdWxhX0ZTX1B1YmxpY0l0ZXJhdG9yKHggOiBT >Y2hlbWVPYmplY3QuVCkgOiAoRlMuUHVibGljSXRlcmF0b3IpIFJBSVNFUyB7IFNjaGVtZS5FIH0g >PSAKICBCRUdJTgogICAgSUYgTk9UIElTVFlQRSh4LEZTLlB1YmxpY0l0ZXJhdG9yKSBUSEVOCiAg >ICAgIFJBSVNFIFNjaGVtZS5FKCJOb3Qgb2YgdHlwZSBGUy5QdWJsaWNJdGVyYXRvciA6ICIgJiBT >Y2hlbWVVdGlscy5TdHJpbmdpZnkoeCkpCiAgICBFTkQ7CiAgICBSRVRVUk4geAogIEVORCBUb01v >ZHVsYV9GU19QdWJsaWNJdGVyYXRvcjsKCgpQUk9DRURVUkUgVG9Nb2R1bGFfRlNfSXRlcmF0b3Io >eCA6IFNjaGVtZU9iamVjdC5UKSA6IChGUy5JdGVyYXRvcikgUkFJU0VTIHsgU2NoZW1lLkUgfSA9 >IAogIEJFR0lOCiAgICBJRiBOT1QgSVNUWVBFKHgsRlMuSXRlcmF0b3IpIFRIRU4KICAgICAgUkFJ >U0UgU2NoZW1lLkUoIk5vdCBvZiB0eXBlIEZTLkl0ZXJhdG9yIDogIiAmIFNjaGVtZVV0aWxzLlN0 >cmluZ2lmeSh4KSkKICAgIEVORDsKICAgIFJFVFVSTiB4CiAgRU5EIFRvTW9kdWxhX0ZTX0l0ZXJh >dG9yOwoKClBST0NFRFVSRSBUb01vZHVsYV9GaWxlX1N0YXR1cyh4IDogU2NoZW1lT2JqZWN0LlQp >IDogKEZpbGUuU3RhdHVzKSBSQUlTRVMgeyBTY2hlbWUuRSB9ID0gCiAgQkVHSU4KICAgIFZBUiBy >ZXMgOiBGaWxlLlN0YXR1czsKICAgICAgICBwIDo9IFNjaGVtZVBhaXIuUGFpcih4KTsKICAgIEJF >R0lOCiAgICAgIFdISUxFIHAgIyBOSUwgRE8KICAgICAgICBJRiBGQUxTRSBUSEVOCiAgICAgICAg >RUxTSUYgU2NoZW1lU3ltYm9sLkZyb21UZXh0KCJ0eXBlIikgPSBTY2hlbWVVdGlscy5GaXJzdChw >LmZpcnN0KSBUSEVOCiAgICAgICAgICByZXMudHlwZSA6PSBUb01vZHVsYV9BdG9tX1QoU2NoZW1l >VXRpbHMuUmVzdChwLmZpcnN0KSkKICAgICAgICBFTFNJRiBTY2hlbWVTeW1ib2wuRnJvbVRleHQo >Im1vZGlmaWNhdGlvblRpbWUiKSA9IFNjaGVtZVV0aWxzLkZpcnN0KHAuZmlyc3QpIFRIRU4KICAg >ICAgICAgIHJlcy5tb2RpZmljYXRpb25UaW1lIDo9IFNjaGVtZU1vZHVsYTNUeXBlcy5Ub01vZHVs >YV9MT05HUkVBTChTY2hlbWVVdGlscy5SZXN0KHAuZmlyc3QpKQogICAgICAgIEVMU0lGIFNjaGVt >ZVN5bWJvbC5Gcm9tVGV4dCgic2l6ZSIpID0gU2NoZW1lVXRpbHMuRmlyc3QocC5maXJzdCkgVEhF >TgogICAgICAgICAgcmVzLnNpemUgOj0gVG9Nb2R1bGFfVkFMMExPTkdJTlRfX1ZBTDEwNzM3NDUz >MzZMT05HSU5UKFNjaGVtZVV0aWxzLlJlc3QocC5maXJzdCkpCiAgICAgICAgRU5EOwogICAgICAg >IHAgOj0gU2NoZW1lUGFpci5QYWlyKHAucmVzdCkKICAgICAgRU5EOwogICAgICBSRVRVUk4gcmVz >CiAgICBFTkQKICBFTkQgVG9Nb2R1bGFfRmlsZV9TdGF0dXM7CgoKUFJPQ0VEVVJFIFRvTW9kdWxh >X1ZBTDBMT05HSU5UX19WQUwxMDczNzQ1MzM2TE9OR0lOVCh4IDogU2NoZW1lT2JqZWN0LlQpIDog >KFsgVkFMKDAsIExPTkdJTlQgKS4uVkFMKC0xMDczNzQ1MzM2LCBMT05HSU5UICkgXSkgUkFJU0VT >IHsgU2NoZW1lLkUgfSA9IAogIEJFR0lOCiAgICBXSVRIIGJhc2VWYWwgPSBUb01vZHVsYV9MT05H >SU5UKHgpIERPCiAgICAgIElGIGJhc2VWYWwgPCBGSVJTVChbIFZBTCgwLCBMT05HSU5UICkuLlZB >TCgtMTA3Mzc0NTMzNiwgTE9OR0lOVCApIF0pIE9SIGJhc2VWYWwgPiBMQVNUKFsgVkFMKDAsIExP >TkdJTlQgKS4uVkFMKC0xMDczNzQ1MzM2LCBMT05HSU5UICkgXSkgVEhFTgogICAgICAgIFJBSVNF >IFNjaGVtZS5FKCJWYWx1ZSBvdXQgb2YgcmFuZ2UgZm9yIFsgVkFMKDAsIExPTkdJTlQgKS4uVkFM >KC0xMDczNzQ1MzM2LCBMT05HSU5UICkgXSA6IiAmIFNjaGVtZVV0aWxzLlN0cmluZ2lmeSh4KSkK >ICAgICAgRU5EOwogICAgICBSRVRVUk4gYmFzZVZhbAogICAgRU5ECiAgRU5EIFRvTW9kdWxhX1ZB >TDBMT05HSU5UX19WQUwxMDczNzQ1MzM2TE9OR0lOVDsKCgpQUk9DRURVUkUgVG9Nb2R1bGFfQXRv >bV9UKHggOiBTY2hlbWVPYmplY3QuVCkgOiAoQXRvbS5UKSBSQUlTRVMgeyBTY2hlbWUuRSB9ID0g >CiAgQkVHSU4KICAgIElGIE5PVCBJU1RZUEUoeCxBdG9tLlQpIFRIRU4KICAgICAgUkFJU0UgU2No >ZW1lLkUoIk5vdCBvZiB0eXBlIEF0b20uVCA6ICIgJiBTY2hlbWVVdGlscy5TdHJpbmdpZnkoeCkp >CiAgICBFTkQ7CiAgICBSRVRVUk4geAogIEVORCBUb01vZHVsYV9BdG9tX1Q7CgoKUFJPQ0VEVVJF >IFRvTW9kdWxhX0xPTkdJTlQoeCA6IFNjaGVtZU9iamVjdC5UKSA6ICBMT05HSU5UICBSQUlTRVMg >eyBTY2hlbWUuRSB9ID0gCiAgQkVHSU4KICAgIFdJVEggcmVmID0gU2NoZW1lTW9kdWxhM1R5cGVz >LlRvTW9kdWxhX0xPTkdJTlQoeCkgRE8KICAgICAgUkVUVVJOIE5BUlJPVyhyZWYsIFJFRiBMT05H >SU5UKV4KICAgIEVORAogIEVORCBUb01vZHVsYV9MT05HSU5UOwoKQkVHSU4gRU5EIEZTU2NoZW1l >U3R1YnMuCg== > >--_2d6969dc-a0fa-42e3-85e1-71600a2e9b7d_-- From hosking at cs.purdue.edu Fri Dec 31 23:01:27 2010 From: hosking at cs.purdue.edu (Tony Hosking) Date: Fri, 31 Dec 2010 17:01:27 -0500 Subject: [M3devel] CM3 status In-Reply-To: References: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com> Message-ID: <9EF449E4-72AB-4461-AC0C-1B0A79341E44@cs.purdue.edu> I didn't OK dropping SPARC stack walking, just agreeing that we should move all platforms to gcc-supported stack walking. On Dec 30, 2010, at 7:01 AM, Jay K wrote: > Tony ok'ed this for Solaris/sparc32 a few months ago. I couldn't get it working with gcc 4.5, not even without optimization. > That was the last step in moving off of gcc 4.3 backend. I wasn't real happy about dropping stack walking for Solaris. It should not be difficult to retain. I thought you were going to try to fix m3cg 4.5 to handle it. My preference would be to retain the stack walking code on Solaris/SPARC (since it is so easy to do...) modulo making sure that m3cg 4.5 could cope with it. > Alpha/OSF also doesn't work. I didn't look much into it, and I really don't think it matters. > It is an extremely little used platform. This year I saw it work on 4.0 and 5.1 but otherwise > it had been unused for several years I believe, and I don't see its use continuing much. Last time I ran M3 on Alpha/OSF it did work. > Upgrade of Solaris/sparc32 from gcc 4.3 to 4.5: > > 2010-10-13 11:18 jkrell > > * m3-sys/cminstall/src/config-no-install/SPARC32_SOLARIS.common, > m3-sys/m3cc/gcc/gcc/m3cg/parse.c, m3-sys/m3cc/src/clean_marker.txt, > m3-sys/m3cc/src/m3makefile, m3-libs/m3core/src/runtime/m3makefile, > m3-sys/m3middle/src/Target.m3, > m3-libs/m3core/src/runtime/SOLgnu/m3makefile, > m3-libs/m3core/src/runtime/SOLgnu/m3makefile-old, > m3-libs/m3core/src/runtime/SOLsun/m3makefile, > m3-libs/m3core/src/runtime/SOLsun/m3makefile-old: > > disable Solaris/sparc32 stack walker > switch Solaris/sparc32 to gcc 4.5 backend > function.c: make failure to volatilize when setjmp/vfork present an error > instead of a warning > add missing volatilization > pin Solaris/sparc32 at -O1 in the config file as -O2/-O3 were > seen to hit internal compiler errors (assertion failures) > remove the "all volatile" paths from parse.c (since they > were only for Solaris/sparc32's stack walker) > > > Tony ok'ing (in my interpretation) the abandonment of our stack walker: > > https://mail.elegosoft.com/pipermail/m3devel/2010-October/008019.html > > > At least that was my interpretation. > Using gcc's exception handling support and *its* stack walker (libgcc/libunwind) > should provide the better and more portable functionality on many platforms. > I'm not certain what'd it look like on systems where gcc isn't the usual C compiler (e.g. Solaris) > but it's bound to work well on Linux, NetBSD, FreeBSD, OpenBSD, and Solaris using gcc. > "more portable" as in, across all architectures. > > > Perhaps I should have stuck back with 4.3 until implementing this however. > > > It is definitely a step backward to not have the stack walker on Solaris/sparc32, > but that is the only platform in years that has had one, and it is not terrible > to have every platform on gcc 4.5.2 and not sprinkling volatile around. > There are some backward steps but definitely a lot forward. > I tried using 5.4.0 tonight and I didn't get far. > > > > o possibly unsafe OS calls in new C code (this may be a wrong deduction > > from my side) > > > I don't know what this is referring to. > The Enable/DisableScheduling? I all but undid that. > It should be in a few functions, e.g. malloc/free/realloc/calloc/opendir/readdir/closedir/fopen/fclose. > Some of those it already is in. With OpenBSD moving to pthreads it matters less. > It only matters for user threads. > > > > o GUI input not working for BadBricks and other games (only on Darwin?) > > > Yes this is still a problem, and occurs in 5.8.6 release, on Darwin local X Server. > Doesn't reproduce when remoted to Cygwin/X. Other X apps do work locally. > Not understood. > It'd be good to get confirmation if/when they ever worked. > > > > o no clean way for exception handling with current gcc > > > This is how things have *always* been, *except* on Alpha/OSF and Solaris/sparc32. > Those two platforms have "regressed", but for Solaris/sparc32 it was discussed and > Alpha/OSF I really don't think is important. > > > Exception handling has always been very inefficient on all but approx. those two platforms. > It has always been desirable to fix. > > The inefficiency has a few parts. Mainly that "try" costs pthread_getspecific and setjmp. > The inefficiency of the actual throw/catch is not as worrisome. > > > > o still alignment issues > > > Details? > > > > I'm concerned that things get tried out, don't work properly for all > > our target platforms, but are left then and not cleaned up and something > > else gets tried. I'm not sure this is correct, it is just me feeling > > unwell after reading all those mails. > > > Not really. > > > > > Hudson and Tinderbox status seem to be mostly OK though, but I haven't > > checked in detail (FreeBSD failing was a disk failure on my system > > recently). But the tests don't cover all the things we should check. > > > Yep I try to remember to check Hudson fairly regularly. > I never look at Tinderbox though. > > > > I think it would be good to have an overview of the projects/work that > > is in progress or pending and its status. For example, we've imported > > a new gcc version, but that doesn't seem to work well on all targets, > > or does it? If not, how are we going to address this? Use older versions > > on some platforms? Can I read up on that somewhere? > > All platforms (except NT386) use gcc 4.5.2 for the backend. > (I did the upgrade after the release was made but before it was announced; > they delay announcement while it propagates to mirrors.) > > > Ok, also ARM_DARWIN hypothetically uses 4.2. > Apple forks gcc fairly aggressively. > Perhaps we should merge the two forks. Perhaps. > ARM_DARWIN isn't really supported currently. Probably that should be worked on. > It'd also be interesting to see what Apple did to 4.2 for ppc/x86... > > > > I'd like to suggest to simply use our Trac WiKi to document the ongoing > > > Agreed but I'm lazy. > I just throw "bombs" around.. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From hendrik at topoi.pooq.com Fri Dec 31 23:26:50 2010 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Fri, 31 Dec 2010 17:26:50 -0500 Subject: [M3devel] emac Message-ID: <20101231222650.GB2428@topoi.pooq.com> I may be acquiring an emac, which is a small (but heavy -- 50 pounds) power-PC-based Apple Mac, if I've been informed correctly, running a somewhat obsolete OS. If I end up with it, would there be anything I can usefully test on it that's not being adequately tested already? -- hendrik From jay.krell at cornell.edu Fri Dec 31 23:47:02 2010 From: jay.krell at cornell.edu (Jay K) Date: Fri, 31 Dec 2010 22:47:02 +0000 Subject: [M3devel] CM3 status In-Reply-To: <9EF449E4-72AB-4461-AC0C-1B0A79341E44@cs.purdue.edu> References: <20101230122314.04vju4e4v4gc4o04@mail.elegosoft.com>, , <9EF449E4-72AB-4461-AC0C-1B0A79341E44@cs.purdue.edu> Message-ID: Oops, you can see the ambiguity? So you'd rather leave Solaris/sparc32 back on gcc-4.3 for now, if the gcc-supported stack walking isn't imminent? And possibly volatile on load/store a lot. (That was more out of laziness maybe, I remember if I tried removing it.) I don't like that, but I can do it. Or is it imminent, by someone other than me? gcc-4.5 even without any optimizations and volatile everywhere didn't work with the Solaris/sparc32 stack walker. I tried a fair amount to debug it but gave up at the time. I continue to assume that Alpha/OSF is even much less interesting, given that it has extremely few users. The code continues to sit unused in CVS, same as it mostly ever did. > Last time I ran M3 on Alpha/OSF it did work. I ran it in 2010 and it didn't work. I don't remember though if that was with gcc 4.3 or 4.5. I could try again with 4.3, but I don't know what the result would be -- we'd leave it back with 4.3 also? > I wasn't real happy about dropping stack walking for Solaris. It should not be difficult to retain. I thought you were going to try to fix m3cg 4.5 to handle it > ...modulo making sure that m3cg 4.5 could cope with it. This was looking to be difficult. Even volatile everywhere and no optimization didn't work. I could give it another try perhaps. Or maybe someone else can? Getting it to work without any optimization and volatile on every load/store should be useful and easy, but it wasn't proving even easy. I figure moving to 4.5 has a fair amount of value, and optimizing one platform Solaris/sparc32 uniquely beyond all others, is less so. Or maybe I should look again more closely at the gcc stuff. Maybe it could be done imminently.. That would nicely remove a lot of target-dependent-ness out of the front/middle end!. - Jay From: hosking at cs.purdue.edu Date: Fri, 31 Dec 2010 17:01:27 -0500 To: jay.krell at cornell.edu CC: m3devel at elegosoft.com Subject: Re: [M3devel] CM3 status I didn't OK dropping SPARC stack walking, just agreeing that we should move all platforms to gcc-supported stack walking. On Dec 30, 2010, at 7:01 AM, Jay K wrote:Tony ok'ed this for Solaris/sparc32 a few months ago. I couldn't get it working with gcc 4.5, not even without optimization. That was the last step in moving off of gcc 4.3 backend. I wasn't real happy about dropping stack walking for Solaris. It should not be difficult to retain. I thought you were going to try to fix m3cg 4.5 to handle it. My preference would be to retain the stack walking code on Solaris/SPARC (since it is so easy to do...) modulo making sure that m3cg 4.5 could cope with it. Alpha/OSF also doesn't work. I didn't look much into it, and I really don't think it matters. It is an extremely little used platform. This year I saw it work on 4.0 and 5.1 but otherwise it had been unused for several years I believe, and I don't see its use continuing much. Last time I ran M3 on Alpha/OSF it did work. Upgrade of Solaris/sparc32 from gcc 4.3 to 4.5: 2010-10-13 11:18 jkrell * m3-sys/cminstall/src/config-no-install/SPARC32_SOLARIS.common, m3-sys/m3cc/gcc/gcc/m3cg/parse.c, m3-sys/m3cc/src/clean_marker.txt, m3-sys/m3cc/src/m3makefile, m3-libs/m3core/src/runtime/m3makefile, m3-sys/m3middle/src/Target.m3, m3-libs/m3core/src/runtime/SOLgnu/m3makefile, m3-libs/m3core/src/runtime/SOLgnu/m3makefile-old, m3-libs/m3core/src/runtime/SOLsun/m3makefile, m3-libs/m3core/src/runtime/SOLsun/m3makefile-old: disable Solaris/sparc32 stack walker switch Solaris/sparc32 to gcc 4.5 backend function.c: make failure to volatilize when setjmp/vfork present an error instead of a warning add missing volatilization pin Solaris/sparc32 at -O1 in the config file as -O2/-O3 were seen to hit internal compiler errors (assertion failures) remove the "all volatile" paths from parse.c (since they were only for Solaris/sparc32's stack walker) Tony ok'ing (in my interpretation) the abandonment of our stack walker: https://mail.elegosoft.com/pipermail/m3devel/2010-October/008019.html At least that was my interpretation. Using gcc's exception handling support and *its* stack walker (libgcc/libunwind) should provide the better and more portable functionality on many platforms. I'm not certain what'd it look like on systems where gcc isn't the usual C compiler (e.g. Solaris) but it's bound to work well on Linux, NetBSD, FreeBSD, OpenBSD, and Solaris using gcc. "more portable" as in, across all architectures. Perhaps I should have stuck back with 4.3 until implementing this however. It is definitely a step backward to not have the stack walker on Solaris/sparc32, but that is the only platform in years that has had one, and it is not terrible to have every platform on gcc 4.5.2 and not sprinkling volatile around. There are some backward steps but definitely a lot forward. I tried using 5.4.0 tonight and I didn't get far. > o possibly unsafe OS calls in new C code (this may be a wrong deduction > from my side) I don't know what this is referring to. The Enable/DisableScheduling? I all but undid that. It should be in a few functions, e.g. malloc/free/realloc/calloc/opendir/readdir/closedir/fopen/fclose. Some of those it already is in. With OpenBSD moving to pthreads it matters less. It only matters for user threads. > o GUI input not working for BadBricks and other games (only on Darwin?) Yes this is still a problem, and occurs in 5.8.6 release, on Darwin local X Server. Doesn't reproduce when remoted to Cygwin/X. Other X apps do work locally. Not understood. It'd be good to get confirmation if/when they ever worked. > o no clean way for exception handling with current gcc This is how things have *always* been, *except* on Alpha/OSF and Solaris/sparc32. Those two platforms have "regressed", but for Solaris/sparc32 it was discussed and Alpha/OSF I really don't think is important. Exception handling has always been very inefficient on all but approx. those two platforms. It has always been desirable to fix. The inefficiency has a few parts. Mainly that "try" costs pthread_getspecific and setjmp. The inefficiency of the actual throw/catch is not as worrisome. > o still alignment issues Details? > I'm concerned that things get tried out, don't work properly for all > our target platforms, but are left then and not cleaned up and something > else gets tried. I'm not sure this is correct, it is just me feeling > unwell after reading all those mails. Not really. > Hudson and Tinderbox status seem to be mostly OK though, but I haven't > checked in detail (FreeBSD failing was a disk failure on my system > recently). But the tests don't cover all the things we should check. Yep I try to remember to check Hudson fairly regularly. I never look at Tinderbox though. > I think it would be good to have an overview of the projects/work that > is in progress or pending and its status. For example, we've imported > a new gcc version, but that doesn't seem to work well on all targets, > or does it? If not, how are we going to address this? Use older versions > on some platforms? Can I read up on that somewhere? All platforms (except NT386) use gcc 4.5.2 for the backend. (I did the upgrade after the release was made but before it was announced; they delay announcement while it propagates to mirrors.) Ok, also ARM_DARWIN hypothetically uses 4.2. Apple forks gcc fairly aggressively. Perhaps we should merge the two forks. Perhaps. ARM_DARWIN isn't really supported currently. Probably that should be worked on. It'd also be interesting to see what Apple did to 4.2 for ppc/x86... > I'd like to suggest to simply use our Trac WiKi to document the ongoing Agreed but I'm lazy. I just throw "bombs" around.. - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: