cellml / libcellml-archived Goto Github PK
View Code? Open in Web Editor NEWThis was the primary repository for the development of libCellML. It will remain here for a short period of time.
This was the primary repository for the development of libCellML. It will remain here for a short period of time.
Part of #11
The recommended way of doing this is to incorporate the Google Test source code into the product's codebase. See for example https://github.com/codecurve/libcellml/tree/basicModelUseCase01/extdep/gtest-1.7.0 for how this ends up, seemed to work well.
Making this an isolated issue and then pull request so that it can be reviewed atomically.
I'm using git to version the master.cfg edits. I think it would be good if there was a "github.com/cellml/libcellml-build" repo that I could submit pull requests to etc.
The file contains buildslave passwords in plain text, so it will be necessary to blank those somehow. Not sure what the security issues are if those leak, probably not serious, since others just use the default "pass" password anyway.
Create: Create an empty validly named model from scratch and serialise it to XML. Test is that the serialised model matches manually validated XML.
(Note that compared to #31, this time the model has a name).
Right now, the gtest code is under a folder named gtest-1.7.0
. Personally, I would simply call that folder gtest
, this to avoid issues many files being considered renamed (if not deleted and recreated) by git whenever gtest is upgraded to a newer version.
Create an initial code stub that will set up the future development work for libCellML. This will include gtest 1.7.0 and a function version() to create a test around. This code stub will need to work with the Buildbot configuration currently in place.
Some progress already made:
Ubuntu 12.04 and 14.04 slaves partially done, forced builds working off this branch for now: https://github.com/codecurve/libcellml/tree/buildBotDummy01
It would be good to have a way to check which branches have successful build/test statuses. Travis shows green ticks/red crosses on the branches view (that would be https://github.com/cellml/libcellml/branches).
See for example https://github.com/opencor/opencor/branches
Suggestions so far:
UML
IDL (using a custom back-end to demonstrate C++ equivalent)
Text
C++ Headers and sample client code.
First priority (I think): OS X 10.9, then 10.8 maybe. I don't think we need 10.7.
Part of issue #11.
Windows 7 (64 bit) is all that I think is needed for now.
MSVC (whichever is currently the latest version available on ABI Build and Test Server (BaTS))
Setup mailing list and e-mail notification for failed builds.
I just came across https://github.com/codecurve/libcellml/tree/buildBotDummy01 and, sure, the code is still in its infancy, but that's the reason we probably ought to agree on some coding style. For example, looking at this version of a file, line 6 reads:
using namespace std;
of which I am not a fan at all (it can make it difficult to read some code).
Anyway, I am not claiming that I have the perfect coding style, but it might be worth looking at the coding style used in OpenCOR. As can be seen, it's pretty much the coding style used by the Qt Creator team.
Description of the process used for making contributions to the codebase, project documentation etc. Includes related documentation about things such as coding standards, how branching is used, how releases are made, etc.
When building the library on Windows using cl.exe the name of the library that gets built is cellml.{lib, dll}. It should be libcellml.{lib, dll}
The current proposal from Randall (@codecurve) is to use the CodeSynthesis XSD tool to generate XML bindings for the serialisation and deserialisation of libCellML objects into and from XML.
@codecurve (Randall) has asked for a develop branch to be created in order to use git flow.
The ABI recently adopted MPL2 for OpenCMISS-Zinc, but this was strongly influenced by the previous use of MPL1.1 (see https://tracker.physiomeproject.org/show_bug.cgi?id=3558).
Should we treat compile warnings as errors? If so, the Cmake config needs to be updated accordingly.
See https://en.wikipedia.org/wiki/Pragma_once.
Seems like a feature that we should use, supported but the compilers that we care about.
I'm currently using a camel-case convention for C++ source file names, (e.g. would be VariableSetHelper.h
). Hugh suggested I change the case convention to all lower case (e.g. would be variablesethelper.h
).
I prefer camel-case. As my example shows, all lower case makes file names look garbled (it's easy to think the first word was "variables" in the lower case example, and "helper" doesn't stand out at the end of the name, since "the" and "per" might be noticed first). The all lower case convention was strongly influenced historically by quirks when using CVS version control. I've used camel case on a C++ project consistently for 5 years a few years ago, and even using CVS, we felt it was preferable. Chaste uses a camel case convention.
What are other people's views on this?
Use case description:
Use libCellML to create a model, and serialise to XML.
This test code illustrates one way of doing this, from the caller's perspective:
https://github.com/codecurve/libcellml/blob/9a1e162fa2af0fc27808d10e0de8fc60b0899511/tests/XmlSerialisationTest.cpp#L17-L37
Note:
For various reasons, depending on how you look at it, this issue deviates from the proposed libCellML development process. Nevertheless, one of the main goals of submitting this issue now is that it will help illustrate some of the aspects of that process, for example, how BuildBot displays the results of builds and tests for the various revisions related to the corresponding pull request. This was discussed at the libCellML meeting last week. Note that the above test code already has corresponding implementation code. Build and test results are already visible under TravisCI, on a mock pull request created to illustrate this, see https://github.com/codecurve/libcellml/pull/3.
As a sub-task of #42, this document will describe the process for contributing new code or changes to existing code, as well as contributing new documentation or changes to existing documentation.
It looks to me like the repository contains all of the gtest code including gtest's own tests. Is that really necessary? It increases the size of the repository without any particular added value.
From https://github.com/cellml/libcellml/blob/master/docs/usecases.rst:
"Create: Create an [empty] model from scratch and serialise it to XML (the test is that the serialised model matches manually validated XML documents)"
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 is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
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.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.