From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitrii Korobeinikov Newsgroups: gmane.emacs.bugs Subject: bug#35419: [Proposal] Buffer Lenses and the Case of Org-Mode (also, Jupyter) Date: Thu, 25 Apr 2019 00:35:16 +0600 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="00000000000030860305874af711" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="172125"; mail-complaints-to="usenet@blaine.gmane.org" To: 35419@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Apr 24 20:36:24 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hJMko-000iXH-RQ for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Apr 2019 20:36:24 +0200 Original-Received: from localhost ([127.0.0.1]:45583 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJMkn-0006JA-Km for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Apr 2019 14:36:21 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42152) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJMka-00068w-Hz for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2019 14:36:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJMkU-0003wt-IR for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2019 14:36:08 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42943) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hJMkU-0003wb-8W for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2019 14:36:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hJMkU-0003Qf-3m for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2019 14:36:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitrii Korobeinikov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Apr 2019 18:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 35419 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.155613095513167 (code B ref -1); Wed, 24 Apr 2019 18:36:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 24 Apr 2019 18:35:55 +0000 Original-Received: from localhost ([127.0.0.1]:56488 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hJMkN-0003QJ-6r for submit@debbugs.gnu.org; Wed, 24 Apr 2019 14:35:55 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55920) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hJMkK-0003Q1-SP for submit@debbugs.gnu.org; Wed, 24 Apr 2019 14:35:53 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:32788) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hJMkF-0003nh-BL for submit@debbugs.gnu.org; Wed, 24 Apr 2019 14:35:47 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:42068) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJMk9-0005v4-1d for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2019 14:35:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJMk2-0003ao-JC for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2019 14:35:41 -0400 Original-Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]:36923) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hJMk1-0003YC-F4 for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2019 14:35:34 -0400 Original-Received: by mail-wr1-x429.google.com with SMTP id t17so14813338wrr.4 for ; Wed, 24 Apr 2019 11:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=aHBkoXfNrn0aJEnzcjCOLqDrTyxit4vkhKYwulyoDEk=; b=r1vDlqwkktkP9p+kcU1nPWAtvoQcbdMX0LEujYzQDOrmiWgH7HHyLqsJqYzYQhERZx 2T4IE/s7CILvm+JrXipDnoYsfNaTP6SW91sIEN/fR8Y68HOVVq5cb1/x/8dkl5K3pU8N VknVcvZzMTUq97QgFA5uKSdWFcVcojCKo3P9SNrhC7fW+z6xQQEC30jiJD1CxLiFz7pI 0QWVIj6qscPrxK5TP2Gy1XCUnlrwTFdq9X3LrXQqGXyZaQmtUvrkXfezevjbRWPHrgbI pn0GsW5xHQtDTj8/hSNfPbEnPST3ZFQeqRDpJPeBIuQ5sgoSkpa9i/bbB4CoI2ptxPdT dHqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=aHBkoXfNrn0aJEnzcjCOLqDrTyxit4vkhKYwulyoDEk=; b=nRibqP5IicqU86U7Ek01rUOxgWzGyuXT+v3q28hvwdmgvRALMcGHjFojdHsdzSFR8P oIWI+r8Q09BKExyBJugDxSHuw85gOw9rinIh1Tp8kJR2r6IvjE/eSowWSrfml4ZFZrtv R8XXpGrN2l2z7kW0JVPXP+XWYx6vwACZuToq0dCztBnSAePyhbTDFpXKPg1/BZxVw+UC vqxrASU3LQHaJBBt3RpYHrRzsOJfz42jl3Pn+3nl/lvo6MMt7nsLUYgVqE8ItTCkvfpg AFX+/kObziZxEzuLLLvfbb7OYhmUwEHGmccshBS32dJyNcPvF1oL+iGaxxioI4Tr6tZy lCzQ== X-Gm-Message-State: APjAAAVYInDDz9vM0tGbbm2CyWlSLMt2JZOToIbOTC+iTnYYdPLzpFII EOOl/QWeqnlsptnCJR6sI5NkcXl3wa9YkKZ42gxjSg== X-Google-Smtp-Source: APXvYqw3LSBcLVfocLu+eGder4+nYYWJnJAs6dFLYWlb4XR2BFpZVrHA2QF/p90O+ERwZc27w5tHnsu4lrB8QWACjZY= X-Received: by 2002:a5d:62cf:: with SMTP id o15mr1133650wrv.45.1556130927956; Wed, 24 Apr 2019 11:35:27 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:158196 Archived-At: --00000000000030860305874af711 Content-Type: multipart/alternative; boundary="00000000000030860005874af70f" --00000000000030860005874af70f Content-Type: text/plain; charset="UTF-8" For your convenience, I have attached this e-mail as an org-mode file. *SUMMARY* /Buffer lens/ is an object inside a buffer which provides that buffer the lines to display and which is linked to another buffer (from which it can take and process data), while mapping the input back to that linked buffer. /Composite lens/ is the extension of this idea to interface any sources of data (for which text interface is possible). Some Org-mode problems are addressed, particularly those concerning source block editing and viewing, syntax checking, completion and reference expansion. This is a proposal for /lenses/. Hereby, I outline the general idea, the problems it solves, the features it introduces and its use cases. * Problem Statement The problem is that it's hard to treat some area inside a buffer - as if it ran in a different buffer, with its own set of modes, - as an object w/ distinct properties and interface. This proposal is not drawn out of thin air: the bigger part of it is about applications (for an immediate example, you could think of an org mode source block.) * Mechanics The idea is to embed a buffer inside another buffer. Have a block of text, a sentence, a table, a word -- some /area/ in your buffer -- behave as if it were in some other distinct buffer, which has it's own modes and keybindings. What's proposed here is to do such a trick using a /buffer lens/. First, let's form a preliminary, prototype definition (it will be changed later in this section). A /buffer lens/ is an object which views its /linked buffer/ and this buffer can be viewed using /areas/. An /area/ is a text object, whose properties and contents are controlled by its /lens/. The /linked buffer/ is (conceptually) just a regular buffer, whose contents the lens can use to control its /area/. Suppose you have opened some buffer - call it a /Working buffer/ or /WB/. /Lens-mode/ is the mode responsible for all the /lenses/ inside the /working buffer/. The goals of the /lens-mode/ are: - Identify, track and handle all the /lenses/ in the buffer. - Display each /area/ according to the options of its /lens/ and its own options. - Let the user relay the control/input to a /lens/ (say, when the cursor is in its /area/), which would in turn relay the input to its /linked buffer/ as if it were in its own window. Either all user actions could be relayed or just a defined subset (e.g. specific keybindings or commands). - Let the user define specific maps and user input handling routines for any specific /lens/ or for any type of /lens/, where type is deduced from the properties of the lens (by a user-defined function). - Propagate save commands to the lenses. (which may signal the /model/ to adapt the changes in the /shared base/: these will be discussed shortly). We could also come up with a general description of a /lens/. Call it a /composite lens/. A /composite lens/ could consist of these parts: /model/, /representation/, /linked buffer/, /shared base/, /shared block/, /view/ and /controller/. This is almost like MVC. I find it somewhat more intuitive to use the term /area/ instead of /view/, so let's do that (at least for now). /Model/ is data (strings, buffers, databases, anything). /Representation/ is the description of how to build /shared blocks/ and /shared bases/ using the /model/. /Shared base/ consists of /shared blocks/. Each /shared block/ is constructed (through representation) to be: - either plain text or - a lens (such as /buffer-lens/) (hence the name /composite-lens/ - it makes use of other lenses). /Linked buffer/ is a buffer which views a /shared base/. This buffer is like a regular buffer (runs its own modes, etc.). /Area/ is associated w/ one /linked buffer/ and is its contents + some properties. /Controller/ maps the user input to the /linked buffer/ of the /area/. Get a load of this: The /linked buffer/ views a /shared base/, which consists of /shared blocks/, which are either plain text or other lenses, being described by the /representation/ of the /model/, which may be ultimately accessed via the /controller/, which maps the user input from the /area/. Plain text for /shared blocks/ is for stuff that doesn't need to be kept in the /model/ (say, for delimiters which identify the /lens/ as such in the /working buffer/, where they reside before the /lens-mode/ runs). The goal of these abstractions is to allow having - multiple /areas/, - each having a dedicated buffer (w/ distinct modes and properties), - which share the same textual data (the /shared base/), - which is compiled from plain text or other lenses (/shared blocks/), - which have their own input interface (e.g. /buffer-lenses/). Since the data is shared between the /areas/ (through /shared base/), if the user makes some changes in one /area/, the changes immediately appear in all other /areas/. As such, a /buffer lens/ is a special case of a /composite lens/, except - it has no /model/ (and so, needs no /representation/), - its /shared base/ is a single buffer. Note, this approach differs from what was described in the beginning of this section: now there can be multiple /linked buffers/, all sharing one /shared base/. This approach is more powerful: it allows multiple /areas/ to behave differently and reduces data duplication. One point worth attention is that an /area/ should also have its own set of properties, such as custom padding, alignment (center, left, right), etc. Such properties could be arbitrary as long as mapping the user input back to the /linked buffer/ can be performed. This will allow visual customizations. /Representations/ should be modifiable (through some interface). The usage of /shared blocks/ above is really for explanatory purposes and, possibly, less of a necessity (but may indeed come in useful when multiple representations). Saving is also an important thing to discuss. The lens should be able to form an area, where the displayed text /shadows/ the text which actually needs to be saved. This is doable: in org-mode, when you fold a title, the ellipsis have arbitrary data hidden in their place. But the possibilities are: - use faces/folding or such (I am not too familiar w/ the associated technicalities, but I think they could work), or - (what seems like the better solution), the save operation could grab the /shared base/ which the /area/ uses (or query the lens for what to save). And as for the undo behavior, what's clear is that the changes will need to be tracked to the /shared base/ of all /areas/ of the same /representation/. * Practical Applications ** Org-mode Org-mode, a distinct planescape in the Emacs multiverse, might be the mode to benefit the most from the use of lenses. *** 3D Tables Suppose you have three table: | 0 | 0 | 0 | | 0 | A | 0 | | 0 | 0 | 0 | | 0 | B | 0 | | B | 0 | B | | 0 | B | 0 | | C | 0 | C | | 0 | 0 | 0 | | C | 0 | C | Say, these tables are just the layers of a 3x3 cube. You might want to view this cube as a distinct entity: -**LAYER 1**- | 0 | 0 | 0 | | 0 | A | 0 | | 0 | 0 | 0 | You could use a composite lens for this. The /model/ would be three buffers, one table in each. The /representation/ describes the /view/ as: - as a string ("-**LAYER 1**-") and - a /buffer lens/ linking one of the three buffers in the /model/. One could command the lens to switch to the next layer: just change the /representation/. When the cursor is in the /area/, the user input now is handled in its /linked buffer/. When the cursor is directly on the table, the input is relayed to the /buffer lens/ of the table, whose /area's/ /linked buffer/ has org-mode running. The tables are identified and replaced when the /lens-mode/ runs for the first time. But what should happen when the user saves the buffer? We want to save all three tables, not just the one which happens to be currently viewed. The possible solution, as discussed in [[Mechanics]], could be to /shadow/ the three tables. Of course, tables can be explored in any way, not just layer by layer. https://en.wikipedia.org/wiki/Online_analytical_processing So, to give a perspective on all this: a table becomes an object and the modes that run in the /linked buffer/ form the interface to this object. And, really, a table is a table for example purposes, and, obviously, anything else could be in its place. *** Code Blocks and Results: Editing and Viewing Here I will first discuss all the relevant problems and then propose a solution. **** Problems ***** Editing Source Blocks [0/5] Consider this block: #+BEGIN_SRC elisp (defun step (x l) (case (< x l) 0 t 1)) #+END_SRC First, 'newline-and-indent doesn't indent the code correctly. It simply seems to look at the first symbol of the previous line: - [ ] support for mode-specific editing features is limited, - [ ] the mode-specific interactive features (say, keybindings) are disregarded. Using 'org-edit-src-code helps, but it is a hassle. What's more, every time 'org-edit-src-code is used: - [ ] a new buffer is created, which implies initialization of the buffer modes, - [ ] the changes need to be written back. The issues with the points above can be demonstrated by observing the bugs w/ 'org-comment-dwim: - the screen is scrolled to show the first line of the block, - in visual line mode, the cursor jumps to the beginning of the block. Marks are thrown back to the beginning of the block -- for the same reason. Also, the larger the code block, the more work has to be done, so, - [ ] some lag is to be expected. (Bug report for the commenting behavior: https:/ sdebbugs.gnu.org/cgi/bugreport.cgi?bug=bug%2334977) ***** Viewing Source Blocks and Results [0/6] Consider these two blocks: #+NAME: syntax-tangling-commenting #+BEGIN_SRC elisp (defun step (x l) (case (< x l) 0 t 1)) #+END_SRC #+BEGIN_SRC elisp :noweb yes <> (step "wrong argument") #+END_SRC First and foremost, there is no syntax checking and neither is there completion: - [ ] what can be easily done in a separate buffer w/ some mode on can't be done inline. And using 'org-edit-src-code is not much of a relief as the syntax checker and the completer have - [ ] no way of dealing with references to process code as if tangled in. The consequences of this point are farther than those of the missing syntax checking or completion: sometimes, looking at code as a coherent whole, and not a series of disconnect snippets, is what the programmer needs. In principle, it could be possible for 'org-edit-source-code to substitute code for each reference, but this is problematic due to the points made in [[Editing Source Blocks]] section. Next, when some failed assertion or a runtime error tells you a line number, looking for it is tough. But there is no way to show line numbers (absolute, as if references were expanded). Or suppose a source block produces a huge table. This means you will want to truncate lines. But maybe that's not what you want for the rest of your buffer. These boil down to: - [ ] can't view a specific area of a buffer, like :results or a source block, as if it were in another buffer. One other nice feature to see would be running the code and seeing the results from within 'org-edit-src-code. Currently, if one works using 'org-edit-src-code, running the code is not an option, because you wouldn't see the :RESULTS anyway. Currently, switching is necessary from the edit buffer to the main buffer and back. This problem could be solved by redirecting the output to some buffer and split screening, but, then again, updating the original buffer is required. - [ ] If the results of execution were to be redirected to a separate buffer, they would have to be mapped back to the original file for consistency. Let's now discuss the visual properties of code blocks and :results. #+NAME: one-liner #+BEGIN_SRC elisp (defun step (x l) (case (< x l) 0 t 1)) #+END_SRC For two lines of meaningful data, there are four lines of, admittedly, noise. Meaningful: the stuff that the programmer concentrates on. For longer snippets, the noise-to-signal ratio drops, but when you have a lot of snippets, these extra lines of parameters add up. And everything starts looking like spiders making love in a bowl of spaghetti. I think one way which could help is to have a summary line and hide the rest: > [one-liner] (elisp) > (defun step (x l) (case (< x l) 0 t 1)) And when it is necessary to edit the description of the block, one could expand it on a key combination: - the appearance of blocks could be more distinct and less noisy. To add to this, note how the code in the source blocks is indented two spaces forward. Those are hard spaces and they weren't inserted right away, only after using 'org-edit-src-code. No doubt, this indentation helps. However, it would be better for it to be purely visual and to be there without having to call anything. In short: - [ ] a powerful way to customize the view of blocks is needed. Next, the /ob-async/ package shows that asynchronous execution of blocks is possible. Apparently, the way it works is by placing a unique identifier in the RESULTS and then replacing it. Another possible scenario: display the current running time in the footer of a block. Is the find/search procedure the best one could do? - [ ] A unified way to update the view of a block / results section could help. **** Solution ***** Basis A source block can be shown via a /composite lens/. And so can be every noweb reference. For instance, suppose a buffer (call it /main buffer/) has these blocks (also used in the following subsections): #+NAME: block-A #+BEGIN_SRC python f = lambda x: x ** x #+END_SRC #+NAME: block-B #+BEGIN_SRC python :noweb yes <> g = lambda x: f(x) + f(x + 1) #+END_SRC So, these lenses are created: - /block-A/ /composite lens/ containing: - /buffer-A/ /lens/ (w/ contents "f = lambda x: x ** x") - begin/end source markers as plain text - /block-B/ /composite lens/ containing: - /buffer-A/ /lens/ (w/ contents "f = lambda x: x ** x" shadowing "<>" or just "<>") - /buffer-B/ /buffer lens/ (w/ contents "g = lambda x: f(x) + f(x + 1)") As you see, the code of block-A appears in two blocks: as code and as a reference. A reasonable thing to do is create just one lens for both. So, this lens should contain the code, but should also be able to show just the reference. There are multiple ways to display this lens (that is, to form an /area/): show the code/reference which, /optionally/, shadows reference/code. For example, in block-B, we may choose to show code and shadow the reference, so that when the document is saved, the text of the reference is actually saved and not the code. So, in the end, there is just one lens for /buffer-A/, with two /areas/, one for /block-B/ and one for /block-A/. The lens could be either /buffer-lens/ or a /composite-lens/, it's up to the implementation. ***** Editing The most important point to remember now is this: the linked buffer has its own set of modes, independent of the mods in the working buffer. Lens-mode offers an important utility (discussed in [[Mechanics]]): it can redirect keybindings and commands when the cursor is in the area of the lens. So, basically, the user can have access to all the features of the modes which run in the linked buffer. This immediately implies proper indentation and the resolution of the bug w/ commenting. (comment keybinding is forwarded to the /inner buffer/ and the right thing is done there.) And what about 'org-edit-src-code? Just open a buffer and show the /buffer-A/B/ lens there! No need to write the changes back: all the areas of the lens update in real time. ***** Viewing In addition to the two blocks from [[Basis]], let's define: #+NAME: block-C #+BEGIN_SRC python :noweb yes <> h = 10 * f(5) * g(2) #+END_SRC #+NAME: block-D #+BEGIN_SRC python :noweb yes <> y = g(1) #+END_SRC So, the dependency tree is this: block-A <-- block-B <-- block-C <-- block-D First, let's see what can be done about syntax checking, completion and the possibility of viewing all the code at once. How can we deal with the noweb references? Understanding what it is exactly that we want may help us answer the question. A rough list of requirements/wishes could be: (regardless of working in the /main buffer/ or using 'org-edit-src-code) - (1) have an option to expand the references into code - (2) have syntax checking and completion: - (a) which work as if the references were expanded (regardless of the actual reference expansion options), - (b) which work as if the code that references the block is seen as well - if included by multiple blocks (e.g. in case of ~block-B~, the usage by ~block-C~ and ~block-D~), prefer the one which ran last. - (c) and minimize the work done. OK, all of the above can exploit the functionality of lenses, which, upon request, can produce the right /area/ based the preferences of the buffer which contains the /lens/. (1) is covered: the lenses for references are recursively asked to show code instead of the reference. (2) is also covered - let's discuss the details. What is point (2),(b) all about? Why would <> care about who references it (i.e blocks C and D)? Wouldn't it be enough for the syntax checker to view just the expanded <> reference? Indeed, that would almost work, but there are flaws to this approach: - things like /unused variable/ or /missing a closing bracket/ will arise, - it is unnecessarily expensive. This last point is simple: why run syntax checker in ~block-A~ and ~block-B~, if one could run it in ~block-C~ and map the changes back? So, the solution is to build source block tree and run syntax checker on the end nodes, while propagating the results back to the root. If there is a fork, propagate from the one which the user ran last. How exactly could this work in our example? - Keep a buffer which views the ~block-C~ lens and recursively tell the reference-lenses to show the code. - Run the syntax checker there and associate the output w/ each lens (recursively). - For completion, propagate user input (from lenses A, B and C) to this same ~block-C~ buffer and deal w/ the result. OK, so much for the tougher share of the problems. Now, let's get the rest of the issues. - View customization is in place: /areas/ may have various properties and can show/hide/display the begin/end ornamentation in any manner. (e.g. :RESULTS lens truncates lines, while the buffer that contains it doesn't, etc., see the [[Problems]] section) (e.g. the /area/ of the code lens is indented two spaces, as it's property) - One could instruct a lens what to do instead of using regexp + replace. (e.g. continuosly update a timer) Results sections can be shown via lenses. Now, when editing w/ 'ord-edit-src-code, just split the screen and open :RESULTS in another buffer. Editing or running the code: everything will be kept in sync w/ the original buffer. Some blocks may output several distinct pieces of data, like here: http://kitchingroup.cheme.cmu.edu/blog/2017/01/29/ob-ipython-and-inline-figures-in-org-mode Replacing the old results could be just a matter of removing the existing lens and placing in a new one. No need to search for the end of the results block. You could select a portion of the block and narrow it. Showing the line numbers should be a matter of running nlinum in the end node buffer (as w/ syntax checking), but I don't know how nlinum works to say for sure. To be fair, some of the descriptions here depend on implementation possibilities, so the level of detail is in accordance. *** Other uses **** Inline view of links One could make some sort of a lens to view a part of a buffer/file identified by a link. The buffer could be the same buffer, an external file, anything. One would not have to follow the link. When following the link is too cumbersome, copy pasting is prevented. **** Display Org documents Sections in an org document could be shown using lenses. Not that I know why this would be useful (well, maybe for making a [[Jupyter]] like environment). But the concept is interesting. **** Connect several source blocks (I have proposed this on the Org-mode mailing list, but now that I think of it, a user-defined way as here is better.) A quite ordinary workflow is to write a block and then test the block seperately (or use :epilogue for one-liners). However, writing out a test seperately is noisy and something like this could be done instead: #+NAME: square-1 #+BEGIN_SRC python square = lambda x: x * x #+END_SRC return [square(x) for x in range(10)] #+END_SRC_TEST This could be accomplished by lenses: lens-mode would only need to check for two adjacent blocks and -test and then wrap them in another lens, showing both like above. Of course, some way to let org-babel know what's going on would be necessary. ** Arbitrary Positioning (Window Lenses) Window lenses are a logical extension of buffer lenses. Imagine you wanted to stack two images horizontally. Viewing two images horizontally in Emacs can be done by creating two windows, one image in each window. That's what a window lens could do, except it would be shown inside a buffer. ** Interactive Graphs This one is tougher than window lenses, but much more interesting. Say, you wanted to have an interactive graph in your buffer (gnuplot, matplotlib). This part of the buffer would require it's own keybindings and all, but the area of the lens could be customized, through its properties of padding/centering and such, to adorn and place the graph in a visually satisfying manner. In the land where unicorns live, one would be able to view any graphical window inside Emacs: something that would satisfy the taste of even the finest gourmets of modern text editing (uGhrHrhmph). Not that the buffer lenses are the biggest problem here, but they just might come in useful. ** Fast Timer Updates (Text as an Object) I have already touched on this topic a bit in the context of Org-Mode, and now, for the sake of completeness, let's form a general characteristic of using lenses. A timer was mentioned: currently, as I understand, if you wanted to put it in your buffer and see it continuously update, you would have to use search and replace, which is not efficient. The solution offered was to use a lens: it would itself update the timer (as a /shared block/ or some other direct manner). And the uses are more general: since /lens-mode/ tracks all the lenses, one could send commands to them. They can update independently. So, if there are text objects, they may be accessed easily. This was one of the goals set in the [[Problem Statement]]. ** Bug Trackers & Websites & Databases (Interface Building) Perhaps, one could work with Gitlab server or similar through lenses. Building an interface for a website doesn't seem to be out of the question either. Accesing a database: why not? * Jupyter Jupyter is a reproducible research environment. https://jupyter.org/ Here is what using it looks like: http://arogozhnikov.github.io/2016/09/10/jupyter-features.html Jupyter has a serious flaw. It doesn't run inside Emacs. (Listen, all is even worse: it runs in a web browser (yes, I know about links and eww.)) I haven't used it much, so let's rely on the opinion of someone who has: https://towardsdatascience.com/5-reasons-why-jupyter-notebooks-suck-4dc201e27086 - 1. It is almost impossible to enable good code versioning (files are JSON, merging is difficult) - 2. There is no IDE integration, no linting, no code-style correction (quite surprising considering the popularity, isn't it?) - 3. Very hard to test (not the problem of Jupyter, really) - 4. The non-linear workflow of jupyter - 5. Jupyter is bad for running long asynchronous tasks Someone also said that many snippets in Jupyter are hard to manage. I believe him. The good stuff about Jupyter: - 1. easy to use / low entry barrier, - 2. interactive graphs, - 3. visually distinct cells. Plan: Emacs beats Jupyter, Jupyter dies an agonizing death, everyone starts using Emacs (the last two points may be reversed). Say, if the stuff in the org-mode section and the interactive graphs (at least for matplotlib) were implemented, making some special easy mode w/ the intuitive keybindings could convert some Jupyter folks. The third point on cells is also doable if lenses get some area customizations like padding and centering. And, if necessary, the whole org tree could be viewed through lenses. And org-mode can already export to html, for presentation purposes. In short: I think making a good reproducible research environment, easily usable and full of features is a good goal and could lure some people into using Emacs (if only superficially at first). * Implementation I am not familiar with Emacs internals to say what's feasible of the proposed structure. And the two major things in [[Mechanics]] that somewhat depend on how Emacs works are: - shadowing, and - making two buffers (w/ different modes) share the same text (/linked buffers/ share the same /shared base/). * Discussion Nothing in this proposal is set in stone, feel free to change it to your liking. Some naming is probably flawed. Some structures might be overly ambitious or unnecessary. All implementation-related suggestions are just suggestions. Some explanations could be more clear. More applications couldn't hurt. The effects of the implementation are contained within the lens-mode. Which means users should not notice the difference unless they turn on the lens-mode. If the implementation is undertaken, this will be good for testing and integration. Overall, I think the applications might be very well worth the effort. Especially for Org-mode. --00000000000030860005874af70f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For your convenience, I have attache= d this e-mail as an org-mode file.

