Build database applications faster than anyone else, and keep your data pollution free as a bonus.
Home Page: http://ampersandtarski.github.io/
License: GNU General Public License v3.0
Check out the release notes and
We are currently in a process to change the way we publish our documentation. The old site can be found here. It is still easier to navigate. The new site can be found here. It contains all documentation of several repositories in a single place. We are still working on structuring it.
The old site does not contain the documentation specific for developers of Ampersand. That can be found as documentation for the developers of ampersand.
Below is Stef's draft text:
An Object is a Concept c, for which there is no declaration r such that
(c==source r && isUni r && isSur r) ||
(c==target r && isInj r && isTot r)
Read: The relation crudR represents the R (read) in the crud matrix.
RELATION crudR[Interface*Object]
i crudR o means: o elem concs (relsUsedIn i)
Create: The relation crudC represents the C in the crud matrix.
RELATION crudC[Interface*Object]
i crudC o means:
Interface i has an editable field of type o
and in this field new atoms can be created, either by the user or automatically by creating a dirty identifier.
Delete: The relation crudD represents the D in the crud matrix.
RELATION crudD[Interface*Object]
i crudD o means:
Interface i has an editable field of type o
and in this field new atoms can be deleted.
Update: The relation crudU represents the U in the crud matrix.
RELATION crudU[Interface*Object]
Let interface i have an editable field of type o that edits relation r:
i crudU o means that r is part of object o (i.e. (sloppilly) of the transitive surjective closure of relations starting at o)
Task:
elem concs (relsUsedIn i)Currently the $allRoles array in Generics.php does not contain the rules that are maintained by the roles anymore. After making a prototype I get the following, although I do have rules that are maintained by the Engineer and ExecEngine
$allRoles =
array
( array ( 'name' => 'Engineer'
, 'ruleNames' => array ()
)
, array ( 'name' => 'ExecEngine'
, 'ruleNames' => array ()
);
I think this bug is introduced with commit a7f87b2 'Merge pull request #62'
Consider the following script:
CONTEXT "One" IN ENGLISH
INCLUDE "Two.adl"
ENDCONTEXT
Assume the file Two.adl contains the following script:
CONTEXT "Two" IN ENGLISH
PURPOSE CONTEXT "Two" {+This context exists to show a bug-}
ENDCONTEXT
Compiling the first script results in the message:
Error(s) found:
Purpose refers to non-existent CONTEXT "Two"
This error is wrong, since CONTEXT "Two" is actually declared. If the parser is capable of ignoring a CONTEXT statement, it should also be capable of ignoring any other statements related to that context.
The ampersand-models/ISAtest/Limorange.adl example shows a number of differences between the old and the new frontends. (Some of these may be intentional because of the slightly different edit model.) All issues mentioned below are in the Person interface for atom martijn.
ownsLimes is not editable in new front-end, whereas the old front-end allows editing on two levels: add/remove on limes and add/remove/modify on limeProperties for each lime.ownsCitrus;I[Orange] does not have any effect in the new front-end. In the old front-end this is editable, even though for --dev deletions don't display correctly until the page is saved (probably due to a styling problem for crossing out underlined atoms).+ menu button only supports 'New Person' and 'New Lime', but does not allow creation of atoms for the other concepts (Nectarine, Citrus, Orange, Limorange, and Lemon)"selected id is undefined" Person.js:84:6In the recent version of Atoms.adl, there are some things that need attention. @stefjoosten, please elaborate on each of the following remarks:
type is TOT. This cannot be derived, because l and r are not SURWhen I create a functional design, and specify the option --outputDir=".\fspec", this specifies the output directory for functional design files. In the resulting .TEX file, I find lines that refer to .PNG files such as
\scalebox{0.5}[0.5]{\includegraphics{./fspec/RelationsInPatternAccounts.png}}
Note that they have the specified output directory in the path of the file. However, it looks like it is the case that this output directory is the current directory when the .PDF file is generated, which results in the error message
pdflatex> ! Package pdftex.def Error: File `./fspec/RelationsInPatternAccounts.png' not found.
This happens fo all picture files. Maybe it helps to leave out the output direcctory in the file path.
Consider the following scriptlet:
factuurRegel :: Factuur * Regel
regelText :: Regel * TEXT [UNI]
factuurOK :: Factuur * Factuur [PROP]
RULE "Factuur check": factuurOK = I[Factuur] /\ -(factuurRegel;-regelText);V
MEANING "A Factuur is ok IFF the Factuur is empty or every of its factuurRegels contains text."
POPULATION factuurRegel CONTAINS [ ("Factuur1", "Regel1") ]
POPULATION regelText CONTAINS [ ("Regel1", "Eentje") ]
POPULATION factuurRegel CONTAINS [ ("Factuur1", "Regel2") ]
POPULATION regelText CONTAINS [ ("Regel2", "Tweede") ]
POPULATION factuurOK CONTAINS [ ("Factuur1", "Factuur1") ]
It seems to me that this is a valid population for the model, but the script does not compile due to population errors. This is also the case when the rule is replaced with its equivalent:
RULE "Factuur controle": factuurOK = I[Factuur] /\ (-factuurRegel ! regelText);V
I have put an elaborate set of testpopulations in the Sentinel, testing both proper and improper populations for factuurOK. The files containing the abovementioned population are FactuurConcat4.adl and FactuurDagger4.adl in the ShouldSucceed directory.
Na commit 7317bff resulteert onderstaande INTERFACE specificatie niet meer in generatie van TABS structuur.
Mijn vermoeden is dat de BOX classificatie stuk is die ervoor zorg dat het juiste template wordt gebruikt voor generatie van html views. In dit geval had dat moeten zijn: Box-TABS.html, maar hij valt terug op de default Box.html template.
CONTEXT Test IN DUTCH
PATTERN Test
CONCEPT SESSION ""
r1 :: A * TEXT
r2 :: A * TEXT
ENDPATTERN
INTERFACE "Overzicht" (r1,r2) FOR "Test" : V[SESSION*A]
TABS [ "Tab1" : r1
, "Tab2" : r2
]
ENDCONTEXT
Reproduce this as:
It works in the old front end, until the point where the exec-engine has to kick in, which proves that the Login.adl is OK:
A construct in an adl script such as:
CONCEPT Criterion "a text used for ..." TYPE "Blob"
results in tables where the column is a BLOB rather than a VARCHAR(255). However, importing an EXCEL file that populates such tables results in messages such as
Error! Concept BLOB does not exists in allConcepts
Error! Cannot find relation with signature 'ctrlCriterion[Control*BLOB]'
Error! Cannot find relation with signature 'bfcCriterion[BFControl*BLOB]'
and so on. Michiel, can you fix this?
In a ROLE statement (e.g. ROLE ExecEngine MAINTAINS UpdateAssignment) I would like to see an error message if the rule name (to the right of MAINTAINS) does not refer to an existing rule.
The reason that DEMO_VOG.adl is taking too long is very likely that there is a loop somewere. I have seen that makeFSpec uses recursion in the definition of the fSpec. I see no reason why that is required, and it is a suspect of the loop(s).
It seems that if you use refer to INTERFACE Kabels at multiple places (in other INTERFACEs), you get the (runtime!) error:
Error! 500 Internal Server Error: Infinite loop in interface 'Kabels' by referencing 'Kabels'
An example of this can be found in the repo ampersand-models\NewFrontend\RWS\RWSbug.adl
A workaround for this is to use the actual contents of the referenced INTERFACEs at all (but one) place rather than to refer to them.
Check out Atoms.adl (from commit Ampersand master:1f1adc8).
I have compiled this script once for the new front end, and once with the old front end.
In the new front end, I cannot create a new atom.
In the old front end, I can make a new atom.
My intended behaviour is to make a new atom in the new front end (so I can use exec-engine rules).
Just for the record: I also tried removing localsettings.php from "\localhost\klad", but that didn't do anything (as expected).
Consider the following script:
CONTEXT Ticket35GitHub IN ENGLISH
normtextNH :: NormText * NormHierarchy
normID :: Norm * NormID
IDENT Norms: Norm(normtextNH,normID)
CLASSIFY Norm ISA NormText
isSubsidiaryToNorm :: NormText * Norm
ENDCONTEXT
This produces the following error:
ampersand.exe: !fatal 428 (module Core.AbstractSyntaxTree) Ampersand v3.0.3[fancy-views:2b5ad66]
Cannot intersect (with operator "/\") expression l of type [NormText*NormText]
ECps (EDcD normtextNH[NormText*NormHierarchy],EFlp (EDcD normtextNH[NormText*NormHierarchy]))
with expression r of type [Norm*Norm]
ECps (EDcD normID[Norm*NormID],EFlp (EDcD normID[Norm*NormID])).
When the IDENT statement is removed, the error disappears.
Currently, when the new framework performs new database install, it runs 2 scripts:
These files contain the needed queries for that, but also run those queries using a database link that is created in the scripts itself.
In order to return any error and/or success messages, I would like to let the new framework perform those queries. My proposed solution for this feature request is to add the queries that are stated in the installer scripts, to the Generics.php file. The scripts can stay as is, to maintain functionality for the current framework and ampersand application.
The 2 arrays in Generics:
$allDBstructQueries = array ( 'DROP DATABASE $DB_name',
'CREATE DATABASE $DB_name DEFAULT CHARACTER SET UTF8',
'DROP TABLE `__SessionTimeout__',
'CREATE TABLE `__SessionTimeout__`
( `SESSION` VARCHAR(255) UNIQUE NOT NULL
, `lastAccess` BIGINT NOT NULL
) ENGINE=InnoDB DEFAULT CHARACTER SET UTF8',
etc..
);
$allDefPopQueries = array ( 'INSERT IGNORE INTO `Project` (`Project`,`tgt_projectName`,`tgt_projectStatus`,`tgt_projectDescription`,`tgt_projectStartDate`,`tgt_projectStarted`)
VALUES (\'2013.01\', \'Alfa board\', \'Afgerond\', \'Het maken van een alfa bordje voor de klant.\', \'2013-12-30T23:00:00.0Z\', \'TRUE\')
, (\'2014.02\', \'Beta board\', \'Loopt\', \'Het verder ontwikkelen tot een beta bordje.\', \'2014-02-14T23:00:00.0Z\', \'TRUE\')
, (\'2014.03\', \'Release board\', NULL, \'Het gereed maken voor vekoop van het bordje.\', \'2014-07-14T23:00:00.0Z\', \'FALSE\')
, (\'2014.04\', \'Odysseus\', NULL, \'Onderzoek naar het kunnen verslaan van Troje.\', NULL, \'FALSE\')
, (\'2014.05\', \'Argos\', NULL, \'Het ophalen van het gulden vlies.\', NULL, \'TRUE\')
, (\'1970.13\', \'Apollo 13\', \'Gelukt (gelukkig)\', \'Zorgen dat we weer met beide benen op de grond komen te staan.\', \'1970-04-11T13:13:13.1313Z\', \'TRUE\')
',
'next insert query'
etc
);
Consider the following script
sPerson :: SESSION * Person [UNI]
sManagesX :: SESSION * X
CLASSIFY Y ISA X
personManagesX :: Person * X =[ ("John", "Johns X") ]
personManagesY :: Person * Y =[ ("Pete", "Petes Y"); ("John", "Johns Y") ]
RULE "sManagement" : sManagesX = sPerson;personManagesX
VIOLATION (TXT "Sessie=", SRC I, TXT "; sPerson=", SRC sPerson, TXT "; sMgsX=", TGT I)
POPULATION sPerson CONTAINS [ ("S1", "John") ]
POPULATION sManagesX CONTAINS [ ("S1", "Johns X"); ("S1", "Johns Y") ]
POPULATION sPerson CONTAINS [ ("S2", "Pete") ]
POPULATION sManagesX CONTAINS [ ("S2", "Petes Y") ]
This produces the following errors, which are not errors:
Violations of rule "sManagement":
- [('S1','Johns Y'), ('S2','Petes Y')]
I get many purposes twice in the resulting PDF. No idea yet what causes this. May this be caused by the insertion of purposes in the invariant list by Martijn?
In chapter 2 of the functional design, Shared Language, I would like to omit the captions of agreements in case of relations with a purpose but without meaning (explanation).
At the same time, in chapter 3 of the functional design (Diagnosis) I would like to signal relations without meaning.
Currently, when a (line in) an INTERFACE refers to an atom for the concept of which multiple INTERFACEs have been defined, some kind of selection must take place. Currently, this selection is made runtime, with (or without) user intervention.
I would like to have a means of selecting an INTERFACE define time, in a similar fashion as are selected define time, and for similar purposes.
I suggest the following syntax:
INTERFACE ifcid ...
...
label : expression LINKTO INTERFACE interfacename
...
The LINKTO keyword would prohibit the runtime expansion of the INTERFACE, but instead call this INTERFACE whenever a user clicks on a (target) atom of expression.
The context ampersand-models/Bugs/No Sentinel/Bug29_InterfaceRefLoop.adl yields incorrect errors about cyclic interface refs:
Error! 500 Internal Server Error: Infinite loop in interface 'Ref' by referencing 'Ref'
The server seems to check the labels on every level in the interface tree, rather than just the roots.
Als je in een Excel bestand een tekst opneemt met quotes (als in: "HeadHunters Inc. doesn't see it as their task ..."), dan komt er bij het importeren een "Error! You have an error in your SQL syntax" vanwege die quote.
Datzelfde geldt als je een veld aan het editen bent en deze tekst er in probeert te stoppen.
Hey Bas,
Ater implementing an 'isa' type check on view annotations, I did a little experiment using the same method for a less restrictive type check on interface refs (ie. target objExr isasource ifcExpr || source ifcExprisa target objExpr instead of target objExr == source ifcExpr, for the code below).
INTERFACE ..
BOX [ ..
, "label": objExpr INTERFACE RefInterface
.. ]
INTERFACE RefInterface : ifcExpr
..Commit 5cad373 on branch experimental-interface-ref-check contains a proof of concept implementation. Do you think this is a good idea, or am I missing something here? The check is done parallel to disambiguation and adding epsilons, so it won't have an adverse effect the quality of the type errors.
To prevent having to topologically sort the interfaces to access their source concepts, I simply run an extra typecheckTerm on the expression of the referenced interface (ifcExpr above). It's not extremely elegant, but doesn't cost much time.
The approach precludes using information from interface refs to disambiguate either objExpr or ifcExpr, but type checker does not seem to do that for boxes either (all types are disambiguated locally), so that shouldn't be a problem.
One of the checks that is currently being done, is the check that SESSION is populated with nothing else than _SESSION. Since this check is added to the Haskell code, Sentinel needs over 40 minutes to finish. This used to be about 13 minutes.
This is partly due to the fact that Haskell is lazy:
Currently subconcepts are not enforced to by mutually exclusive, so if Orange ISA Citrus and Lemon ISA Citrus and no other generalizations are declared, we may still have an atom (e.g. strangeFruit) that is in both Lemon and Orange. See ampersand-models/ISAtest/Strange.adl. This may cause unexpected behavior when such atoms are part of other relations, as they will be effectively treated as the same atom.
The file DTV.adl [8db95f2] is compiled properly into a working prototype by means of Prototype v3.0.3[no git info], build time: 07-Dec-14 09:31:20. It can even generate a DTV.tex file...
However, when compiling with Ampersand v3.0.3[master:8df0d1f], build time: 07-Apr-15 21:59:08, we get a fatal 260 from P2A_Converters:
D:\git\ampersand-models\NVWA DTV>Ampersand DTV.adl -fl --verbose
Reading file DTV.adl
Reading file D:\git\ampersand-models\NVWA DTV\Login.adl
Reading file D:\git\ampersand-models\NVWA DTV\Tijdvakken.adl
Reading file D:\git\ampersand-models\NVWA DTV\Diensten.adl
Reading file D:\git\ampersand-models\NVWA DTV\Referentielijsten.adl
Reading file D:\git\ampersand-models\NVWA DTV\Medewerkers.adl
Reading file D:\git\ampersand-models\NVWA DTV\Tijdverantwoordingen.adl
Reading file D:\git\ampersand-models\NVWA DTV\Periodeverantwoordingen.adl
Reading file D:\git\ampersand-models\NVWA DTV\MedewerkerRechten.adl
Reading file D:\git\ampersand-models\NVWA DTV\Resultaten.adl
Reading file D:\git\ampersand-models\NVWA DTV\Urenpools.adl
Reading file D:\git\ampersand-models\NVWA DTV\PDirektBestanden.adl
Reading file D:\git\ampersand-models\NVWA DTV\PopForDTVtesting.pop
Reading file D:\git\ampersand-models\NVWA DTV\History.adl
Processing DTV
Using Template: D:\git\ampersand\.cabal-sandbox\x86_64-windows-ghc-7.8.4\ampersand-3.0.3\AmpersandData\..\outputTemplates\default.latex
Generating latex to : .\DTV.tex
Ampersand: !fatal 260 (module ADL1.P2A_Converters) Ampersand v3.0.3[master:8df0d1f]
the technical type should be derived from the conceptdefs of this concept.
At first I thought that a class system would render views obsolete, but since we will want to access more than just the raw atom id when presenting it, views will still be useful. In fact, they may provide an elegant way to specify the concept-specific html and js code we need for sophisticated presentations of atoms.
Consider this example:
SPEC Color ISA String
gName :: Ghost -> String = [("ghost1_","Inky");("ghost_2", "Pinky");("ghost_3", "Clyde")]
gColor :: Ghost -> Color = [("ghost1_","cyan");("ghost_2", "pink"); ("ghost_3", "orange")]
VIEW ColoredGhost: Ghost {ghostName : gName, ghostColor : gColor }
HTML
... <span style="{color: $ghostColor$}">$ghostName$</span> ...
ENDVIEW
INTERFACE GhostlyInterface : I[Ghost]
BOX [ "Ghost": I<ColoredGhost>
]The <ColoredGhost> annotation in the interface specifies the view that should be used to show the ghost. The VIEW specifies how to obtain the name and color from the Ampersand model, and how this information is used to create a colored html presentation.
We can use the same mechanism to present a boolean as an html checkbox:
VIEW BoolSwitch: Bool {boolVal : I}
HTML
.. some html presentation of a switch, referring to $boolVal$ ..
JS
.. some JavaScript code needed for switches ..
ENDVIEWAt the same time, we can also have a textual presentation for booleans:
VIEW BoolYesNo: Bool {boolVal : I}
HTML
<span .. showBoolYesNo($boolVal$).. > ..</span>
JS
.. function showBoolYesNo(bool) { return bool=="True" ? "Yes" : "No"; }
ENDVIEWThe annotation to specify the view:
INTERFACE ...
BOX [ "Has finished": hasFinished <BoolSwitch>
]can be seen as a shorthand for
INTERFACE ...
BOX [ "Has finished": hasFinished ATOMIC<BoolSwitch>
]This is analogous to the way we specify classes for boxes ("label": rel BOX<Class> [..]). (We might even want to declare VIEWs for boxes as well, but I haven't really thought about that yet.)
To prevent a multitude of view annotations, we need some way to specify a default view for a concept:
VIEW BoolStr : Bool {boolVal : I} DEFAULTFor each primitive type we can define a default string-based view, and for any other concept we use a default view that shows the raw atom id string (aka the dirty identifier).
If we have all this, the old VIEW syntax can be treated as syntactic sugar.
Old:
VIEW Client: Client(clientName, TXT " from ", clientCity)New:
VIEW Client: Client {seg1: clientName, seg2: V;' in ', seg3: clientCity} DEFAULT
HTML
$allAttrs:{attr|$attr.val$}
ENDVIEWIn the html template code allAttrs is a list of all attributes, and the string-template construct $allAttrs:{attr|$attr.val$}$ iterates over the attibutes and concatenates the attribute value strings.
In general, a view declaration will look something like this:
VIEW <view_id> : <concept> { (<label> : <relation> )* } DEFAULT?
HTML
... $<label>$ ... or some expression referring to $allAttrs$ ..
JS
.. not sure what attributes we would like have here ..
ENDVIEW A lot of things are still unclear, especially concerning non-univalent relations, editing of values, and how to knit everything together. I am also not sure how compositional the Angular code in the current view tree is, but we may be able to generate some extra code in between to fix that. We will also need to figure out what kind of JavaScript fragments we will allow, and how we will access these.
A nice aspect of the new views is that the impact on the Ampersand language will be rather low, and that we will be able to do a lot of experimenting even on a partial implementation.
I'm interested to know what everybody thinks about this.
Interface refs are not handled entirely correctly by the new front-end. In
ampersand-models/Bugs/No Sentinel/Bug30_InterfaceRefBug.adl, no atoms are shown for "buggyRef", even though all three subinterfaces "inline", "ref", and "buggyRef" are equivalent.
The idea of HTML TEMPLATEs in VIEWs is to 'paint' a view on an atom and it is being used in increasingly fashionable ways. The tltle text that is produced in INTERFACES also use VIEWs - in particular: the DEFAULT view. This means that currently, if you use a DEFAULT view that does some nice things (such as display risks in a fashionable way), this corrupts the title in the interface where you can edit such risks, by displaying all arguments that are passed to the view.
There are several options to go about this issue:
VIEWs after the title expression, and use that to display the title.Thanks to Rob Rambhajan and Lex Wedemeijer for forwarding the following bug to us.
Something funny happened in RAP2, when a student submitted a file in which some of the atoms have a name that starts with a space. Apart from giving this message, the software seemed to work properly.
Gerard has diagnosed this as follows:
An atom that starts with a space causes equal atomID's for near-equal atom strings. This is caused by the way atomID's are generated, which does not distinguish between a string that starts with a space and the same string without that space.
Here is the script that produced the message (unabbreviated)
{-
Auteur: Rob Rambhajan
Stdnr : 851658740
-}
{-------------------------------------------------------------------}
CONTEXT Wijzigingsproces_RVB
PATTERN Wijzigingsproces
{-------------------------------------------------------------------}
{--------------------------Start Concepten--------------------------}
CONCEPT "VTW"
"Een voorstel tot wijziging van het systeem, uniek te identificeren met een uniek nummer"
CONCEPT "Businessboardoverleg"
"Beheert en prioriteert wijzigingsportefuille Wijzigingen met een grotere impact worden voorgelegd in de B-board. De B-board beoordeeld deze wijzigingsvoorstellen ten opzichte van elkaar op 'baten', kosten en impact op de organisatie."
CONCEPT "Impactanalyse"
"Document waarin de impact op het system, de aanpalende systemen, hardware, network en de organisatie wordt beschreven In dit document wordt ook een begroting van de kosten en resources vastgelegd"
CONCEPT "Medewerkerinformatievoorziening"
"De persoon verantwoordelijk voor het vervaardigen van, en het oplossen van fouten in, Applicatie, afdeling van het RVB welke verantwoordelijk is voor het implementeren van ICT wijzigingen en verantwoordelijk voor het exploiteren, beheer en onderhoud van de ICT-voorzieningen van de Rgd"
CONCEPT "Applicatie"
"Betreft een computerprogramma ter ondersteuning van een proces."
CONCEPT "Applicatieissue"
"De wens of een tekortkoming dat waargenomen wordt in Applicatie tijdens de uitvoeren van het proces."
CONCEPT "Prio"
"De prioriteit die toegekend wordt aan de VTW's door de buisnessboard;Prio 1, Prio 2, en Prio 3."
CONCEPT "Priotoekenning"
"De bepaling van de juiste Prio van een VTW op basis 'baten', kosten en impact op de organisatie."
CONCEPT "Systeemeigenaar"
"Een persoonmedewerker die een verantwoordelijk is voor de kwaliteit van de Applicatie en de daaraan gerelateerde risicos."
CONCEPT "Hoofdgebruiker"
"De persoon verantwoordelijk voor de uitvoering van een gebruikersacceptatietest."
{--------------------------Eind Concepten---------------------------}
{--------------------------Start Relaties---------------------------}
bespreekt :: Businessboardoverleg * VTW[TOT, INJ, SUR]
PRAGMA "Businessboardoverleg" " bespreekt " "VTW"
EXPLANATION "Een Businessboardoverleg bespreekt 1 of meer VTW. Een VTW wordt in precies 1 Businessboardoverleg besproken."
=[
("Businessboardoverleg 01_2015", "01_2015 VTW 18 Gebouw kenmerken toevoegen");
("Businessboardoverleg 01_2015", "01_2015 VTW 37 Storingsmelding datum en tijd toevoegen");
("Businessboardoverleg 02_2015", "02_2015 VTW 22 functionaliteit i.v.m. BIR compliancy");
("Businessboardoverleg 02_2015", "02_2015 VTW 16 annotaties toevoegen in APRO Imaging")
].
heeft :: Systeemeigenaar * Applicatieissue[INJ]
PRAGMA "Systeemeigenaar" " heeft " " Applicatieissue"
EXPLANATION "Een Systeemeigenaar heeft 0, 1 of meerdere Applicatieissue . Een Applicatieissue wordt geconstateerd door 0 of 1 Systeemeigenaar."
=[
("Joost van Buren", " Gebouw kenmerken toevoegen");
("Joost van Buren", " Storingsmelding datum en tijd toevoegen");
("Hans Smit", " 3-weg matching invoeren voor inkooporders");
("Hans Smit", " functionaliteit i.v.m. BIR compliancy");
("Hans Smit", " annotaties toevoegen in APRO Imaging")
].
registreert :: Systeemeigenaar * VTW[INJ, SUR]
PRAGMA "Systeemeigenaar " " registreert " " VTW"
EXPLANATION "Een Systeemeigenaar registreert 0, 1 of meerdere VTW. Een VTW wordt geregistreerd door precies 1 Systeemeigenaar."
=[
("Joost van Buren", "01_2015 VTW 18 Gebouw kenmerken toevoegen");
("Joost van Buren", "01_2015 VTW 37 Storingsmelding datum en tijd toevoegen");
("Hans Smit", "02_2015 VTW 22 functionaliteit i.v.m. BIR compliancy");
("Hans Smit", "02_2015 VTW 16 annotaties toevoegen in APRO Imaging")
].
beschrijft :: VTW * Applicatieissue[TOT]
PRAGMA "VTW " " beschrijft " " Applicatieissue"
EXPLANATION "Een VTW beschrijft 1 of meerdere Applicatieissue. Een Applicatieissue kan door 0, 1 of meerdere VTW worden beschreven."
=[
("01_2015 VTW 18 Gebouw kenmerken toevoegen"," Gebouw kenmerken toevoegen");
("01_2015 VTW 37 Storingsmelding datum en tijd toevoegen"," Storingsmelding datum en tijd toevoegen");
("02_2015 VTW 22 functionaliteit i.v.m. BIR compliancy","functionaliteit i.v.m. BIR compliancy");
("02_2015 VTW 16 annotaties toevoegen in APRO Imaging","annotaties toevoegen in APRO Imaging")
].
wordt_gemaakt_voor :: Impactanalyse * VTW[UNI, TOT]
PRAGMA "Impactanalyse " " wordt gemaakt voor " " VTW "
EXPLANATION "Een Impactanalyse wordt gemaakt voor precies 1 VTW. Voor een VTW kunnen 0, 1 of meerdere Impactanalyseen worden uitgevoerd."
=[
("IA VTW 18", "01_2015 VTW 18 Gebouw kenmerken toevoegen");
("IA VTW 37", "01_2015 VTW 37 Storingsmelding datum en tijd toevoegen");
("IA VTW 22", "02_2015 VTW 22 functionaliteit i.v.m. BIR compliancy");
("IA VTW 16", "02_2015 VTW 16 annotaties toevoegen in APRO Imaging")
].
vraagt_om :: Businessboardoverleg * Impactanalyse[INJ, SUR]
PRAGMA "Businessboardoverleg " " vraagt om " " Impactanalyse"
EXPLANATION "Een Businessboardoverleg kan 0, 1 of meerdere Impactanalyse vragen. Een Impactanalyse wordt door precies 1 Businessboardoverleg gevraagd."
=[
("Businessboardoverleg 01_2015", "IA VTW 18");
("Businessboardoverleg 01_2015", "IA VTW 37");
("Businessboardoverleg 02_2015", "IA VTW 22");
("Businessboardoverleg 02_2015", "IA VTW 16")
].
doet :: Businessboardoverleg * Priotoekenning[TOT, INJ, SUR]
PRAGMA "Businessboardoverleg " " doet " " Priotoekenning"
EXPLANATION "Een Businessboardoverleg doet 1 of meerdere Priotoekenningen. Een Priotoekenning wordt door precies 1 Businessboardoverleg gedaan."
=[
("Businessboardoverleg 01_2015", "01_2015 VTW 18 Gebouw kenmerken toevoegen_Priotoekenning:Prio 2");
("Businessboardoverleg 01_2015", "01_2015 VTW 37 Storingsmelding datum en tijd toevoegen_Priotoekenning:Prio 2");
("Businessboardoverleg 02_2015", "02_2015 VTW 22 functionaliteit i.v.m. BIR compliancy_Priotoekenning:Prio 2");
("Businessboardoverleg 02_2015", "02_2015 VTW 16 annotaties toevoegen in APRO Imaging_Priotoekenning:Prio 2")
].
ontvangt :: Hoofdgebruiker * Priotoekenning[TOT, INJ, SUR]
PRAGMA "Hoofdgebruiker " " ontvangt " " Priotoekenning"
EXPLANATION "Een Hoofdgebruiker ontvangt 1 of meerdere Priotoekenningen. Een Priotoekenning wordt door precies 1 Hoofdgebruiker ontvangen."
=[
("HdB", "01_2015 VTW 18 Gebouw kenmerken toevoegen_Priotoekenning:Prio 2");
("EvG", "01_2015 VTW 37 Storingsmelding datum en tijd toevoegen_Priotoekenning:Prio 2");
("AH", "02_2015 VTW 22 functionaliteit i.v.m. BIR compliancy_Priotoekenning:Prio 2");
("PG", "02_2015 VTW 16 annotaties toevoegen in APRO Imaging_Priotoekenning:Prio 2")
].
past_aan :: Hoofdgebruiker * Prio[INJ]
PRAGMA "Hoofdgebruiker " " past_aan " " Priotoekenning"
EXPLANATION "Een Hoofdgebruiker past 0, 1 of meerdere Prio aan. Een Prio wordt door 0 of 1 Hoofdgebruiker aangepast."
=[
("HdB", "01_2015 VTW 18 Gebouw kenmerken toevoegen_Priotoekenning:Prio 1");
("EvG", "01_2015 VTW 37 Storingsmelding datum en tijd toevoegen_Priotoekenning:Prio 1");
("AH", "02_2015 VTW 22 functionaliteit i.v.m. BIR compliancy_Priotoekenning:Prio 1");
("PG", "02_2015 VTW 16 annotaties toevoegen in APRO Imaging_Priotoekenning:Prio 1")
].
geeft_akkoord :: Hoofdgebruiker * VTW[INJ, SUR]
PRAGMA "Hoofdgebruiker " " geeft_akkoord " " VTW"
EXPLANATION "Een Hoofdgebruiker geeft akkoord voor 0, 1 of meerdere VTW. Een VTW wordt door precies 1 Hoofdgebruiker geaccordeerd."
=[
("HdB", "01_2015 VTW 18 Gebouw kenmerken toevoegen");
("EvG", "01_2015 VTW 37 Storingsmelding datum en tijd toevoegen");
("AH", "02_2015 VTW 22 functionaliteit i.v.m. BIR compliancy");
("PG", "02_2015 VTW 16 annotaties toevoegen in APRO Imaging")
].
geeft_opdracht_aan :: Hoofdgebruiker * Medewerkerinformatievoorziening[INJ]
PRAGMA "Hoofdgebruiker " " geeft opdracht aan " " Medewerkerinformatievoorziening"
EXPLANATION "Een Hoofdgebruiker geeft opdracht aan 0, 1 of meerdere Medewerkerinformatievoorziening. Een Medewerkerinformatievoorziening ontvangt van 0 of 1 een Hoofdgebruiker een opdracht."
=[
("HdB", "Joop");
("EvG", "Chanel");
("AH", "Ralph");
("PG", "Hugo")
].
realiseert :: Medewerkerinformatievoorziening * VTW[INJ]
PRAGMA "Medewerkerinformatievoorziening " " realiseert " " VTW"
EXPLANATION "Een Medewerkerinformatievoorziening realiseert 0, 1 of meerdere VTW. Een VTW wordt door 0 of 1 Medewerkerinformatievoorziening gerealiseerd."
=[
("Joop","01_2015 VTW 18 Gebouw kenmerken toevoegen");
("Chanel","01_2015 VTW 37 Storingsmelding datum en tijd toevoegen");
("Ralph","02_2015 VTW 22 functionaliteit i.v.m. BIR compliancy");
("Hugo","02_2015 VTW 16 annotaties toevoegen in APRO Imaging")
].
is_toegewezen_aan :: VTW * Medewerkerinformatievoorziening [INJ]
PRAGMA "VTW " " is toegewezen aaan " " Medewerkerinformatievoorziening"
EXPLANATION "Er zijn 0, 1 of meerdere VTW toegewezen aan een Medewerkerinformatievoorziening. Een Medewerkerinformatievoorziening heeft 0, 1 of meerdere VTW toegewezen gekregen."
=[
("01_2015 VTW 18 Gebouw kenmerken toevoegen","Joop");
("01_2015 VTW 37 Storingsmelding datum en tijd toevoegen","Chanel");
("02_2015 VTW 22 functionaliteit i.v.m. BIR compliancy","Ralph");
("02_2015 VTW 16 annotaties toevoegen in APRO Imaging","Hugo")
].
wordt_aangepast_middels :: Applicatie * VTW [INJ,SUR]
PRAGMA "Applicatie " " wordt aangepast middels " " VTW"
EXPLANATION "Er worden 0, 1 of meerdere Applicaties aangepast middels een VTW. Een VTW heeft een aanpassing van 0, 1 of meerdere Applicaties tot gevolg."
=[
("Condor", "01_2015 VTW 18 Gebouw kenmerken toevoegen");
("e-BSService Contracts", "01_2015 VTW 37 Storingsmelding datum en tijd toevoegen");
("e-BS", "02_2015 VTW 22 functionaliteit i.v.m. BIR compliancy");
("APRO", "02_2015 VTW 16 annotaties toevoegen in APRO Imaging")
].
ontwikkelt :: Medewerkerinformatievoorziening * Applicatie[TOT, SUR]
PRAGMA "Medewerkerinformatievoorziening " " ontwikkelt " " Applicatie"
EXPLANATION "Een Medewerkerinformatievoorziening ontwikkelt 1 of meerdere Applicatie. Applicatie wordt ontwikkeld door 1 of meerdere Medewerkerinformatievoorziening."
=[
("Joop", "Condor");
("Chanel", "e-BSService Contracts");
("Ralph", "e-BS");
("Hugo", "APRO")
].
krijgt :: VTW * Priotoekenning[TOT]
PRAGMA "VTW " " krijgt " " Priotoekenning"
EXPLANATION "Een VTW krijgt 1 of meerdere Priotoekenningen. Een Priotoekenning wordt gedaan voor 0, 1 of meerdere VTWen."
=[
("01_2015 VTW 18 Gebouw kenmerken toevoegen", "01_2015 VTW 18 Gebouw kenmerken toevoegen_Priotoekenning:Prio 2");
("01_2015 VTW 37 Storingsmelding datum en tijd toevoegen", "01_2015 VTW 37 Storingsmelding datum en tijd toevoegen_Priotoekenning:Prio 2");
("02_2015 VTW 22 functionaliteit i.v.m. BIR compliancy", "02_2015 VTW 22 functionaliteit i.v.m. BIR compliancy_Priotoekenning:Prio 2");
("02_2015 VTW 16 annotaties toevoegen in APRO Imaging", "02_2015 VTW 16 annotaties toevoegen in APRO Imaging_Priotoekenning:Prio 2")
].
bepaalt :: Priotoekenning * Prio[UNI, TOT, SUR]
PRAGMA "Priotoekenning " " bepaalt " " Prio"
EXPLANATION "Een Priotoekenning bepaalt precies 1 Prio. Een Prio wordt bepaalt door 1 of meerdere Priotoekenningen."
=[
("01_2015 VTW 18 Gebouw kenmerken toevoegen_Priotoekenning:Prio 2","01_2015 VTW 18 Gebouw kenmerken toevoegen_Priotoekenning:Prio 1");
("01_2015 VTW 37 Storingsmelding datum en tijd toevoegen_Priotoekenning:Prio 2","01_2015 VTW 37 Storingsmelding datum en tijd toevoegen_Priotoekenning:Prio 1");
("02_2015 VTW 22 functionaliteit i.v.m. BIR compliancy_Priotoekenning:Prio 2","02_2015 VTW 22 functionaliteit i.v.m. BIR compliancy_Priotoekenning:Prio 1");
("02_2015 VTW 16 annotaties toevoegen in APRO Imaging_Priotoekenning:Prio 2", "02_2015 VTW 16 annotaties toevoegen in APRO Imaging_Priotoekenning:Prio 1")
].
{---------------------------Eind Relaties---------------------------}
{---------------------------Start Regels----------------------------}
RULE Impactanalyse_moet_gemaakt_worden_voor_de_VTW
MAINTAINS vraagt_om |- bespreekt;wordt_gemaakt_voor~
EXPLANATION "ALS de VTW is besproken in het Businessboardoverleg DAN MOET Impactanalyse gemaakt worden voor de VTW."
RULE Businessboard_overleg_moet_voor_iedere_VTW_de_Prio_bepalen
MAINTAINS doet |- bespreekt;krijgt
EXPLANATION "ALS een VTW besproken wordt in het Businessboardoverleg DAN MOET voor de VTW een Priotoekenning worden gedaan."
RULE Hoofdgebruiker_past_op_basis_van_Priotoekenning_de_Prio_aan
MAINTAINS past_aan |- ontvangt;bepaalt
EXPLANATION "ALS een Priotoekenning heeft plaatsgeonden DAN MOET de Hoofdgebruiker de Prio aanpassen."
RULE alleen_een_Hoofdgebruiker_mag_een_VTW_aan_Medewerkerinformatievoorziening_toewijzen
MAINTAINS is_toegewezen_aan |- geeft_akkoord~;geeft_opdracht_aan
EXPLANATION "ALS een VTW wordt toegewezen aan een Medewerkerinformatievoorziening DAN MOET de Hoofdgebruiker het toewijzen aan de Medewerkerinformatievoorziening."
RULE Medewerkerinformatievoorziening_moet_VTW_in_Applicatie_implementeren
MAINTAINS realiseert~ |- wordt_aangepast_middels~;ontwikkelt~
EXPLANATION "ALS een VTW is ingediend voor een Applicatie DAN MOET de Medewerkerinformatievoorziening de VTW implementeren."
RULE Hoofdgebruiker_moet_VTW_toewijzen
MAINTAINS krijgt~ |- ontvangt~;geeft_akkoord
EXPLANATION "ALS voor een VTW een Priotoekenning is gedaan DAN MOET de Hoofdgebruiker die de Priotoekenning ontvangt de VTW toewijzen aan de een medewerker informatievoorziening."
{----------------------------Eind Regels----------------------------}
ENDPATTERN
ENDCONTEXT
The new sql generator on master causes some problems in the generated prototypes. The prototypes below are currently broken:
http://sentinel.tarski.nl/ampersand/Limorange/index.php?interface=Overview&atom=1
http://sentinel.tarski.nl/ampersand/Delivery/index.php?interface=Overview&atom=1
http://sentinel.tarski.nl/ampersand/Hello/index.php?interface=Overview&atom=1
(These are the only ones I tested, so there's probably more)
Dit is een vervolg op ticket417 in sourceforge.. Laten we vooral daar geen nieuwe updates meer doen, want dat is erg verwarrend.Indien nodig, dan graag hier op github een nieuw ticket aanmaken, en er dan naar verwijzen.
Creating new objects (atoms with several relations) is distinct from updating them. For starters, new objects should often relate to other, already existing ones. For example, a new order line should relate to precisely one order. We do not want to bother the user with specifying such links. In the old prototype generator, the editor took care of this and I assume that the new one will do this too, some day.
However, some fields may need to be filled in automatically where their contents depend on session variables (i.e. relations where the source (or target) atom is in SESSION). For example, a session user may be set as the author of a Note (or Comment). In order to prevent false populations in a multi-user environment, the rule for automatically populating fields using session variables requires that the object itself be created in the same SESSION. So, creating new atoms should be done in an interface that starts with the '_SESSION' atom.
Request: replace the list of INTERFACEs that you get when clicking on the '+' icon (i.e. the rightmost icon) in the menu bar with INTERFACEs whose source atom start with the '_SESSION' atom (and/or INTERFACEs whose name starts with the text 'New', in which case &-writers can control which INTERFACEs are there - in this case, such INTERFACEs should NOT be included in the list of selections that you get when clicking on a single atom (link)).
In the Person interface of ampersand-models/ISAtest/Limorange.adl (on my machine http://localhost/AmpersandInSites/Limorange/#/Person/martijn), interface labels overlap with the atom values:
This interface also shows how having the layout change on mouse-over events may cause problems. If you you scroll down and try to edit in the ownsLimes;I[Orange] fields, the page changes considerably, and you will have to scroll down again to see the field again.
If I make statement elmMapping :: Element * Element [SYM]
In Generics.php I get:
$allRules =
array
( 'SYM elmMapping::Element*Element' =>
array ( 'name' => 'SYM elmMapping::Element*Element'
, 'ruleAdl' => 'elmMapping = elmMapping~'
, 'origin' => 'line 40:25, file "C:\\\\Users\\\\stornebrinkmhm\\\\AppData\\\\Local\\\\My Local Documents\\\\Ampersand\\\\T4SMM\\\\SMM-Ontology.adl"'
, 'meaning' => 'elmMapping[Element] is symmetric'
, 'message' => 'elmMapping[Element] is not symmetric'
, 'srcConcept' => 'Element'
, 'tgtConcept' => 'Element'
, 'conjunctIds' => array ('conj_23')
, 'pairView' =>
array
()
)
so far so good. But if I look at conj_23 i see:
$allConjuncts =
array
( 'conj_23' =>
array ( 'signalRuleNames' => array ('Symmetry of mappings, add mapping')
, 'invariantRuleNames' => array ('SYM elmMapping::Element*Element')
, 'violationsSQL' => '/* this will quaranteed return 0 rows: */
select
distinct
a as src, a as tgt
from (/* Select nothing... */
select 1 as a)
as nothing
where a <> 1'
)
There is some 'dummy' sql code here, which will never result in an violation. The SYM rule is thus not checked.
While experimenting with populating the database with --ast-tables, a lot of tables stay empty, even though the insert statements are generated into InstallerDefPop.php.
I suspect that something goes wrong, and there is no proper error handling.
Here's an idea I just had for a more compositional alternative to <?>. If we have a function f :: a -> b -> Guarded C that we want to apply to the results of two guarded expressions guardedA :: Guarded A and guardedB :: Guarded B this could be expressed elegantly with a monad:
testM :: Guarded C
testM =
do { a <- guardedA
; b <- guardedB
; f a b
}
but with our applicative functor we get:
testA1 :: Guarded C
testA1 = (\(a,b) -> f a b) <?> ((,) <$> guardedA <*> guardedB)
I don't have a good intuition for the <?> combinator (which may come later), but it is also not very compositional, which requires us to tuple and untuple the a and b arguments.
On the other hand, if we use a function unguard :: Guarded (Guarded a) -> Guarded a, we can simply use <$> to compose the arguments and consolidate the nested Guarded's aftwerwards:
testA2 :: Guarded C
testA2 = unguard $ f <$> guardedA <*> guardedB
The definition of unguard is straightforward:
unguard :: Guarded (Guarded a) -> Guarded a
unguard (Errors errs) = Errors errs
unguard (Checked g) = g
Other people must have run into this as well, so I thought a combinator like this would be in an Applicative/Error functor module somewhere, but I haven't found it so far.
Since we have CLASSIFY, the complement of a relations may be preceeded with V, so that you can get constructs such as (V - r). I was wondering whether or not V may be replaced with any other relation that satisfies type checking constraints, e.g. (s - r)and if so, does that mean that this expression represents the set of pairs { (a,b) | (a,b) \elem s and (a,b) \notelem r }?
Such constructs would be useful e.g. when testing whether or not an atom has a set of properties (each of which represented with a relation that is [PROP]), or selecting sets of atoms that have such sets of properties, as in
INTERFACE test: '_SESSION';sessionOrders;(orderIsAccepted - orderIsShipped)
which would then work on all orders that have been accepted but not yet shipped.
Curently, installing Ampesand on a windows machine, for someone without a Haskell stack, is not straintforeward. We have tried this with the windows installer before. This works, but it is combersome to create a new version of the installer.
If all files from AmpersandData are incorporated into ampersand.exe, simular to staticfiles, it will be possible to distribute ampersand.exe.
Steps involved:
Currently, there is no relations between the Concept in an IDENT statement and the source of the expression. There should be one, because the expression might be overloaded, giving unhelpful error messages. For this reason, I added ShouldSucceed/try47.adl:
CONTEXT Try47 IN ENGLISH
IDENT Context: Context(name)
RELATION name[Context*ContextName] [UNI,TOT,INJ]
IDENT Pattern: Pattern(name)
RELATION name[Pattern*PatternName] [UNI,TOT,INJ]
ENDCONTEXT
This now gives the following message:
Error(s) found:
Cannot disambiguate the relation: name
Please add a signature (e.g. [A*B]) to the relation.
Relations you may have intended:
name[Context*ContextName]
name[Pattern*PatternName]
Error at symbol name in file try47.adl at line 3 : 24
Because all patterns and processes are in vprocesses, as well as in vpatterns, there is duplication when we collect from both of these. For instance, all rule purposes are duplicated. (e.g. invariant 'verantwoordingsperiode' in chapter 6.2.2 of the functional specification for DTV.adl)
Fixing this requires some changes to Motivation.hs, but may also arise in other places where results from vprocesses are combined with those from vpatterns.
When compiling \git\ampersand-models\NVWA DTV\Login.adl and running it on XAMPP, I get a database error.
Symptoms:
The Ampersand programmer can fix the problem by removing V[ONE*SESSION]; from line 128 of Login.adl, which is the root expression of INTERFACE "Wijzig uw account". Obviously, the mistake is to use ONE as the session atom. Nevertheless, Ampersand should not respond with a database error, but rather with an Ampersand message about ONE.
Identification:
This concerns commit d503b15, which has been compiled with Ampersand v3.1.0[master:c76fb54], build time: 04-May-15 16:34:24 West-Europa, by the following command:
D:>Ampersand --verbose --newFrontend -pD:\htdocs\klad\ Login.adl
Han, I see somthing funny in LaTeX. Below, please find the last part of the (verbose) output of Ampersand.
I am getting this when compiling NVWA DTV/Tijdverantwoording.adl, but also other .adl files in NVWA DTV. Since you are working on LaTeX things anyway, would you look into this for me?
.\RulesInPatternAutoMaintainHistory.png written.
Generating Png using Dot.
.\Classification.png written.
Generating Png using Dot.
.\LogicalDataModel.png written.
Generating Png using Dot.
.\TechnicalDataModel.png written.
----------- LaTeX error-----------
Overfull \hbox (1291.9695pt too wide) in alignment at lines 18759--18785
[] [] [] []
[]
Package longtable Warning: Column widths have changed
(longtable) in table 44.1 on input line 18785.
[260
] ("D:\git\ampersand-models\NVWA DTV\Tijdverantwoording.gls" [261]
! Undefined control sequence.
<argument> \letcs {\glo@name
}{glo@\glsdetoklabel {Assignment}@name}\expanda...
l.5 ...tentrycounter[]{page}\glsnumberformat{20}}}
----------------------------------
ERROR: Latex execution failed.
For more information, run pdflatex on: Tijdverantwoording.tex
Or consult the log file:
.\Tijdverantwoording.log0
PdfLatex was called once.
Done.
Done.
D:\git\ampersand-models\NVWA DTV>
Consider the scriptlet:
INTERFACE Test : <expression>
<remainder of the interface>
Whenever Test is invoked by the user for some (src)atom, the paints all sorts of stuff on the screen, given the (tgt)atom(s) of . However, when there are no such (tgt)atoms, an error is given rather than an empty screen, which suggests that there is something wrong in the database, or in the code, or ... Rather than presenting this error, it would be preferable to NOT show this error, but catch it and provide some regular text on the screen that does not have this association, e.g. saying: "There is nothing to show, or you are not permitted to see it."
For purposes such as:
parser directives are called for. Realizing that this increases the "beheerslast", parser directive syntax) should be ADL-agnostic. For starters (i.e. to accommodate purposes 1, 2 and 3), the following (minimum) syntax is proposed for an <if-expression>:
#IF <condition>
<textlines>
#ENDIF
and <set-line> and <clr-line>
#SET <variablename> (TRUE | FALSE)
#CLR <variablename>
This can be specified in a BNF-like notation as follows:
<if-expression> ::= <if-line> <textlines> <endif-line>
<if-line> ::= #IF <condition>
<condition> ::= [NOT] <variablename> [EXISTS]
<textlines> ::= ( <ADL text> | <set-line> | <clr-line> )
<set-line> ::= #SET <variablename> (TRUE | FALSE)
<clr-line> ::= #CLR <variablename>
<endif-line> ::= #ENDIF
When compiling the file Interfaces.adl, I get the following behaviour:
D:\data\sjo00577\Documents\git\ampersand\AmpersandData\FormalAmpersand>Ampersand -fl Interfaces.adl
----------- LaTeX error-----------
File: ts1lmr.fd 2009/10/30 v1.6 Font defs for Latin Modern
)
LaTeX Font Info: Try loading font information for T1+lmtt on input line 1354
.
("D:\Program Files\MiKTeX 2.9\tex\latex\lm\t1lmtt.fd"
File: t1lmtt.fd 2009/10/30 v1.6 Font defs for Latin Modern
) [19] [20 <D:/data/sjo00577/Documents/git/ampersand/AmpersandData/FormalAmpersand/TechnicalDataModel.png>] [21]
(D:\data\sjo00577\Documents\git\ampersand\AmpersandData\FormalAmpersand\Interfaces.gls [22]
! Use of \\smash doesn't match its definition.
\@tforloop #1#2\@@ #3#4->\def #3 #1}\ifx #3\@nnil \expandafter \@fornoop \el...
l.5 ...etentrycounter[]{page}\glsnumberformat{4}}}
----------------------------------
ERROR: Latex execution failed.
For more information, run pdflatex on: Interfaces.tex
Or consult the log file:
.\Interfaces.log0
In one of the comments below, @hanjoosten suggests:
"The cause of your problem seems to be a glossary item that does not exist, but it is referenced. (assumably a relation). It would exist iff that relation had either a MEANING or a PURPOSE defined. But since it lacks both, the relation is skipped in the natural language chapter."
Could anyone verify or falsify Han's hypothesis, so as to further this issue?
When compiling with --ast-tables, I get a populated metamodel.
Inspecting that in the database (on phpMySQL), my eye is caught by the table conceptone.
It is empty, but I would expect it to contain one element in all situations.
Handling [PROP]-type relations in relation algebra is very handy. However, editing them in the new frontend currently is cumbersome, as they need to be 'translated' into booleans to avoid the 'dirty identifiers' to show up on the screen.
In order for the frontend to manage this translation, it is necessary that it gets information about the expressions that are [PROP]erties, in the same way as it gets information on expressions that are [UNI] or [TOT]. There are two places where this needs to be done:
exprIsProp (like exprIsUni and exprIsTot), and$exprIsProp$ (like Furthermore, the default template for properties can be set to the Atomic-BOOL template (like with BOOL concept).
Currently, the INCLUDE statement only supports simple filenames.
In order to keep sources of &-modules in a single location, I would like to use constucts such as:
INCLUDE "..\lib\login.adl"
INCLUDE "C:\Ampersand\Library\login.adl"
Would that be possible?
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.