johncalhoun / flamingo Goto Github PK

container is full of bugs and issues,
dont really need, std and thrust vectors will work fine
maybe drop from project

Xml could be used for agent defs or google protobufs might provide a more natural interface, similar to how caffee library works

What is the final decision on the iterator for the transporter class?

The DataFrame class needs to pass some sort of iterator that goes over all the columns and points only to the rows that need to be moved.

I know there is a tuple where each element of the tuple points to a column in the dataframe but how does the iterator play into this?

What is the format for and Address?
In Flamingo/dataframe/source_files/addressbook.cpp

We have a key-value setup.

On L14 the value is defined as a template object.

What exactly is to be expected there? More specifically, can we expect it to be serialized and have a process id (PID) in it?

should be one license file,
choose which kind and file it in

should two data frames be able to share columns(through point access)

this does not pass test,
not sure if the test is wrong
or if the code is wrong,

nothing is using code at the moment so nothing is broken but this.

I foresee several parts the project needing shared locking mechanisms.
the c++14 standard has shared locking but it is not supported in cuda 7.5,

Threading utility library should provided
shared locking
shared lock guard
lock guard

make for easy transition to standard implementation when the time comes.

To enhance communication add labels such as:

• communication
• loadbalancer
• etc..

If not, what alternative might accomplish this purpose?

assing test host is stalling at rootLocal=_root1

Statically
join horizontal type

Runtime
join hoziontal,copy and reference
split horizontal. copy and reference

join verticaly,copy
split verticaly.copy

set get test segfaults on the resize(1) functions

namespace for each project

The Transporter class should be of a static state.
That being said, should the Transporter class be a class consisting of static methods, or should the class follow a singleton design pattern?

After some thought, I believe that the decision weighs on which of these two situations more accurately describes how the Transporter class will work.

• The methods will need data members in this class or
• The methods will be able to get all the data they need through passed in parameters.

rebind doesnt compile, must be a compatibility issue with new compilers
found in issue #21

need bool conversion for dataframe iterator

better directions for building test benchmark facilities
maybe move to cmake build system

change to scoped enum for better clarity of use

const int for the combined row types

1)const iterator
2)reverse iterator

Should project use standard MPI or Boost MPI?

Thoughts:
Seeing as this project is built in CPP and already uses Boost elsewhere in the project, it would make since to keep this consistency and use Boost MPI which brings in a CPP friendly MPI interface

For more reading:
http://www.boost.org/doc/libs/1_60_0/doc/html/mpi.html

We cannot implement the data frame with a full std::vector like interface.
The question is what member functions from the vector interface is need to best implement transporter
here are the options

sequence container
container

Are they the same thing?
If not, whats different?

cannt seem to get to compile on fedora 22,
compileErrors.txt

dataframe transpost class needs to be able to serialize rows from data frame,send through mpi,and recieve on other side
use

boost::serialize

go through allocator and see what documentation needs to be added

start other components

• scheduler
• communicator
• agent definetion

needs to release pools of data when appropriate

wrap around various communication libraries to move data( the messages) for the agents

• addressing
• bulk movement

ideally is asynchronous

better organize source files, seperate out the .h(hpp,cu etc) and .inl

need a job scheduler,

• thread pool
• cuda aware
• dependency graph

like TBB graph.
if can figure out just wrap around TBB graph
or implement own

boiler plate comments for source files should be added as specified in google style sheets

I would like to implement the ARC cache algorithm for cordinating dataframes. however; this is covered by a IBM patent. not sure exactly how to move forward

need const versions of several dataframe member functions
first need to implement the const iterator

allocator test does not compile,
probabily some wierd c+11 problem

header files descriptions needs to be put in

root swap test segfaults

fill in specification files with outlines of the code and classes that need to be built in each projected,
they are .otl files for vimoutliner

I am not sure what thread safety is needed for the dataframe class. It probably depends on the interface between the dataframe and the scheduler.