devosoft / empirical Goto Github PK

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.

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); }

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.

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.

• License ( suggested: the MIT license http://choosealicense.com/licenses/mit/ )
• Preferred formatting tools (potentially include automated checking for formatting; "Writing tools to enforce policy", etc)

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.

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 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).

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.

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

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:

• We currently lack automated formatting/testing, making it difficult to easily keep to a standard ("write code to enforce policy" and all that)
• We don't currently have a decided formatting standard anyway and I'm not sure how important an issue that should be

Thoughts/Comments?

see #32, specifically #32 (comment)

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.

Couple different schools of thought on PRs

1. Open them immediately when you start working on an issue, so as other people can provide feedback/makes linking other issues etc. easier
2. Open them only when you're ready for merge

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?

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.

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.

Make target that'll complain at the user if they write code that isn't covered by the tests

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:

• Pointers we are in charge of and need to build the associated object.
• Pointers we are NOT in charge of and someone else needs to expliclty build first before we can connect to them (perhaps save a list on loading what we are waiting for?)
• Pointers we are not in charge of because they are objects built elsewhere. (In some way, these are the most challenging because we need to know to save the original pointer information so we can later map things together properly.

Options:

• We can require a user to explicitly mark objects that might be pointed to (so we know to identify their pointers)
• We can require that points to objects are saved before the objects themselves (and then we just need to examine but not store all pointers)
• We can disallow pointers to objects that weren't explicitly allocated.

• set up saucelabs' UI testing ( https://saucelabs.com/beta/signup/OSS )
• set up travis CI #2 #32

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.

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

I'm going to do this anyway since I want to get a better feel for the codebase

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?

currently I think diff-cover has a hardcoded path in its maketarget tht might break if people put their envs in other places

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.

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?

Or at least, it stopped blowing up when we switched to double quotes. See #50 (comment) for more details.

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.

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.

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?

see #64

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.

Specifically Animate.js fails:

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:

• flex
• bison
• libiconv
• make
• strip

A starting point is the Physics system to be able to easily control how bodies react to events and interact with each other.

Should stash these in doc/getting-started

Current known dependencies:

in general:

• cmake/build-essential
• g++/llvm/emscripten (depending on what you want to do)
• python (2?)

for testing:

• catch
• gcov, lcov,

for docs:

• doxygen
  • flex, bison, libiconv, latex (reccomended), cmake
• breathe
  • Nothing...?
• Sphinx
  • pypi, virtualenvs

Need to go through on a clean system and figure out what all we need to install from scratch to get going.

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.

e.g. breathe's doxygen directives, how to comment things so doxygen plays nice with them, etc.

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:

• Easier to understand and hence modify in the future.
• More standard C++
• Macro can be created anywhere and not require a whole new file.

Cons:

• Current system is (probably) more flexible.
• Current system makes the macros look cleaner.
• Current system does not require macros.h to be included, which can slow compilation times.

filenames == PR #'s
makestarget to concatenate into official changelog

From dib-lab/khmer#1013

Used to quickly squash commits pre-merge

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.

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.

For easy demoing/explanations, etc.

Perhaps steal from UTests...?

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?

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.