neurondm-0.1.8

neurondm vbump for release

neurondm-0.1.7

neurondm vbump for release

0.1.34

sheets notes and comments about _row_from_index quirks

clifn-0.0.1

sheets notes and comments about _row_from_index quirks

neurondm-0.1.6

neurondm vbump for release

0.1.33

ontload fix import_tree issues

neurondm-0.1.5

Now somewhat more decoupled from the NIF-Ontology repository.

ttlser-1.1.5

ttlser add no_reorder_rdf_star to fix owl:annotatedTarget reordering

there are some property chin axioms in ro.owl that have been annotated
and before this fix the annotated target was reordered causing owlapi
to include the reordered property chain axioms from the targets which
not surprisingly produced a bunch of unsatisfiable classes

no_reorder_rdf_start is a dict where the keys are the direct linking
predicate to the list that should not be reordered and the values are
the secondary linking predicate that connects to the predicate that
will be tested as a member of no_reorder_list, in which case the list
will not be reordered since its target will not be reordered (if this
paragraph was confusing look at test/no-reorder.ttl for an example).

vbump for release and bump the nifttl version

0.1.32

utils Async critical fix for variant behavior on pypy3, vbump

to make a very long debug story much shorter: it turns out that pypy3
and cpython have remarkably and dangerously different behavior for
closures in comprehensions

fixing the bad closure behavior also seems to have resolved the
wild and crazy hitching and slowdowns seen toward the end of long
async runs, probably because i was also changing

these have obvious behavior that is consistent for both
pypy3 and cpython

help = (lambda : OH_NO for OH_NO in range(10))
me = list(help)
sigh = [m() for m in me]

help = (lambda : OH_NO for OH_NO in range(10))
sigh = [h() for h in help]

however consider

from time import sleep
import asyncio
from concurrent.futures import ThreadPoolExecutor
def OH_NO_NO_NO():
    ex = ThreadPoolExecutor()
    help = (lambda : (OH_NO, sleep((OH_NO + 1) / 10)) for OH_NO in range(10))
    #help = (lambda : OH_NO for OH_NO in range(10))
    async def ohno(future_):
        loop = asyncio.get_event_loop()
        futures = []
        for f in help:
            futures.append(loop.run_in_executor(ex, f))
        out = []
        for f in futures:
            out.append(await f)
            sleep(0.1)
        future_.set_result(out)

    future = asyncio.Future()
    loop = asyncio.get_event_loop()
    loop.run_until_complete(ohno(future))
    return future.result()

cpython also fails in this case, but if you look at pypy3 the behavior
is significantly more variable, in the context of Async there is some
additional factor which has somehow ensured that cpython chunk didn't
get rebound ... or something like that ... I haven't completed the
investigation with a full explaination, but this is at least part of
the story

0.1.31

methods match GO naming change for sanity