[vistrails-dev] Thomas Caswell is here; gotomeeting?

Rémi Rampin remirampin at gmail.com
Mon Feb 9 14:01:48 EST 2015


>
> XML seems to work well. JSON/YAML should also work if nicely structured?
> YAML looks better than JSON at representing multi-line strings like python
> code.
>

YAML and JSON are almost equivalent for our use (YAML being the superset).
It is a lot easier for humans to handle. I'm no fan of XML, but it is what
we use everywhere else, so we might want to stick to it (although the
format and libs are generally harder to use).

-- 
Rémi


2015-02-09 13:17 EST, Tommy Ellqvist <tommy.ellqvist at nyu.edu>:

>
> On 9 feb 2015, at 17:55, David Koop <dkoop at umassd.edu> wrote:
>
>
> On Feb 9, 2015, at 11:42 AM, Rémi Rampin <remirampin at gmail.com> wrote:
>
> The diffing/patching system has not really been discussed so far, I think
> we should design it carefully.
>
>
> Dave’s work on the matplotlib package looks like a good start. It supports
> diffing/merging and could support more attributes for new types of wrappers.
>
> For manual patching we need the serialized format to be easily readable
> and editable. This is an important factor when selecting a serialization
> because parsing speed does not seem to be a problem.
> XML seems to work well. JSON/YAML should also work if nicely structured?
> YAML looks better than JSON at representing multi-line strings like python
> code.
>
> The other part is to patch the compute method. The VTK wrapper can patch a
> compute method for classes, superclasses, VTK classes that contain a
> certain method or any other pattern. The matplotlib patcher can only patch
> classes and superclasses and is not as general. I think we will be able to
> have patterns for most types of patterns but it may sometimes be easier for
> package developers to add their own.
>
> The automatic upgrades should probably be derived from these diffs.
>
>
> This is a nice idea. This would give two purposes to the diffs:
>
> 1) The original use: Patching so that we can fix any issues where we want
> to build a manual translation of a parameter or alternate port specs, etc.
> 2) The proposed idea: If we diff the specs from different package
> versions, we can show developers (and users) exactly what has changed.
> Then, we can build an upgrade template (a fill-in-your-upgrade-code py or
> json file) and potentially suggest what upgrade mappings make sense. The
> automatic upgrades (where nothing changes) do not need to be here, but the
> “remap shortcuts” (port type changes but ok, port name changes, module name
> changes, value translations) could certainly be made available in such a
> template. This will encourage developers to add upgrades to their packages,
> and make it easier to describe how the upgrade should work.
>
>
> Yes. Diff’ing could be used to detect changes and suggest upgrades. It may
> be useful to have templates that can produce code that can be compared with
> the diff, but I am not sure how that would work.
>
> Thanks,
> Tommy
>
>
> Dave
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vistrails.org/pipermail/vistrails-dev/attachments/20150209/0fcec888/attachment.html>


More information about the vistrails-dev mailing list