From ahaas at airmail.net Wed Dec 3 13:14:00 2003 From: ahaas at airmail.net (Art Haas) Date: Wed Dec 3 13:14:09 2003 Subject: [PythonCAD] Weak-references in Python Message-ID: <20031203181400.GA14063@artsapartment.org> Hi. Now that the Thanksgiving holidays are over it's time to get moving with some PythonCAD coding. One thing I'd like to do is investigate the use of weak references in the code. The python development list had discussed these things recently, though they have been part of python since the 2.1 release. Weak references are documented in the 'libweakref.tex' file in the Python documentation, and based on the following PEP: http://python.sourceforge.net/peps/pep-0205.html It appears that weak references have a number of good potential uses in PythonCAD as using these things will ensure that the various entities in a drawing don't have stray references which prohibit the entity's destruction and memory reclamation. This behavior is very desirable as a drawing with many entities could take up a great deal of memory, and releasing that memory is important to keep the overall memory usage down. There is no use of weak references in the current code at present. I'll be poking around a bit for info on them, and try them out in a few places as well. I'm hoping that there are people on the mailing list with some experience in using them and can write to the list regarding their experiences - good, bad, or ugly (ah-yi-ah-yi-ah)! Near the end of this year I'll write up some stuff regarding the state of the program, and the good and bad things that I think this first year of public release has shown. I'll also be writing up some things regarding the direction of development over the next year, both short and long term. Printing and hatching are certainly on the list, as well as improving the editing (moving, changing linetypes and colors, etc) of entities will be on the list as well. Another goal is improving the code itself - fixing various places where the code is structured poorly or can be written in a more "pythonic" way, for example. Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ewilhelm at sbcglobal.net Thu Dec 4 07:31:25 2003 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Thu Dec 4 07:30:06 2003 Subject: [PythonCAD] DXF reader testing (and IPC) In-Reply-To: <3FBC8D27.2040109@gva.es> References: <3FBC8D27.2040109@gva.es> Message-ID: <200312040631.25385.ewilhelm@sbcglobal.net> > The following was supposedly scribed by > Luis W. Sevilla > on Thursday 20 November 2003 03:45 am: >Hi > I'd like to take a look to the DXF reader. It dumps my dxf, but ... >what now? How can I view the draw? Write a back-end to pythoncad for loading dwg/dxf? You might want to look at my CAD::Drawing Perl module, which has started to grow the begginings of a GUI. I plan to eventually incorporate Art's dwg reader as a backend (currently, it just uses the opendwg toolkit.) 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?) --Eric -- "Everything should be made as simple as possible, but no simpler." --Albert Einstein From ahaas at airmail.net Thu Dec 4 09:39:53 2003 From: ahaas at airmail.net (Art Haas) Date: Thu Dec 4 09:40:03 2003 Subject: [PythonCAD] DXF reader testing (and IPC) In-Reply-To: <200312040631.25385.ewilhelm@sbcglobal.net> References: <3FBC8D27.2040109@gva.es> <200312040631.25385.ewilhelm@sbcglobal.net> Message-ID: <20031204143953.GA11479@artsapartment.org> On Thu, Dec 04, 2003 at 06:31:25AM -0600, Eric Wilhelm wrote: > > Write a back-end to pythoncad for loading dwg/dxf? > > You might want to look at my CAD::Drawing Perl module, which has started to > grow the begginings of a GUI. I plan to eventually incorporate Art's dwg > reader as a backend (currently, it just uses the opendwg toolkit.) > > 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. Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ewilhelm at sbcglobal.net Thu Dec 4 21:51:55 2003 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Thu Dec 4 21:50:37 2003 Subject: [PythonCAD] DXF reader testing (and IPC) In-Reply-To: <20031204143953.GA11479@artsapartment.org> References: <3FBC8D27.2040109@gva.es> <200312040631.25385.ewilhelm@sbcglobal.net> <20031204143953.GA11479@artsapartment.org> Message-ID: <200312042051.55140.ewilhelm@sbcglobal.net> > 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 From gmoffatt at gt.rr.com Fri Dec 5 13:06:58 2003 From: gmoffatt at gt.rr.com (Gary Moffatt) Date: Fri Dec 5 13:07:42 2003 Subject: [PythonCAD] Communications - etc. - HPGL Message-ID: <200312051206.58191.gmoffatt@gt.rr.com> First, drawings are usually of things we want to build and hopefully, in the future we will make robots to build them. This is particularly true in space, where the living conditions are non-existant. It is no accident that numerical control (NC) and HPGL are closely related - a plotter is a kind of robot. Fundamentally the concepts of HPGL should be directly supported in CAD, and a backend for HPGL should be easy. In terms of what is important, it seems to me the two frames paradigm for cropping and scaling is most important because it defines how the drawing relates to the paper, connecting the conceptual to the physical. Besides there are utilities that convert HPGL directly to Postscript. Applause for what you are doing. -- Registered Linux user #312657 From pfrostie at yahoo.com Thu Dec 4 19:37:20 2003 From: pfrostie at yahoo.com (phrostie) Date: Fri Dec 5 16:52:02 2003 Subject: [PythonCAD] Communications - etc. - HPGL In-Reply-To: <200312051206.58191.gmoffatt@gt.rr.com> References: <200312051206.58191.gmoffatt@gt.rr.com> Message-ID: <200312041937.20496.pfrostie@yahoo.com> there are a number of cad apps for linux that claim hpgl output. i have tried a number of them with my HP7550 and CalComp1024. they all fail to plot. there is an initailization string that has to proceed the HPGL code. i suspect that is is where the problem lies. older ploters like mine require this. i know many people have MUCH newer plotters and so this is not a problem, but if it is possible could this be added? On Fri December 5 2003 13:06, Gary Moffatt wrote: > First, drawings are usually of things we want to build and hopefully, in > the future we will make robots to build them. This is particularly true in > space, where the living conditions are non-existant. It is no accident that > numerical control (NC) and HPGL are closely related - a plotter is a kind > of robot. Fundamentally the concepts of HPGL should be directly supported > in CAD, and a backend for HPGL should be easy. In terms of what is > important, it seems to me the two frames paradigm for cropping and scaling > is most important because it defines how the drawing relates to the paper, > connecting the conceptual to the physical. Besides there are utilities that > convert HPGL directly to Postscript. Applause for what you are doing. > -- > Registered Linux user #312657 Registered Linux user #53630 From ahaas at airmail.net Fri Dec 5 17:19:27 2003 From: ahaas at airmail.net (Art Haas) Date: Fri Dec 5 17:19:33 2003 Subject: [PythonCAD] Communications - etc. - HPGL In-Reply-To: <200312041937.20496.pfrostie@yahoo.com> References: <200312051206.58191.gmoffatt@gt.rr.com> <200312041937.20496.pfrostie@yahoo.com> Message-ID: <20031205221927.GB1010@artsapartment.org> On Thu, Dec 04, 2003 at 07:37:20PM -0500, phrostie wrote: > there are a number of cad apps for linux that claim hpgl output. i have tried > a number of them with my HP7550 and CalComp1024. they all fail to plot. > there is an initailization string that has to proceed the HPGL code. i > suspect that is is where the problem lies. older ploters like mine require > this. i know many people have MUCH newer plotters and so this is not a > problem, but if it is possible could this be added? > When printing code starts taking shape then there will be some idea as to how easy or difficult it is to support HPGL printers. I have _zero_ experience in writing HPGL code, so I don't know what will be involved. Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Wed Dec 10 11:37:17 2003 From: ahaas at airmail.net (Art Haas) Date: Wed Dec 10 11:41:41 2003 Subject: [PythonCAD] Working on subversion repo Message-ID: <20031210163717.GD6148@artsapartment.org> Hi. Last night subversion was installed on the remote machine. The binary works as it successfully pulled the subversion code itself from the repository kept at http://svn.collab.net/repos/svn/trunk, but the program has problems reading the local copy of my subversion repo! I'm trying to figure out what the problem is, and have mailed the subversion developers for help. The problem appears to be a BerkeleyDB problem, as the program fails to read the '__db' files kept within a subversion repository. On both my local machine (Debian) and the remote machine (RedHat) the 4.0.14 version of Berkeley DB is installed. I'll mail out more info when this problem is fixed, hopefully today or tomorrow. I did want the list to know that access to the subversion repository should be returning soon. Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Wed Dec 10 12:14:13 2003 From: ahaas at airmail.net (Art Haas) Date: Wed Dec 10 12:14:19 2003 Subject: [PythonCAD] Subversion repo now accessible again Message-ID: <20031210171413.GF6148@artsapartment.org> Hi. A short exchange with the subversion developers has provided me with enough info to make the repo accessible again. I've just used the remote repo to update a copy I keep on my machine here, so it looks like access to the repo works for the time being. The core problem I had with the remote repo is unresolved - it will not read my local copy of the repository files. When the files are on the remote repository I have to run an 'svnadmin recover' command, in effect reconstructing these files on the remote machine. At that point the files can be read, but the next update from my local machine makes them unreadable again. I'll be using this workaround for the time being until the problem is resolved. The subversion binary on the new machine is the current development version kept in their svn repo. I think you'll need a very recent subversion binary to access the repo - 0.34.0 is the latest official release and that should be fine. I'd recommend everyone using subversion to upgrade to this release. Let me know if you can get the files from the repository again. Thanks. Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Fri Dec 12 13:14:46 2003 From: ahaas at airmail.net (Art Haas) Date: Fri Dec 12 13:15:08 2003 Subject: [PythonCAD] Improving the transfer of entities between layers Message-ID: <20031212181446.GA19047@artsapartment.org> Hi. One thing that PythonCAD has always handled with unpleasant side-effects has been transferring entities between layers. If you just wanted to move a segment, circle, or some other thing between the layers it went smoothly, but problems arose if there were dimensions associated with points used by these transferred entities, or in the case of radial dimensions, the entities themselves. I've added some new code that fixes this glitch, and have tried it out with good results. Draw a segment, then draw a dimension using the segment endpoints. Now, create a new layer, then transfer the segment from the old layer to the new one. Previously the dimension will be deleted, because the segment endpoints get removed when the segment is moved. The new code I've added resets the dimension to use the new segment endpoints in the new layer, so the dimension survives the segment transfer. Yay! I've sent the new code to the repo, so if you update your code you'll get this improvement. The code to handle transferring objects is now in a file 'Generic/transfer.py'; the transferObject() method of the Image class is being deprecated as it is just not up to the job. Having mentioned deprecating that method, one thing I think that will occur in several future releases is the deprecation of more methods in classes like Image and Layer. Some of these methods are poorly implemented like the transferObject() method was, and others probably shouldn't be in their class at all. It is certain that newer and simpler methods will be introduced to some of the classes as development proceeds; hopefully the experiences of this years efforts will pay dividends in deciding what and how to add these new methods. Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Mon Dec 15 16:48:57 2003 From: ahaas at airmail.net (Art Haas) Date: Mon Dec 15 16:49:04 2003 Subject: [PythonCAD] Repo troubles again Message-ID: <20031215214857.GA2855@artsapartment.org> Hi. The subversion repository is acting very strangely. The latest subversion code was installed on it this morning, and I was able to successfully update from the public repository. After making some changes here and then sending them to the repository, I'm finding that the code on the public repository can be examined once or twice, then the repo seems to get hosed up. Grrrr .... Accessing the public repository may be a bit spotty for a short while as I try to get things fixed. Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Mon Dec 15 17:53:52 2003 From: ahaas at airmail.net (Art Haas) Date: Mon Dec 15 17:54:01 2003 Subject: [PythonCAD] Repo rebuilt and seems to work Message-ID: <20031215225352.GB2855@artsapartment.org> Hi. I've rebuilt the repository and things seem to work without problems. Time will tell if this is the case. Here's a little Subversion info for what I've done. The latest version of Subversion recommends the BerkeleyDB-4.2 libraries, so I downloaded, built, and installed them on both my local machine and the remote machine. On the remote machine I then rebuilt Apache and Subversion to use this new BerkeleyDB library. On my local machine I did the same thing with both these programs as well. After doing a precautionary 'svnadmin dump' of my local repo, I installed my new subversion binary, and used 'svnadmin recover' to update the various files in the repo. An 'svnadmin verify' showed things looked good, so I checked in a change to my local repo, then synced my repo with the remote repo using rsync. Here's where things went splat - trying to retrieve the change from the remote repo produced errors, so I logged into the remote machine and tried reading the repo with 'svn ls'. No luck, so I resent my local repo back to the remote machine, where 'svn ls' would read it once, then fail again. So, on my local machine I again did 'svnadmin dump', made a new local repo, and reloaded the stuff with 'svnadmin load'. This new repo looked good, so I sent it to the remote site, and have been able to read and retrieve the files without problems. I'm suspecting that the fix to these problems occured when my local repo was reload with 'svnadmin load'. The BerkeleyDB files were all rebuilt with the latest BerkeleyDB library, not converted from the output of an older release. So, hopefully the repository access will be working correctly for the forseeable future. Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Thu Dec 18 07:52:41 2003 From: ahaas at airmail.net (Art Haas) Date: Thu Dec 18 07:52:49 2003 Subject: [PythonCAD] Away for a couple of days Message-ID: <20031218125241.GA20525@artsapartment.org> Hi. I'll be offline until the 22nd or so, then online again for a day or two, then offline again for a short spell. Between Christmas and New Year's I'm going to make an eleventh release which will contain the fixes applied in the last month or so. PythonCAD will be one year old on the December 21. Yay! Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Tue Dec 30 12:15:05 2003 From: ahaas at airmail.net (Art Haas) Date: Tue Dec 30 12:15:30 2003 Subject: [PythonCAD] ANNOUNCE: Eleventh release of PythonCAD now available Message-ID: <20031230171505.GA19024@artsapartment.org> I'd like to announce the eleventh development release of PythonCAD, a CAD package for open-source software users. As the name implies, PythonCAD is written entirely in Python. The goal of this project is to create a fully scriptable drafting program that will match and eventually exceed features found in commercial CAD software. PythonCAD is released under the GNU Public License (GPL). PythonCAD requires Python 2.2 or Python 2.3. The interface is GTK 2.0 based, and uses the PyGTK module for interfacing to GTK. The design of PythonCAD is built around the idea of separating the interface from the back end as much as possible. By doing this, it is hoped that both GNOME and KDE interfaces can be added to PythonCAD through usage of the appropriate Python module. Addition of other interfaces will depend on the availability of a Python module for that particular interface and developer interest and action. The eleventh release adds a few more fixes for running PythonCAD under Python 2.3 that were missed in the tenth release. This release improves the transfer of entities with associated dimensions from one layer to another. Prior to this release the dimension would be deleted, but now the dimension is preserved. This release also contains a number of file saving and loading cleanups applied to the code. A small number of bug fixes have been applied as well, and the addition of Ellipse and Spline entities has begun, though neither is complete yet. PythonCAD marked its first birthday on December 21, 2003! Yay! The mailing list for the development and use of PythonCAD is available. Visit the following page for information about subscribing and viewing the mailing list archive: http://mail.python.org/mailman/listinfo/pythoncad Visit the PythonCAD web site for more information about what PythonCAD does and aims to be: http://www.pythoncad.org/ Come and join me in developing PythonCAD into a world class drafting program, and Happy New Year to everyone! Art Haas -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822 From ahaas at airmail.net Tue Dec 30 14:53:34 2003 From: ahaas at airmail.net (Art Haas) Date: Tue Dec 30 14:53:45 2003 Subject: [PythonCAD] Plans for next release Message-ID: <20031230195334.GA23106@artsapartment.org> Hi. The eleventh release is out there, and after taking a quick peek at the logs on the website it appears to be making its way out. So now we start looking at what to do for the next release and beyond. Take a peek at the following page to see my short summary regarding the development efforts of this year. Fixing some of the problems listed in the page are always on the development agenda, as well as adding new features. http://www.pythoncad.org/status.html For the short term I want to add much more to the new Ellipse and Spline entities. Right now the Ellipse entity is somewhat complete in that it has visual attributes as well as its basic functionality. The spline stuff is still in its infancy. Adding to both entities means PythonCAD becomes more useful, especially when splines start working. Another goal for the short term is to do some more work in saving files. There is a simple optimization that can be made by only storing references to points, circles, and arcs that are used by dimensions. Currently a reference for each one of these objects is stored, but that is wasteful. If a drawing had a million points, but only used two out of that vast number in a dimension, then only those two points should be stored for writing the dimension entity in the file. A medium-term goal for the next couple of months is reworking the way the entities are stored in a layer. The current method of using sorted lists has worked when the entity count is small, but as the number of entities increases the list approach is seeming to become inefficient. I'll write a bit about how I plan to address this problem in another mail. I'd also like to make use of more Python goodies like weak references in future releases. Weak references will not increase the reference count on an object, so objects don't stick around longer than they should. I think that adding weak references will flush out a few bugs in the code, and then these exposed bugs can get fixed. Adding the ability to undo or redo an action is something I've been thinking about lately, and I've had a few ideas on how to implement it. I will play around a bit with my approach and, if it looks promising, try to get it implemented into the code as quickly as possible. Printing and hatching, the two largest deficiencies in the code, are both medium-term and long-term goals for next year's development efforts. Happy New Year to everyone. Art -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822