Re: [cellml-discussion] r1755 - in pce/trunk/chrome/content: controls ui util
Hi,
A few review comments for this commit are inline.
CellML Automated Notifications wrote:
Author: agarny
Date: 2007-09-19 05:47:09 +1200 (Wed, 19 Sep 2007)
New Revision: 1755
Modified:
pce/trunk/chrome/content/controls/graph.xml
pce/trunk/chrome/content/controls/model.xml
pce/trunk/chrome/content/ui/MainWindow.js
pce/trunk/chrome/content/util/GraphSupport.js
pce/trunk/chrome/content/util/Metadata.js
pce/trunk/chrome/content/util/ModelURLLoader.js
pce/trunk/chrome/content/util/VariablePath.js
Log:
Made some 'alert' messages more meaningful.
Modified: pce/trunk/chrome/content/controls/graph.xml
===
--- pce/trunk/chrome/content/controls/graph.xml 2007-09-18 05:56:23 UTC
(rev 1754)
+++ pce/trunk/chrome/content/controls/graph.xml 2007-09-18 17:47:09 UTC
(rev 1755)
@@ -267,7 +267,7 @@
const
XUL=http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul;;
var tcs = e.element.getElementsByTagNameNS(XUL, treecell);
tcs.item(1).setAttribute(label, m.name);
-
+
I agree that lines with only spaces are bad - I will make a note of this
when we come to writing up our style guidelines.
try
{
var typeT = ds.GetTarget(first, typeR, true);
@@ -1531,7 +1531,7 @@
try
{
this.gcontext.moveTo(xe, y);
- } catch (e) { alert(Got problem with xe= + xe + and y= + y); }
+ } catch (e) { alert(There is a problem with xe= + xe + and y=
+ y + .); }
this.gcontext.lineTo(x, y);
this.gcontext.stroke();
}
Modified: pce/trunk/chrome/content/controls/model.xml
===
--- pce/trunk/chrome/content/controls/model.xml 2007-09-18 05:56:23 UTC
(rev 1754)
+++ pce/trunk/chrome/content/controls/model.xml 2007-09-18 17:47:09 UTC
(rev 1755)
@@ -305,12 +305,11 @@
// Now go through the code information, and find initial values to set...
var ciit = ci.iterateTargets();
-var v;
while ((ct = ciit.nextComputationTarget()) != null)
{
if (ct.degree == 0 ct.type == 2 /* STATE_VARIABLE */)
{
-var cv = FindElementByPath(MakeVariablePath(ct.variable), m);
+var cv = FindElementByPath(MakeVariablePath(ct.variable),
ct.variable, m);
See my comments about the changes to FindElementByPath on VariablePath.js
cv.initialValue = dc.getRawData(ct.assignedIndex, guess);
}
}
Modified: pce/trunk/chrome/content/ui/MainWindow.js
===
--- pce/trunk/chrome/content/ui/MainWindow.js 2007-09-18 05:56:23 UTC (rev
1754)
+++ pce/trunk/chrome/content/ui/MainWindow.js 2007-09-18 17:47:09 UTC (rev
1755)
@@ -65,7 +65,7 @@
window.ccgs =
cc[@cellml.org/ccgs-bootstrap;1].
getService(ci.cellml_servicesICodeGeneratorBootstrap).createCodeGenerator();
-
+
// Get the CellML Integration Service...
window.cis =
cc[@cellml.org/cis-bootstrap;1].
@@ -81,7 +81,7 @@
}
catch (e)
{
- alert(Caught exception: + e);
+ alert(A problem occurred while registering the different services
required by PCEnv: + e + .);
}
}
@@ -142,8 +142,8 @@
}
catch (e)
{
- alert(Invalid URL on command line: + ns.getArgument(i) + ( +
-NormaliseInputURL(ns.getArgument(i)) + ): + e);
+ alert(An invalid URL was provided to PCEnv: + ns.getArgument(i) +
( +
+NormaliseInputURL(ns.getArgument(i)) + ): + e + .);
I have two concerns with the new message:
1) We don't say where the invalid URL came from. This error would
presumably usually arise when deliberately invoking the program from
with arguments on the command line, and so the user would be aware that
they had done this, and it would be good to draw their attention to the
fact that the URL they passed is invalid.
2) I am not sure about whether we should just write 'PCEnv' in alerts
like this - we can obviously search for all instances and replace them
if we ever change the name, although it will make life harder, e.g., for
someone creating a differently branded fork for inclusion in a
distribution or for some other purpose. Having a 'branding string' might
be one way around it, or we could just avoid naming the product in such
messages since it is probably not necessary here.
}
}
Modified: pce/trunk/chrome/content/util/GraphSupport.js
===
--- pce/trunk/chrome/content/util/GraphSupport.js 2007-09-18 05:56:23 UTC
(rev 1754)
+++ pce/trunk/chrome/content/util/GraphSupport.js 2007-09-18 17:47:09 UTC
(rev 1755)
@@ -9,6 +9,7 @@
return function()
{
var idcr =
[cellml-discussion] Proposal: Standardised CellML real number format
Hi all, The CellML Specification does not define the format in which real numbers will be represented at all (it just says, for initial_value: The value of the |initial_value| attribute may be a real number or a variable). The MathML specification defines A real number is presented in decimal notation. Decimal notation consists of an optional sign (+ or -) followed by a string of digits possibly separated into an integer and a fractional part by a decimal point. Some examples are 0.3, 1, and -31.56. If a different |base| is specified, then the digits are interpreted as being digits computed to that base. This means that there are no constraints at all on how initial values can be represented. It is common practice in current CellML processing to use representations in standard notation, using formats like 1E8. Therefore, I think that we need to restrict it down to something like (in regular expression syntax): (\-|)[0-9]+(\.[0-9]+|)(E(-|)[0-9]+|e(-|)[0-9]+|) In other words: An optional - , followed by 1 or more digits from 0 to 9, followed by an optional decimal point (not a comma or momayyez) followed by an optional E or e character with a possible sign and one or more digits after it. Are there any opinions about this? I will re-raise this at the next CellML meeting next Wednesday so we can summarise any discussion which has occurred on the mailing lists, so please send your comments before then. Best regards, Andrew ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
[cellml-discussion] CellML Versioning Strategy
Hi all, At the break-away session on the versioning strategy for CellML (which followed the Auckland CellML meeting today) we discussed the future of how we would version CellML, including whether we would put all elements for the next version of CellML in a completely different namespace, or only the elements that had changed. A summary of the discussion is up at http://www.cellml.org/meeting_minutes/MeetingMinutes19September2007/ under Breakaway session on versioning strategy for CellML. Note that the participants at the session have not had a chance to correct errors in it yet, and it may not yet accurately reflect everyone's view. However, it does lay out the options, and so may provide a starting point for any suggestions or comments from the community. Please send and such suggestions or comments to the CellML discussion mailing list prior to the 3rd October 2007. Best regards, Andrew ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Proposal: Standardised CellML real number format
David Nickerson wrote: Therefore, I think that we need to restrict it down to something like (in regular expression syntax): (\-|)[0-9]+(\.[0-9]+|)(E(-|)[0-9]+|e(-|)[0-9]+|) In other words: An optional - , followed by 1 or more digits from 0 to 9, followed by an optional decimal point (not a comma or momayyez) followed by an optional E or e character with a possible sign and one or more digits after it. probably best to allow for an optional '+' or '-' both at the start and following the exponent character. I have no experience, but does using a non-EN locale make it difficult to enter numbers with a decimal point? Based on http://en.wikipedia.org/w/index.php?title=Keyboard_layoutoldid=158242943 it looks like we are okay for the European, South American, and Asian keyboard layouts. I am not sure about the Arabic and Armenian layouts. However, I think that programs can present the numbers to the user in whatever format they like, as long as the specification describes that they are stored in a consistent way. Users who can't enter the full stop / period character who want to edit a CellML file in a text editor will have other problems anyway, e.g. they couldn't type in the CellML namespace or the XML version (or any cn elements in the MathML). Best regards, Andrew ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
[cellml-discussion] CellML Versioning Strategy
Andrew was opposed to the idea of changing all the namespaces, and suggested changing the namespace of a particular element in only some circumstances: I agree very strongly with this. It would make writing out xpath expressions simpler since you know absolutely what namespace for what elements you want to target. The namespace argument also applies to new attributes - they need to be placed into a new namespace too and references explicitly as such in a document since the rule for CellML is that unnamespaced attributes will acquire the namespace of the element owning them. Poul thinks that mixing namespaces means you have to scan the entire document before you can determine that you don't support a particular version of the model. I don't understand that. You might want to scan a document to see what versions the model conforms up to, but one of the nice things about pushing these new elements/attributes into new namespaces is that you can still treat a model as say 1.1 even if it contains 1.2 elements and attributes. So the scanning is already done implicitly by a library that is simply trying to use a CellML model and is reading it at the version level it is capable of. Of course CellML 1.1 is broken in this sense. There was some discussion about what namespace the model element should be in CellML 1.2. Randall suggested it should be in CellML 1.1 and not CellML 1.0 Can we apply this to all existing elements and attributes then? So that when 1.2 comes along and its interpretation we only really have 1.2 and 1.1 to deal with. cheers Matt On 9/19/07, Andrew Miller [EMAIL PROTECTED] wrote: Hi all, At the break-away session on the versioning strategy for CellML (which followed the Auckland CellML meeting today) we discussed the future of how we would version CellML, including whether we would put all elements for the next version of CellML in a completely different namespace, or only the elements that had changed. A summary of the discussion is up at http://www.cellml.org/meeting_minutes/MeetingMinutes19September2007/ under Breakaway session on versioning strategy for CellML. Note that the participants at the session have not had a chance to correct errors in it yet, and it may not yet accurately reflect everyone's view. However, it does lay out the options, and so may provide a starting point for any suggestions or comments from the community. Please send and such suggestions or comments to the CellML discussion mailing list prior to the 3rd October 2007. Best regards, Andrew ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] CellML Versioning Strategy
On 9/19/07, Andrew Miller [EMAIL PROTECTED] wrote: Matt Halstead wrote: Andrew was opposed to the idea of changing all the namespaces, and suggested changing the namespace of a particular element in only some circumstances: I agree very strongly with this. It would make writing out xpath expressions simpler since you know absolutely what namespace for what elements you want to target. The namespace argument also applies to new attributes - they need to be placed into a new namespace too and references explicitly as such in a document since the rule for CellML is that unnamespaced attributes will acquire the namespace of the element owning them. This is something which I think we should change ASAP - it is a deviation from the XML specification which we should not be declaring at the CellML level. I think that once this is sorted out, versioning the elements is sufficient, and there is no need to mix namespaces of attributes within the same element (if the attribute definitions change, then the semantics of the element have changed, so we change its namespace). Yup Poul thinks that mixing namespaces means you have to scan the entire document before you can determine that you don't support a particular version of the model. I don't understand that. You might want to scan a document to see what versions the model conforms up to, but one of the nice things about pushing these new elements/attributes into new namespaces is that you can still treat a model as say 1.1 even if it contains 1.2 elements and attributes. So the scanning is already done implicitly by a library that is simply trying to use a CellML model and is reading it at the version level it is capable of. Of course CellML 1.1 is broken in this sense. There was some discussion about what namespace the model element should be in CellML 1.2. Randall suggested it should be in CellML 1.1 and not CellML 1.0 Can we apply this to all existing elements and attributes then? So that when 1.2 comes along and its interpretation we only really have 1.2 and 1.1 to deal with. I think that was the intention - model was only an example of an element with semantics that we don't plan to change, and any other element which is neither new nor changed in CellML 1.2 would be treated along the same lines. Then we can just implement 1.2 (and perhaps 1.0) without worrying about explicitly implementing 1.1 as a separate task. Best regards, Andrew cheers Matt On 9/19/07, Andrew Miller [EMAIL PROTECTED] wrote: Hi all, At the break-away session on the versioning strategy for CellML (which followed the Auckland CellML meeting today) we discussed the future of how we would version CellML, including whether we would put all elements for the next version of CellML in a completely different namespace, or only the elements that had changed. A summary of the discussion is up at http://www.cellml.org/meeting_minutes/MeetingMinutes19September2007/ under Breakaway session on versioning strategy for CellML. Note that the participants at the session have not had a chance to correct errors in it yet, and it may not yet accurately reflect everyone's view. However, it does lay out the options, and so may provide a starting point for any suggestions or comments from the community. Please send and such suggestions or comments to the CellML discussion mailing list prior to the 3rd October 2007. Best regards, Andrew ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