*SUMMARY* /Buff= er lens/ is an object inside a buffer which provides that buffer the lines = to display and which is linked to another buffer (from which it can take an= d process data), while mapping the input back to that linked buffer. /Compo= site lens/ is the extension of this idea to interface any sources of data (= for which text interface is possible). Some Org-mode problems are addressed= , particularly those concerning source block editing and viewing, syntax ch= ecking, completion and reference expansion.

This i= s a proposal for /lenses/. Hereby, I outline the general idea, the problems= it solves, the features it introduces and its use cases.

* Problem Statement

=C2=A0 The problem is = that it's hard to treat some area inside a buffer
=C2=A0 - as= if it ran in a different buffer, with its own set of modes,
=C2= =A0 - as an object w/ distinct properties and interface.

=C2=A0 This proposal is not drawn out of thin air: the bigger part o= f it is about applications
=C2=A0 (for an immediate example, you = could think of an org mode source block.)

* Mechan= ics

=C2=A0 The idea is to embed a buffer inside an= other buffer.
=C2=A0 Have a block of text, a sentence, a table, a= word -- some /area/ in your buffer -- behave as if it were in some other d= istinct buffer, which has it's own modes and keybindings.
=C2=A0 What's proposed here is to do such a trick using a /= buffer lens/.

=C2=A0 First, let's form a preli= minary, prototype definition (it will be changed later in this section).
=C2=A0 A /buffer lens/ is an object which views its /linked buffer/= and this buffer can be viewed using /areas/.
=C2=A0 An /area/ is= a text object, whose properties and contents are controlled by its /lens/.=
=C2=A0 The /linked buffer/ is (conceptually) just a regular buff= er, whose contents the lens can use to control its /area/.

=C2=A0 Suppose you have opened some buffer - call it a /Working bu= ffer/ or /WB/.
=C2=A0 /Lens-mode/ is the mode responsible for all= the /lenses/ inside the /working buffer/.

=C2=A0 = The goals of the /lens-mode/ are:
=C2=A0 - Identify, track and ha= ndle all the /lenses/ in the buffer.
=C2=A0 - Display each /area/= according to the options of its /lens/ and its own options.
=C2= =A0 - Let the user relay the control/input to a /lens/ (say, when the curso= r is in its /area/), which would in turn relay the input to its /linked buf= fer/ as if it were in its own window. Either all user actions could be rela= yed or just a defined subset (e.g. specific keybindings or commands).
=
=C2=A0 - Let the user define specific maps and user input handling rou= tines for any specific /lens/ or for any type of /lens/, where type is dedu= ced from the properties of the lens (by a user-defined function).
=C2=A0 - Propagate save commands to the lenses.
=C2=A0 =C2=A0 (w= hich may signal the /model/ to adapt the changes in the /shared base/: thes= e will be discussed shortly).

=C2=A0 We could also= come up with a general description of a /lens/.
=C2=A0 Call it a= /composite lens/.
=C2=A0=C2=A0
=C2=A0 A /composite len= s/ could consist of these parts: /model/, /representation/, /linked buffer/= , /shared base/, /shared block/, /view/ and /controller/.
=C2=A0 = This is almost like MVC.
=C2=A0 I find it somewhat more intuitive= to use the term /area/ instead of /view/, so let's do that (at least f= or now).

=C2=A0 /Model/ is data (strings, buffers,= databases, anything).
=C2=A0 /Representation/ is the description= of how to build /shared blocks/ and /shared bases/ using the /model/.
=C2=A0 /Shared base/ consists of /shared blocks/.
=C2=A0 Ea= ch /shared block/ is constructed (through representation) to be:
= =C2=A0 - either plain text or
=C2=A0 - a lens (such as /buffer-le= ns/) (hence the name /composite-lens/ - it makes use of other lenses).
=C2=A0 /Linked buffer/ is a buffer which views a /shared base/. This = buffer is like a regular buffer (runs its own modes, etc.).
=C2= =A0 /Area/ is associated w/ one /linked buffer/ and is its contents + some = properties.
=C2=A0 /Controller/ maps the user input to the /linke= d buffer/ of the /area/.=C2=A0

=C2=A0 Get a load o= f this:
=C2=A0 The /linked buffer/ views a /shared base/, which c= onsists of /shared blocks/, which are either plain text or other lenses, be= ing described by the /representation/ of the /model/, which may be ultimate= ly accessed via the /controller/, which maps the user input from the /area/= .

=C2=A0 Plain text for /shared blocks/ is for stu= ff that doesn't need to be kept in the /model/ (say, for delimiters whi= ch identify the /lens/ as such in the /working buffer/, where they reside b= efore the /lens-mode/ runs).

=C2=A0 The goal of th= ese abstractions is to allow having
=C2=A0 - multiple /areas/,=C2= =A0
=C2=A0 - each having a dedicated buffer (w/ distinct modes an= d properties),
=C2=A0 =C2=A0 - which share the same textual data = (the /shared base/),=C2=A0
=C2=A0 =C2=A0 =C2=A0 - which is compil= ed from plain text or other lenses (/shared blocks/),
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 - which have their own input interface (e.g. /buffer-lens= es/).

=C2=A0 Since the data is shared between the = /areas/ (through /shared base/), if the user makes some changes in one /are= a/, the changes immediately appear in all other /areas/.

=C2=A0 As such, a /buffer lens/ is a special case of a /composite le= ns/, except=C2=A0
=C2=A0 - it has no /model/ (and so, needs no /r= epresentation/),=C2=A0
=C2=A0 - its /shared base/ is a single buf= fer.
=C2=A0 Note, this approach differs from what was described i= n the beginning of this section: now there can be multiple /linked buffers/= , all sharing one /shared base/.
=C2=A0 This approach is more pow= erful: it allows multiple /areas/ to behave differently and reduces data du= plication.

=C2=A0 One point worth attention is tha= t an /area/ should also have its own set of properties, such as custom padd= ing, alignment (center, left, right), etc.
=C2=A0 Such properties= could be arbitrary as long as mapping the user input back to the /linked b= uffer/ can be performed.
=C2=A0 This will allow visual customizat= ions.

=C2=A0 /Representations/ should be modifiabl= e (through some interface).

=C2=A0 The usage of /s= hared blocks/ above is really for explanatory purposes and, possibly, less = of a necessity (but may indeed come in useful when multiple representations= ).

=C2=A0 Saving is also an important thing to dis= cuss.
=C2=A0 The lens should be able to form an area, where the d= isplayed text /shadows/ the text which actually needs to be saved.
=C2=A0 This is doable: in org-mode, when you fold a title, the ellipsis h= ave arbitrary data hidden in their place.
=C2=A0 But the possibil= ities are:
=C2=A0 - use faces/folding or such (I am not too famil= iar w/ the associated technicalities, but I think they could work), or
=C2=A0 - (what seems like the better solution), the save operation co= uld grab the /shared base/ which the /area/ uses (or query the lens for wha= t to save).

=C2=A0 And as for the undo behavior, w= hat's clear is that the changes will need to be tracked to the /shared = base/ of all /areas/ of the same /representation/.

* Practical Applications

** Org-mode
=C2=A0 Org-mode, a distinct planescape in the Emacs multiverse= , might be the mode to benefit the most from the use of lenses.
<= br>
*** 3D Tables

=C2=A0 =C2=A0 Suppose = you have three table:

=C2=A0 =C2=A0 | 0 | 0 | 0 |<= /div>
=C2=A0 =C2=A0 | 0 | A | 0 |
=C2=A0 =C2=A0 | 0 | 0 | 0 |=

=C2=A0 =C2=A0 | 0 | B | 0 |
=C2=A0 =C2= =A0 | B | 0 | B |
=C2=A0 =C2=A0 | 0 | B | 0 |

=C2=A0 =C2=A0 | C | 0 | C |
=C2=A0 =C2=A0 | 0 | 0 | 0 |
=C2=A0 =C2=A0 | C | 0 | C |

=C2=A0 =C2=A0 S= ay, these tables are just the layers of a 3x3 cube.
=C2=A0 =C2=A0= You might want to view this cube as a distinct entity:
=C2=A0 = =C2=A0=C2=A0
=C2=A0 =C2=A0 -**LAYER 1**-
=C2=A0 =C2=A0 = | 0 | 0 | 0 |
=C2=A0 =C2=A0 | 0 | A | 0 |
=C2=A0 =C2=A0= | 0 | 0 | 0 |

=C2=A0 =C2=A0 You could use a compo= site lens for this.
=C2=A0 =C2=A0 The /model/ would be three buff= ers, one table in each.
=C2=A0 =C2=A0 The /representation/ descri= bes the /view/ as:
=C2=A0 =C2=A0 - as a string ("-**LAYER 1*= *-") and
=C2=A0 =C2=A0 - a /buffer lens/ linking one of the = three buffers in the /model/.

=C2=A0 =C2=A0 One co= uld command the lens to switch to the next layer: just change the /represen= tation/.

=C2=A0 =C2=A0 When the cursor is in the /= area/, the user input now is handled in its /linked buffer/.
=C2= =A0 =C2=A0 When the cursor is directly on the table, the input is relayed t= o the /buffer lens/ of the table, whose /area's/ /linked buffer/ has or= g-mode running.

=C2=A0 =C2=A0 The tables are ident= ified and replaced when the /lens-mode/ runs for the first time.
= =C2=A0 =C2=A0 But what should happen when the user saves the buffer?
<= div>=C2=A0 =C2=A0 We want to save all three tables, not just the one which = happens to be currently viewed.
=C2=A0 =C2=A0 The possible soluti= on, as discussed in [[Mechanics]], could be to /shadow/ the three tables.

=C2=A0 =C2=A0 Of course, tables can be explored in = any way, not just layer by layer.

<= /div>
=C2=A0 =C2=A0 So, to give a perspective on all this: a table beco= mes an object and the modes that run in the /linked buffer/ form the interf= ace to this object.
=C2=A0 =C2=A0 And, really, a table is a table= for example purposes, and, obviously, anything else could be in its place.=

*** Code Blocks and Results: Editing and Viewing<= /div>

=C2=A0 =C2=A0 Here I will first discuss all the re= levant problems and then propose a solution.

**** = Problems
***** Editing Source Blocks [0/5]

=C2=A0 =C2=A0 =C2=A0Consider this block:

=C2=A0= =C2=A0 =C2=A0#+BEGIN_SRC elisp
=C2=A0 =C2=A0 =C2=A0 =C2=A0(defun= step (x l)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(case (< x l) 0<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0t 1))
=C2=A0 =C2=A0 =C2=A0#+END_SRC

=C2=A0 =C2=A0 = =C2=A0First, 'newline-and-indent doesn't indent the code correctly.=
=C2=A0 =C2=A0 =C2=A0It simply seems to look at the first symbol = of the previous line:

=C2=A0 =C2=A0 =C2=A0- [ ] su= pport for mode-specific editing features is limited,
=C2=A0 =C2= =A0 =C2=A0- [ ] the mode-specific interactive features (say, keybindings) a= re disregarded.

