[Edu-sig] Re: VPython

[Scott David Daniels]

Arthur wrote:

>>I looked over the code I thought I had re-done, and it was not
>>what I remembered working on.  Here is a working version that
>>doesn't build up a massive string, but rather writes to a destination.
>>If you need a destination, make a CStringIO and use it.  It would
>>be fun to try and mix this with the PyGeo code.
OK, I sure mangled that explanation.  I should have said:
     If you need a string, use a CStringIO as the destination and
     unpack when done.

> I gave it a whirl with PyGeo.  
> 
> About the furthest I've ever gotten into string processing (not fun to me)
> was my effort to follow and extend Ruth's povexport.py code.  So that I am
> not sure I follow what you are accomplishing versus the "stock" code.  
> ... Could you explain better the "use case" difference between your 
> version and Ruth's?
I have images with tens of thousands of truncated torii.  The torii get
turned into curves, and the resultant file is massive.  Unfortunately,
the N**2 effect of string concatenation was making these runs take a
_long_ time.

> 2 BTWs:
> 
> 1. I seemed to have needed to change AttributeError to KeyError on line 344.
Most likely correct.

> 2. The functionality I would like to see is PovRay automatically called to
> render the exported code - rather than requiring a separate look for the
> file and call to PovRay.  At a practical level, this would provide for a
> more coherent workflow - looking at what you got and redoing it until you
> have it as you want to see it.  But I don't have the confidence that I could
> accomplish this sensibly in a crossplatform way, that would fail gracefully,
> not require config files (where is the pvengine executable?), etc.  Any
> thoughts?
I do know the pov-ray people have been pretty insistent on making sure
nobody repackages it in a way you don't see their interface.  I think
we'd need to wait for the repackaging they are in the midst of.

-Scott David Daniels
Scott.Daniels at Acm.Org