From ahaas at airmail.net Tue Nov 9 20:23:53 2004 From: ahaas at airmail.net (Art Haas) Date: Tue Nov 9 20:24:06 2004 Subject: [PythonCAD] Latest changes at repo Message-ID: <20041109192353.GD26279@artsapartment.org> Hi. I've sent a few more changes up to the public Subversion repo. A problem reported on the mailing list about loading the preferences has been fixed, and a recently introduced bug where dimensions loaded from a file would be the wrong color has been fixed. I'd sent other change over the last week or two, and those changes were usually small bug fixes. I am making progress with enhancing the printing of dimensions. I've got code in place that will print out the endpoint markers on a dimension, though this code is not yet in the repo. It should make it out within a day or two. My plans are to make the next release either at the end of this week or sometime next week. More info later. 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 dgcov at e-zim.com Fri Nov 12 15:40:09 2004 From: dgcov at e-zim.com (Dave Coventry) Date: Fri Nov 12 16:10:25 2004 Subject: [PythonCAD] AMD64 Bit Message-ID: <20041112144009.8A87A3955@sitemail.everyone.net> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythoncad/attachments/20041112/6b0af954/attachment.htm From ahaas at airmail.net Fri Nov 12 17:13:06 2004 From: ahaas at airmail.net (Art Haas) Date: Fri Nov 12 17:13:13 2004 Subject: [PythonCAD] AMD64 Bit In-Reply-To: <20041112144009.8A87A3955@sitemail.everyone.net> References: <20041112144009.8A87A3955@sitemail.everyone.net> Message-ID: <20041112161306.GH3360@artsapartment.org> On Fri, Nov 12, 2004 at 06:40:09AM -0800, Dave Coventry wrote: > Hi Art, > > I've just bought a 64bit shuttle which I've set up with Ubuntu64 (http://www.ubuntu.com/). > > Do you think there are likely to be any issues with pythoncad? > > What would be the advantages (if any)? > > Many thanks, > > Dave Coventry. Hi. PythonCAD depends on Python, GTK, and the PyGTK bindings, so if they run nicely in a 64bit environment, and I believe they do, then PythonCAD should run fine. I don't see any advantage right now for PythonCAD on a 64bit machine. 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 Fri Nov 12 19:43:16 2004 From: ahaas at airmail.net (Art Haas) Date: Fri Nov 12 19:43:33 2004 Subject: [PythonCAD] [ANNOUNCE] Eighteenth release of PythonCAD now available Message-ID: <20041112184316.GI3360@artsapartment.org> I'm pleased to announce the eighteenth 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. As of the sixteenth release, a Cocoa based front end is available for people on OS X having the Python/Objective-C bindings. Addition of other PythonCAD interfaces will depend on the availability of a Python module for that particular interface and developer interest and action. The eighteenth release of PythonCAD enhances the printing abilities introduced in the seventeenth release. Radial and Angular dimensions are now printed completely, and dimension markers like arrows or slashes are printed for all dimension entities. Another enhancement in this release is the improved restoration of deleted dimensions in undo operations. Previously the dimensions were recreated with their various attributes having default values, whereas now they are recreated with the attribute values being restored to the values they had when the dimension was deleted. This release also features numerous internal code improvements dealing with the storage of entity values for undo/redo operations, and a wide variety of bug fixes and code improvements are present in this release as well. Additionally, an RPM '.spec' file is now included in the code for people wishing to build RPM packages of PythonCAD. The '.spec' file was created by D. Scott Barninger, and I'd like to thank him for this contribution. I'd also like to thank Cedric Delfosse for providing PythonCAD '.deb' packages to Debian users. 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 Sat Nov 13 17:20:04 2004 From: ahaas at airmail.net (Art Haas) Date: Sat Nov 13 17:20:46 2004 Subject: [PythonCAD] File saving bug in eighteenth release Message-ID: <20041113162004.GI7238@artsapartment.org> Hi. I've been informed that there is a bug in saving files with the eighteenth release. Specifically it is when loading up older files and then trying to save them. After poking around a bit I've duplicated the problem here, and it looks like it would affect drawings that have text entities. Drawings without text seem to save correctly. I've made the patch below and sent it to the person reporting the bug. On my test case the patch fixed the problem. If you've downloaded the eighteenth release, please apply this patch. I'm almost certainly going to make a nineteenth release today, but I do want to hear that this patch fixes the bug that was reported to me. If you care to test it, find an older drawing you've made that has some text entities, and make a copy that you can test with. Load up your copy, and try to save it. If the save fails, apply the patch below to the eighteenth release, then again copy your test drawing, load it up, then save. It should save successfully. Art Haas Index: PythonCAD/Generic/text.py =================================================================== --- PythonCAD/Generic/text.py (revision 1374) +++ PythonCAD/Generic/text.py (working copy) @@ -34,11 +34,11 @@ font_style_string(style) """ - if style == NORMAL: + if style == TextStyle.FONT_NORMAL: _str = 'normal' - elif style == OBLIQUE: + elif style == TextStyle.FONT_OBLIQUE: _str = 'oblique' - elif style == ITALIC: + elif style == TextStyle.FONT_ITALIC: _str = 'italic' else: raise ValueError, "Unknown font style: " + str(style) @@ -49,13 +49,13 @@ font_weight_string(weight) """ - if weight == NORMAL: + if weight == TextStyle.WEIGHT_NORMAL: _str = 'normal' - elif weight == LIGHT: + elif weight == TextStyle.WEIGHT_LIGHT: _str = 'light' - elif weight == BOLD: + elif weight == TextStyle.WEIGHT_BOLD: _str = 'bold' - elif weight == HEAVY: + elif weight == TextStyle.WEIGHT_HEAVY: _str = 'heavy' else: raise ValueError, "Unknown font weight: " + str(weight) -- 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 Sat Nov 13 19:43:17 2004 From: ahaas at airmail.net (Art Haas) Date: Sat Nov 13 19:43:33 2004 Subject: [PythonCAD] [ANNOUNCE] Nineteenth release of PythonCAD now available Message-ID: <20041113184317.GR7238@artsapartment.org> I'm pleased to announce the nineteenth 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. As of the sixteenth release, a Cocoa based front end is available for people on OS X having the Python/Objective-C bindings. Addition of other PythonCAD interfaces will depend on the availability of a Python module for that particular interface and developer interest and action. The nineteenth release of PythonCAD fixes a file saving bug found shortly after the eighteenth release was made public. The bug affected drawings that had text entities. A fix for this bug was found and tested by the bug reporter (thanks Ed Richley!) and confirmed to fix the problem. The serious nature of the bug called for making this new release. The only other change appearing in this release is the addition of the PostScript command 'showpage' appearing at the end of the generated plot file. Anyone using the eighteenth release is urge to upgrade immediately. 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 Tue Nov 16 16:24:31 2004 From: ahaas at airmail.net (Art Haas) Date: Tue Nov 16 16:24:38 2004 Subject: [PythonCAD] Post nineteenth release plans Message-ID: <20041116152431.GO2993@artsapartment.org> Hi. Now that the shortlived eighteenth release and bug-fix nineteenth release are out, work on the twentieth release begins. Users of the Cocoa front end will find the nineteenth releaes is not usable, as the changes I'd made were insufficient to make that front-end work again after the code movement several releases ago. Fortunately a patch was sent to me that fixed many of the problems, but the Cocoa front end is still not completely fixed. The patch has been commited, and I've synced the public repo up so subversion users on Cocoa can get it. I'm wanting to reexamine the way that files are saved in the next release. The current approach is not as robust as I like, and although a backup copy is made before saving a file, should the file save fail for any reason you are left with an invalid file and you have to manually rename the backup copy back to the original name. A better approach would be to save the file with a temporary name, and if that save is successful then make the backup and rename the temporary file to the correct name. This way, the existing file is not tampered with until the new file has been completely saved, so any glitches in saving the new file will not require you to rename a backup copy. Other than fixing bugs, I don't have any immediate plans for what else to try and get in the next release. Some suggestions have been mailed to me, and a few of them may appear. By the way, I'm targetting the middle to end of December for the twentieth release. 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 Wed Nov 17 00:15:48 2004 From: ewilhelm at sbcglobal.net (Eric Wilhelm) Date: Wed Nov 17 00:15:55 2004 Subject: [PythonCAD] Post nineteenth release plans In-Reply-To: <20041116152431.GO2993@artsapartment.org> References: <20041116152431.GO2993@artsapartment.org> Message-ID: <200411161715.48439.ewilhelm@sbcglobal.net> # The following was supposedly scribed by # Art Haas # on Tuesday 16 November 2004 09:24 am: >A better approach >would be to save the file with a temporary name, and if that save is >successful then make the backup and rename the temporary file to the >correct name. This way, the existing file is not tampered with until > the new file has been completely saved, so any glitches in saving > the new file will not require you to rename a backup copy. One caveat in this scheme: You cannot save into a symlink (or a hard link for that matter.) Maybe this is solved by getting all of the XML into an in-memory string, and then open(file, 'w') the file and write into it. However, here I'm assuming that your main concern about failed saves is during creation of the XML. If you really need an atomic write action, then you would have to follow a symlink back to the original and perform your os.rename() operation there. However, readlink() only works on symlinks, not hard links, so this scheme doesn't do everything that open(file, 'w') does. Let's forget about links for a second and just note that using a rename will lose any existing permissions on a file, creating problems where a file is shared between users (if I set a file as a+r and that is not the default of my umask, then pythoncad will make my setting go away whenever I save.) There is also an issue of who saves the file (I believe any user can write into a file with a+w permissions, but only the owner can remove it (or move, or rename on top of it.)) Also, note the implications of same on your backup file strategy. Maybe you need to actually open() the backup and then read the current file into it, then open() the destination file and write the new XML. Then, as long as you have write permission on both files, everything is okay, regardless of who owns them. --Eric -- The opinions expressed in this e-mail were randomly generated by the computer and do not necessarily reflect the views of its owner. --Management From ahaas at airmail.net Wed Nov 17 01:33:18 2004 From: ahaas at airmail.net (Art Haas) Date: Wed Nov 17 01:35:06 2004 Subject: [PythonCAD] Post nineteenth release plans In-Reply-To: <200411161715.48439.ewilhelm@sbcglobal.net> References: <20041116152431.GO2993@artsapartment.org> <200411161715.48439.ewilhelm@sbcglobal.net> Message-ID: <20041117003318.GA22825@artsapartment.org> On Tue, Nov 16, 2004 at 05:15:48PM -0600, Eric Wilhelm wrote: > # The following was supposedly scribed by > # Art Haas > # on Tuesday 16 November 2004 09:24 am: > > >A better approach > >would be to save the file with a temporary name, and if that save is > >successful then make the backup and rename the temporary file to the > >correct name. This way, the existing file is not tampered with until > > the new file has been completely saved, so any glitches in saving > > the new file will not require you to rename a backup copy. > > One caveat in this scheme: You cannot save into a symlink (or a hard > link for that matter.) True. If you look at the current file saving code in 'imageio.py', you'll see that there is an effort being made already to not write into symbolic links. However, the code wouldn't pass a security audit as the symlink could be added after the test was done but before the file is actually opened. What I'm starting to do is change the 'save_image' function to take an open filehandle instead of a filename. First, this change will move any file manipulations out of this function, and secondly it will allow this function to be used to write the file info out to a filehandle that could be attached to a pipe. > Maybe this is solved by getting all of the XML into an in-memory > string, and then open(file, 'w') the file and write into it. > However, here I'm assuming that your main concern about failed saves > is during creation of the XML. That is most of it. I'd hate to lose a drawing because the file save operation failed whether due to a bug in the code or possibly some disk space issue. Imaging losing hours or days worth of work that way. Ugh. > If you really need an atomic write action, then you would have to > follow a symlink back to the original and perform your os.rename() > operation there. However, readlink() only works on symlinks, not > hard links, so this scheme doesn't do everything that open(file, 'w') > does. I'm still not fond of the idea of writing through a symbolic link. It seems like doing that is asking for trouble. > Let's forget about links for a second and just note that using a > rename will lose any existing permissions on a file, creating > problems where a file is shared between users (if I set a file as a+r > and that is not the default of my umask, then pythoncad will make my > setting go away whenever I save.) There is also an issue of who > saves the file (I believe any user can write into a file with a+w > permissions, but only the owner can remove it (or move, or rename on > top of it.)) Also, note the implications of same on your backup file > strategy. Maybe you need to actually open() the backup and then read > the current file into it, then open() the destination file and write > the new XML. Then, as long as you have write permission on both > files, everything is okay, regardless of who owns them. Typically it is the ownership and permissions on the directory that control renaming and deleting files, but your points about file permissions and ownership are all good ones. There are lots of different scenarios that can happen, and almost certainly the way that saving files is changed is going to have drawback in some of the scenarios. If two different users have write access to a file, I can't think of a way to prevent them from saving over each other's changes. I'll hopefully have some code to show this week and having a few people take a look and offer suggestions would be great. If someone could post some pseudo-code for ways they've implemented file saving routines in programs they have written, or routines that they've found to be robust, that would be great too. Maybe a few examples of good examples could be listed as well - possibly people can recommend some KDE, GNOME, or other open source program. 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 Nov 17 21:46:55 2004 From: ahaas at airmail.net (Art Haas) Date: Wed Nov 17 21:47:04 2004 Subject: [PythonCAD] Post nineteenth release plans In-Reply-To: <20041117003318.GA22825@artsapartment.org> References: <20041116152431.GO2993@artsapartment.org> <200411161715.48439.ewilhelm@sbcglobal.net> <20041117003318.GA22825@artsapartment.org> Message-ID: <20041117204655.GD22825@artsapartment.org> On Tue, Nov 16, 2004 at 06:33:18PM -0600, Art Haas wrote: > > I'll hopefully have some code to show this week and having a few people > take a look and offer suggestions would be great. If someone could post > some pseudo-code for ways they've implemented file saving routines in > programs they have written, or routines that they've found to be robust, > that would be great too. Maybe a few examples of good examples could be > listed as well - possibly people can recommend some KDE, GNOME, or other > open source program. > Here's the first shot at how file saving will be done. I'll be modifying the code in the 'gtkmenus.py' file to use this routine: def _save_file(gtkimage, filename): _abs = os.path.abspath(filename) _bname = os.path.basename(_abs) _newfile = _abs + '.new' _handle = fileio.CompFile(_newfile, "w", truename=_bname) try: imageio.new_save_image(gtkimage, _handle) finally: _handle.close() # print "saved new file %s" % _newfile _backup = _abs + '~' if os.path.exists(_backup): # print "removing existing backup %s" % _backup os.unlink(_backup) _mode = None if os.path.exists(_abs): _st = os.stat(_abs) _mode = stat.S_IMODE(_st.st_mode) os.rename(_abs, _backup) # print "renaming existing to backup %s" % _backup try: os.rename(_newfile, _abs) except: os.rename(_abs, _backup) raise # print "renaming new file to filename %s" % _abs if _mode is not None and hasattr(os, 'chmod'): # print "restoring file permissions" os.chmod(_abs, _mode) if gtkimage.getFilename() is None: gtkimage.setFilename(_abs) The file is first saved with '.new' extension, then any existing backup file is removed. If there is currently an existing file, the permissions are saved and the file is renamed to the backup name, then the '.new' file is renamed to the correct name. If there was an existing file found, the permissions are restored to the newly written copy. The code doesn't play nicely with symbolic links or hardlinks. Comments? 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 Nov 19 00:02:30 2004 From: ahaas at airmail.net (Art Haas) Date: Fri Nov 19 00:02:37 2004 Subject: [PythonCAD] File saving code changes now in repo Message-ID: <20041118230230.GC25414@artsapartment.org> Hi. I've added the code the reworks the file saving routines to the repository and sent it out. The routines use the os.rename() function, but I've also written a routine that uses a file reading and writing approach. The rename() approach doesn't work nicely with hardlinks, while the second does ... but the second can mess up files unexpectedly if the written file is a symbolic or hardlinked file. I've used the rename() approach previously, and by default XEmacs does the same, though XEmacs can be changed to use a read/write routine. There are some small code fixes in the repo as well. -- 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 Nov 30 23:31:11 2004 From: ahaas at airmail.net (Art Haas) Date: Tue Nov 30 23:31:16 2004 Subject: [PythonCAD] Python 2.4 now available Message-ID: <20041130223111.GD32281@artsapartment.org> Hi. This is just a heads-up to everyone that Python 2.4 is now available. Any early installers out there should feel free to mail back info about how PythonCAD runs on this release, as I've not tried it yet. Visit the mothership for more info about the latest release ... http://www.python.org 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