[PythonCAD] DXF reader testing (and IPC)

[Eric Wilhelm]

> The following was supposedly scribed by
> Art Haas
> on Thursday 04 December 2003 08:39 am:

>> Art,
>>
>> Has pythoncad got any IPC capabilities yet?  I've been thinking lately
>> about the possibility of TCP or socket communication.  What would this do
>> for your load/save capabilities?  (i.e. what if your save/load functions
>> just spawned a back-end and dumped/read XML over a pipe?)
>
>No, there isn't any code to do that yet. As for the loading and saving
>of files through a pipe, I've tried to write things so that doing this
>is possible. I don't know if anyone has tried to do this, however.
>Perhaps adding some kind of socket communications will be done - it
>should be easier to do than in other programs because we're writing
>Python code and have the socket module to make things easier.
>
>File loading is handled in 'Generic/imageio.py' in the load_image()
>function. This function takes an opened filehandle and reads from it.
>The filehandle can be a pipe or a diskfile. I've thought that the way to
>handling importing or exporting other file formats would be that the
>format reader would be a stand-alone program that reads the file in its
>native format and coverts the data into the PythonCAD format. The
>PythonCAD program itself would then read the output of the file reading
>program, possibly through a pipe or some sort of temporary file.

I've been working on CAD::Drawing as a file-format independent Perl interface 
to vector graphics.  The backend modules currently support dwg/dxf (via 
opendwg toolkit) and I've started on some SQL-based storage methods.  It 
would be interesting to see this turn into a backend for PythonCAD.  I plan 
to integrate your dwg/dxf module via Inline (wrapping the python code in 
Perl,) but you had also suggested before that a straight translation be done.  
Either way would work, though the native Perl code may (possibly) be faster.  

Memory becomes a problem unless you enable per/entity read/write (which is 
also something that I have considered.)  With my current setup, each format 
just loads straight into a datastructure, but that could be loaded/freed 
per-entity with the right design.

Maybe the pipe program would be something like 'cat' except that it would be 
dumping each entity as xml.  It might look something like the following:
	use CAD::Drawing;
	$d = CAD::Drawing->new(
		dump_on_load => STDOUT,
		outformat => "pythoncad",
		);
	$d->load(shift); # file-format autodetected (with optional over-rides)

I was interested in whether there might be a chance of some socket IPC because 
I've put together the beginnings of a Tk gui and I wasn't liking the way it 
looked for expandability.  With writing all of the callbacks and selection 
code, it was looking like too much would be happening within a codebase that 
really just wanted to do batch processing.  This got me thinking that maybe I 
could write to a pipe and then open a socket connection and listen for 
commands.

--Eric

BTW, CAD::Drawing was just uploaded to CPAN.  Needs a decent makefile (which 
won't be simple, but I'm working on it.)  If you want to play with it or need 
help installing it, feel free to drop me a line.

-- 
"It is impossible to make anything foolproof because fools are so ingenious."
                                        --Murphy's Second Corollary