Releases: tgbugs/pyontutils
Releases · tgbugs/pyontutils
0.1.35
neurondm-0.1.8
neurondm vbump for release
neurondm-0.1.7
neurondm vbump for release
0.1.34
clifn-0.0.1
sheets notes and comments about _row_from_index quirks
neurondm-0.1.6
neurondm vbump for release
0.1.33
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