=C2=A0 =C2=A0 =C2=A0Using 'org= -edit-src-code helps, but it is a hassle.

=C2=A0 = =C2=A0 =C2=A0What's more, every time 'org-edit-src-code is used:

=C2=A0 =C2=A0 =C2=A0- [ ] a new buffer is created, w= hich implies initialization of the buffer modes,
=C2=A0 =C2=A0 = =C2=A0- [ ] the changes need to be written back.

= =C2=A0 =C2=A0 =C2=A0The issues with the points above can be demonstrated by= observing the bugs w/ 'org-comment-dwim:

=C2= =A0 =C2=A0 =C2=A0- the screen is scrolled to show the first line of the blo= ck,
=C2=A0 =C2=A0 =C2=A0- in visual line mode, the cursor jumps t= o the beginning of the block.

=C2=A0 =C2=A0 =C2=A0= Marks are thrown back to the beginning of the block -- for the same reason.=

=C2=A0 =C2=A0 =C2=A0Also, the larger the code blo= ck, the more work has to be done, so,

=C2=A0 =C2= =A0 =C2=A0- [ ] some lag is to be expected.

=C2=A0= =C2=A0 =C2=A0(Bug report for the commenting behavior: https:/sdebbugs.gnu.org/cgi/bugreport.cgi?bug=3Dbug%2334977)

<= /div>
***** Viewing Source Blocks and Results [0/6]

=C2=A0 =C2=A0 =C2=A0Consider these two blocks:

=C2=A0 =C2=A0 =C2=A0#+NAME: syntax-tangling-commenting
=C2=A0 = =C2=A0 =C2=A0#+BEGIN_SRC elisp
=C2=A0 =C2=A0 =C2=A0 =C2=A0(defun = step (x l)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(case (< x l) 0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0t 1))
=
=C2=A0 =C2=A0 =C2=A0#+END_SRC

=C2=A0 =C2=A0 = =C2=A0#+BEGIN_SRC elisp :noweb yes
=C2=A0 =C2=A0 =C2=A0 =C2=A0<= ;<syntax-tangling-commenting>>
=C2=A0 =C2=A0 =C2=A0 =C2= =A0(step "wrong argument")
=C2=A0 =C2=A0 =C2=A0#+END_SR= C

=C2=A0 =C2=A0 =C2=A0First and foremost, there is= no syntax checking and neither is there completion:

=C2=A0 =C2=A0 =C2=A0- [ ] what can be easily done in a separate buffer w= / some mode on can't be done inline.

=C2=A0 = =C2=A0 =C2=A0And using 'org-edit-src-code is not much of a relief as th= e syntax checker and the completer have=C2=A0

=C2= =A0 =C2=A0 =C2=A0- [ ] no way of dealing with references to process code as= if tangled in.

=C2=A0 =C2=A0 =C2=A0The consequenc= es of this point are farther than those of the missing syntax checking or c= ompletion:
=C2=A0 =C2=A0 =C2=A0sometimes, looking at code as a co= herent whole, and not a series of disconnect snippets, is what the programm= er needs.

=C2=A0 =C2=A0 =C2=A0In principle, it cou= ld be possible for 'org-edit-source-code to substitute code for each re= ference, but this is problematic due to the points made in [[Editing Source= Blocks]] section.

=C2=A0 =C2=A0 =C2=A0Next, when = some failed assertion or a runtime error tells you a line number, looking f= or it is tough.
=C2=A0 =C2=A0 =C2=A0But there is no way to show l= ine numbers (absolute, as if references were expanded).
=C2=A0 = =C2=A0 =C2=A0Or suppose a source block produces a huge table.
=C2= =A0 =C2=A0 =C2=A0This means you will want to truncate lines.
=C2= =A0 =C2=A0 =C2=A0But maybe that's not what you want for the rest of you= r buffer.
=C2=A0 =C2=A0 =C2=A0These boil down to:

<= /div>
=C2=A0 =C2=A0 =C2=A0- [ ] can't view a specific area of a buf= fer, like :results or a source block, as if it were in another buffer.

=C2=A0 =C2=A0 =C2=A0One other nice feature to see woul= d be running the code and seeing the results from within 'org-edit-src-= code.
=C2=A0 =C2=A0 =C2=A0Currently, if one works using 'org-= edit-src-code, running the code is not an option, because you wouldn't = see the :RESULTS anyway.
=C2=A0 =C2=A0 =C2=A0Currently, switching= is necessary from the edit buffer to the main buffer and back.
= =C2=A0 =C2=A0 =C2=A0This problem could be solved by redirecting the output = to some buffer and split screening, but, then again, updating the original = buffer is required.

=C2=A0 =C2=A0 =C2=A0- [ ] If t= he results of execution were to be redirected to a separate buffer, they wo= uld have to be mapped back to the original file for consistency.
=
=C2=A0 =C2=A0 =C2=A0Let's now discuss the visual propert= ies of code blocks and :results.

=C2=A0 =C2=A0 =C2= =A0#+NAME: one-liner
=C2=A0 =C2=A0 =C2=A0#+BEGIN_SRC elisp
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0(defun step (x l) (case (< x l) 0 t 1))
=C2=A0 =C2=A0 =C2=A0#+END_SRC

=C2=A0 =C2= =A0 =C2=A0For two lines of meaningful data, there are four lines of, admitt= edly, noise.
=C2=A0 =C2=A0 =C2=A0Meaningful: the stuff that the p= rogrammer concentrates on.=C2=A0
=C2=A0 =C2=A0 =C2=A0For longer s= nippets, the noise-to-signal ratio drops, but when you have a lot of snippe= ts, these extra lines of parameters add up.
=C2=A0 =C2=A0 =C2=A0A= nd everything starts looking like spiders making love in a bowl of spaghett= i.

=C2=A0 =C2=A0 =C2=A0I think one way which could= help is to have a summary line and hide the rest:

=C2=A0 =C2=A0 =C2=A0> [one-liner] (elisp) <other stuff>
=C2=A0 =C2=A0 =C2=A0>=C2=A0 (defun step (x l) (case (< x l) 0 t 1))<= /div>

=C2=A0 =C2=A0 =C2=A0And when it is necessary to ed= it the description of the block, one could expand it on a key combination:<= /div>

=C2=A0 =C2=A0 =C2=A0- the appearance of blocks cou= ld be more distinct and less noisy.

=C2=A0 =C2=A0 = =C2=A0To add to this, note how the code in the source blocks is indented tw= o spaces forward.
=C2=A0 =C2=A0 =C2=A0Those are hard spaces and t= hey weren't inserted right away, only after using 'org-edit-src-cod= e.
=C2=A0 =C2=A0 =C2=A0No doubt, this indentation helps.
=C2=A0 =C2=A0 =C2=A0However, it would be better for it to be purely visua= l and to be there without having to call anything.

=C2=A0 =C2=A0 =C2=A0In short:

=C2=A0 =C2=A0 =C2= =A0- [ ] a powerful way to customize the view of blocks is needed.

=C2=A0 =C2=A0 =C2=A0Next, the /ob-async/ package shows tha= t asynchronous execution of blocks is possible.
=C2=A0 =C2=A0 =C2= =A0Apparently, the way it works is by placing a unique identifier in the RE= SULTS and then replacing it.
=C2=A0 =C2=A0 =C2=A0Another possible= scenario: display the current running time in the footer of a block.
=
=C2=A0 =C2=A0 =C2=A0Is the find/search procedure the best one could do= ?

=C2=A0 =C2=A0 =C2=A0- [ ] A unified way to updat= e the view of a block / results section could help.

**** Solution
***** Basis

=C2=A0 =C2= =A0 A source block can be shown via a /composite lens/.
=C2=A0 = =C2=A0 And so can be every noweb reference.

=C2=A0= =C2=A0 For instance, suppose a buffer (call it /main buffer/) has these bl= ocks (also used in the following subsections):

=C2= =A0 =C2=A0 #+NAME: block-A
=C2=A0 =C2=A0 #+BEGIN_SRC python
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0f =3D lambda x: x ** x
=C2=A0 =C2= =A0 #+END_SRC

