Add graph-level robust list handling GList. Add tests for G.#3893
Open
afs wants to merge 4 commits intoapache:mainfrom
Open
Add graph-level robust list handling GList. Add tests for G.#3893afs wants to merge 4 commits intoapache:mainfrom
GList. Add tests for G.#3893afs wants to merge 4 commits intoapache:mainfrom
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
GListprovides robust RDF list handling at theGraphlevel. It is neded to make writing SHALC 1.2 list validation.Unlike
GNode+GraphList, it is not working on generalized"findable" concept. It is executing with no unnecessary object creation.It has checks for well-formed lists (one
rdf:first, onerdf:restper list cell, no cycles). It provides operations for accessing lists which check integrity but assume no cycles (cycle checking is moderately expensive for such low-level operations.As part of this, creating tests has been an experiment in using the most basic, free co-pilot setup to generate tests. The task is not difficult and it is easy to check and review.
For
GList, tests were first hand-written then copilot used to check coverage and add tests to be more comprehensive.The class
Ghas been around for a while. It is a low level internal API for wrapping up getting data out of graphs, such as checking one object is present for an SP lookup and always closing iterators, to reduce boilerplate in graph access code. The idea is to have a static import of the class so the functions become words available for writing code. DSL-ish.Goriginally started small and testing was by usage. But its grown. It would benefit from its own tests.Gshould be easy because it is many small, self-contained functions, no class state, with javadoc. It should not be a not very demanding task, it is (human) time consuming.The experiment is to use the default, free, co-pilot setup in Eclipse to see how it feels for individuals without enterprise-paid-for accounts.
And does it save time?
Learnings:
For increasing the coverage for
GList, it has been sucessful.My first attempt was building a single test file for
Gstarted OK. I was adding in groups of related operations to allow for review, e.g. all the SP accessors. But as more chunks were added, copilot "decided" to revise the earlier tests, lost track of coverage, lost earlier work and I could get it to backtrack and recover. It seems it lost the basic context. I threw the work away, got it to forget the last 24 hours (elapsed) and started again with one file per chunk.That has been reasonably successful. Not a massive time saving but it was task that needed doing and wasn't happening. It still needs reviewing but the biggest advantage is that it is easier to spend my time in chunks on it across a few days with little (human) context-switching costs.
In one case, it found one bug. I fixed it manually. I didn't let copilot change any
src/maincode because ...In another case, it confidently offered to change the implementation to match the test but the test was wrong.
By submitting this pull request, I acknowledge that I am making a contribution to the Apache Software Foundation under the terms and conditions of the Contributor's Agreement.