From ahaas at airmail.net Wed Jun 2 13:37:24 2004 From: ahaas at airmail.net (Art Haas) Date: Wed Jun 2 13:37:35 2004 Subject: [PythonCAD] One more thing ... Message-ID: <20040602173724.GS3653@artsapartment.org> Python 2.3.4 was released a week or two ago, and I'm now using it as my '/usr/bin/python' binary. Things seem to work fine with this release. -- 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 Jun 2 13:36:01 2004 From: ahaas at airmail.net (Art Haas) Date: Wed Jun 2 13:37:36 2004 Subject: [PythonCAD] Small fixes for fourteenth release and new stuff at repo Message-ID: <20040602173601.GR3653@artsapartment.org> Hi. I've been working on removing some of the code duplication in the various Quadtree subclasses. Many of these classes have the same code for moving through the tree duplicated two or three times. I've changed most of these routines now to use a common method call to walk through the Quadtrees, and things look pretty good. I've sent my changes to the repository so people using subversion can grab them and see. The old routines are still present, they now have a temporary 'old_' prefix in their name. When I'm happy with the new routines these older ones will be removed. While working on this stuff I found a dumb bug in the VCLineQuadtree code. In the file 'Generic/vcline.py', on lines 487-488 you'll see this: _bmin = _bounds[0] _bmax = _bounds[0] The '_bmax' index is wrong - it should be '2'. Change the line like so: _bmax = _bounds[2] Also, there was an omission in the 'Generic/layer.py' file. The canParent() method of the Layer class is missing the 'text.TextBlock' class in the tuple listing valid children of the layer. The method starts on line 1917, and you'll see that the isinstance() second argument is a tuple with lots of class types listed. Adding in 'text.TextBlock' to the tuple fixes a problem seen when adding text to a drawing. The last line of the tuple looks like this ... ccircle.CCircle, dimension.Dimension)) Change it to ... ccircle.CCircle, dimension.Dimension, text.TextBlock)) and the problem is fixed. Sorry that this slipped by. If you pull the code from the repo you'll also get fixes for splitting entities. When splitting a group of entities selected within a boxed region, the code previously relied on the entities being in a sorted order from leftmost to rightmost. The quadtree stuff did away with that assumption, but the splittin code had a number of tests that needed to be removed which weren't until now. Splitting a number of entities works much better now that the tests have been 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 CSomerlot at Brwncald.com Thu Jun 3 08:36:28 2004 From: CSomerlot at Brwncald.com (Somerlot, Chris) Date: Thu Jun 3 08:37:48 2004 Subject: [PythonCAD] Small fixes for fourteenth release and new stuff at repo Message-ID: I'm having trouble getting a fresh checkout from the repo going. I get these errors: File "C:\Python23\Lib\site-packages\PythonCAD\Generic\acline.py", line 667 for _node in self.getNodes(_x, _y, _angle) ^ SyntaxError: invalid syntax And... File "C:\Python23\Lib\site-packages\PythonCAD\gtkpycad.py", line 323, in main img = Interface.Gtk.gtkimage.GTKImage() AttributeError: 'module' object has no attribute 'GTKImage' Not sure why the last one is occuring. Also, it turns out the reason files can't be written or saved on windows is because fileio.py does not open them as binary, like the Gzip class in gzip.py does. Adding the following at line 45 solves the problem: if mode and 'b' not in mode: mode += 'b' Chris From ahaas at airmail.net Thu Jun 3 09:50:22 2004 From: ahaas at airmail.net (Art Haas) Date: Thu Jun 3 09:50:34 2004 Subject: [PythonCAD] Small fixes for fourteenth release and new stuff at repo In-Reply-To: References: Message-ID: <20040603135022.GB19242@artsapartment.org> On Thu, Jun 03, 2004 at 08:36:28AM -0400, Somerlot, Chris wrote: > I'm having trouble getting a fresh checkout from the repo going. I get > these errors: > > File "C:\Python23\Lib\site-packages\PythonCAD\Generic\acline.py", line > 667 > for _node in self.getNodes(_x, _y, _angle) > ^ > SyntaxError: invalid syntax Fixed. I'd fixed this after commiting the change, but hadn't checked in the fix. Grr ... > And... > > File "C:\Python23\Lib\site-packages\PythonCAD\gtkpycad.py", line 323, > in main > img = Interface.Gtk.gtkimage.GTKImage() > AttributeError: 'module' object has no attribute 'GTKImage' > > Not sure why the last one is occuring. I don't know about this one. The program starts normally here. Can you try running python from a command line and then do this ... $ python > import Interface.Gtk.gtkimage > dir(Interface.Gtk.gtkimage) You should see 'GTKImage' in the output. > Also, it turns out the reason files can't be written or saved on windows > is because fileio.py does not open them as binary, like the Gzip class > in gzip.py does. Adding the following at line 45 solves the problem: > > if mode and 'b' not in mode: > mode += 'b' Thanks! I've checked in a slightly different change - the mode will get the binary flag if sys.platform is 'win32'. I think that should cover all the current windows versions. Do an 'svn update' again and you'll get the changes. 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 CSomerlot at Brwncald.com Thu Jun 3 17:23:22 2004 From: CSomerlot at Brwncald.com (Somerlot, Chris) Date: Thu Jun 3 17:24:47 2004 Subject: FW: [PythonCAD] Small fixes for fourteenth release and new stuff atrepo Message-ID: > > > > File "C:\Python23\Lib\site-packages\PythonCAD\gtkpycad.py", line > > 323, in main > > img = Interface.Gtk.gtkimage.GTKImage() > > AttributeError: 'module' object has no attribute 'GTKImage' > > > > Not sure why the last one is occuring. > > I don't know about this one. The program starts normally > here. Can you try running python from a command line and then > do this ... > The fresh checkout absolved this problem. Thanks! From fb102 at soton.ac.uk Thu Jun 3 17:57:28 2004 From: fb102 at soton.ac.uk (Floris Bruynooghe) Date: Thu Jun 3 17:57:35 2004 Subject: [PythonCAD] An open file format for Computer Aided Design (CAD) Message-ID: <20040603215728.GA9016@balder.anrpg.homeip.net> > http://bugbear.blackfish.org.uk/~bruno/draft/ > > I think it could be interesting. Very interesting and promising. However I think it is a bad idea to make it standard behaviour in any CAD program. They should stick with what they have I recon and only provide this new file format for users who know what they want. My reason for saying that is for people who don't have their filesystem optimised for this and generally don't bother about filesystems really. For example I never bothered finetuning my ext2 filesystem as it is very low on my priority list and would require lots of analysis, I just never found the time. This means that my filesystem is just the standard generated by Debian, which happens to have a block size of 4Kb. Now this last small detail has quite some inpact on this fileformat as it potentially has thousends of small files way smaller then the block size of the average filesystem, makeing whole the drawing an absolute huge size on disk. Secondly, and less important, it is dangerous to just rely on the undo of the filesystem. Once more this is for users who don't have theire filesytem tuned. Don't get me wrong. I think it is a great idea and would love to see it being used to test it in actual industial type use. See how it performs in real life. Just my thoughts... flub -- Debian GNU/Linux -- The power of freedom www.debian.org | www.gnu.org | www.kernel.org From ewilhelm at sbcglobal.net Thu Jun 3 18:07:36 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Thu Jun 3 18:06:08 2004 Subject: [PythonCAD] An open file format for Computer Aided Design (CAD) In-Reply-To: <20040603215728.GA9016@balder.anrpg.homeip.net> References: <20040603215728.GA9016@balder.anrpg.homeip.net> Message-ID: <200406031707.36259.ewilhelm@sbcglobal.net> # The following was supposedly scribed by # Floris Bruynooghe # on Thursday 03 June 2004 04:57 pm: >Very interesting and promising. However I think it is a bad idea to >make it standard behaviour in any CAD program. They should stick with >what they have I recon and only provide this new file format for users >who know what they want. > >My reason for saying that is for people who don't have their filesystem >optimised for this and generally don't bother about filesystems really. >block size of 4Kb. > makeing whole the drawing an absolute huge size on disk. Ok, but if one were to build support for this file-based format directly into the internals of their application, it likely would not be a simple change to go back to monolithic files. However, a really simple way to switch back to monolithic files would be to use a loop filesystem, and most users would never notice the difference. Using a loop filesystem or not is a really simple option which wouldn't have much impact on the core of the code. With regard to backups/corruption concerns and undo-only-via-filesystem, again most users would not really notice the difference. If it all goes on behind the scenes, it's no big deal to someone who doesn't need the flexibility of fs-based data, but to someone who does, a system without support for it is a brick wall. --Eric -- Peer's Law: The solution to the problem changes the problem. From ewilhelm at sbcglobal.net Thu Jun 3 18:31:28 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Thu Jun 3 18:29:58 2004 Subject: [PythonCAD] dwg reader tester rig Message-ID: <200406031731.28261.ewilhelm@sbcglobal.net> Hi, For all of you that would like to try the dwg reader on some of your files, there is now a fairly automated testing rig available at: http://ericwilhelm.homeip.net/svn/py_dwg_tester/py_dwg_tester.tar.gz Art and myself have been going back-and forth with the python code a little and I've added some debug functionality to the modules, as well as created a perl harness script and a python test script. I wouldn't say that it's for the faint of heart, but it shouldn't be too difficult to run on a Linux system (windows users may have to work a little harder.) You'll need IPC::Run from CPAN, but other than that everything is in the one tarball. Check the README. There's a few ways to run things. If you don't have much hard-drive space or CPU power, you may want to disable the logging by going without the logs/ directory (now the default.) If you don't have any errors in the errs/ directory when you're done, congratulations, now all you have to do is wait and look forward to reading dwg files from pythoncad:) --Eric -- "I will not reason and compare, my business is to create... The road of excess leads to the palace of wisdom." --William Blake From fb102 at soton.ac.uk Thu Jun 3 18:41:29 2004 From: fb102 at soton.ac.uk (Floris Bruynooghe) Date: Thu Jun 3 18:41:36 2004 Subject: [PythonCAD] An open file format for Computer Aided Design (CAD) In-Reply-To: <200406031707.36259.ewilhelm@sbcglobal.net> References: <20040603215728.GA9016@balder.anrpg.homeip.net> <200406031707.36259.ewilhelm@sbcglobal.net> Message-ID: <20040603224129.GA9619@balder.anrpg.homeip.net> On Thu, Jun 03, 2004 at 05:07:36PM -0500, Eric Wilhelm wrote: > Ok, but if one were to build support for this file-based format directly into > the internals of their application, it likely would not be a simple change to Sure, it would already be a horible task rewriting it to file-based format. However, I think on long term it is usefull to build an application with file-based as default as it makes life so much easier for the devellopers. But on the short term it's probably better to get some abstraction layer in between so both formats can be used. This would make one of them sub-optimal however. I realize this is not easy and it's very likely I havent thought properly about it yet though. > go back to monolithic files. However, a really simple way to switch back to > monolithic files would be to use a loop filesystem, and most users would > never notice the difference. Using a loop filesystem or not is a really > simple option which wouldn't have much impact on the core of the code. Indeed, didn't think of that. Evident! Ok, I can't think of any other drawback really :-) flub -- Debian GNU/Linux -- The power of freedom www.debian.org | www.gnu.org | www.kernel.org From digitect at mindspring.com Thu Jun 3 19:13:41 2004 From: digitect at mindspring.com (Steve Hall) Date: Thu Jun 3 19:13:48 2004 Subject: [PythonCAD] An open file format for Computer Aided Design (CAD) Message-ID: <9808086.1086304421610.JavaMail.root@wamui04.slb.atl.earthlink.net> From: Floris Bruynooghe, Jun 3, 2004 5:57 PM > > > http://bugbear.blackfish.org.uk/~bruno/draft/ > > > > I think it could be interesting. > > Very interesting and promising. However I think it is a bad idea to > make it standard behaviour in any CAD program. They should stick > with what they have I recon and only provide this new file format > for users who know what they want. > > [various issues with file system optimization] Not sure if Bruno reads this list, but let me defend it as a concept cooked up in reaction to a thread several of us had about how to track CAD files like source code in a version control system. The file system architecture is only a way to isolate changes to the smallest portions to make CVS faster. I doubt there was much thought into block sizes or other file system-related concerns. I frankly would prefer these flexibilities and control over the reduced disk access and similar physical limitations that seem to be vaporizing under the pressure of Moore's Law and friends anyway. BTW, (and slightly more on-topic) I also think it exposes a weakness of markup file formats like XML. Diff (and CVS-like systems dependant on it) require that the order of content and structuring whitespace be absolutely controlled. This is somewhat counter to the idea that certain flexibilities are permitted within markup. Is this a weakness of diff or XML? What do we give up by using XML? -- Steve Hall [ digitect@mindspring.com ] Cream... the Vim text editor in sheep's clothing! http://cream.sourceforge.net From steve at przepiora.org Tue Jun 8 07:52:45 2004 From: steve at przepiora.org (Stephen M. Przepiora) Date: Tue Jun 8 12:14:02 2004 Subject: [PythonCAD] Compliments and suggestions Message-ID: <1086695565.32433.10.camel@noon.gearnet.net> First let me say well done so far on it, it is fast. I was surprised at the speed of it. I have a few suggestions: Toolbar buttons for things instead of menu items. for instance putting the different objects like segment on a toolbar would be a great thing to do for usability. Snapping A must have to connect and select objects. Some changes to moving/extending. When I click on an object, say a segment and drag I should be able to move the object. If I click on a point of the segment I should be able to move just the point of the segment. Although I have been programming for a number of years, I have never done so in python. It is one of the languages I have put on my list of things to learn. I will try adding toolbars and see how I do, but I cannot promise anything for the others. Keep up the good work, Steve From rafmed at ya.com Fri Jun 11 14:52:10 2004 From: rafmed at ya.com (rafael) Date: Fri Jun 11 14:46:15 2004 Subject: [PythonCAD] installation Message-ID: <40C9FF5A.3050009@ya.com> On install Pythoncad R14 (Mandrake 9.1) I obtain this error running install Traceback (most recent call last): File "/xxxx/xxx/xxx/PythonCAD-DS1-R14/setup.py", line 19, in ? packages=['Generic', File "/usr/lib/python2.2/distutils/core.py", line 138, in setup dist.run_commands() File "/usr/lib/python2.2/distutils/dist.py", line 893, in run_commands self.run_command(cmd) File "/usr/lib/python2.2/distutils/dist.py", line 912, in run_command cmd_obj.ensure_finalized() File "/usr/lib/python2.2/distutils/cmd.py", line 112, in ensure_finalized self.finalize_options() File "/usr/lib/python2.2/distutils/command/install.py", line 273, in finalize_options (prefix, exec_prefix) = get_config_vars('prefix', 'exec_prefix') File "/usr/lib/python2.2/distutils/sysconfig.py", line 427, in get_config_vars func() File "/usr/lib/python2.2/distutils/sysconfig.py", line 332, in _init_posix raise DistutilsPlatformError(my_msg) distutils.errors.DistutilsPlatformError: invalid Python installation: unable to open /usr/lib/python2.2/config/Makefile (No such file or directory) What can I do? Thank you very much rafael From w.knol at niwa.co.nz Fri Jun 11 20:47:54 2004 From: w.knol at niwa.co.nz (Wilbert Knol) Date: Fri Jun 11 20:50:45 2004 Subject: [PythonCAD] installation In-Reply-To: <40C9FF5A.3050009@ya.com> References: <40C9FF5A.3050009@ya.com> Message-ID: <200406121247.54680.w.knol@niwa.co.nz> On Sat, 12 Jun 2004 06:52, rafael wrote: > On install Pythoncad R14 (Mandrake 9.1) I obtain this error I, too, had endless problems with Mdk 9.0 and 9.1 (the download versions) trying to get PythonCAD to run. My conclusion was that the Mandrake GTK and Python packages were buggy. RPM dependencies stopped me from removing and upgrading those packages. In the end I gave up and upgraded to Mdk 10.0 which solved those problems. You'll have no problems running recent releases of PythonCAD under Mdk 10.0. Wilbert. From ahaas at airmail.net Sun Jun 13 10:40:55 2004 From: ahaas at airmail.net (Art Haas) Date: Sun Jun 13 10:41:04 2004 Subject: [PythonCAD] Subversion updated Message-ID: <20040613144055.GA2644@artsapartment.org> Hi. Just a short note to say that the subversion binary has been updated on the machine hosting the public repository. The new binary seems to work fine. 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 Jun 15 14:16:45 2004 From: ahaas at airmail.net (Art Haas) Date: Tue Jun 15 17:04:37 2004 Subject: [PythonCAD] [ANNOUNCE] Fifteenth release of PythonCAD now available Message-ID: <20040615181645.GD3093@artsapartment.org> I'm pleased to announce the fifteenth 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 fifteenth release of PythonCAD offers users on Mac OS X a native, Cocoa based interface utilizing the Python/Objective-C bridge. The Python/Objective-C code is available at http://pyobjc.sf.net/. A nice side benefit from the development of the Cocoa code was the exposure of various bugs and design issues in the interface neutral code. Bugs exposed by this work have been fixed, and several design improvements are now in the code thanks to this work. The Cocoa interface code is contributed by David Haas, and I thank him greatly for his work. This release includes several more undo/redo improvements. The addition and removal of points on a polyline can now be undone or redone, and assorted other editing operations have improved undo/redo handling as well. A variety of bug fixes have also been added in this release. Small bugs regarding entity searching, arc boundaries, layer addition and removal, and entity storage have been fixed. A few code improvements appear in this release also. 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! 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 Wed Jun 16 12:09:35 2004 From: ahaas at airmail.net (Art Haas) Date: Thu Jun 17 06:26:50 2004 Subject: [PythonCAD] [ANNOUNCE] Sixteenth release of PythonCAD now available Message-ID: <20040616160935.GB3093@artsapartment.org> Hi. Due to packaging problems in the fifteenth release, and a code snafu the bit the Cocoa interface, I'm releasing the sixteenth version of PythonCAD. The missing Cocoa files have been added, and a patch addressing the Layer problems on Cocoa have been applied. Additionally a small patch for chamfers and fillets is in this release as well, but otherwise this release is identical to the fifteenth release. My thanks to David Haas for contributing the Cocoa interface code, and resolving the problems in the fifteenth release. 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 Wed Jun 16 11:00:36 2004 From: ahaas at airmail.net (Art Haas) Date: Thu Jun 17 08:41:37 2004 Subject: [PythonCAD] Sixteenth release appearing today ... Message-ID: <20040616150036.GW3093@artsapartment.org> Hi. I botched the packaging of the fifteenth release - some of the files needed for the Cocoa interface were missing. After regenerating the archives with the missing files, it turned out there was a missing patch or two needed for the Cocoa stuff to work correctly. So, the big introduction of a working Cocoa interface hasn't come off as smoothly as one would hope. :-( David has sent me a patch or two needed for fixing the Cocoa stuff, so I'll add it and get with him to try things out. Once we've got things resolved, I'll tag the sixteenth release and send it out. There is also one small patch that is not Cocoa-specific that will be in this release, but for all intents and purposes, the sixteenth release will be identical to the fifteenth. The new release should appear on the web site this afternoon. 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