Release v1.3: new DAG solver, better plotting & "sideffect"#1
Release v1.3: new DAG solver, better plotting & "sideffect"#1ankostis wants to merge 146 commits intohuyng:masterfrom
Conversation
were writing in text-mode in PY3. and failing as encoding error.
Tokens work as usual while solving the DAG but they are never assigned any values to/from the operation's functions. + TC included. + Docs updated.\+ Added `modifiers` superclass to facilitate identification code. + refactored FunctionalOperation._compute().
+ _norm_kwargs:
+ use isinstance() instead of type-equality checks,
to support new modier classes;
+ avoid excessive dict searches with local vars.
not really needed, better be explicit which modifier is searched.
receiving partial inputs, needed for other operations.
+ The x2 TCs added just before are now passing.
NOTE dict are not deterministic in <PY3.6. So this commit would not improve determinism in those pythons. + build: add `boltons` dependency for ndexedSet. + doc: mark all set usage if affect determinism. + e.g. see reproducibility problem in yahoo#14.
the later described in yahoo#21.
not after compose(). + All TCs pass ok. + NOTE this is not yet what is described in yahoo#21.
to pass +TC checking DeleteInst vary when inputs change. - x4 TCs still failing, and need revamp of dag-solution.
+ Read the next doc-only commit to understand changes.
+ Renamed:
+ net.steps --> net.execution_plan.
+ (old)compile() --> _build_execution_plan()
+ _find_necessary_steps() --> (new)compile() + _solve_dag()
compile() became the master function invoking _solve_dag &
_build-execution_plan(), and do the caching.
+ refact(compute()): extract common tasks from sequential/parallel.
+ refact show_layers() to allow full-print, geting also string
(not just printing), and using custom classes for representation.
+ Raise AssertionError when invalid class in plan.
it's a logic error, not a language type-error.
Probaly unreported bug in v1.2.4 for '_neccessary_steps_cache`.
+ Pruning behaves correctly also when outputs given; this happens by breaking incoming provide-links to any given intermedediate inputs. + Unsatisfied detection now includes those without outputs due to broken links (above). + Remove some uneeded "glue" from unsatisfied-detection code, leftover from previous compile() refactoring. + Renamed satisfiable --> satisfied. + Improved unknown output requested raise-message. + x3 TCs PASS, x1 in yahoo#24 and the first x2 in yahoo#25. - 1x TCs in yahoo#25 still FAIL, and need "Pinning" of given-inputs (the operation MUST and MUST NOT run in these cases).
numpy was used just for its assert_raise
so as to politely print IndexedSets in those attributes.
but still annotate edges with optional edge data-attribute. Reverted bc Operation must not know its network, to belong to more than one. Also the `Operation.net` contradicted `NetwotkOperation.net`; the later indeed is the network it wraps (not the net it is part of).
+ homegine titles + fix: autodoc renders nothing without :special-members:
7f2976f to
88c68e9
Compare
+ enh(net): mark dag-edges with sideffects; + enh(plot): plot sideffect inks as such; + enh(plot): update legend; + doc(plot): move legend text along with the code producing it. + doc: stray image fixes.
+ fix glitches in README.
if built without cleaing, stray artifacts might make it into wheel.
and when giving `pytest --lf` i get:
_____________________________________ ERROR collecting setup.py _____________________________________
/usr/lib/python3.7/distutils/fancy_getopt.py:233: in getopt
opts, args = getopt.getopt(args, short_opts, self.long_opts)
/usr/lib/python3.7/getopt.py:93: in getopt
opts, args = do_longs(opts, args[0][2:], longopts, args[1:])
/usr/lib/python3.7/getopt.py:157: in do_longs
has_arg, opt = long_has_args(opt, longopts)
/usr/lib/python3.7/getopt.py:174: in long_has_args
raise GetoptError(_('option --%s not recognized') % opt, opt)
E getopt.GetoptError: option --lf not recognized
as debug aid (was doing that for plans already). + enh: annotate also networks.
863c7eb to
7bd3f85
Compare
|
Regarding the repo choice, if you have troubles keeping it under the old company, what would you say to make a new GitHub-organization and move it there. What do you think? In the mean time, i'm pushing fixes to the main repo (yahoo#31). Tip: |
|
Where is development moving to? I have my own graphkit fork as well. I'd consider migrating back to the original if it can provide the same functionality as my fork. |
|
we're moving it to this repo. |
|
What are the two repos here: https://github.com/pygraphkit |
|
I'm open for suggestions on how to proced, but i need |


Please read https://github.com/ankostis/graphkit/blob/master/CHANGES.rst.
It contains also 2 plots comparing the flowchart of the library before and after this PR.