Re^2: Open Human Readable Computer Aided Design file format

[SciDude]

in reply to Re: Open Human Readable Computer Aided Design file format
in thread Open Human Readable Computer Aided Design file format

CAD on Linux

Anticipation of the benefits of perl6 prompts me to speculate on the future of CAD on linux.

I agree with you that this is a "better-than-most CAD format" but disagree on the "just another" part.

With some nurturing, this project that now discusses the format of open source CAD objects may actually become the next competitor to now closed-source and highly commercial software in a similar fashion to the GIMP and Mozilla (Firefox.) Considerable interest is growing for CAD on Linux and I predict the outcome to be impressive.

Open Discussion

Bruno has stated that the discussion has resolved to use YAML for the internal file format. He is now planning the extension of Draft to include revisions now being discussed at the cad-linux-dev list. In classic open source style, he asks openly for any assistance interested persons may provide. You can view the most recent discussion here.

[jdporter]

Maybe if they just include a hook to the Eclipse shell, as an (optional) layer above the fs, they can get the versioning/collaboration "for free". IMHO, that's the only very interesting part of this problem. The rest is just the classic (yet still never quite settled) question of how best to freeze/thaw objects.

I for one am disappointed they're using YAML. It's an ugly, non-intuitive (to my non-Pythonized eyes), and obsequiously-different format. But if they do it right, the freeze/thaw layer will be pluggable, so I could use XML, or Lisp, or whatever, as I saw fit.

[ewilhelm]

The beauty of using YAML is that it works well with simple shell tools like grep and also diff's well because a change of one property involves a change of one line. XML is too often stored without linebreaks, not to mention what happens when you add linebreaks and then diff that.

[jdporter]

Obviously, line-oriented tools, such as grep and diff, are mismatched to XML. A proper XML toolset operates on the data structures, not on the raw text.

The "one difference, one line" feature is nice... but it doesn't include any context, i.e. where in the data structure the different element is; you'd have to do something else to reveal that (e.g. load it in an editor). An XML diff'ing tool can report such context, because it knows it.

Don't misunderstand me — I'm not defending XML. I know it has its problems. But — unlike yaml — being gratuitously different isn't one of them.

[toma]

I've been using YAML for storing CAD data for a while now. I use it to store simulation and design information about electrical designs.

Mostly YAML works but I have seen it get fooled by some of the data that I have tried to store.

I use YAML to serialize large perl data structures into files. I will probably change from using YAML to something more reliable, at least for complex data structures. XML is the leading candidate.

There are some very interesting ideas that would be useful for CAD in Higher Order Perl.

I don't agree that perl 5 is unsuitable for writing CAD tools. At least one company sells a very large perl program that is a full-featured CAD tool.

Since such a large percentage of CAD work is really data munging, it tempting to just write the whole thing in Perl.

I have run into a fundamental problem with perl and CAD, though. Perl ruins the accuracy of floating point numbers at about 16 digits when numbers get stringified. Many things can trigger stringification, so it is difficult to prevent it from happening.