mattalexpugh / mds Goto Github PK

Steps required:

1. Ascertain repo directory
2. Invoke mds makefiles
3. Compile and install Python extensions using distutils

Finish this up and send a demo to Evan!

As per the C++ API -- smaller experiments on this need to be consolidated into a usable extension.

Majority of logic is implemented here already, but a lot of tests should be made to ensure it's working as anticipated.

There are some neat new features in Cython 0.27 which could be useful for the MDS Python API:

• __richcmp__ -> __eq__ etc.
• Python 3's type-hinting annotations
• C++ classes containing properly refcounted PyObjects
• Extension module initialization (?)

Basic namespace support is present in the Python API, numerous components still required:

1. Type resolution for primitives (deduction)
2. Record storing & retrieval
3. Array storing & retrieval (downcasting?)
4. Logical implementation of Namespace paths

This is my current task -- getting these implemented. Key points:

1. Declaration
2. Instantiation
3. Committing to Namespace
4. Retrieval from Namespace

Point 4 is most interesting, as is the key point of interoperability between languages in MDS:

1. We should have some concept of hierarchy in terms of polymorphism -- if we don't know what the concrete class C (derives A <- B <- C) actually looks like, casting it to something further up the chain (B, then A, in that order) should work until C is known -- at which point, 'cast' the returned object to C
2. A valid type sharing the identifier I need only implement a subset of the original Records declared fields in order to be considered compatible
3. Records are only collections of these types (record_field*) and contain no logic

In both primitives (and arrays thereof) we should use MDS's atomic operations for div, add, mul, sub instead of doing this in Python. This can be done with:

__i<op>__ boxing the relevant handle from MDS.

At present, *handle objects are held on the stack in their wrapper objects. This may not be too problematic given they internally have a pointer to elements on the gc_heap, but it may be more prudent to use Cython's existing shared_ptr bindings to hold these.

Further to this, where we are executing Python code through IsolationContext and Task, we need to make sure that Python's reference counting is correct on the objects returned to avoid memory leaks.

Port the existing tutorial document to the Python API

Steps to reproduce:

1. Clear all MPGC heaps
2. Create new MPGC heap (size unimportant)
3. Run Python API tests with python -m unittest discover

If no error, simply repeat step 3:

/home/pughma/repo/public/mpgc/src/gc_thread.cpp:251: mpgc::mark_black(const mpgc::offset_ptr<const mpgc::gc_allocated>&, mpgc::gc_control_block&, mpgc::Traversal_queue&)::<lambda(const mpgc::base_offset_ptr*)>: Assertion 'ptr.is_valid()' failed.

At present, extensions are packaged/namespaced at very coarse granularity to save time in the continual recompilation during testing. A more obvious and/or natural ordering may be possible; this should be investigated before the final release is pushed upstream.

There are a number of methods provided by the view_independent_handle object that currently aren't exposed (dealing with literal-templated types in current Cython requires delicate massaging). There are some useful methods that we're potentially missing, like uuid().

The simplest solution would just be to manually declare these methods in all concrete classes where we want them visible. This doesn't seem the nicest solution though; actually getting the hierarchy to resemble the C++ implementation would be good.