MediaWiki API result

{
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "Refactoring_Framework_Release_History",
        "continue": "gapcontinue||"
    },
    "warnings": {
        "main": {
            "*": "Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes."
        },
        "revisions": {
            "*": "Because \"rvslots\" was not specified, a legacy format has been used for the output. This format is deprecated, and in the future the new format will always be used."
        }
    },
    "query": {
        "pages": {
            "285": {
                "pageid": 285,
                "ns": 0,
                "title": "Records Extension",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "This page is under development. It is intended to be a user oriented manual for using records in Event-B. This page should be read in conjunction with the  [[Structured_Types|Structured Types]] page which gives a more theoretical description of the origin of the Records extension.\n\n==Introduction==\nThe Event-B mathematical language currently does not support a syntax for the direct definition of structured types such as records or class structures.\nThe Records Extension introduces a new modelling construct to provide a notion of structured types in Event-B Contexts.\n\nCurrently, structured variables are not supported. Variables that are typed as an instance of a record type can be thought of as identifying a particular record value. Hence it is not possible to vary an individual field, the variable must be assigned a complete new record value instance. To vary an individual field this new record value instance can be selected to have the same field value for every other field.)\n\n==UI Extensions==\nThe '''Event-B editor''' is extended to include two new top level clauses. These are '''Record Declarations''' and '''Record Extensions'''.\n\nRecords (or sub-records) are introduced in the Record Declarations clause. Records that are introduced here without a '''Supertypes''' clause are equivalent to carrier sets. Those that have a Supertypes clause are equivalent to constants that are a subset of the referenced (i.e. subtyped) record or carrier set.\n\nRecord Extensions may only add new fields to a record that has previously been declared in a Record Declaration. The extended record is referenced in an 'extends' clause.\n\nRecord Declaration clause also contains a toggle button to control the record's closure property. A closed record cannot be subtyped by other records or extended by record extensions.\n\nThe '''Event-B navigator''' is extended to show a new node '''Records'''. Under this node are listed the records and records extensions in the Context. \nRecord Extensions are displayed as the name of the extended record appended with a + sign. Each record or record extension can be expanded to show the owned fields. (Note that this list is not cumulative, only the new fields are shown). \n(Currently in the Navigator, the Records node is shown as the first item in the Context whereas eleswhere it appears between carrier sets and constants. This is due to a limitation in the Rodin tool extension facilities).\n\nThe '''Outline''' panel shows the records followed by record extensions as a plain list without the Records node. Again, the record or record extension can be expanded to show the fields.\n\nIn all  cases, the '''icon''' used for a record reflects its equivalence. That is, if it does not have a supertypes clause, it is displayed with the same icon as a carrier set. otherwise it is displayed with the same icon as a constant.\n\n==Semantics of Records==\nThe semantics of Records are given by their translation into 'pure' Event-B. This translation is performed by extensions to the static checker which generates a 'checked context' (.BCC file) containing pure Event-B from an unchecked (.BUC file) containing record elements. Hence the translated Event-B is not visible to the user. \n\n\n<center>\n{| align=\"centre\" border = \"1\" cellpadding = \"10\" cellspacing=\"5\"\n|<math>  \\textbf{  RECORD}~~~~ R  </math> || <math>  \\textbf{~~SET}~~~~ R  </math>\n|-\n|<math>  \\textbf{  RECORD}~~~~ R, ~~~~\\textbf{SUPERTYPE}~~~~ S ~~~~</math> || <math>  \\textbf{~~CONSTANT}~~~~ R , ~~~~\\textbf{AXIOM}~~~~  R \\in \\pow (S) ~~~~</math>\n|-\n|<math>  \\textbf{  FIELD}~~~~ f \\in F</math> || <math>  \\textbf{~~CONSTANT}~~~~ f , ~~~~\\textbf{AXIOM}~~~~  f \\in R \\rightarrow  F ~~~~</math>\n|}\n</center>\n\n\n[It may be instructive to open the *.bcc file with a text editor to examine the generated carrier sets, constants, and axioms]\n\n==Usage==\n\nFirst define Records in the Record Declarations section. Some of these can subtype others but you need at least one that is not a subset, i.e. has no supertypes. <s>Note that we decided not to allow records to subtype or extend Carrier Sets, but you can do the equivalent by defining a record without any fields and subtyping/extending that.</s> To be correctly static-checked record definitions must be in order of their referencing i.e. a subtype record would follow a supertype record which it references (to know about its type). In opposite case static checker will show a typing problem.\n\nAdd fields and give them a type by entering an expression that evaluates to a set. Note that this expression must be a basic type expression. You can use records, constants and sets in the expression.\n\nAfter a record is defined it can be declared as closed using a toggle button in its Record Declaration clause. When record is closed it cannot be subtyped or extended anymore. Another effect of closing a record is that additional axioms are generated for it in the checked context. These include a closure axiom, a make-function for the record and an update-function for each of its fields (also for derived fields from supertype records). Another axiom \u2014 feasibility axiom \u2014 is generated for every record independent of its closure attribute.\n\nFor Record Extensions just select the record you want to add new fields to from the drop down list and then add the new fields. Only open (not closed) records can be extended, although the drop down list contains all the declared records.\n\nYou can refer to records and fields in axioms/theorems. E.g., you could define a constant to be an instance of a record. In all cases you can refer to records and fields in the current or visible abstract (extended*) contexts.\n\nYou use fields as if they were functions (which is what they are in the checked context). \n\ne.g. if <math>r</math> belongs to <math>myRecord</math> which has a field, <math>myField \\in \\nat</math> then I could write in a predicate <math> myField(r) > 5 </math>.\n\n==Proving With Records==\nThe prover will refer to records as sets and constants, and to fields as constants. Therefore for proving you may need to be aware of this. \n\nAxioms that are automatically generated for typing records and their fields will have automatically generated labels and these may be referenced in the prover interface.\n\nThe automatically generated labels use an easy to interpret format: \n* Subtype Record typing axioms are in the format ''<recordName>.type<d>''  (where d is a decimal digit appended to ensure there are no name clashes) \n* Field typing axioms are in the format ''<recordName>.<fieldName>.type<d>''  (where d is a decimal digit appended to ensure there are no name clashes)\n\nOther axioms use record and field labels in their labelling, which leads to a longer and slightly confusing but still interpretable format:\n* Feasibility axioms are in the format ''<recordName>.feasibility'' (or ''<recordName>.feasibility.ext<n>'' in case of record extensions)\n* Closure axioms are in the format ''<recordName>.closure''\n* Make function's 1st axiom (function's typing) is in the format ''<recordName>.make.axm1''\n* Make function's 2nd axiom (for each field) is in the format ''<recordName>.<fieldName>.make.axm2''\n* Update function's 1st axiom (record field update function's typing) is in the format ''<recordName>.<fieldName>.update.axm1''\n* Update function's 2nd axiom (equivalence to record construction with a specific value of updated field) is in the format ''<recordName>.<fieldName>.update.axm2''\n\n==Current Limitations==\n* Records are not supported by the Camille text editor (see warning below)\n* <s>Records are not supported by the Pretty print facility</s>\n* <s>Records are not supported by the Synthesis view facility</s>\n* Records are not supported by the EventB2Latex plug-in\n* <s>Records are not supported by the Refactoring plug-in</s>\n* Records are partially supported by the Decomposition plug-in (Machines that use records can be decomposed, but the Context that contains the record cannot).\n* Records may have, at most, one supertype.\n* <s>Records may only have records as supertypes (not carrier sets)</s>\n* <s>There is no finalisation of a record - hence make functions are not supported</s>\n\n==Warning==\n\nRecords are not supported in the Camille text editor. Editing a context that contains records with the Camille editor may result in the Records being lost.\n\n[[Category:Work in progress]] [[Category:Design]]"
                    }
                ]
            },
            "286": {
                "pageid": 286,
                "ns": 0,
                "title": "Refactoring Framework",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "{| align=\"right\"\n| __TOC__\n|}\n\n==News ==\n* ''6th May 2014'' : [[#Version_1.3.0|Version 1.3.0]] released. It is based on Rodin 3.0.x.\n* ''25th June 2012'' : [[#Version_1.2.2|Version 1.2.2]] released. It is based on Rodin 2.5.x.\n* ''29th June 2011'' : [[#Version_1.2.0|Version 1.2.0]] released. It is based on Rodin 2.2.x.\n* ''8th Nov 2010'' : [[#Version_1.0.0|Version 1.0.0]] released. It is based on Rodin 2.0.x.\n* ''28th May 2010'' : [[#Version_0.0.8|Version 0.0.8]] released. It is based on Rodin 1.3.x.\n* ''30th March 2010'' : [[#Version_0.0.7|Version 0.0.7]] released. It is based on Rodin 1.2.x.\n* ''25th February 2010'': [[#Version_0.0.6|Version 0.0.6]] released. It is based on Rodin 1.2.x.\n* ''13th January 2010'': [[#Version_0.0.5|Version 0.0.5]] released. It is based on Rodin 1.1.0.\n* ''5th November 2009'': [[#Version_0.0.4|Version 0.0.4]] released. It is based on Rodin 1.1.0.\n* ''2nd November 2009'': [[#Version_0.0.4|Version 0.0.4]] released. It is based on Rodin 1.1.0.\n* ''3rd July 2009'': [[#Version_0.0.2|Version 0.0.2]] released. It is based on Rodin 1.0.\n* ''1st July 2009'': [[#Version_0.0.1|Version 0.0.1]] released. It is based on Rodin 1.0.0 RC1.\n\n==The Rename Refactoring Plug-in == \n\nOne of the most recurring requirement from users of the Rodin platform is to have simple means for renaming modeling elements.  Users want to have a unique operation that will rename an element both at its declaration and all its occurrences. Moreover, they require that renaming an element doesn't modify their existing proof state (no loss of proof).\n\nThis requirement falls in the more general context of ''refactoring''. In software engineering, \"refactoring\" source code means improving it without changing its overall results, and is sometimes informally referred to as \"cleaning it up\". In the case of the Rodin platform, the refactoring framework is related to the first option, where refactoring should not change the overall behaviour of the files/elements, nor loosing proofs.\n\nThe following diagram shows the architecture of the refactoring framework.\n\n[[Image:Architecture_refactoring_framework.jpg|500x400px]]\n\n==The Rename Refactoring Framework Architecture == \n\nCurrently, it is being developed the application of such framework to event-b files (context, machines, proofs obligations, etc) and elements (constants, variables, carrier sets, etc). There are still some tests to be run for the different elements of contexts and machines. The next goal would be to apply and use this framework on Rodin (together with file editors or perspectives).\n\n[[Image:RefTree.jpg|center|450x400px]]\n\n==== Refactoring Trees after processing the extension points ====\n\nSince there are proof obligations associated with Event-B files, while renaming the goal would be to cause the less effort as possible on re-proving and if possible re-using the proofs that are already discharged. The refactoring should not change the semantic of any of the elements/files. Instead, it should just change names or labels, so the proofs should not have to be re-generated (nor re-discharged). That is one of final goals while applying of this framework to Event-B.\n\n==Initial Work ==\n\nInitial work towards implementation of this framework is described in [http://stups.hhu.de/mediawiki/images/9/94/Holl2007_Bachelorarbeit.pdf Sonja Holl's Bachelor thesis]\n\n==Installing/Updating ==\n\nThe installation or update for the renaming/refactoring plug-in is available under the main Rodin Update site (http://rodin-b-sharp.sourceforge.net/updates) and category 'Utilities'. Like always, after the installation, restarting the application is recommended.\n\n==Usage ==\n\nThe Renaming/Refactory plug-in allows the renaming of:\t\n\n* Variables\n* Parameters\n* Carrier Sets\n* Constants\n* Events\n* Other labelled elements (invariants, axioms, guards, etc)\n\n====Requirements before using ====\n\nBefore using the renaming/refactory, all the files in the project should be saved ( it will be asked to save if there are unsaved files). There should be no errors in the project, otherwise it could lead to even more errors after applying the renaming (warning).\n\n==== Steps of usage ====\n\n# User selects element to be renamed at the Event-B Explorer\n# By right clicking in the element, there should appear an option 'Refactory...'. Selecting that option should open a wizard [[Image:refactory menu.png|300x300px]]\n# User introduces new element name in the first page of the wizard. Then click in 'Next'. [[Image:new_name_wizard2.png|400x350px]]\n# If the option '''Wait for Indexer to update''' is selected, then '''if the rodin indexer is not up to date, the user has to wait for it. Otherwise, the user can cancel the operation and try later. ''' [[Image:Refactory_progress_updating_rodin_indexer.png| middle |300x300px]]. If the option '''Wait for Indexer to update''' is not selected, the tool will use the previous version of the indexer and rename accordingly.  \n# Once the indexer is up to date, the user can proceed with the operation.[[Image:refactory_rodin_indexer_updated.png|350x300px]]\n# A list of related files is created and the plug-in check for possible clashes and returns a report\n# User decides if he wants to execute renaming (by clicking in 'Finish')\n\n[[Image:refactory_report_wizard.png|400x300px]]\n\n== Bugs, Features and Comments == \n\n''Any reports of bugs, features or comments are welcome. Please, use the SourceForge trackers to report a bug on existing features, or to request new features:''\n\n* [https://sourceforge.net/tracker/?atid=651669&group_id=108850&category=1259297 Bugs]\n* [https://sourceforge.net/tracker/?atid=651672&group_id=108850&category=1259298 Feature Requests]\n\n====Features Request====\n* Implement UNDO for renaming\n\n== Releases ==\n\n=====Version 1.3.0 =====\n\n''6th May 2014''\n\nThis new release is a port to Rodin 3.x.\n\n=====Version 1.2.2 =====\n\n''25th June 2012''\n\nA release of renaming/refactory (v1.2.2) compatible with Rodin v2.5 is available in the main Rodin update site (Utilities category). \n*Bug fix\n** Fixed bug related with waiting for the rodin indexer to update\n\n*Feature Request:\n** Added option to rename without having to wait for the rodin indexer to update.\n\n=====Version 1.2.0 =====\n\n''29th June 2011''\n\nA release of renaming/refactory (v1.2.0) compatible with Rodin v2.2.x is available in the main Rodin update site. \n*Bug fix\n** Before renaming, ignore unsaved files that finish with 'tmp'.\n** Sometimes platform would hang when renaming. This happens because the rodin indexer is still updating when the renaming operation is called and the platform would hang/block until the indexer had finished updating. To circumvent this problem, an additional wizard step is added corresponding to the indexer update. That step allows the user to stop the renaming and start later without hanging the platform.\n\n*Feature Request:\n** More accurate monitor progress bar.\n** Shorter description of reasoner version problem.\n**Optimised rewriting of freeIdentifiers when renaming variables and constants.\n\n=====Version 1.0.0 =====\n\n''8th Nov 2010''\n\nA release of renaming/refactory (v1.0.0) compatible with Rodin v2.0.x is available in the main Rodin update site. \n\n=====Version 0.0.8 =====\n\n''28th May 2010''\n\nA release of renaming/refactory (v0.0.8) compatible with Rodin v1.3.x is available in the main Rodin update site. A bug related to assignment using the \"become such that\" operator was fixed. Also, when renaming proofs, this is done by running a job which can run in background.\n\n*Bug Fix\n**Bug 3005170: ''If a variable is renamed, which is used in a \"becomes such that\", the assignment does not type check any longer after the renaming operation, because the variable has disappeared.''\n**Bug 3005202: ''When a renaming operation is performed, the provers are launched. The waiting time may be quite long and it is impossible to do anything else.\nIt is always necessary to run the provers? If it is indeed mandatory, the provers should be temporarily disconnected until the renaming has been performed, and run when this operation has completed''.\n\n=====Version 0.0.7 =====\n\n''30th March 2010''\n\nA release of renaming/refactory (v0.0.7) compatible with Rodin v1.2.x is available in the main Rodin update site.\n\n*Bug Fix\n**Fix bug that occurred when renaming an event whose machine was refined.\n\n=====Version 0.0.6 =====\n\n''25th February 2010''\n\nA release of renaming/refactory (v0.0.6) compatible with Rodin v1.2.x is available in the main Rodin update site.\n\n*Feature Request\n**Renaming of all proofs after the element renaming. For each proof obligation, if proof rebuilding does not work, a new proofTree is created based on the initial proofTree and on the renamed element. By applying the ancient rule, if a proof is discharged before the renamed, it remains discharged after the renaming.\n\n=====Version 0.0.5 =====\n\n''13th January 2010''\n\nA release of renaming/refactory (v0.0.5) fixing a few bugs found is already available.\n\n=====Version 0.0.4 =====\n\n''5th November 2009''\n\nA release of renaming/refactory (v0.0.4) compatible with Rodin v1.1.0 is available in the main Rodin update site (bug fix from 0.0.3). Before starting the renaming, it is recommended to clean and build the project in order to have the indexer tables updated (IMPORTANT).\n\n*Bug fix\n** Renaming of proofs would not save the proof files after renaming\n** Renaming of labelled elements would not update the proofs.\n\n*Possible Problem\n** If you try to rename and the operation runs successfully without any errors but does not have any effect, you should:\n*** First, try to fix the renaming manually on the respective file (or using the renaming framework, revert to the original name)\n*** Try to make a CLEAN and BUILD to ensure that the Rodin indexer is updated before the renaming.\n*** Run the renaming again and should be working fine.\n\n=====Version 0.0.3 =====\n\n''2nd November 2009''\n\nA release of renaming/refactory (v0.0.3) compatible with Rodin v1.1.0 is already available in the main Rodin update site. Before starting the renaming, it is recommended to clean and build the project in order to have the indexer tables updated.\n\n*Features\n** Renaming of machines and contexts is possible using the indexers. After the renaming of a machine/context, the change is propagated over the related files\n** Renaming of proofs: after the renaming, the proof obligations are also updated to reflect the renaming. It might be necessary to manually refresh the status of some proof obligations (although the proof is already discharged). This renaming is not fully-functional at the moment and some discharged proof obligations may have to be discharged again. We intend to fix this problem in the future.\n\n=====Version 0.0.2 =====\n\n''3rd July 2009''\n\n*Bugs\n** Validate if new name is in the list of reserved words of Event-B (dom,ran, card, etc)\n\n=====Version 0.0.1 =====\n\n''1st July 2009''\n\nA release of renaming/refactory (v0.0.1) compatible with Rodin v1.0.0 is already available in the main Rodin update site. \n\nNote that this version is still a prototype so prone to errors. So it is suggested to back up the projects before starting to use the renaming plug-in. The plug-in uses the most recent version of Rodin Indexer. Before starting the renaming, it is recommended to clean and build the project in order to have the indexer tables updated.\n\nAlthough one of the goals is to the rename the respective proof obligations, this feature is not available in this version. It should be available in the next release. If you find bugs or errors, please let me know by updating this wiki-page or [mailto:ras07r@ecs.soton.ac.uk email].\n\n[[Category:Design]]\n\n[[Category:Plugin]]\n[[Category:User documentation]]"
                    }
                ]
            }
        }
    }
}