=C2=A0 =C2=A0 #+NAME: block-B
<= div>=C2=A0 =C2=A0 #+BEGIN_SRC python :noweb yes
=C2=A0 =C2=A0 =C2= =A0 =C2=A0<<block-A>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0g = =3D lambda x: f(x) + f(x + 1)
=C2=A0 =C2=A0 #+END_SRC
<= br>
=C2=A0 =C2=A0 So, these lenses are created:
=C2=A0 = =C2=A0 - /block-A/ /composite lens/ containing:
=C2=A0 =C2=A0 =C2= =A0 =C2=A0- /buffer-A/ /lens/ (w/ contents "f =3D lambda x: x ** x&quo= t;)
=C2=A0 =C2=A0 =C2=A0 =C2=A0- begin/end source markers as plai= n text
=C2=A0 =C2=A0 - /block-B/ /composite lens/ containing:
=C2=A0 =C2=A0 =C2=A0 =C2=A0- /buffer-A/ /lens/ (w/ contents "f = =3D lambda x: x ** x" shadowing "<<block-A>>" or= just "<<block-A>>")
=C2=A0 =C2=A0 =C2=A0 = =C2=A0- /buffer-B/ /buffer lens/ (w/ contents "g =3D lambda x: f(x) + = f(x + 1)")

=C2=A0 =C2=A0 As you see, the code= of block-A appears in two blocks: as code and as a reference.
= =C2=A0 =C2=A0 A reasonable thing to do is create just one lens for both.
=C2=A0 =C2=A0 So, this lens should contain the code, but should als= o be able to show just the reference.
=C2=A0 =C2=A0 There are mul= tiple ways to display this lens (that is, to form an /area/):
=C2= =A0 =C2=A0 show the code/reference which, /optionally/, shadows reference/c= ode.
=C2=A0 =C2=A0 For example, in block-B, we may choose to show= code and shadow the reference, so that when the document is saved, the tex= t of the reference is actually saved and not the code.

=
=C2=A0 =C2=A0 So, in the end, there is just one lens for /buffer-A/, w= ith two /areas/, one for /block-B/ and one for /block-A/.
=C2=A0 = =C2=A0 The lens could be either /buffer-lens/ or a /composite-lens/, it'= ;s up to the implementation.

***** Editing

=C2=A0 =C2=A0 The most important point to remember now is= this:=C2=A0
=C2=A0 =C2=A0 the linked buffer has its own set of m= odes, independent of the mods in the working buffer.

=C2=A0 =C2=A0 Lens-mode offers an important utility (discussed in [[Mech= anics]]):=C2=A0
=C2=A0 =C2=A0 it can redirect keybindings and com= mands when the cursor is in the area of the lens.
=C2=A0 =C2=A0 S= o, basically, the user can have access to all the features of the modes whi= ch run in the linked buffer.
=C2=A0 =C2=A0 This immediately impli= es proper indentation and the resolution of the bug w/ commenting.
=C2=A0 =C2=A0 (comment keybinding is forwarded to the /inner buffer/ and = the right thing is done there.)

=C2=A0 =C2=A0 And = what about 'org-edit-src-code?
=C2=A0 =C2=A0 Just open a buff= er and show the /buffer-A/B/ lens there!
=C2=A0 =C2=A0 No need to= write the changes back: all the areas of the lens update in real time.

***** Viewing

=C2=A0 =C2=A0 = In addition to the two blocks from [[Basis]], let's define:
<= br>
=C2=A0 =C2=A0 #+NAME: block-C
=C2=A0 =C2=A0 #+BEGIN= _SRC python :noweb yes
=C2=A0 =C2=A0 =C2=A0 =C2=A0<<block-B= >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0h =3D 10 * f(5) * g(2)
<= div>=C2=A0 =C2=A0 #+END_SRC

=C2=A0 =C2=A0 #+NAME: = block-D
=C2=A0 =C2=A0 #+BEGIN_SRC python :noweb yes
=C2= =A0 =C2=A0 =C2=A0 =C2=A0<<block-B>>
=C2=A0 =C2=A0 =C2= =A0 =C2=A0y =3D g(1)
=C2=A0 =C2=A0 #+END_SRC

=
=C2=A0 =C2=A0 So, the dependency tree is this:
=C2=A0 =C2=A0= block-A <-- block-B <-- block-C
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <-- block-D<= /div>

=C2=A0 =C2=A0 First, let's see what can be don= e about syntax checking, completion and the possibility of viewing all the = code at once.
=C2=A0 =C2=A0 How can we deal with the noweb refere= nces?

=C2=A0 =C2=A0 Understanding what it is exact= ly that we want may help us answer the question.
=C2=A0 =C2=A0 A = rough list of requirements/wishes could be:

=C2=A0= =C2=A0 (regardless of working in the /main buffer/ or using 'org-edit-= src-code)
=C2=A0 =C2=A0 - (1) have an option to expand the refere= nces into code
=C2=A0 =C2=A0 - (2) have syntax checking and compl= etion:
=C2=A0 =C2=A0 =C2=A0 =C2=A0- (a) which work as if the refe= rences were expanded (regardless of the actual reference expansion options)= ,
=C2=A0 =C2=A0 =C2=A0 =C2=A0- (b) which work as if the code that= references the block is seen as well=C2=A0
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0- if included by multiple blocks (e.g. in case of ~block-B~, t= he usage by ~block-C~ and ~block-D~), prefer the one which ran last.
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0- (c) and minimize the work done.
=
=C2=A0 =C2=A0 OK, all of the above can exploit the functiona= lity of lenses, which, upon request, can produce the right /area/ based the= preferences of the buffer which contains the /lens/.
=C2=A0 =C2= =A0 (1) is covered: the lenses for references are recursively asked to show= code instead of the reference.
=C2=A0 =C2=A0 (2) is also covered= - let's discuss the details.

=C2=A0 =C2=A0 Wh= at is point (2),(b) all about?
=C2=A0 =C2=A0 Why would <<bl= ock-B>> care about who references it (i.e blocks C and D)?
= =C2=A0 =C2=A0 Wouldn't it be enough for the syntax checker to view just= the expanded <<block-A>> reference?
=C2=A0 =C2=A0 In= deed, that would almost work, but there are flaws to this approach:
=C2=A0 =C2=A0 - things like /unused variable/ or /missing a closing brac= ket/ will arise,
=C2=A0 =C2=A0 - it is unnecessarily expensive.

=C2=A0 =C2=A0 This last point is simple: why run sy= ntax checker in ~block-A~ and ~block-B~, if one could run it in ~block-C~ a= nd map the changes back?
=C2=A0 =C2=A0 So, the solution is to bui= ld source block tree and run syntax checker on the end nodes, while propaga= ting the results back to the root. If there is a fork, propagate from the o= ne which the user ran last.
=C2=A0 =C2=A0 How exactly could this = work in our example?
=C2=A0 =C2=A0 - Keep a buffer which views th= e ~block-C~ lens and recursively tell the reference-lenses to show the code= .=C2=A0
=C2=A0 =C2=A0 - Run the syntax checker there and associat= e the output w/ each lens (recursively).
=C2=A0 =C2=A0 - For comp= letion, propagate user input (from lenses A, B and C) to this same ~block-C= ~ buffer and deal w/ the result.

=C2=A0 =C2=A0 OK,= so much for the tougher share of the problems.
=C2=A0 =C2=A0 Now= , let's get the rest of the issues.

=C2=A0 =C2= =A0 - View customization is in place: /areas/ may have various properties a= nd can show/hide/display the begin/end ornamentation in any manner.
=C2=A0 =C2=A0 =C2=A0 (e.g. :RESULTS lens truncates lines, while the buff= er that contains it doesn't, etc., see the [[Problems]] section)
<= div>=C2=A0 =C2=A0 =C2=A0 (e.g. the /area/ of the code lens is indented two = spaces, as it's property)

=C2=A0 =C2=A0 - One = could instruct a lens what to do instead of using regexp + replace.
=C2=A0 =C2=A0 =C2=A0 (e.g. continuosly update a timer)

=C2=A0 =C2=A0 Results sections can be shown via lenses.
= =C2=A0 =C2=A0 Now, when editing w/ 'ord-edit-src-code, just split the s= creen and open :RESULTS in another buffer.
=C2=A0 =C2=A0 Editing = or running the code: everything will be kept in sync w/ the original buffer= .
=C2=A0 =C2=A0 Some blocks may output several distinct pieces of= data, like here:
=C2=A0 =C2=A0 Replacing the ol= d results could be just a matter of removing the existing lens and placing = in a new one.
=C2=A0 =C2=A0 No need to search for the end of the = results block.

=C2=A0 =C2=A0 You could select a po= rtion of the block and narrow it.

=C2=A0 =C2=A0 Sh= owing the line numbers should be a matter of running nlinum in the end node= buffer (as w/ syntax checking), but I don't know how nlinum works to s= ay for sure.

=C2=A0 =C2=A0 To be fair, some of the= descriptions here depend on implementation possibilities, so the level of = detail is in accordance.

*** Other uses
=
**** Inline view of links

=C2=A0 = =C2=A0 =C2=A0One could make some sort of a lens to view a part of a buffer/= file identified by a link.
=C2=A0 =C2=A0 =C2=A0The buffer could b= e the same buffer, an external file, anything.
=C2=A0 =C2=A0 =C2= =A0One would not have to follow the link.
=C2=A0 =C2=A0 =C2=A0Whe= n following the link is too cumbersome, copy pasting is prevented.

**** Display Org documents

=C2=A0= =C2=A0 =C2=A0Sections in an org document could be shown using lenses.
=C2=A0 =C2=A0 =C2=A0Not that I know why this would be useful (well, m= aybe for making a [[Jupyter]] like environment).
=C2=A0 =C2=A0 = =C2=A0But the concept is interesting.

**** Connect= several source blocks

=C2=A0 =C2=A0 =C2=A0(I have= proposed this on the Org-mode mailing list, but now that I think of it, a = user-defined way as here is better.)

=C2=A0 =C2=A0= =C2=A0A quite ordinary workflow is to write a block and then test the bloc= k seperately (or use :epilogue for one-liners).
=C2=A0 =C2=A0 =C2= =A0However, writing out a test seperately is noisy and something like this = could be done instead:

=C2=A0 =C2=A0 =C2=A0#+NAME:= square-1
=C2=A0 =C2=A0 =C2=A0#+BEGIN_SRC python
=C2=A0= =C2=A0 =C2=A0 =C2=A0square =3D lambda x: x * x
=C2=A0 =C2=A0 =C2= =A0#+END_SRC
=C2=A0 =C2=A0 =C2=A0 =C2=A0return [square(x) for x i= n range(10)]
=C2=A0 =C2=A0 =C2=A0#+END_SRC_TEST

=C2=A0 =C2=A0 =C2=A0This could be accomplished by lenses: lens-mode= would only need to check for two adjacent blocks <name> and <name= >-test and then wrap them in another lens, showing both like above.

=C2=A0 =C2=A0 =C2=A0Of course, some way to let org-bab= el know what's going on would be necessary.

**= Arbitrary Positioning (Window Lenses)

=C2=A0 =C2= =A0Window lenses are a logical extension of buffer lenses.
=C2=A0= =C2=A0Imagine you wanted to stack two images horizontally.
=C2= =A0 =C2=A0Viewing two images horizontally in Emacs can be done by creating = two windows, one image in each window.
=C2=A0 =C2=A0That's wh= at a window lens could do, except it would be shown inside a buffer.
<= div>
** Interactive Graphs

=C2=A0 = =C2=A0This one is tougher than window lenses, but much more interesting.
=C2=A0 =C2=A0Say, you wanted to have an interactive graph in your b= uffer (gnuplot, matplotlib).
=C2=A0 =C2=A0This part of the buffer= would require it's own keybindings and all, but the area of the lens c= ould be customized, through its properties of padding/centering and such, t= o adorn and place the graph in a visually satisfying manner.

=
=C2=A0 =C2=A0In the land where unicorns live, one would be able = to view any graphical window inside Emacs: something that would satisfy the= taste of even the finest gourmets of modern text editing (uGhrHrhmph).

=C2=A0 =C2=A0Not that the buffer lenses are the bigge= st problem here, but they just might come in useful.

** Fast Timer Updates (Text as an Object)

=C2= =A0 =C2=A0I have already touched on this topic a bit in the context of Org-= Mode, and now, for the sake of completeness, let's form a general chara= cteristic of using lenses.

=C2=A0 =C2=A0A timer wa= s mentioned: currently, as I understand, if you wanted to put it in your bu= ffer and see it continuously update, you would have to use search and repla= ce, which is not efficient.
=C2=A0 =C2=A0The solution offered was= to use a lens: it would itself update the timer (as a /shared block/ or so= me other direct manner).

=C2=A0 =C2=A0And the uses= are more general: since /lens-mode/ tracks all the lenses, one could send = commands to them.
=C2=A0 =C2=A0They can update independently.
=C2=A0 =C2=A0So, if there are text objects, they may be accessed eas= ily.
=C2=A0 =C2=A0This was one of the goals set in the [[Problem = Statement]].

** Bug Trackers & Websites & = Databases (Interface Building)

=C2=A0 =C2=A0Perhap= s, one could work with Gitlab server or similar through lenses.
<= br>
=C2=A0 =C2=A0Building an interface for a website doesn't = seem to be out of the question either.

=C2=A0 =C2= =A0Accesing a database: why not?

* Jupyter

=C2=A0 Jupyter is a reproducible research environment.

=C2=A0 Here is what using it looks= like:

=C2=A0 Jupyter h= as a serious flaw.
=C2=A0 It doesn't run inside Emacs.
<= div>=C2=A0 (Listen, all is even worse: it runs in a web browser (yes, I kno= w about links and eww.))

=C2=A0 I haven't used= it much, so let's rely on the opinion of someone who has:
=C2=A0 - 1. = It is almost impossible to enable good code versioning (files are JSON, mer= ging is difficult)
=C2=A0 - 2. There is no IDE integration, no li= nting, no code-style correction=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0= (quite surprising considering the popularity, isn't it?)
=C2= =A0 - 3. Very hard to test (not the problem of Jupyter, really)
= =C2=A0 - 4. The non-linear workflow of jupyter
=C2=A0 - 5. Jupyte= r is bad for running long asynchronous tasks

=C2= =A0 Someone also said that many snippets in Jupyter are hard to manage. I b= elieve him.=C2=A0

=C2=A0 The good stuff about Jupy= ter:
=C2=A0 - 1. easy to use / low entry barrier,
=C2= =A0 - 2. interactive graphs,
=C2=A0 - 3. visually distinct cells.=

=C2=A0 Plan: Emacs beats Jupyter, Jupyter dies an= agonizing death, everyone starts using Emacs (the last two points may be r= eversed).

=C2=A0 Say, if the stuff in the org-mode= section and the interactive graphs (at least for matplotlib) were implemen= ted, making some special easy mode w/ the intuitive keybindings could conve= rt some Jupyter folks.

=C2=A0 The third point on c= ells is also doable if lenses get some area customizations like padding and= centering. And, if necessary, the whole org tree could be viewed through l= enses.

=C2=A0 And org-mode can already export to h= tml, for presentation purposes.

=C2=A0 In short: I= think making a good reproducible research environment, easily usable and f= ull of features is a good goal and could lure some people into using Emacs = (if only superficially at first).

* Implementation=

=C2=A0 I am not familiar with Emacs internals to = say what's feasible of the proposed structure.
=C2=A0=C2=A0
=C2=A0 And the two major things in [[Mechanics]] that somewhat dep= end on how Emacs works are:
=C2=A0 - shadowing, and
=C2= =A0 - making two buffers (w/ different modes) share the same text (/linked = buffers/ share the same /shared base/).
=C2=A0=C2=A0
* = Discussion

=C2=A0 Nothing in this proposal is set = in stone, feel free to change it to your liking.

= =C2=A0 Some naming is probably flawed.
=C2=A0 Some structures mig= ht be overly ambitious or unnecessary.
=C2=A0 All implementation-= related suggestions are just suggestions.

=C2=A0 S= ome explanations could be more clear.

=C2=A0 More = applications couldn't hurt.

=C2=A0 The effects= of the implementation are contained within the lens-mode.
=C2=A0= Which means users should not notice the difference unless they turn on the= lens-mode.
=C2=A0 If the implementation is undertaken, this will= be good for testing and integration.

=C2=A0 Overa= ll, I think the applications might be very well worth the effort.
=C2=A0 Especially for Org-mode.
--00000000000030860005874af70f-- --00000000000030860305874af711 Content-Type: application/octet-stream; name="buffer-lenses.org" Content-Disposition: attachment; filename="buffer-lenses.org" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_juvk2kea0 IytUSVRMRTogW1Byb3Bvc2FsXSBCdWZmZXIgTGVuc2VzIGFuZCB0aGUgQ2FzZSBvZiBPcmctTW9k ZSAoYWxzbywgSnVweXRlcikgCiMrQVVUSE9SOiBEbWl0cmlpIEtvcm9iZWluaWtvdgojK0VNQUlM OiBkaW0xMjEya0BnbWFpbC5jb20KCipTVU1NQVJZKiAvQnVmZmVyIGxlbnMvIGlzIGFuIG9iamVj dCBpbnNpZGUgYSBidWZmZXIgd2hpY2ggcHJvdmlkZXMgdGhhdCBidWZmZXIgdGhlIGxpbmVzIHRv IGRpc3BsYXkgYW5kIHdoaWNoIGlzIGxpbmtlZCB0byBhbm90aGVyIGJ1ZmZlciAoZnJvbSB3aGlj aCBpdCBjYW4gdGFrZSBhbmQgcHJvY2VzcyBkYXRhKSwgd2hpbGUgbWFwcGluZyB0aGUgaW5wdXQg YmFjayB0byB0aGF0IGxpbmtlZCBidWZmZXIuIC9Db21wb3NpdGUgbGVucy8gaXMgdGhlIGV4dGVu c2lvbiBvZiB0aGlzIGlkZWEgdG8gaW50ZXJmYWNlIGFueSBzb3VyY2VzIG9mIGRhdGEgKGZvciB3 aGljaCB0ZXh0IGludGVyZmFjZSBpcyBwb3NzaWJsZSkuIFNvbWUgT3JnLW1vZGUgcHJvYmxlbXMg YXJlIGFkZHJlc3NlZCwgcGFydGljdWxhcmx5IHRob3NlIGNvbmNlcm5pbmcgc291cmNlIGJsb2Nr IGVkaXRpbmcgYW5kIHZpZXdpbmcsIHN5bnRheCBjaGVja2luZywgY29tcGxldGlvbiBhbmQgcmVm ZXJlbmNlIGV4cGFuc2lvbi4KClRoaXMgaXMgYSBwcm9wb3NhbCBmb3IgL2xlbnNlcy8uIEhlcmVi eSwgSSBvdXRsaW5lIHRoZSBnZW5lcmFsIGlkZWEsIHRoZSBwcm9ibGVtcyBpdCBzb2x2ZXMsIHRo ZSBmZWF0dXJlcyBpdCBpbnRyb2R1Y2VzIGFuZCBpdHMgdXNlIGNhc2VzLgoKKiBQcm9ibGVtIFN0 YXRlbWVudAoKICBUaGUgcHJvYmxlbSBpcyB0aGF0IGl0J3MgaGFyZCB0byB0cmVhdCBzb21lIGFy ZWEgaW5zaWRlIGEgYnVmZmVyCiAgLSBhcyBpZiBpdCByYW4gaW4gYSBkaWZmZXJlbnQgYnVmZmVy LCB3aXRoIGl0cyBvd24gc2V0IG9mIG1vZGVzLAogIC0gYXMgYW4gb2JqZWN0IHcvIGRpc3RpbmN0 IHByb3BlcnRpZXMgYW5kIGludGVyZmFjZS4KCiAgVGhpcyBwcm9wb3NhbCBpcyBub3QgZHJhd24g b3V0IG9mIHRoaW4gYWlyOiB0aGUgYmlnZ2VyIHBhcnQgb2YgaXQgaXMgYWJvdXQgYXBwbGljYXRp b25zCiAgKGZvciBhbiBpbW1lZGlhdGUgZXhhbXBsZSwgeW91IGNvdWxkIHRoaW5rIG9mIGFuIG9y ZyBtb2RlIHNvdXJjZSBibG9jay4pCgoqIE1lY2hhbmljcwoKICBUaGUgaWRlYSBpcyB0byBlbWJl ZCBhIGJ1ZmZlciBpbnNpZGUgYW5vdGhlciBidWZmZXIuCiAgSGF2ZSBhIGJsb2NrIG9mIHRleHQs IGEgc2VudGVuY2UsIGEgdGFibGUsIGEgd29yZCAtLSBzb21lIC9hcmVhLyBpbiB5b3VyIGJ1ZmZl ciAtLSBiZWhhdmUgYXMgaWYgaXQgd2VyZSBpbiBzb21lIG90aGVyIGRpc3RpbmN0IGJ1ZmZlciwg d2hpY2ggaGFzIGl0J3Mgb3duIG1vZGVzIGFuZCBrZXliaW5kaW5ncy4KCiAgV2hhdCdzIHByb3Bv c2VkIGhlcmUgaXMgdG8gZG8gc3VjaCBhIHRyaWNrIHVzaW5nIGEgL2J1ZmZlciBsZW5zLy4KCiAg Rmlyc3QsIGxldCdzIGZvcm0gYSBwcmVsaW1pbmFyeSwgcHJvdG90eXBlIGRlZmluaXRpb24gKGl0 IHdpbGwgYmUgY2hhbmdlZCBsYXRlciBpbiB0aGlzIHNlY3Rpb24pLgogIEEgL2J1ZmZlciBsZW5z LyBpcyBhbiBvYmplY3Qgd2hpY2ggdmlld3MgaXRzIC9saW5rZWQgYnVmZmVyLyBhbmQgdGhpcyBi dWZmZXIgY2FuIGJlIHZpZXdlZCB1c2luZyAvYXJlYXMvLgogIEFuIC9hcmVhLyBpcyBhIHRleHQg b2JqZWN0LCB3aG9zZSBwcm9wZXJ0aWVzIGFuZCBjb250ZW50cyBhcmUgY29udHJvbGxlZCBieSBp dHMgL2xlbnMvLgogIFRoZSAvbGlua2VkIGJ1ZmZlci8gaXMgKGNvbmNlcHR1YWxseSkganVzdCBh IHJlZ3VsYXIgYnVmZmVyLCB3aG9zZSBjb250ZW50cyB0aGUgbGVucyBjYW4gdXNlIHRvIGNvbnRy b2wgaXRzIC9hcmVhLy4KCiAgU3VwcG9zZSB5b3UgaGF2ZSBvcGVuZWQgc29tZSBidWZmZXIgLSBj YWxsIGl0IGEgL1dvcmtpbmcgYnVmZmVyLyBvciAvV0IvLgogIC9MZW5zLW1vZGUvIGlzIHRoZSBt b2RlIHJlc3BvbnNpYmxlIGZvciBhbGwgdGhlIC9sZW5zZXMvIGluc2lkZSB0aGUgL3dvcmtpbmcg YnVmZmVyLy4KCiAgVGhlIGdvYWxzIG9mIHRoZSAvbGVucy1tb2RlLyBhcmU6CiAgLSBJZGVudGlm eSwgdHJhY2sgYW5kIGhhbmRsZSBhbGwgdGhlIC9sZW5zZXMvIGluIHRoZSBidWZmZXIuCiAgLSBE aXNwbGF5IGVhY2ggL2FyZWEvIGFjY29yZGluZyB0byB0aGUgb3B0aW9ucyBvZiBpdHMgL2xlbnMv IGFuZCBpdHMgb3duIG9wdGlvbnMuCiAgLSBMZXQgdGhlIHVzZXIgcmVsYXkgdGhlIGNvbnRyb2wv aW5wdXQgdG8gYSAvbGVucy8gKHNheSwgd2hlbiB0aGUgY3Vyc29yIGlzIGluIGl0cyAvYXJlYS8p LCB3aGljaCB3b3VsZCBpbiB0dXJuIHJlbGF5IHRoZSBpbnB1dCB0byBpdHMgL2xpbmtlZCBidWZm ZXIvIGFzIGlmIGl0IHdlcmUgaW4gaXRzIG93biB3aW5kb3cuIEVpdGhlciBhbGwgdXNlciBhY3Rp b25zIGNvdWxkIGJlIHJlbGF5ZWQgb3IganVzdCBhIGRlZmluZWQgc3Vic2V0IChlLmcuIHNwZWNp ZmljIGtleWJpbmRpbmdzIG9yIGNvbW1hbmRzKS4KICAtIExldCB0aGUgdXNlciBkZWZpbmUgc3Bl Y2lmaWMgbWFwcyBhbmQgdXNlciBpbnB1dCBoYW5kbGluZyByb3V0aW5lcyBmb3IgYW55IHNwZWNp ZmljIC9sZW5zLyBvciBmb3IgYW55IHR5cGUgb2YgL2xlbnMvLCB3aGVyZSB0eXBlIGlzIGRlZHVj ZWQgZnJvbSB0aGUgcHJvcGVydGllcyBvZiB0aGUgbGVucyAoYnkgYSB1c2VyLWRlZmluZWQgZnVu Y3Rpb24pLgogIC0gUHJvcGFnYXRlIHNhdmUgY29tbWFuZHMgdG8gdGhlIGxlbnNlcy4KICAgICh3 aGljaCBtYXkgc2lnbmFsIHRoZSAvbW9kZWwvIHRvIGFkYXB0IHRoZSBjaGFuZ2VzIGluIHRoZSAv c2hhcmVkIGJhc2UvOiB0aGVzZSB3aWxsIGJlIGRpc2N1c3NlZCBzaG9ydGx5KS4KCiAgV2UgY291 bGQgYWxzbyBjb21lIHVwIHdpdGggYSBnZW5lcmFsIGRlc2NyaXB0aW9uIG9mIGEgL2xlbnMvLgog IENhbGwgaXQgYSAvY29tcG9zaXRlIGxlbnMvLgogIAogIEEgL2NvbXBvc2l0ZSBsZW5zLyBjb3Vs ZCBjb25zaXN0IG9mIHRoZXNlIHBhcnRzOiAvbW9kZWwvLCAvcmVwcmVzZW50YXRpb24vLCAvbGlu a2VkIGJ1ZmZlci8sIC9zaGFyZWQgYmFzZS8sIC9zaGFyZWQgYmxvY2svLCAvdmlldy8gYW5kIC9j b250cm9sbGVyLy4KICBUaGlzIGlzIGFsbW9zdCBsaWtlIE1WQy4KICBJIGZpbmQgaXQgc29tZXdo YXQgbW9yZSBpbnR1aXRpdmUgdG8gdXNlIHRoZSB0ZXJtIC9hcmVhLyBpbnN0ZWFkIG9mIC92aWV3 Lywgc28gbGV0J3MgZG8gdGhhdCAoYXQgbGVhc3QgZm9yIG5vdykuCgogIC9Nb2RlbC8gaXMgZGF0 YSAoc3RyaW5ncywgYnVmZmVycywgZGF0YWJhc2VzLCBhbnl0aGluZykuCiAgL1JlcHJlc2VudGF0 aW9uLyBpcyB0aGUgZGVzY3JpcHRpb24gb2YgaG93IHRvIGJ1aWxkIC9zaGFyZWQgYmxvY2tzLyBh bmQgL3NoYXJlZCBiYXNlcy8gdXNpbmcgdGhlIC9tb2RlbC8uCiAgL1NoYXJlZCBiYXNlLyBjb25z aXN0cyBvZiAvc2hhcmVkIGJsb2Nrcy8uCiAgRWFjaCAvc2hhcmVkIGJsb2NrLyBpcyBjb25zdHJ1 Y3RlZCAodGhyb3VnaCByZXByZXNlbnRhdGlvbikgdG8gYmU6CiAgLSBlaXRoZXIgcGxhaW4gdGV4 dCBvcgogIC0gYSBsZW5zIChzdWNoIGFzIC9idWZmZXItbGVucy8pIChoZW5jZSB0aGUgbmFtZSAv Y29tcG9zaXRlLWxlbnMvIC0gaXQgbWFrZXMgdXNlIG9mIG90aGVyIGxlbnNlcykuCiAgL0xpbmtl ZCBidWZmZXIvIGlzIGEgYnVmZmVyIHdoaWNoIHZpZXdzIGEgL3NoYXJlZCBiYXNlLy4gVGhpcyBi dWZmZXIgaXMgbGlrZSBhIHJlZ3VsYXIgYnVmZmVyIChydW5zIGl0cyBvd24gbW9kZXMsIGV0Yy4p LgogIC9BcmVhLyBpcyBhc3NvY2lhdGVkIHcvIG9uZSAvbGlua2VkIGJ1ZmZlci8gYW5kIGlzIGl0 cyBjb250ZW50cyArIHNvbWUgcHJvcGVydGllcy4KICAvQ29udHJvbGxlci8gbWFwcyB0aGUgdXNl ciBpbnB1dCB0byB0aGUgL2xpbmtlZCBidWZmZXIvIG9mIHRoZSAvYXJlYS8uIAoKICBHZXQgYSBs b2FkIG9mIHRoaXM6CiAgVGhlIC9saW5rZWQgYnVmZmVyLyB2aWV3cyBhIC9zaGFyZWQgYmFzZS8s IHdoaWNoIGNvbnNpc3RzIG9mIC9zaGFyZWQgYmxvY2tzLywgd2hpY2ggYXJlIGVpdGhlciBwbGFp biB0ZXh0IG9yIG90aGVyIGxlbnNlcywgYmVpbmcgZGVzY3JpYmVkIGJ5IHRoZSAvcmVwcmVzZW50 YXRpb24vIG9mIHRoZSAvbW9kZWwvLCB3aGljaCBtYXkgYmUgdWx0aW1hdGVseSBhY2Nlc3NlZCB2 aWEgdGhlIC9jb250cm9sbGVyLywgd2hpY2ggbWFwcyB0aGUgdXNlciBpbnB1dCBmcm9tIHRoZSAv YXJlYS8uCgogIFBsYWluIHRleHQgZm9yIC9zaGFyZWQgYmxvY2tzLyBpcyBmb3Igc3R1ZmYgdGhh dCBkb2Vzbid0IG5lZWQgdG8gYmUga2VwdCBpbiB0aGUgL21vZGVsLyAoc2F5LCBmb3IgZGVsaW1p dGVycyB3aGljaCBpZGVudGlmeSB0aGUgL2xlbnMvIGFzIHN1Y2ggaW4gdGhlIC93b3JraW5nIGJ1 ZmZlci8sIHdoZXJlIHRoZXkgcmVzaWRlIGJlZm9yZSB0aGUgL2xlbnMtbW9kZS8gcnVucykuCgog IFRoZSBnb2FsIG9mIHRoZXNlIGFic3RyYWN0aW9ucyBpcyB0byBhbGxvdyBoYXZpbmcKICAtIG11 bHRpcGxlIC9hcmVhcy8sIAogIC0gZWFjaCBoYXZpbmcgYSBkZWRpY2F0ZWQgYnVmZmVyICh3LyBk aXN0aW5jdCBtb2RlcyBhbmQgcHJvcGVydGllcyksCiAgICAtIHdoaWNoIHNoYXJlIHRoZSBzYW1l IHRleHR1YWwgZGF0YSAodGhlIC9zaGFyZWQgYmFzZS8pLCAKICAgICAgLSB3aGljaCBpcyBjb21w aWxlZCBmcm9tIHBsYWluIHRleHQgb3Igb3RoZXIgbGVuc2VzICgvc2hhcmVkIGJsb2Nrcy8pLAog ICAgICAgIC0gd2hpY2ggaGF2ZSB0aGVpciBvd24gaW5wdXQgaW50ZXJmYWNlIChlLmcuIC9idWZm ZXItbGVuc2VzLykuCgogIFNpbmNlIHRoZSBkYXRhIGlzIHNoYXJlZCBiZXR3ZWVuIHRoZSAvYXJl YXMvICh0aHJvdWdoIC9zaGFyZWQgYmFzZS8pLCBpZiB0aGUgdXNlciBtYWtlcyBzb21lIGNoYW5n ZXMgaW4gb25lIC9hcmVhLywgdGhlIGNoYW5nZXMgaW1tZWRpYXRlbHkgYXBwZWFyIGluIGFsbCBv dGhlciAvYXJlYXMvLgoKICBBcyBzdWNoLCBhIC9idWZmZXIgbGVucy8gaXMgYSBzcGVjaWFsIGNh c2Ugb2YgYSAvY29tcG9zaXRlIGxlbnMvLCBleGNlcHQgCiAgLSBpdCBoYXMgbm8gL21vZGVsLyAo YW5kIHNvLCBuZWVkcyBubyAvcmVwcmVzZW50YXRpb24vKSwgCiAgLSBpdHMgL3NoYXJlZCBiYXNl LyBpcyBhIHNpbmdsZSBidWZmZXIuCiAgTm90ZSwgdGhpcyBhcHByb2FjaCBkaWZmZXJzIGZyb20g d2hhdCB3YXMgZGVzY3JpYmVkIGluIHRoZSBiZWdpbm5pbmcgb2YgdGhpcyBzZWN0aW9uOiBub3cg dGhlcmUgY2FuIGJlIG11bHRpcGxlIC9saW5rZWQgYnVmZmVycy8sIGFsbCBzaGFyaW5nIG9uZSAv c2hhcmVkIGJhc2UvLgogIFRoaXMgYXBwcm9hY2ggaXMgbW9yZSBwb3dlcmZ1bDogaXQgYWxsb3dz IG11bHRpcGxlIC9hcmVhcy8gdG8gYmVoYXZlIGRpZmZlcmVudGx5IGFuZCByZWR1Y2VzIGRhdGEg ZHVwbGljYXRpb24uCgogIE9uZSBwb2ludCB3b3J0aCBhdHRlbnRpb24gaXMgdGhhdCBhbiAvYXJl YS8gc2hvdWxkIGFsc28gaGF2ZSBpdHMgb3duIHNldCBvZiBwcm9wZXJ0aWVzLCBzdWNoIGFzIGN1 c3RvbSBwYWRkaW5nLCBhbGlnbm1lbnQgKGNlbnRlciwgbGVmdCwgcmlnaHQpLCBldGMuCiAgU3Vj aCBwcm9wZXJ0aWVzIGNvdWxkIGJlIGFyYml0cmFyeSBhcyBsb25nIGFzIG1hcHBpbmcgdGhlIHVz ZXIgaW5wdXQgYmFjayB0byB0aGUgL2xpbmtlZCBidWZmZXIvIGNhbiBiZSBwZXJmb3JtZWQuCiAg VGhpcyB3aWxsIGFsbG93IHZpc3VhbCBjdXN0b21pemF0aW9ucy4KCiAgL1JlcHJlc2VudGF0aW9u cy8gc2hvdWxkIGJlIG1vZGlmaWFibGUgKHRocm91Z2ggc29tZSBpbnRlcmZhY2UpLgoKICBUaGUg dXNhZ2Ugb2YgL3NoYXJlZCBibG9ja3MvIGFib3ZlIGlzIHJlYWxseSBmb3IgZXhwbGFuYXRvcnkg cHVycG9zZXMgYW5kLCBwb3NzaWJseSwgbGVzcyBvZiBhIG5lY2Vzc2l0eSAoYnV0IG1heSBpbmRl ZWQgY29tZSBpbiB1c2VmdWwgd2hlbiBtdWx0aXBsZSByZXByZXNlbnRhdGlvbnMpLgoKICBTYXZp bmcgaXMgYWxzbyBhbiBpbXBvcnRhbnQgdGhpbmcgdG8gZGlzY3Vzcy4KICBUaGUgbGVucyBzaG91 bGQgYmUgYWJsZSB0byBmb3JtIGFuIGFyZWEsIHdoZXJlIHRoZSBkaXNwbGF5ZWQgdGV4dCAvc2hh ZG93cy8gdGhlIHRleHQgd2hpY2ggYWN0dWFsbHkgbmVlZHMgdG8gYmUgc2F2ZWQuCiAgVGhpcyBp cyBkb2FibGU6IGluIG9yZy1tb2RlLCB3aGVuIHlvdSBmb2xkIGEgdGl0bGUsIHRoZSBlbGxpcHNp cyBoYXZlIGFyYml0cmFyeSBkYXRhIGhpZGRlbiBpbiB0aGVpciBwbGFjZS4KICBCdXQgdGhlIHBv c3NpYmlsaXRpZXMgYXJlOgogIC0gdXNlIGZhY2VzL2ZvbGRpbmcgb3Igc3VjaCAoSSBhbSBub3Qg dG9vIGZhbWlsaWFyIHcvIHRoZSBhc3NvY2lhdGVkIHRlY2huaWNhbGl0aWVzLCBidXQgSSB0aGlu ayB0aGV5IGNvdWxkIHdvcmspLCBvcgogIC0gKHdoYXQgc2VlbXMgbGlrZSB0aGUgYmV0dGVyIHNv bHV0aW9uKSwgdGhlIHNhdmUgb3BlcmF0aW9uIGNvdWxkIGdyYWIgdGhlIC9zaGFyZWQgYmFzZS8g d2hpY2ggdGhlIC9hcmVhLyB1c2VzIChvciBxdWVyeSB0aGUgbGVucyBmb3Igd2hhdCB0byBzYXZl KS4KCiAgQW5kIGFzIGZvciB0aGUgdW5kbyBiZWhhdmlvciwgd2hhdCdzIGNsZWFyIGlzIHRoYXQg dGhlIGNoYW5nZXMgd2lsbCBuZWVkIHRvIGJlIHRyYWNrZWQgdG8gdGhlIC9zaGFyZWQgYmFzZS8g b2YgYWxsIC9hcmVhcy8gb2YgdGhlIHNhbWUgL3JlcHJlc2VudGF0aW9uLy4KCiogUHJhY3RpY2Fs IEFwcGxpY2F0aW9ucwoKKiogT3JnLW1vZGUKCiAgT3JnLW1vZGUsIGEgZGlzdGluY3QgcGxhbmVz Y2FwZSBpbiB0aGUgRW1hY3MgbXVsdGl2ZXJzZSwgbWlnaHQgYmUgdGhlIG1vZGUgdG8gYmVuZWZp dCB0aGUgbW9zdCBmcm9tIHRoZSB1c2Ugb2YgbGVuc2VzLgoKKioqIDNEIFRhYmxlcwoKICAgIFN1 cHBvc2UgeW91IGhhdmUgdGhyZWUgdGFibGU6CgogICAgfCAwIHwgMCB8IDAgfAogICAgfCAwIHwg QSB8IDAgfAogICAgfCAwIHwgMCB8IDAgfAoKICAgIHwgMCB8IEIgfCAwIHwKICAgIHwgQiB8IDAg fCBCIHwKICAgIHwgMCB8IEIgfCAwIHwKCiAgICB8IEMgfCAwIHwgQyB8CiAgICB8IDAgfCAwIHwg MCB8CiAgICB8IEMgfCAwIHwgQyB8CgogICAgU2F5LCB0aGVzZSB0YWJsZXMgYXJlIGp1c3QgdGhl IGxheWVycyBvZiBhIDN4MyBjdWJlLgogICAgWW91IG1pZ2h0IHdhbnQgdG8gdmlldyB0aGlzIGN1 YmUgYXMgYSBkaXN0aW5jdCBlbnRpdHk6CiAgICAKICAgIC0qKkxBWUVSIDEqKi0KICAgIHwgMCB8 IDAgfCAwIHwKICAgIHwgMCB8IEEgfCAwIHwKICAgIHwgMCB8IDAgfCAwIHwKCiAgICBZb3UgY291 bGQgdXNlIGEgY29tcG9zaXRlIGxlbnMgZm9yIHRoaXMuCiAgICBUaGUgL21vZGVsLyB3b3VsZCBi ZSB0aHJlZSBidWZmZXJzLCBvbmUgdGFibGUgaW4gZWFjaC4KICAgIFRoZSAvcmVwcmVzZW50YXRp b24vIGRlc2NyaWJlcyB0aGUgL3ZpZXcvIGFzOgogICAgLSBhcyBhIHN0cmluZyAoIi0qKkxBWUVS IDEqKi0iKSBhbmQKICAgIC0gYSAvYnVmZmVyIGxlbnMvIGxpbmtpbmcgb25lIG9mIHRoZSB0aHJl ZSBidWZmZXJzIGluIHRoZSAvbW9kZWwvLgoKICAgIE9uZSBjb3VsZCBjb21tYW5kIHRoZSBsZW5z IHRvIHN3aXRjaCB0byB0aGUgbmV4dCBsYXllcjoganVzdCBjaGFuZ2UgdGhlIC9yZXByZXNlbnRh dGlvbi8uCgogICAgV2hlbiB0aGUgY3Vyc29yIGlzIGluIHRoZSAvYXJlYS8sIHRoZSB1c2VyIGlu cHV0IG5vdyBpcyBoYW5kbGVkIGluIGl0cyAvbGlua2VkIGJ1ZmZlci8uCiAgICBXaGVuIHRoZSBj dXJzb3IgaXMgZGlyZWN0bHkgb24gdGhlIHRhYmxlLCB0aGUgaW5wdXQgaXMgcmVsYXllZCB0byB0 aGUgL2J1ZmZlciBsZW5zLyBvZiB0aGUgdGFibGUsIHdob3NlIC9hcmVhJ3MvIC9saW5rZWQgYnVm ZmVyLyBoYXMgb3JnLW1vZGUgcnVubmluZy4KCiAgICBUaGUgdGFibGVzIGFyZSBpZGVudGlmaWVk IGFuZCByZXBsYWNlZCB3aGVuIHRoZSAvbGVucy1tb2RlLyBydW5zIGZvciB0aGUgZmlyc3QgdGlt ZS4KICAgIEJ1dCB3aGF0IHNob3VsZCBoYXBwZW4gd2hlbiB0aGUgdXNlciBzYXZlcyB0aGUgYnVm ZmVyPwogICAgV2Ugd2FudCB0byBzYXZlIGFsbCB0aHJlZSB0YWJsZXMsIG5vdCBqdXN0IHRoZSBv bmUgd2hpY2ggaGFwcGVucyB0byBiZSBjdXJyZW50bHkgdmlld2VkLgogICAgVGhlIHBvc3NpYmxl IHNvbHV0aW9uLCBhcyBkaXNjdXNzZWQgaW4gW1tNZWNoYW5pY3NdXSwgY291bGQgYmUgdG8gL3No YWRvdy8gdGhlIHRocmVlIHRhYmxlcy4KCiAgICBPZiBjb3Vyc2UsIHRhYmxlcyBjYW4gYmUgZXhw bG9yZWQgaW4gYW55IHdheSwgbm90IGp1c3QgbGF5ZXIgYnkgbGF5ZXIuCiAgICBodHRwczovL2Vu Lndpa2lwZWRpYS5vcmcvd2lraS9PbmxpbmVfYW5hbHl0aWNhbF9wcm9jZXNzaW5nCgogICAgU28s IHRvIGdpdmUgYSBwZXJzcGVjdGl2ZSBvbiBhbGwgdGhpczogYSB0YWJsZSBiZWNvbWVzIGFuIG9i amVjdCBhbmQgdGhlIG1vZGVzIHRoYXQgcnVuIGluIHRoZSAvbGlua2VkIGJ1ZmZlci8gZm9ybSB0 aGUgaW50ZXJmYWNlIHRvIHRoaXMgb2JqZWN0LgogICAgQW5kLCByZWFsbHksIGEgdGFibGUgaXMg YSB0YWJsZSBmb3IgZXhhbXBsZSBwdXJwb3NlcywgYW5kLCBvYnZpb3VzbHksIGFueXRoaW5nIGVs c2UgY291bGQgYmUgaW4gaXRzIHBsYWNlLgoKKioqIENvZGUgQmxvY2tzIGFuZCBSZXN1bHRzOiBF ZGl0aW5nIGFuZCBWaWV3aW5nCgogICAgSGVyZSBJIHdpbGwgZmlyc3QgZGlzY3VzcyBhbGwgdGhl IHJlbGV2YW50IHByb2JsZW1zIGFuZCB0aGVuIHByb3Bvc2UgYSBzb2x1dGlvbi4KCioqKiogUHJv YmxlbXMKKioqKiogRWRpdGluZyBTb3VyY2UgQmxvY2tzIFswLzVdCgogICAgIENvbnNpZGVyIHRo aXMgYmxvY2s6CgogICAgICMrQkVHSU5fU1JDIGVsaXNwCiAgICAgICAoZGVmdW4gc3RlcCAoeCBs KQogICAgICAgICAoY2FzZSAoPCB4IGwpIDAKICAgICAgICAgICAgICAgdCAxKSkKICAgICAjK0VO RF9TUkMKCiAgICAgRmlyc3QsICduZXdsaW5lLWFuZC1pbmRlbnQgZG9lc24ndCBpbmRlbnQgdGhl IGNvZGUgY29ycmVjdGx5LgogICAgIEl0IHNpbXBseSBzZWVtcyB0byBsb29rIGF0IHRoZSBmaXJz dCBzeW1ib2wgb2YgdGhlIHByZXZpb3VzIGxpbmU6CgogICAgIC0gWyBdIHN1cHBvcnQgZm9yIG1v ZGUtc3BlY2lmaWMgZWRpdGluZyBmZWF0dXJlcyBpcyBsaW1pdGVkLAogICAgIC0gWyBdIHRoZSBt b2RlLXNwZWNpZmljIGludGVyYWN0aXZlIGZlYXR1cmVzIChzYXksIGtleWJpbmRpbmdzKSBhcmUg ZGlzcmVnYXJkZWQuCgogICAgIFVzaW5nICdvcmctZWRpdC1zcmMtY29kZSBoZWxwcywgYnV0IGl0 IGlzIGEgaGFzc2xlLgoKICAgICBXaGF0J3MgbW9yZSwgZXZlcnkgdGltZSAnb3JnLWVkaXQtc3Jj LWNvZGUgaXMgdXNlZDoKCiAgICAgLSBbIF0gYSBuZXcgYnVmZmVyIGlzIGNyZWF0ZWQsIHdoaWNo IGltcGxpZXMgaW5pdGlhbGl6YXRpb24gb2YgdGhlIGJ1ZmZlciBtb2RlcywKICAgICAtIFsgXSB0 aGUgY2hhbmdlcyBuZWVkIHRvIGJlIHdyaXR0ZW4gYmFjay4KCiAgICAgVGhlIGlzc3VlcyB3aXRo IHRoZSBwb2ludHMgYWJvdmUgY2FuIGJlIGRlbW9uc3RyYXRlZCBieSBvYnNlcnZpbmcgdGhlIGJ1 Z3Mgdy8gJ29yZy1jb21tZW50LWR3aW06CgogICAgIC0gdGhlIHNjcmVlbiBpcyBzY3JvbGxlZCB0 byBzaG93IHRoZSBmaXJzdCBsaW5lIG9mIHRoZSBibG9jaywKICAgICAtIGluIHZpc3VhbCBsaW5l IG1vZGUsIHRoZSBjdXJzb3IganVtcHMgdG8gdGhlIGJlZ2lubmluZyBvZiB0aGUgYmxvY2suCgog ICAgIE1hcmtzIGFyZSB0aHJvd24gYmFjayB0byB0aGUgYmVnaW5uaW5nIG9mIHRoZSBibG9jayAt LSBmb3IgdGhlIHNhbWUgcmVhc29uLgoKICAgICBBbHNvLCB0aGUgbGFyZ2VyIHRoZSBjb2RlIGJs b2NrLCB0aGUgbW9yZSB3b3JrIGhhcyB0byBiZSBkb25lLCBzbywKCiAgICAgLSBbIF0gc29tZSBs YWcgaXMgdG8gYmUgZXhwZWN0ZWQuCgogICAgIChCdWcgcmVwb3J0IGZvciB0aGUgY29tbWVudGlu ZyBiZWhhdmlvcjogaHR0cHM6L3NkZWJidWdzLmdudS5vcmcvY2dpL2J1Z3JlcG9ydC5jZ2k/YnVn PWJ1ZyUyMzM0OTc3KQoKKioqKiogVmlld2luZyBTb3VyY2UgQmxvY2tzIGFuZCBSZXN1bHRzIFsw LzZdCgogICAgIENvbnNpZGVyIHRoZXNlIHR3byBibG9ja3M6CgogICAgICMrTkFNRTogc3ludGF4 LXRhbmdsaW5nLWNvbW1lbnRpbmcKICAgICAjK0JFR0lOX1NSQyBlbGlzcAogICAgICAgKGRlZnVu IHN0ZXAgKHggbCkKICAgICAgICAgKGNhc2UgKDwgeCBsKSAwCiAgICAgICAgICAgICAgIHQgMSkp CiAgICAgIytFTkRfU1JDCgogICAgICMrQkVHSU5fU1JDIGVsaXNwIDpub3dlYiB5ZXMKICAgICAg IDw8c3ludGF4LXRhbmdsaW5nLWNvbW1lbnRpbmc+PgogICAgICAgKHN0ZXAgIndyb25nIGFyZ3Vt ZW50IikKICAgICAjK0VORF9TUkMKCiAgICAgRmlyc3QgYW5kIGZvcmVtb3N0LCB0aGVyZSBpcyBu byBzeW50YXggY2hlY2tpbmcgYW5kIG5laXRoZXIgaXMgdGhlcmUgY29tcGxldGlvbjoKCiAgICAg LSBbIF0gd2hhdCBjYW4gYmUgZWFzaWx5IGRvbmUgaW4gYSBzZXBhcmF0ZSBidWZmZXIgdy8gc29t ZSBtb2RlIG9uIGNhbid0IGJlIGRvbmUgaW5saW5lLgoKICAgICBBbmQgdXNpbmcgJ29yZy1lZGl0 LXNyYy1jb2RlIGlzIG5vdCBtdWNoIG9mIGEgcmVsaWVmIGFzIHRoZSBzeW50YXggY2hlY2tlciBh bmQgdGhlIGNvbXBsZXRlciBoYXZlIAoKICAgICAtIFsgXSBubyB3YXkgb2YgZGVhbGluZyB3aXRo IHJlZmVyZW5jZXMgdG8gcHJvY2VzcyBjb2RlIGFzIGlmIHRhbmdsZWQgaW4uCgogICAgIFRoZSBj b25zZXF1ZW5jZXMgb2YgdGhpcyBwb2ludCBhcmUgZmFydGhlciB0aGFuIHRob3NlIG9mIHRoZSBt aXNzaW5nIHN5bnRheCBjaGVja2luZyBvciBjb21wbGV0aW9uOgogICAgIHNvbWV0aW1lcywgbG9v a2luZyBhdCBjb2RlIGFzIGEgY29oZXJlbnQgd2hvbGUsIGFuZCBub3QgYSBzZXJpZXMgb2YgZGlz Y29ubmVjdCBzbmlwcGV0cywgaXMgd2hhdCB0aGUgcHJvZ3JhbW1lciBuZWVkcy4KCiAgICAgSW4g cHJpbmNpcGxlLCBpdCBjb3VsZCBiZSBwb3NzaWJsZSBmb3IgJ29yZy1lZGl0LXNvdXJjZS1jb2Rl IHRvIHN1YnN0aXR1dGUgY29kZSBmb3IgZWFjaCByZWZlcmVuY2UsIGJ1dCB0aGlzIGlzIHByb2Js ZW1hdGljIGR1ZSB0byB0aGUgcG9pbnRzIG1hZGUgaW4gW1tFZGl0aW5nIFNvdXJjZSBCbG9ja3Nd XSBzZWN0aW9uLgoKICAgICBOZXh0LCB3aGVuIHNvbWUgZmFpbGVkIGFzc2VydGlvbiBvciBhIHJ1 bnRpbWUgZXJyb3IgdGVsbHMgeW91IGEgbGluZSBudW1iZXIsIGxvb2tpbmcgZm9yIGl0IGlzIHRv dWdoLgogICAgIEJ1dCB0aGVyZSBpcyBubyB3YXkgdG8gc2hvdyBsaW5lIG51bWJlcnMgKGFic29s dXRlLCBhcyBpZiByZWZlcmVuY2VzIHdlcmUgZXhwYW5kZWQpLgogICAgIE9yIHN1cHBvc2UgYSBz b3VyY2UgYmxvY2sgcHJvZHVjZXMgYSBodWdlIHRhYmxlLgogICAgIFRoaXMgbWVhbnMgeW91IHdp bGwgd2FudCB0byB0cnVuY2F0ZSBsaW5lcy4KICAgICBCdXQgbWF5YmUgdGhhdCdzIG5vdCB3aGF0 IHlvdSB3YW50IGZvciB0aGUgcmVzdCBvZiB5b3VyIGJ1ZmZlci4KICAgICBUaGVzZSBib2lsIGRv d24gdG86CgogICAgIC0gWyBdIGNhbid0IHZpZXcgYSBzcGVjaWZpYyBhcmVhIG9mIGEgYnVmZmVy LCBsaWtlIDpyZXN1bHRzIG9yIGEgc291cmNlIGJsb2NrLCBhcyBpZiBpdCB3ZXJlIGluIGFub3Ro ZXIgYnVmZmVyLgoKICAgICBPbmUgb3RoZXIgbmljZSBmZWF0dXJlIHRvIHNlZSB3b3VsZCBiZSBy dW5uaW5nIHRoZSBjb2RlIGFuZCBzZWVpbmcgdGhlIHJlc3VsdHMgZnJvbSB3aXRoaW4gJ29yZy1l ZGl0LXNyYy1jb2RlLgogICAgIEN1cnJlbnRseSwgaWYgb25lIHdvcmtzIHVzaW5nICdvcmctZWRp dC1zcmMtY29kZSwgcnVubmluZyB0aGUgY29kZSBpcyBub3QgYW4gb3B0aW9uLCBiZWNhdXNlIHlv dSB3b3VsZG4ndCBzZWUgdGhlIDpSRVNVTFRTIGFueXdheS4KICAgICBDdXJyZW50bHksIHN3aXRj aGluZyBpcyBuZWNlc3NhcnkgZnJvbSB0aGUgZWRpdCBidWZmZXIgdG8gdGhlIG1haW4gYnVmZmVy IGFuZCBiYWNrLgogICAgIFRoaXMgcHJvYmxlbSBjb3VsZCBiZSBzb2x2ZWQgYnkgcmVkaXJlY3Rp bmcgdGhlIG91dHB1dCB0byBzb21lIGJ1ZmZlciBhbmQgc3BsaXQgc2NyZWVuaW5nLCBidXQsIHRo ZW4gYWdhaW4sIHVwZGF0aW5nIHRoZSBvcmlnaW5hbCBidWZmZXIgaXMgcmVxdWlyZWQuCgogICAg IC0gWyBdIElmIHRoZSByZXN1bHRzIG9mIGV4ZWN1dGlvbiB3ZXJlIHRvIGJlIHJlZGlyZWN0ZWQg dG8gYSBzZXBhcmF0ZSBidWZmZXIsIHRoZXkgd291bGQgaGF2ZSB0byBiZSBtYXBwZWQgYmFjayB0 byB0aGUgb3JpZ2luYWwgZmlsZSBmb3IgY29uc2lzdGVuY3kuCgogICAgIExldCdzIG5vdyBkaXNj dXNzIHRoZSB2aXN1YWwgcHJvcGVydGllcyBvZiBjb2RlIGJsb2NrcyBhbmQgOnJlc3VsdHMuCgog ICAgICMrTkFNRTogb25lLWxpbmVyCiAgICAgIytCRUdJTl9TUkMgZWxpc3AKICAgICAgIChkZWZ1 biBzdGVwICh4IGwpIChjYXNlICg8IHggbCkgMCB0IDEpKQogICAgICMrRU5EX1NSQwoKICAgICBG b3IgdHdvIGxpbmVzIG9mIG1lYW5pbmdmdWwgZGF0YSwgdGhlcmUgYXJlIGZvdXIgbGluZXMgb2Ys IGFkbWl0dGVkbHksIG5vaXNlLgogICAgIE1lYW5pbmdmdWw6IHRoZSBzdHVmZiB0aGF0IHRoZSBw cm9ncmFtbWVyIGNvbmNlbnRyYXRlcyBvbi4gCiAgICAgRm9yIGxvbmdlciBzbmlwcGV0cywgdGhl IG5vaXNlLXRvLXNpZ25hbCByYXRpbyBkcm9wcywgYnV0IHdoZW4geW91IGhhdmUgYSBsb3Qgb2Yg c25pcHBldHMsIHRoZXNlIGV4dHJhIGxpbmVzIG9mIHBhcmFtZXRlcnMgYWRkIHVwLgogICAgIEFu ZCBldmVyeXRoaW5nIHN0YXJ0cyBsb29raW5nIGxpa2Ugc3BpZGVycyBtYWtpbmcgbG92ZSBpbiBh IGJvd2wgb2Ygc3BhZ2hldHRpLgoKICAgICBJIHRoaW5rIG9uZSB3YXkgd2hpY2ggY291bGQgaGVs cCBpcyB0byBoYXZlIGEgc3VtbWFyeSBsaW5lIGFuZCBoaWRlIHRoZSByZXN0OgoKICAgICA+IFtv bmUtbGluZXJdIChlbGlzcCkgPG90aGVyIHN0dWZmPgogICAgID4gIChkZWZ1biBzdGVwICh4IGwp IChjYXNlICg8IHggbCkgMCB0IDEpKQoKICAgICBBbmQgd2hlbiBpdCBpcyBuZWNlc3NhcnkgdG8g ZWRpdCB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIGJsb2NrLCBvbmUgY291bGQgZXhwYW5kIGl0IG9u IGEga2V5IGNvbWJpbmF0aW9uOgoKICAgICAtIHRoZSBhcHBlYXJhbmNlIG9mIGJsb2NrcyBjb3Vs ZCBiZSBtb3JlIGRpc3RpbmN0IGFuZCBsZXNzIG5vaXN5LgoKICAgICBUbyBhZGQgdG8gdGhpcywg bm90ZSBob3cgdGhlIGNvZGUgaW4gdGhlIHNvdXJjZSBibG9ja3MgaXMgaW5kZW50ZWQgdHdvIHNw YWNlcyBmb3J3YXJkLgogICAgIFRob3NlIGFyZSBoYXJkIHNwYWNlcyBhbmQgdGhleSB3ZXJlbid0 IGluc2VydGVkIHJpZ2h0IGF3YXksIG9ubHkgYWZ0ZXIgdXNpbmcgJ29yZy1lZGl0LXNyYy1jb2Rl LgogICAgIE5vIGRvdWJ0LCB0aGlzIGluZGVudGF0aW9uIGhlbHBzLgogICAgIEhvd2V2ZXIsIGl0 IHdvdWxkIGJlIGJldHRlciBmb3IgaXQgdG8gYmUgcHVyZWx5IHZpc3VhbCBhbmQgdG8gYmUgdGhl cmUgd2l0aG91dCBoYXZpbmcgdG8gY2FsbCBhbnl0aGluZy4KCiAgICAgSW4gc2hvcnQ6CgogICAg IC0gWyBdIGEgcG93ZXJmdWwgd2F5IHRvIGN1c3RvbWl6ZSB0aGUgdmlldyBvZiBibG9ja3MgaXMg bmVlZGVkLgoKICAgICBOZXh0LCB0aGUgL29iLWFzeW5jLyBwYWNrYWdlIHNob3dzIHRoYXQgYXN5 bmNocm9ub3VzIGV4ZWN1dGlvbiBvZiBibG9ja3MgaXMgcG9zc2libGUuCiAgICAgQXBwYXJlbnRs eSwgdGhlIHdheSBpdCB3b3JrcyBpcyBieSBwbGFjaW5nIGEgdW5pcXVlIGlkZW50aWZpZXIgaW4g dGhlIFJFU1VMVFMgYW5kIHRoZW4gcmVwbGFjaW5nIGl0LgogICAgIEFub3RoZXIgcG9zc2libGUg c2NlbmFyaW86IGRpc3BsYXkgdGhlIGN1cnJlbnQgcnVubmluZyB0aW1lIGluIHRoZSBmb290ZXIg b2YgYSBibG9jay4KICAgICBJcyB0aGUgZmluZC9zZWFyY2ggcHJvY2VkdXJlIHRoZSBiZXN0IG9u ZSBjb3VsZCBkbz8KCiAgICAgLSBbIF0gQSB1bmlmaWVkIHdheSB0byB1cGRhdGUgdGhlIHZpZXcg b2YgYSBibG9jayAvIHJlc3VsdHMgc2VjdGlvbiBjb3VsZCBoZWxwLgoKKioqKiBTb2x1dGlvbgoq KioqKiBCYXNpcwoKICAgIEEgc291cmNlIGJsb2NrIGNhbiBiZSBzaG93biB2aWEgYSAvY29tcG9z aXRlIGxlbnMvLgogICAgQW5kIHNvIGNhbiBiZSBldmVyeSBub3dlYiByZWZlcmVuY2UuCgogICAg Rm9yIGluc3RhbmNlLCBzdXBwb3NlIGEgYnVmZmVyIChjYWxsIGl0IC9tYWluIGJ1ZmZlci8pIGhh cyB0aGVzZSBibG9ja3MgKGFsc28gdXNlZCBpbiB0aGUgZm9sbG93aW5nIHN1YnNlY3Rpb25zKToK CiAgICAjK05BTUU6IGJsb2NrLUEKICAgICMrQkVHSU5fU1JDIHB5dGhvbgogICAgICAgZiA9IGxh bWJkYSB4OiB4ICoqIHgKICAgICMrRU5EX1NSQwoKICAgICMrTkFNRTogYmxvY2stQgogICAgIytC RUdJTl9TUkMgcHl0aG9uIDpub3dlYiB5ZXMKICAgICAgIDw8YmxvY2stQT4+CiAgICAgICBnID0g bGFtYmRhIHg6IGYoeCkgKyBmKHggKyAxKQogICAgIytFTkRfU1JDCgogICAgU28sIHRoZXNlIGxl bnNlcyBhcmUgY3JlYXRlZDoKICAgIC0gL2Jsb2NrLUEvIC9jb21wb3NpdGUgbGVucy8gY29udGFp bmluZzoKICAgICAgIC0gL2J1ZmZlci1BLyAvbGVucy8gKHcvIGNvbnRlbnRzICJmID0gbGFtYmRh IHg6IHggKiogeCIpCiAgICAgICAtIGJlZ2luL2VuZCBzb3VyY2UgbWFya2VycyBhcyBwbGFpbiB0 ZXh0CiAgICAtIC9ibG9jay1CLyAvY29tcG9zaXRlIGxlbnMvIGNvbnRhaW5pbmc6CiAgICAgICAt IC9idWZmZXItQS8gL2xlbnMvICh3LyBjb250ZW50cyAiZiA9IGxhbWJkYSB4OiB4ICoqIHgiIHNo YWRvd2luZyAiPDxibG9jay1BPj4iIG9yIGp1c3QgIjw8YmxvY2stQT4+IikKICAgICAgIC0gL2J1 ZmZlci1CLyAvYnVmZmVyIGxlbnMvICh3LyBjb250ZW50cyAiZyA9IGxhbWJkYSB4OiBmKHgpICsg Zih4ICsgMSkiKQoKICAgIEFzIHlvdSBzZWUsIHRoZSBjb2RlIG9mIGJsb2NrLUEgYXBwZWFycyBp biB0d28gYmxvY2tzOiBhcyBjb2RlIGFuZCBhcyBhIHJlZmVyZW5jZS4KICAgIEEgcmVhc29uYWJs ZSB0aGluZyB0byBkbyBpcyBjcmVhdGUganVzdCBvbmUgbGVucyBmb3IgYm90aC4KICAgIFNvLCB0 aGlzIGxlbnMgc2hvdWxkIGNvbnRhaW4gdGhlIGNvZGUsIGJ1dCBzaG91bGQgYWxzbyBiZSBhYmxl IHRvIHNob3cganVzdCB0aGUgcmVmZXJlbmNlLgogICAgVGhlcmUgYXJlIG11bHRpcGxlIHdheXMg dG8gZGlzcGxheSB0aGlzIGxlbnMgKHRoYXQgaXMsIHRvIGZvcm0gYW4gL2FyZWEvKToKICAgIHNo b3cgdGhlIGNvZGUvcmVmZXJlbmNlIHdoaWNoLCAvb3B0aW9uYWxseS8sIHNoYWRvd3MgcmVmZXJl bmNlL2NvZGUuCiAgICBGb3IgZXhhbXBsZSwgaW4gYmxvY2stQiwgd2UgbWF5IGNob29zZSB0byBz aG93IGNvZGUgYW5kIHNoYWRvdyB0aGUgcmVmZXJlbmNlLCBzbyB0aGF0IHdoZW4gdGhlIGRvY3Vt ZW50IGlzIHNhdmVkLCB0aGUgdGV4dCBvZiB0aGUgcmVmZXJlbmNlIGlzIGFjdHVhbGx5IHNhdmVk IGFuZCBub3QgdGhlIGNvZGUuCgogICAgU28sIGluIHRoZSBlbmQsIHRoZXJlIGlzIGp1c3Qgb25l IGxlbnMgZm9yIC9idWZmZXItQS8sIHdpdGggdHdvIC9hcmVhcy8sIG9uZSBmb3IgL2Jsb2NrLUIv IGFuZCBvbmUgZm9yIC9ibG9jay1BLy4KICAgIFRoZSBsZW5zIGNvdWxkIGJlIGVpdGhlciAvYnVm ZmVyLWxlbnMvIG9yIGEgL2NvbXBvc2l0ZS1sZW5zLywgaXQncyB1cCB0byB0aGUgaW1wbGVtZW50 YXRpb24uCgoqKioqKiBFZGl0aW5nCgogICAgVGhlIG1vc3QgaW1wb3J0YW50IHBvaW50IHRvIHJl bWVtYmVyIG5vdyBpcyB0aGlzOiAKICAgIHRoZSBsaW5rZWQgYnVmZmVyIGhhcyBpdHMgb3duIHNl dCBvZiBtb2RlcywgaW5kZXBlbmRlbnQgb2YgdGhlIG1vZHMgaW4gdGhlIHdvcmtpbmcgYnVmZmVy LgoKICAgIExlbnMtbW9kZSBvZmZlcnMgYW4gaW1wb3J0YW50IHV0aWxpdHkgKGRpc2N1c3NlZCBp biBbW01lY2hhbmljc11dKTogCiAgICBpdCBjYW4gcmVkaXJlY3Qga2V5YmluZGluZ3MgYW5kIGNv bW1hbmRzIHdoZW4gdGhlIGN1cnNvciBpcyBpbiB0aGUgYXJlYSBvZiB0aGUgbGVucy4KICAgIFNv LCBiYXNpY2FsbHksIHRoZSB1c2VyIGNhbiBoYXZlIGFjY2VzcyB0byBhbGwgdGhlIGZlYXR1cmVz IG9mIHRoZSBtb2RlcyB3aGljaCBydW4gaW4gdGhlIGxpbmtlZCBidWZmZXIuCiAgICBUaGlzIGlt bWVkaWF0ZWx5IGltcGxpZXMgcHJvcGVyIGluZGVudGF0aW9uIGFuZCB0aGUgcmVzb2x1dGlvbiBv ZiB0aGUgYnVnIHcvIGNvbW1lbnRpbmcuCiAgICAoY29tbWVudCBrZXliaW5kaW5nIGlzIGZvcndh cmRlZCB0byB0aGUgL2lubmVyIGJ1ZmZlci8gYW5kIHRoZSByaWdodCB0aGluZyBpcyBkb25lIHRo ZXJlLikKCiAgICBBbmQgd2hhdCBhYm91dCAnb3JnLWVkaXQtc3JjLWNvZGU/CiAgICBKdXN0IG9w ZW4gYSBidWZmZXIgYW5kIHNob3cgdGhlIC9idWZmZXItQS9CLyBsZW5zIHRoZXJlIQogICAgTm8g bmVlZCB0byB3cml0ZSB0aGUgY2hhbmdlcyBiYWNrOiBhbGwgdGhlIGFyZWFzIG9mIHRoZSBsZW5z IHVwZGF0ZSBpbiByZWFsIHRpbWUuCgoqKioqKiBWaWV3aW5nCgogICAgSW4gYWRkaXRpb24gdG8g dGhlIHR3byBibG9ja3MgZnJvbSBbW0Jhc2lzXV0sIGxldCdzIGRlZmluZToKCiAgICAjK05BTUU6 IGJsb2NrLUMKICAgICMrQkVHSU5fU1JDIHB5dGhvbiA6bm93ZWIgeWVzCiAgICAgICA8PGJsb2Nr LUI+PgogICAgICAgaCA9IDEwICogZig1KSAqIGcoMikKICAgICMrRU5EX1NSQwoKICAgICMrTkFN RTogYmxvY2stRAogICAgIytCRUdJTl9TUkMgcHl0aG9uIDpub3dlYiB5ZXMKICAgICAgIDw8Ymxv Y2stQj4+CiAgICAgICB5ID0gZygxKQogICAgIytFTkRfU1JDCgogICAgU28sIHRoZSBkZXBlbmRl bmN5IHRyZWUgaXMgdGhpczoKICAgIGJsb2NrLUEgPC0tIGJsb2NrLUIgPC0tIGJsb2NrLUMKICAg ICAgICAgICAgICAgICAgICAgICAgPC0tIGJsb2NrLUQKCiAgICBGaXJzdCwgbGV0J3Mgc2VlIHdo YXQgY2FuIGJlIGRvbmUgYWJvdXQgc3ludGF4IGNoZWNraW5nLCBjb21wbGV0aW9uIGFuZCB0aGUg cG9zc2liaWxpdHkgb2Ygdmlld2luZyBhbGwgdGhlIGNvZGUgYXQgb25jZS4KICAgIEhvdyBjYW4g d2UgZGVhbCB3aXRoIHRoZSBub3dlYiByZWZlcmVuY2VzPwoKICAgIFVuZGVyc3RhbmRpbmcgd2hh dCBpdCBpcyBleGFjdGx5IHRoYXQgd2Ugd2FudCBtYXkgaGVscCB1cyBhbnN3ZXIgdGhlIHF1ZXN0 aW9uLgogICAgQSByb3VnaCBsaXN0IG9mIHJlcXVpcmVtZW50cy93aXNoZXMgY291bGQgYmU6Cgog ICAgKHJlZ2FyZGxlc3Mgb2Ygd29ya2luZyBpbiB0aGUgL21haW4gYnVmZmVyLyBvciB1c2luZyAn b3JnLWVkaXQtc3JjLWNvZGUpCiAgICAtICgxKSBoYXZlIGFuIG9wdGlvbiB0byBleHBhbmQgdGhl IHJlZmVyZW5jZXMgaW50byBjb2RlCiAgICAtICgyKSBoYXZlIHN5bnRheCBjaGVja2luZyBhbmQg Y29tcGxldGlvbjoKICAgICAgIC0gKGEpIHdoaWNoIHdvcmsgYXMgaWYgdGhlIHJlZmVyZW5jZXMg d2VyZSBleHBhbmRlZCAocmVnYXJkbGVzcyBvZiB0aGUgYWN0dWFsIHJlZmVyZW5jZSBleHBhbnNp b24gb3B0aW9ucyksCiAgICAgICAtIChiKSB3aGljaCB3b3JrIGFzIGlmIHRoZSBjb2RlIHRoYXQg cmVmZXJlbmNlcyB0aGUgYmxvY2sgaXMgc2VlbiBhcyB3ZWxsIAogICAgICAgICAtIGlmIGluY2x1 ZGVkIGJ5IG11bHRpcGxlIGJsb2NrcyAoZS5nLiBpbiBjYXNlIG9mIH5ibG9jay1CfiwgdGhlIHVz YWdlIGJ5IH5ibG9jay1DfiBhbmQgfmJsb2NrLUR+KSwgcHJlZmVyIHRoZSBvbmUgd2hpY2ggcmFu IGxhc3QuCiAgICAgICAtIChjKSBhbmQgbWluaW1pemUgdGhlIHdvcmsgZG9uZS4KCiAgICBPSywg YWxsIG9mIHRoZSBhYm92ZSBjYW4gZXhwbG9pdCB0aGUgZnVuY3Rpb25hbGl0eSBvZiBsZW5zZXMs IHdoaWNoLCB1cG9uIHJlcXVlc3QsIGNhbiBwcm9kdWNlIHRoZSByaWdodCAvYXJlYS8gYmFzZWQg dGhlIHByZWZlcmVuY2VzIG9mIHRoZSBidWZmZXIgd2hpY2ggY29udGFpbnMgdGhlIC9sZW5zLy4K ICAgICgxKSBpcyBjb3ZlcmVkOiB0aGUgbGVuc2VzIGZvciByZWZlcmVuY2VzIGFyZSByZWN1cnNp dmVseSBhc2tlZCB0byBzaG93IGNvZGUgaW5zdGVhZCBvZiB0aGUgcmVmZXJlbmNlLgogICAgKDIp IGlzIGFsc28gY292ZXJlZCAtIGxldCdzIGRpc2N1c3MgdGhlIGRldGFpbHMuCgogICAgV2hhdCBp cyBwb2ludCAoMiksKGIpIGFsbCBhYm91dD8KICAgIFdoeSB3b3VsZCA8PGJsb2NrLUI+PiBjYXJl IGFib3V0IHdobyByZWZlcmVuY2VzIGl0IChpLmUgYmxvY2tzIEMgYW5kIEQpPwogICAgV291bGRu J3QgaXQgYmUgZW5vdWdoIGZvciB0aGUgc3ludGF4IGNoZWNrZXIgdG8gdmlldyBqdXN0IHRoZSBl eHBhbmRlZCA8PGJsb2NrLUE+PiByZWZlcmVuY2U/CiAgICBJbmRlZWQsIHRoYXQgd291bGQgYWxt b3N0IHdvcmssIGJ1dCB0aGVyZSBhcmUgZmxhd3MgdG8gdGhpcyBhcHByb2FjaDoKICAgIC0gdGhp bmdzIGxpa2UgL3VudXNlZCB2YXJpYWJsZS8gb3IgL21pc3NpbmcgYSBjbG9zaW5nIGJyYWNrZXQv IHdpbGwgYXJpc2UsCiAgICAtIGl0IGlzIHVubmVjZXNzYXJpbHkgZXhwZW5zaXZlLgoKICAgIFRo aXMgbGFzdCBwb2ludCBpcyBzaW1wbGU6IHdoeSBydW4gc3ludGF4IGNoZWNrZXIgaW4gfmJsb2Nr LUF+IGFuZCB+YmxvY2stQn4sIGlmIG9uZSBjb3VsZCBydW4gaXQgaW4gfmJsb2NrLUN+IGFuZCBt YXAgdGhlIGNoYW5nZXMgYmFjaz8KICAgIFNvLCB0aGUgc29sdXRpb24gaXMgdG8gYnVpbGQgc291 cmNlIGJsb2NrIHRyZWUgYW5kIHJ1biBzeW50YXggY2hlY2tlciBvbiB0aGUgZW5kIG5vZGVzLCB3 aGlsZSBwcm9wYWdhdGluZyB0aGUgcmVzdWx0cyBiYWNrIHRvIHRoZSByb290LiBJZiB0aGVyZSBp cyBhIGZvcmssIHByb3BhZ2F0ZSBmcm9tIHRoZSBvbmUgd2hpY2ggdGhlIHVzZXIgcmFuIGxhc3Qu CiAgICBIb3cgZXhhY3RseSBjb3VsZCB0aGlzIHdvcmsgaW4gb3VyIGV4YW1wbGU/CiAgICAtIEtl ZXAgYSBidWZmZXIgd2hpY2ggdmlld3MgdGhlIH5ibG9jay1DfiBsZW5zIGFuZCByZWN1cnNpdmVs eSB0ZWxsIHRoZSByZWZlcmVuY2UtbGVuc2VzIHRvIHNob3cgdGhlIGNvZGUuIAogICAgLSBSdW4g dGhlIHN5bnRheCBjaGVja2VyIHRoZXJlIGFuZCBhc3NvY2lhdGUgdGhlIG91dHB1dCB3LyBlYWNo IGxlbnMgKHJlY3Vyc2l2ZWx5KS4KICAgIC0gRm9yIGNvbXBsZXRpb24sIHByb3BhZ2F0ZSB1c2Vy IGlucHV0IChmcm9tIGxlbnNlcyBBLCBCIGFuZCBDKSB0byB0aGlzIHNhbWUgfmJsb2NrLUN+IGJ1 ZmZlciBhbmQgZGVhbCB3LyB0aGUgcmVzdWx0LgoKICAgIE9LLCBzbyBtdWNoIGZvciB0aGUgdG91 Z2hlciBzaGFyZSBvZiB0aGUgcHJvYmxlbXMuCiAgICBOb3csIGxldCdzIGdldCB0aGUgcmVzdCBv ZiB0aGUgaXNzdWVzLgoKICAgIC0gVmlldyBjdXN0b21pemF0aW9uIGlzIGluIHBsYWNlOiAvYXJl YXMvIG1heSBoYXZlIHZhcmlvdXMgcHJvcGVydGllcyBhbmQgY2FuIHNob3cvaGlkZS9kaXNwbGF5 IHRoZSBiZWdpbi9lbmQgb3JuYW1lbnRhdGlvbiBpbiBhbnkgbWFubmVyLgogICAgICAoZS5nLiA6 UkVTVUxUUyBsZW5zIHRydW5jYXRlcyBsaW5lcywgd2hpbGUgdGhlIGJ1ZmZlciB0aGF0IGNvbnRh aW5zIGl0IGRvZXNuJ3QsIGV0Yy4sIHNlZSB0aGUgW1tQcm9ibGVtc11dIHNlY3Rpb24pCiAgICAg IChlLmcuIHRoZSAvYXJlYS8gb2YgdGhlIGNvZGUgbGVucyBpcyBpbmRlbnRlZCB0d28gc3BhY2Vz LCBhcyBpdCdzIHByb3BlcnR5KQoKICAgIC0gT25lIGNvdWxkIGluc3RydWN0IGEgbGVucyB3aGF0 IHRvIGRvIGluc3RlYWQgb2YgdXNpbmcgcmVnZXhwICsgcmVwbGFjZS4KICAgICAgKGUuZy4gY29u dGludW9zbHkgdXBkYXRlIGEgdGltZXIpCgogICAgUmVzdWx0cyBzZWN0aW9ucyBjYW4gYmUgc2hv d24gdmlhIGxlbnNlcy4KICAgIE5vdywgd2hlbiBlZGl0aW5nIHcvICdvcmQtZWRpdC1zcmMtY29k ZSwganVzdCBzcGxpdCB0aGUgc2NyZWVuIGFuZCBvcGVuIDpSRVNVTFRTIGluIGFub3RoZXIgYnVm ZmVyLgogICAgRWRpdGluZyBvciBydW5uaW5nIHRoZSBjb2RlOiBldmVyeXRoaW5nIHdpbGwgYmUg a2VwdCBpbiBzeW5jIHcvIHRoZSBvcmlnaW5hbCBidWZmZXIuCiAgICBTb21lIGJsb2NrcyBtYXkg b3V0cHV0IHNldmVyYWwgZGlzdGluY3QgcGllY2VzIG9mIGRhdGEsIGxpa2UgaGVyZToKICAgIGh0 dHA6Ly9raXRjaGluZ3JvdXAuY2hlbWUuY211LmVkdS9ibG9nLzIwMTcvMDEvMjkvb2ItaXB5dGhv bi1hbmQtaW5saW5lLWZpZ3VyZXMtaW4tb3JnLW1vZGUKICAgIFJlcGxhY2luZyB0aGUgb2xkIHJl c3VsdHMgY291bGQgYmUganVzdCBhIG1hdHRlciBvZiByZW1vdmluZyB0aGUgZXhpc3RpbmcgbGVu cyBhbmQgcGxhY2luZyBpbiBhIG5ldyBvbmUuCiAgICBObyBuZWVkIHRvIHNlYXJjaCBmb3IgdGhl IGVuZCBvZiB0aGUgcmVzdWx0cyBibG9jay4KCiAgICBZb3UgY291bGQgc2VsZWN0IGEgcG9ydGlv biBvZiB0aGUgYmxvY2sgYW5kIG5hcnJvdyBpdC4KCiAgICBTaG93aW5nIHRoZSBsaW5lIG51bWJl cnMgc2hvdWxkIGJlIGEgbWF0dGVyIG9mIHJ1bm5pbmcgbmxpbnVtIGluIHRoZSBlbmQgbm9kZSBi dWZmZXIgKGFzIHcvIHN5bnRheCBjaGVja2luZyksIGJ1dCBJIGRvbid0IGtub3cgaG93IG5saW51 bSB3b3JrcyB0byBzYXkgZm9yIHN1cmUuCgogICAgVG8gYmUgZmFpciwgc29tZSBvZiB0aGUgZGVz Y3JpcHRpb25zIGhlcmUgZGVwZW5kIG9uIGltcGxlbWVudGF0aW9uIHBvc3NpYmlsaXRpZXMsIHNv IHRoZSBsZXZlbCBvZiBkZXRhaWwgaXMgaW4gYWNjb3JkYW5jZS4KCioqKiBPdGhlciB1c2VzCgoq KioqIElubGluZSB2aWV3IG9mIGxpbmtzCgogICAgIE9uZSBjb3VsZCBtYWtlIHNvbWUgc29ydCBv ZiBhIGxlbnMgdG8gdmlldyBhIHBhcnQgb2YgYSBidWZmZXIvZmlsZSBpZGVudGlmaWVkIGJ5IGEg bGluay4KICAgICBUaGUgYnVmZmVyIGNvdWxkIGJlIHRoZSBzYW1lIGJ1ZmZlciwgYW4gZXh0ZXJu YWwgZmlsZSwgYW55dGhpbmcuCiAgICAgT25lIHdvdWxkIG5vdCBoYXZlIHRvIGZvbGxvdyB0aGUg bGluay4KICAgICBXaGVuIGZvbGxvd2luZyB0aGUgbGluayBpcyB0b28gY3VtYmVyc29tZSwgY29w eSBwYXN0aW5nIGlzIHByZXZlbnRlZC4KCioqKiogRGlzcGxheSBPcmcgZG9jdW1lbnRzCgogICAg IFNlY3Rpb25zIGluIGFuIG9yZyBkb2N1bWVudCBjb3VsZCBiZSBzaG93biB1c2luZyBsZW5zZXMu CiAgICAgTm90IHRoYXQgSSBrbm93IHdoeSB0aGlzIHdvdWxkIGJlIHVzZWZ1bCAod2VsbCwgbWF5 YmUgZm9yIG1ha2luZyBhIFtbSnVweXRlcl1dIGxpa2UgZW52aXJvbm1lbnQpLgogICAgIEJ1dCB0 aGUgY29uY2VwdCBpcyBpbnRlcmVzdGluZy4KCioqKiogQ29ubmVjdCBzZXZlcmFsIHNvdXJjZSBi bG9ja3MKCiAgICAgKEkgaGF2ZSBwcm9wb3NlZCB0aGlzIG9uIHRoZSBPcmctbW9kZSBtYWlsaW5n IGxpc3QsIGJ1dCBub3cgdGhhdCBJIHRoaW5rIG9mIGl0LCBhIHVzZXItZGVmaW5lZCB3YXkgYXMg aGVyZSBpcyBiZXR0ZXIuKQoKICAgICBBIHF1aXRlIG9yZGluYXJ5IHdvcmtmbG93IGlzIHRvIHdy aXRlIGEgYmxvY2sgYW5kIHRoZW4gdGVzdCB0aGUgYmxvY2sgc2VwZXJhdGVseSAob3IgdXNlIDpl cGlsb2d1ZSBmb3Igb25lLWxpbmVycykuCiAgICAgSG93ZXZlciwgd3JpdGluZyBvdXQgYSB0ZXN0 IHNlcGVyYXRlbHkgaXMgbm9pc3kgYW5kIHNvbWV0aGluZyBsaWtlIHRoaXMgY291bGQgYmUgZG9u ZSBpbnN0ZWFkOgoKICAgICAjK05BTUU6IHNxdWFyZS0xCiAgICAgIytCRUdJTl9TUkMgcHl0aG9u CiAgICAgICBzcXVhcmUgPSBsYW1iZGEgeDogeCAqIHgKICAgICAjK0VORF9TUkMKICAgICAgIHJl dHVybiBbc3F1YXJlKHgpIGZvciB4IGluIHJhbmdlKDEwKV0KICAgICAjK0VORF9TUkNfVEVTVAoK ICAgICBUaGlzIGNvdWxkIGJlIGFjY29tcGxpc2hlZCBieSBsZW5zZXM6IGxlbnMtbW9kZSB3b3Vs ZCBvbmx5IG5lZWQgdG8gY2hlY2sgZm9yIHR3byBhZGphY2VudCBibG9ja3MgPG5hbWU+IGFuZCA8 bmFtZT4tdGVzdCBhbmQgdGhlbiB3cmFwIHRoZW0gaW4gYW5vdGhlciBsZW5zLCBzaG93aW5nIGJv dGggbGlrZSBhYm92ZS4KCiAgICAgT2YgY291cnNlLCBzb21lIHdheSB0byBsZXQgb3JnLWJhYmVs IGtub3cgd2hhdCdzIGdvaW5nIG9uIHdvdWxkIGJlIG5lY2Vzc2FyeS4KCioqIEFyYml0cmFyeSBQ b3NpdGlvbmluZyAoV2luZG93IExlbnNlcykKCiAgIFdpbmRvdyBsZW5zZXMgYXJlIGEgbG9naWNh bCBleHRlbnNpb24gb2YgYnVmZmVyIGxlbnNlcy4KICAgSW1hZ2luZSB5b3Ugd2FudGVkIHRvIHN0 YWNrIHR3byBpbWFnZXMgaG9yaXpvbnRhbGx5LgogICBWaWV3aW5nIHR3byBpbWFnZXMgaG9yaXpv bnRhbGx5IGluIEVtYWNzIGNhbiBiZSBkb25lIGJ5IGNyZWF0aW5nIHR3byB3aW5kb3dzLCBvbmUg aW1hZ2UgaW4gZWFjaCB3aW5kb3cuCiAgIFRoYXQncyB3aGF0IGEgd2luZG93IGxlbnMgY291bGQg ZG8sIGV4Y2VwdCBpdCB3b3VsZCBiZSBzaG93biBpbnNpZGUgYSBidWZmZXIuCgoqKiBJbnRlcmFj dGl2ZSBHcmFwaHMKCiAgIFRoaXMgb25lIGlzIHRvdWdoZXIgdGhhbiB3aW5kb3cgbGVuc2VzLCBi dXQgbXVjaCBtb3JlIGludGVyZXN0aW5nLgogICBTYXksIHlvdSB3YW50ZWQgdG8gaGF2ZSBhbiBp bnRlcmFjdGl2ZSBncmFwaCBpbiB5b3VyIGJ1ZmZlciAoZ251cGxvdCwgbWF0cGxvdGxpYikuCiAg IFRoaXMgcGFydCBvZiB0aGUgYnVmZmVyIHdvdWxkIHJlcXVpcmUgaXQncyBvd24ga2V5YmluZGlu Z3MgYW5kIGFsbCwgYnV0IHRoZSBhcmVhIG9mIHRoZSBsZW5zIGNvdWxkIGJlIGN1c3RvbWl6ZWQs IHRocm91Z2ggaXRzIHByb3BlcnRpZXMgb2YgcGFkZGluZy9jZW50ZXJpbmcgYW5kIHN1Y2gsIHRv IGFkb3JuIGFuZCBwbGFjZSB0aGUgZ3JhcGggaW4gYSB2aXN1YWxseSBzYXRpc2Z5aW5nIG1hbm5l ci4KCiAgIEluIHRoZSBsYW5kIHdoZXJlIHVuaWNvcm5zIGxpdmUsIG9uZSB3b3VsZCBiZSBhYmxl IHRvIHZpZXcgYW55IGdyYXBoaWNhbCB3aW5kb3cgaW5zaWRlIEVtYWNzOiBzb21ldGhpbmcgdGhh dCB3b3VsZCBzYXRpc2Z5IHRoZSB0YXN0ZSBvZiBldmVuIHRoZSBmaW5lc3QgZ291cm1ldHMgb2Yg bW9kZXJuIHRleHQgZWRpdGluZyAodUdockhyaG1waCkuCgogICBOb3QgdGhhdCB0aGUgYnVmZmVy IGxlbnNlcyBhcmUgdGhlIGJpZ2dlc3QgcHJvYmxlbSBoZXJlLCBidXQgdGhleSBqdXN0IG1pZ2h0 IGNvbWUgaW4gdXNlZnVsLgoKKiogRmFzdCBUaW1lciBVcGRhdGVzIChUZXh0IGFzIGFuIE9iamVj dCkKCiAgIEkgaGF2ZSBhbHJlYWR5IHRvdWNoZWQgb24gdGhpcyB0b3BpYyBhIGJpdCBpbiB0aGUg Y29udGV4dCBvZiBPcmctTW9kZSwgYW5kIG5vdywgZm9yIHRoZSBzYWtlIG9mIGNvbXBsZXRlbmVz cywgbGV0J3MgZm9ybSBhIGdlbmVyYWwgY2hhcmFjdGVyaXN0aWMgb2YgdXNpbmcgbGVuc2VzLgoK ICAgQSB0aW1lciB3YXMgbWVudGlvbmVkOiBjdXJyZW50bHksIGFzIEkgdW5kZXJzdGFuZCwgaWYg eW91IHdhbnRlZCB0byBwdXQgaXQgaW4geW91ciBidWZmZXIgYW5kIHNlZSBpdCBjb250aW51b3Vz bHkgdXBkYXRlLCB5b3Ugd291bGQgaGF2ZSB0byB1c2Ugc2VhcmNoIGFuZCByZXBsYWNlLCB3aGlj aCBpcyBub3QgZWZmaWNpZW50LgogICBUaGUgc29sdXRpb24gb2ZmZXJlZCB3YXMgdG8gdXNlIGEg bGVuczogaXQgd291bGQgaXRzZWxmIHVwZGF0ZSB0aGUgdGltZXIgKGFzIGEgL3NoYXJlZCBibG9j ay8gb3Igc29tZSBvdGhlciBkaXJlY3QgbWFubmVyKS4KCiAgIEFuZCB0aGUgdXNlcyBhcmUgbW9y ZSBnZW5lcmFsOiBzaW5jZSAvbGVucy1tb2RlLyB0cmFja3MgYWxsIHRoZSBsZW5zZXMsIG9uZSBj b3VsZCBzZW5kIGNvbW1hbmRzIHRvIHRoZW0uCiAgIFRoZXkgY2FuIHVwZGF0ZSBpbmRlcGVuZGVu dGx5LgogICBTbywgaWYgdGhlcmUgYXJlIHRleHQgb2JqZWN0cywgdGhleSBtYXkgYmUgYWNjZXNz ZWQgZWFzaWx5LgogICBUaGlzIHdhcyBvbmUgb2YgdGhlIGdvYWxzIHNldCBpbiB0aGUgW1tQcm9i bGVtIFN0YXRlbWVudF1dLgoKKiogQnVnIFRyYWNrZXJzICYgV2Vic2l0ZXMgJiBEYXRhYmFzZXMg KEludGVyZmFjZSBCdWlsZGluZykKCiAgIFBlcmhhcHMsIG9uZSBjb3VsZCB3b3JrIHdpdGggR2l0 bGFiIHNlcnZlciBvciBzaW1pbGFyIHRocm91Z2ggbGVuc2VzLgoKICAgQnVpbGRpbmcgYW4gaW50 ZXJmYWNlIGZvciBhIHdlYnNpdGUgZG9lc24ndCBzZWVtIHRvIGJlIG91dCBvZiB0aGUgcXVlc3Rp b24gZWl0aGVyLgoKICAgQWNjZXNpbmcgYSBkYXRhYmFzZTogd2h5IG5vdD8KCiogSnVweXRlcgoK ICBKdXB5dGVyIGlzIGEgcmVwcm9kdWNpYmxlIHJlc2VhcmNoIGVudmlyb25tZW50LgogIGh0dHBz Oi8vanVweXRlci5vcmcvCgogIEhlcmUgaXMgd2hhdCB1c2luZyBpdCBsb29rcyBsaWtlOgogIGh0 dHA6Ly9hcm9nb3pobmlrb3YuZ2l0aHViLmlvLzIwMTYvMDkvMTAvanVweXRlci1mZWF0dXJlcy5o dG1sCgogIEp1cHl0ZXIgaGFzIGEgc2VyaW91cyBmbGF3LgogIEl0IGRvZXNuJ3QgcnVuIGluc2lk ZSBFbWFjcy4KICAoTGlzdGVuLCBhbGwgaXMgZXZlbiB3b3JzZTogaXQgcnVucyBpbiBhIHdlYiBi cm93c2VyICh5ZXMsIEkga25vdyBhYm91dCBsaW5rcyBhbmQgZXd3LikpCgogIEkgaGF2ZW4ndCB1 c2VkIGl0IG11Y2gsIHNvIGxldCdzIHJlbHkgb24gdGhlIG9waW5pb24gb2Ygc29tZW9uZSB3aG8g aGFzOgogIGh0dHBzOi8vdG93YXJkc2RhdGFzY2llbmNlLmNvbS81LXJlYXNvbnMtd2h5LWp1cHl0 ZXItbm90ZWJvb2tzLXN1Y2stNGRjMjAxZTI3MDg2CiAgLSAxLiBJdCBpcyBhbG1vc3QgaW1wb3Nz aWJsZSB0byBlbmFibGUgZ29vZCBjb2RlIHZlcnNpb25pbmcgKGZpbGVzIGFyZSBKU09OLCBtZXJn aW5nIGlzIGRpZmZpY3VsdCkKICAtIDIuIFRoZXJlIGlzIG5vIElERSBpbnRlZ3JhdGlvbiwgbm8g bGludGluZywgbm8gY29kZS1zdHlsZSBjb3JyZWN0aW9uIAogICAgICAgKHF1aXRlIHN1cnByaXNp bmcgY29uc2lkZXJpbmcgdGhlIHBvcHVsYXJpdHksIGlzbid0IGl0PykKICAtIDMuIFZlcnkgaGFy ZCB0byB0ZXN0IChub3QgdGhlIHByb2JsZW0gb2YgSnVweXRlciwgcmVhbGx5KQogIC0gNC4gVGhl IG5vbi1saW5lYXIgd29ya2Zsb3cgb2YganVweXRlcgogIC0gNS4gSnVweXRlciBpcyBiYWQgZm9y IHJ1bm5pbmcgbG9uZyBhc3luY2hyb25vdXMgdGFza3MKCiAgU29tZW9uZSBhbHNvIHNhaWQgdGhh dCBtYW55IHNuaXBwZXRzIGluIEp1cHl0ZXIgYXJlIGhhcmQgdG8gbWFuYWdlLiBJIGJlbGlldmUg aGltLiAKCiAgVGhlIGdvb2Qgc3R1ZmYgYWJvdXQgSnVweXRlcjoKICAtIDEuIGVhc3kgdG8gdXNl IC8gbG93IGVudHJ5IGJhcnJpZXIsCiAgLSAyLiBpbnRlcmFjdGl2ZSBncmFwaHMsCiAgLSAzLiB2 aXN1YWxseSBkaXN0aW5jdCBjZWxscy4KCiAgUGxhbjogRW1hY3MgYmVhdHMgSnVweXRlciwgSnVw eXRlciBkaWVzIGFuIGFnb25pemluZyBkZWF0aCwgZXZlcnlvbmUgc3RhcnRzIHVzaW5nIEVtYWNz ICh0aGUgbGFzdCB0d28gcG9pbnRzIG1heSBiZSByZXZlcnNlZCkuCgogIFNheSwgaWYgdGhlIHN0 dWZmIGluIHRoZSBvcmctbW9kZSBzZWN0aW9uIGFuZCB0aGUgaW50ZXJhY3RpdmUgZ3JhcGhzIChh dCBsZWFzdCBmb3IgbWF0cGxvdGxpYikgd2VyZSBpbXBsZW1lbnRlZCwgbWFraW5nIHNvbWUgc3Bl Y2lhbCBlYXN5IG1vZGUgdy8gdGhlIGludHVpdGl2ZSBrZXliaW5kaW5ncyBjb3VsZCBjb252ZXJ0 IHNvbWUgSnVweXRlciBmb2xrcy4KCiAgVGhlIHRoaXJkIHBvaW50IG9uIGNlbGxzIGlzIGFsc28g ZG9hYmxlIGlmIGxlbnNlcyBnZXQgc29tZSBhcmVhIGN1c3RvbWl6YXRpb25zIGxpa2UgcGFkZGlu ZyBhbmQgY2VudGVyaW5nLiBBbmQsIGlmIG5lY2Vzc2FyeSwgdGhlIHdob2xlIG9yZyB0cmVlIGNv dWxkIGJlIHZpZXdlZCB0aHJvdWdoIGxlbnNlcy4KCiAgQW5kIG9yZy1tb2RlIGNhbiBhbHJlYWR5 IGV4cG9ydCB0byBodG1sLCBmb3IgcHJlc2VudGF0aW9uIHB1cnBvc2VzLgoKICBJbiBzaG9ydDog SSB0aGluayBtYWtpbmcgYSBnb29kIHJlcHJvZHVjaWJsZSByZXNlYXJjaCBlbnZpcm9ubWVudCwg ZWFzaWx5IHVzYWJsZSBhbmQgZnVsbCBvZiBmZWF0dXJlcyBpcyBhIGdvb2QgZ29hbCBhbmQgY291 bGQgbHVyZSBzb21lIHBlb3BsZSBpbnRvIHVzaW5nIEVtYWNzIChpZiBvbmx5IHN1cGVyZmljaWFs bHkgYXQgZmlyc3QpLgoKKiBJbXBsZW1lbnRhdGlvbgoKICBJIGFtIG5vdCBmYW1pbGlhciB3aXRo IEVtYWNzIGludGVybmFscyB0byBzYXkgd2hhdCdzIGZlYXNpYmxlIG9mIHRoZSBwcm9wb3NlZCBz dHJ1Y3R1cmUuCiAgCiAgQW5kIHRoZSB0d28gbWFqb3IgdGhpbmdzIGluIFtbTWVjaGFuaWNzXV0g dGhhdCBzb21ld2hhdCBkZXBlbmQgb24gaG93IEVtYWNzIHdvcmtzIGFyZToKICAtIHNoYWRvd2lu ZywgYW5kCiAgLSBtYWtpbmcgdHdvIGJ1ZmZlcnMgKHcvIGRpZmZlcmVudCBtb2Rlcykgc2hhcmUg dGhlIHNhbWUgdGV4dCAoL2xpbmtlZCBidWZmZXJzLyBzaGFyZSB0aGUgc2FtZSAvc2hhcmVkIGJh c2UvKS4KICAKKiBEaXNjdXNzaW9uCgogIE5vdGhpbmcgaW4gdGhpcyBwcm9wb3NhbCBpcyBzZXQg aW4gc3RvbmUsIGZlZWwgZnJlZSB0byBjaGFuZ2UgaXQgdG8geW91ciBsaWtpbmcuCgogIFNvbWUg bmFtaW5nIGlzIHByb2JhYmx5IGZsYXdlZC4KICBTb21lIHN0cnVjdHVyZXMgbWlnaHQgYmUgb3Zl cmx5IGFtYml0aW91cyBvciB1bm5lY2Vzc2FyeS4KICBBbGwgaW1wbGVtZW50YXRpb24tcmVsYXRl ZCBzdWdnZXN0aW9ucyBhcmUganVzdCBzdWdnZXN0aW9ucy4KCiAgU29tZSBleHBsYW5hdGlvbnMg Y291bGQgYmUgbW9yZSBjbGVhci4KCiAgTW9yZSBhcHBsaWNhdGlvbnMgY291bGRuJ3QgaHVydC4K CiAgVGhlIGVmZmVjdHMgb2YgdGhlIGltcGxlbWVudGF0aW9uIGFyZSBjb250YWluZWQgd2l0aGlu IHRoZSBsZW5zLW1vZGUuCiAgV2hpY2ggbWVhbnMgdXNlcnMgc2hvdWxkIG5vdCBub3RpY2UgdGhl IGRpZmZlcmVuY2UgdW5sZXNzIHRoZXkgdHVybiBvbiB0aGUgbGVucy1tb2RlLgogIElmIHRoZSBp bXBsZW1lbnRhdGlvbiBpcyB1bmRlcnRha2VuLCB0aGlzIHdpbGwgYmUgZ29vZCBmb3IgdGVzdGlu ZyBhbmQgaW50ZWdyYXRpb24uCgogIE92ZXJhbGwsIEkgdGhpbmsgdGhlIGFwcGxpY2F0aW9ucyBt aWdodCBiZSB2ZXJ5IHdlbGwgd29ydGggdGhlIGVmZm9ydC4KICBFc3BlY2lhbGx5IGZvciBPcmct bW9kZS4K --00000000000030860305874af711--