Re: [cellml-discussion] FW: r1756 - pce/trunk/chrome/content/ui
Randall Britten wrote:
Don't you think we should put a test in somewhere for this? (Perhaps a
manual test for it is already in Litmus?).
It is already in Litmus, although we could probably do automated testing
of PCEnv too (it requires running Javascript as part of the tests, but
Mozilla do this so we could do this if we want to depend on having debug
versions of Mozilla available as part of build process - probably a
space problem for now on my VM, but once we get our testing platform I
have asked for much more space for the Win32 image).
Best regards,
Andrew
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of CellML
Automated Notifications
Sent: Wednesday, 19 September 2007 4:11 p.m.
To: [EMAIL PROTECTED]
Subject: r1756 - pce/trunk/chrome/content/ui
Author: amil082
Date: 2007-09-19 16:10:36 +1200 (Wed, 19 Sep 2007)
New Revision: 1756
Modified:
pce/trunk/chrome/content/ui/Menu.js
Log:
Fix export CSV function, which was been broken as a consequence of the move
to the new
CCGS.
Modified: pce/trunk/chrome/content/ui/Menu.js
===
--- pce/trunk/chrome/content/ui/Menu.js 2007-09-18 17:47:09 UTC (rev
1755)
+++ pce/trunk/chrome/content/ui/Menu.js 2007-09-19 04:10:36 UTC (rev
1756)
@@ -153,34 +153,48 @@
function WriteCSVData(datacollector, cmodel, stream)
{
var header = '';
- var varit = cmodel.codeInformation.iterateVariables();
+ var ctit = cmodel.codeInformation.iterateTargets();
var vars = [];
var i;
- var v, bv;
- while ((v = varit.nextVariable()) != null)
-if (v.type == 0/* BOUND*/)
- bv = v.source.name + '(' + v.source.unitsName + ')';
-else if (v.type == 1/* CONSTANT */)
+ var ct, bv;
+ var rateCount = cmodel.codeInformation.rateIndexCount;
+
+ while ((ct = ctit.nextComputationTarget()) != null)
+if (ct.type == 0/* VARIABLE_OF_INTEGRATION */)
+ bv = ct.variable.name + '(' + ct.variable.unitsName + ')';
+else if (ct.type == 1/* CONSTANT */)
;
-else
- vars[v.variableIndex] = v.source.name + '(' + v.source.unitsName +
')';
- var vc = cmodel.codeInformation.variableCount;
- for (i = 0; i vc; i++)
- {
-if (header != '')
- header = header + ',';
-header = header + vars[i];
- }
- if (bv != null)
- {
-if (header != '')
- header = header + ',';
-header = header + bv;
- }
+else if (ct.type == 4/* FLOATING */)
+ ;
+else // state variable or algebraic...
+{
+ var isSV = (ct.type == 2/* STATE_VARIABLE */);
+ var isRate = (ct.degree 0);
+ var idx = isSV ? 1 : (isRate ? rateCount + 1 : 2 * rateCount + 1);
+ idx += ct.assignedIndex;
+
+ var primes = ;
+ if (isRate)
+ {
+var x;
+for (x = ct.degree; x 0; x--)
+ primes = primes + ';
+ }
+ else
+primes = '(' + ct.variable.unitsName + ')';
+
+ vars[idx] = ct.variable.name + primes;
+}
+
+ header = bv;
+ var vc = 2 * rateCount + 1 + cmodel.codeInformation.algebraicIndexCount;
+
+ for (i = 1; i vc; i++)
+header += ',' + vars[i];
+
header = header + \n;
stream.write(header, header.length);
- vc = vc + 1;
try
{
var t = 0;
___
automated-notifications mailing list
[EMAIL PROTECTED]
http://www.cellml.org/mailman/listinfo/automated-notifications
___
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
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. So something like (assuming my use of the syntax is correct): (\+|\-|)[0-9]+(\.[0-9]+|)((E|e)(\+|\-|)[0-9]+) Note that I have also 'simplified' the exponent part. Alan. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] CellML Versioning Strategy
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. That all seems reasonable to me, just one comment: - At the moment, CellML doesn't explicitly support the rem element (remainder function in MathML), even though CellML does allow its use (at the risk of ending in a situation where a model may work fine in a given CellML tool -- that supports the rem element --, but not in a nother -- that doesn't support the rem element --). Now, say that we officially want CellML to 'support' the rem element, how do we go about doing that? Otherwise, Matt wrote: ... 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... Treat that model in what way? Surely, if a model uses some 1.2 elements, then there must be a reason to it. Therefore, a 1.2 model cannot be treated as a 1.1 model, or did I miss something? Alan. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] CellML Versioning Strategy
Matt Halstead wrote: Otherwise, Matt wrote: ... 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... Treat that model in what way? Surely, if a model uses some 1.2 elements, then there must be a reason to it. Therefore, a 1.2 model cannot be treated as a 1.1 model, or did I miss something? It really depends on the intention of adding to the spec. If you are adding elements that change the interpretation of the CellML 1.1 namespace elements, then yes, there is no point in trying to see only the cellml 1.1 model within a model that has 1.2 elements. Sometimes people use levels to denote changes to a spec (which often also a new namespace) that are additive and still render the previous level a valid model. I think that the CellML specification should only describe 'core' aspects which affect the interpretation of the model. Anything which is additive should not be in the core CellML but should use extension elements or be in RDF. A simple rule to identify whether an unrecognised element is a fatal error is to see if it is in a namespace starting with http://www.cellml.org/cellml/ . If it is, then tools should assume that they are unable to interpret the model correctly and so should fail. If it isn't, it is an extension element, and so is not essential to the interpretation of the model, but rather is additive as Matt has described, and so may safely be ignored. Best regards, Andrew Alan. ___ 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
