devosoft / empirical Goto Github PK
View Code? Open in Web Editor NEWA library of tools for scientific software development, with emphasis on also being able to build web interfaces using Emscripten.
License: Other
A library of tools for scientific software development, with emphasis on also being able to build web interfaces using Emscripten.
License: Other
Current questions:
What's the best way to do this? A direct transfer of ownership from @mercere99 to Devosoft? Forking @mercere99's repo into Devosoft? Making an empty Devosoft repo and pushing a copy of Empirical up to it?
@emilydolson @nahumj Thoughts?
Since web::Textbox handles << for basic strings, it should also be able to handle std::endl, which should simply translate to "
" on the HTML side. The challenge is that std::endl has a strange type associated with it, but this should still be possible using decltype.
emp::BitSet currently assumes 32-bit fields, which is what Emscripten uses, but most modern processes handle 64-bit value natively.
We've already made this shift with emp::BitVector, which gives something like a 20% speedup. However if we ALWAYS use 64-bit values, we have a substantial slowdown in Emscripten since the 64-bit values need to be simulated.
It's definitely worth noting how this all works in BitVector and paralleling the changes.
As of now, the config object is full introspective, but can only be setup through a text file. For web interfaces, the current system is not ideal, so config object should work smoothly to generate and appropriate set of UI Widgets for configuration.
Right now each cell in a table has its own Style object, as does each row (plus one for the table as a whole). We should be able to specify a default cell style or row style without needing to go through and change every single cell/row manually.
The difference between these approaches will be especially notable when tables change size so that new rows or cells are created. If a default style is present, they can be made to look correct without much additional work.
We technically support OS X but we don't currently have a way to test on it--I haven't even verified that our build process will work on a mac (e.g. all the make targets)
@mercere99 and I briefly discussed getting access to an OS X machine of Beacon's for Empirical (would need some graphical interfacing to get the initial dependencies installed--OS X security stuff needs graphical confirmation, which is annoying) but for most of the work simple shell access would be enough.
see #64
Looks like commit 8f69dd6 made it necessary to add an extra set of parentheses inside a lot of (maybe all?) emp_assert() calls. As a result, some stuff in JSWrap.h, vector.h, and functions.h broke (and maybe elsewhere as where). I added the necessary parentheses in those three files to get my code to compile, but haven't pushed those changes yet because I don't know if there's an easy fix to emp_assert() so it doesn't require the extra parentheses.
I'm gonna ssume we'll only be running Doxygen in a dev environment, so these'll be considered dev dependencies:
From the install docs:
GetByte returns incorrect data when using a 64bit machine. Also, some other parts are hard-coded for 32-bit while others are made flexible with preprocessor typedef uint32_t field_type
or typedef uint64_t field_type
.
One way to reproduce:
BitVector bv(64); // 64 bits of data
bv.SetUInt(0,707406378); // sets first 32 bits to each byte=42 (should probably be renamed, or made flexible too)
bv.SetUInt(1,707406378); // sets second 32 bits to each byte=42
assert((int)bv.GetByte(0) == 42); // Pass
assert((int)bv.GetByte(1) == 42); // Pass
assert((int)bv.GetByte(2) == 42); // Pass
assert((int)bv.GetByte(3) == 42); // Pass
assert((int)bv.GetByte(4) == 42); // Fails
``
Not sure how close we are to feeling ready for any sort of release but thought it'd be good to start the conversation.
Semantic versioning has always seemed like a sensible option to me, though again I'm not sure what the opinions on versioning/releases are.
I feel like this + licenses + docs would be the primary blocks between where we are now and being considered 'usable' by outsiders (in my admittedly highly limited experience).
cc @mercere99 thoughts?
So we've just about settled on implementing an MIT license for Empirical.
One thing of note is that Doxygen uses a GPL license, though it looks like MIT will interface with that nicely.
Not super critical, but it would make writing code that accepts a generic container easier (since insert is the only method all STL containers have for adding elements).
Was migrating tests to Catch and was unable to compile grid.h
attempted to run old unit tests for grid and things exploded:
bocajnotnef@GCU-Caconym:~/git/Empirical/UTests/tools⟫ make grid
g++ grid.cc -o grid
In file included from /usr/include/c++/4.9/initializer_list:36:0,
from ../../tools/functions.h:6,
from ../../tools/bitset_utils.h:9,
from ../../tools/BitVector.h:19,
from ../../tools/grid.h:33,
from grid.cc:5:
/usr/include/c++/4.9/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support for the \
^
In file included from ../../tools/bitset_utils.h:9:0,
from ../../tools/BitVector.h:19,
from ../../tools/grid.h:33,
from grid.cc:5:
../../tools/functions.h:25:19: error: ‘function’ is not a member of ‘std’
double time_fun(std::function<void()> test_fun) {
^
../../tools/functions.h:25:41: error: ‘test_fun’ was not declared in this scope
double time_fun(std::function<void()> test_fun) {
^
../../tools/functions.h:25:51: error: expected ‘,’ or ‘;’ before ‘{’ token
double time_fun(std::function<void()> test_fun) {
^
../../tools/functions.h:64:44: error: template declaration of ‘const T& emp::min’
template <typename T> const T & min(std::initializer_list<const T&> lst) {
^
../../tools/functions.h:64:39: error: ‘initializer_list’ is not a member of ‘std’
template <typename T> const T & min(std::initializer_list<const T&> lst) {
^
../../tools/functions.h:64:61: error: expected primary-expression before ‘const’
template <typename T> const T & min(std::initializer_list<const T&> lst) {
^
../../tools/functions.h:73:44: error: template declaration of ‘const T& emp::max’
template <typename T> const T & max(std::initializer_list<const T&> lst) {
^
../../tools/functions.h:73:39: error: ‘initializer_list’ is not a member of ‘std’
template <typename T> const T & max(std::initializer_list<const T&> lst) {
^
../../tools/functions.h:73:61: error: expected primary-expression before ‘const’
template <typename T> const T & max(std::initializer_list<const T&> lst) {
[+1000 moar lines]
../../tools/grid.h:172:5: error: invalid use of template-name ‘emp::Grid::Board’ without an argument list
Board & board;
^
../../tools/grid.h:175:16: error: expected ‘)’ before ‘&’ token
Cell(Board & b, int in_id) : board(b), id(in_id) { ; }
^
../../tools/grid.h:176:26: warning: defaulted and deleted functions only available with -std=c++11 or -std=gnu++11
Cell(const Cell &) = default;
^
../../tools/grid.h:177:38: warning: defaulted and deleted functions only available with -std=c++11 or -std=gnu++11
Cell & operator=(const Cell &) = default;
^
../../tools/grid.h: In member function ‘CELL_TYPE emp::Grid::Cell<CELL_TYPE>::GetValue() const’:
../../tools/grid.h:179:41: error: ‘board’ was not declared in this scope
CELL_TYPE GetValue() const { return board.GetCellValue(id); }
^
../../tools/grid.h: In member function ‘void emp::Grid::Cell<CELL_TYPE>::SetValue(CELL_TYPE)’:
../../tools/grid.h:180:38: error: ‘board’ was not declared in this scope
void SetValue(CELL_TYPE value) { board.SetCellValue(id, value); }
^
../../tools/grid.h: At global scope:
../../tools/grid.h:186:5: error: invalid use of template-name ‘emp::Grid::Board’ without an argument list
Board & board;
^
../../tools/grid.h:189:17: error: expected ‘)’ before ‘&’ token
VEdge(Board & b, int in_id) : board(b), id(in_id) { ; }
^
../../tools/grid.h:190:28: warning: defaulted and deleted functions only available with -std=c++11 or -std=gnu++11
VEdge(const VEdge &) = default;
The errors all throughout functions, bitset_utils, etc. didn't occur when I was migrating things--I only saw failures throughout grid itself.
ping @mercere99
A starting point is the Physics system to be able to easily control how bodies react to events and interact with each other.
Currently, indices into emp::BitSet are in big endian (i.e. Bitset[0] is the right-most bit). This makes sense when thinking of a BitSet as a binary number, but it's confusing when using a BitSet as an organism (or just as a container for a sequence of 1s and 0s). Is this desired behavior? If so, we should probably add an explanatory note.
Right now, if a library user creates two variables with the same name for the config object, a non-intuitive error occurs. Can we figure out a way (probably using static_assert) to provide a more obvious error?
So there's essentially two paths we could take for having docs. We could have plain text docs or we could have docs managed by an engine e.g. Sphinx (http://sphinx-doc.org/contents.html).
Pros to flat: No dependency hell
Pros to engine'd: Prettier, usually more navigable, easily structured
+1 to engine'd and to Sphinx specifically, but that's just because I know it. Thoughts/comments?
Make target that'll complain at the user if they write code that isn't covered by the tests
I'm going to do this anyway since I want to get a better feel for the codebase
Couple different schools of thought on PRs
Arguably, 2 is more intuitive, though I prefer 1.
@mercere99 discussed this and he pointed out that if we adopt 1 we'll have to make sure everyone adopts it, so incomplete PRs don't get merged by folk who missed the memo.
Thoughts/opinions?
e.g. breathe's doxygen directives, how to comment things so doxygen plays nice with them, etc.
Often novice users of software should only see a small number of configuration options (with the remainder set to defaults) in order to simplify user experience.
A simple possibility is to have multiple levels, where as you set level to a higher value more configuration options appear. Alternatively (and perhaps more flexibly) config settings should be part of a category, such as "basic", "structure populations", "sexual selection", etc. This would also allow doing "basic", "standard", or "advanced" stats.
Right now, all CSS modifications occur on individual HTML objects, but we should also be able to create CSSClass objects in C++ to modify any particular type of class. The challenge is that this functionality doesn't seem to be supported by JQuery (not sure why; I'm concerned that there might be a good reason for that!), but there are some good StackOverflow answers on how to deal with it.
http://stackoverflow.com/questions/9153718/change-the-style-of-an-entire-css-class-using-javascript
http://stackoverflow.com/questions/7125453/modifying-css-class-property-values-on-the-fly-with-javascript-jquery/23143665#23143665
Means we have to find an emscripten package/container for travis, and I don't think one currently exists.
Well, we can install the emscripten package from apt-get, but the version of that package might not play nice with our code.
Obviously there's a lot, but now we can keep track of it. I'll add to this as I find stuff.
These should probably all be their own separate issues, but eh.
For easy demoing/explanations, etc.
Perhaps steal from UTests...?
Or at least, it stopped blowing up when we switched to double quotes. See #50 (comment) for more details.
Right now, library users need to manage keypresses independently of the document object, however there is no reason for a single document to have more than one KeypressManager, so it should probably be incorporated right in.
Once this is the case, we can also simplify some keypress directing. For example, a button could have a hotkey associated with it; when that button is active, the keypress manager should be informed about the hotkey.
A function that is given a name in JSWrap() is created on the JS side to be used easily. However, JSDelete() does not do anything special to make sure to delete the JS version of the function. We need for that deletion to happen -or- if that doesn't work, officially declare that JSDelete() cannot delete a named function and throw a warning if this is attempted.
I'm working my way through the web examples file and I realized that the native
maketarget falls over because of a bunch of JS/Emscripten specific material that g++/gcc tries to compile.
Is it necessary to have a 'native' maketarget in a folder that relies specifically on using JS for the UI?
Additionally, I need to find a way to make Travis use Emscripten. I don't think there's a docker container for the EMSDK, which presents an issue. In theory we could clone in the SDK and build emcc from source, but that'll take a tremendously long time to compile for each build.
Looks like the fix for #60 (or one of the other two commits around then) introduced an error. When I try to compile examples/evo/NK.cc I get this error:
../../evo/../tools/functions.h: In function ‘constexpr bool emp::toggle(bool&)’:
../../evo/../tools/functions.h:37:79: error: expression ‘(in_bool = (! in_bool))’ is not a constant-expression
inline constexpr bool toggle(bool & in_bool) { return (in_bool = !in_bool); }
Should stash these in doc/getting-started
Current known dependencies:
in general:
for testing:
for docs:
Need to go through on a clean system and figure out what all we need to install from scratch to get going.
I skimmed through the Sauce Labs docs (https://wiki.saucelabs.com/display/DOCS/JavaScript+Unit+Testing+with+Sauce+Labs) and it looks mostly like they take in a pregenerated page and run tests on it, which means a couple of things.
a) we need to find a javascript unit test suite to cover JS funcitonality of Empirical
b) sauce doesn't do UI testing per se--that is, I don't think they could verify things in the animation library, or the self-resizing tables, etc., they can just check and verify that the JS updates the page properly from outside stimulus, or similar.
I need to play with the JS side of Empirical some more.
currently I think diff-cover has a hardcoded path in its maketarget tht might break if people put their envs in other places
Right now, serialization can handle many base objects or objects that were explicitly designed to allow saving and loading. The problem is, that pointers are ignored (or worse, copies as a numerical value). We need to have a way for pointers to be able to be dealt with gracefully.
Specifically, we have:
Options:
filenames == PR #'s
makestarget to concatenate into official changelog
something like:
// This file is part of Empirical, https://github.com/mercere99/Empirical/, and is
// Copyright (C) Michigan State University, 2015. It is licensed
// under the MIT Software license; see doc/LICENSE
I think I wrote a script to do this on a per-folder basis...gotta dig it up.
see #32, specifically #32 (comment)
Right now, we have a complex system for the config file to be put together where a file full of macros is repeatedly called. With all of the new macro tricks that have been worked into Empirical, we should be able to simplify this entire system into a single macro.
Pros:
Cons:
When the configuration object is use to CHANGE a variable during the course of a run, it should be able to have a function pointer that is automatically run with the new (and the old?) values so that the system can be updated gracefully to reflect this change.
Likewise, settings should be able to have a flag to indicate that they can't be changed once initial configuration is finished, though of course such settings should be avoided when possible.
From dib-lab/khmer#1013
Used to quickly squash commits pre-merge
I think this was mentioned in a verbal conversation though I don't remember quite which.
I feel one of the early pieces of documentation should be contribution guidelines for the project, detailing preferred formatting specs, if/how commits should be squashed, how PRs should be reviewed, etc. I think that establishing that early on will prevent problems down the line.
Additionally if we establish clear rules for what's required in a PR/merge then it's easier to prevent the review process from blocking on one specific person, or at least reducing the amount of time required by reviewers with a high value-to-time ration (i.e. @mercere99)
Some problems with this:
Thoughts/Comments?
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.