From ahaas at airmail.net Tue Feb 1 19:13:29 2005 From: ahaas at airmail.net (Art Haas) Date: Tue Feb 1 19:13:35 2005 Subject: [PythonCAD] Plans for next release Message-ID: <20050201181329.GG2291@artsapartment.org> Hi. As release 22 is now out, it is time to start work on the next release. Unlike in the past there is no one place in the code that I want to concentrate work on. Fixing bugs is, as always, part of the work, but beyond that I'm not certain on what area to concentrate development efforts. Lots of different bits in the code can use attention, so my puzzle of the moment is to decide on which way to go. The next month will be hectic for me with regards to things in the real world, so there will be numerous periods of inactivity. Things should settle down by the middle of March, but I'd still like to get a release of some sorts out at the end of this month. 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 dturvene at comcast.net Thu Feb 3 06:56:14 2005 From: dturvene at comcast.net (David Turvene) Date: Thu Feb 3 07:56:31 2005 Subject: [PythonCAD] Comments, bug report Message-ID: <4201BCFE.1090108@comcast.net> I recently loaded PythonCad v22 and am really pleased with it. It's powerful and easy to use. I especially like the rich set of customizations (however, see the bugfix below). Thanks! Dave Thoughts (probably all very familiar) 1) I'm having a hard time adjusting the dimension values to anything "real-world". It appears the values come directly from the pixel offset from the screen edge. One idea is to put a customizable scaling factor in the various dimension calculate() methods. 2) I saw an email train about construction lines being offset from a reference con line but I had a hard time figuring out how to make them the same precise distance. I ended up laying out a number of lines then hand-editting in the XML file to be an exact offset. 3) Add a call stack trace to exception handling code - see the DumpException call below. In fact thoughts #1 and #2 could be two parts to a general scaling calculation design. For example: describe how many con lines to fill the screen and the "real world" distance between them. That becomes your scaling factor. If you zoom out, you will need to add more con lines; call the same function but the scaling factor is immutable (or at least should be hard to change.) Bug: When I took some examples from the default prefs.py file into my local one, I got an type exception. Here's the patch I did to fix it. --- /opt/PythonCAD-DS1-R22/PythonCAD/Generic/preferences.py 2004-11-17 11:58:36.000000000 -0500 +++ /usr/lib/python2.3/site-packages/PythonCAD/Generic/preferences.py 2005-02-03 00:44:24.455793872 -0500 @@ -957,7 +957,16 @@ def _set_textstyles(prefmod): continue _r, _g, _b = _color.getColors() _color = color.get_color(_r, _g, _b) - _textstyle = text.TextStyle(_name, _family, _size, _style, _weight, _color) + + ## 050201:DST - fixed call to TextStyle class + ## _textstyle = text.TextStyle(_name, _family, _size, _style, _weight, _color) + _textstyle = text.TextStyle(_name, + family=_family, + size=_size, + style=_style, + weight=_weight, + color=_color) + if _textstyle not in _textstyles: _textstyles.append(_textstyle) else: @@ -1141,5 +1150,7 @@ variable being set to True. if hasattr(_mod, _key): _prefkeys[_key](_mod) _set_defaults(_mod) - except: # should print the error out - sys.stderr.write("Syntax error in %s\n" % _user_prefs) + except: + from UtilsLocal import DumpException + DumpException('Syntax error in %s\n' % _user_prefs) + From john_g at cibolo.com Sat Feb 5 18:41:06 2005 From: john_g at cibolo.com (John Griessen) Date: Sat Feb 5 18:41:13 2005 Subject: [PythonCAD] use of select function in pythoncad svn revision 1685 ( today's) Message-ID: <42050532.9030001@cibolo.com> Hi, I try select in advance of any other commands and get no results, but when left to be done during a modify->stretch, select by bounding box works fine. Is edit->select intended to be used before modify or edit commands ever? If no such path to using it is intended now, would you please point me to the places in the code where bounding box or item by item select is implemented, and I will try adding such a feature. John Griessen From ahaas at airmail.net Thu Feb 10 00:42:40 2005 From: ahaas at airmail.net (Art Haas) Date: Thu Feb 10 00:42:48 2005 Subject: [PythonCAD] Anyone have experience with the parser module? Message-ID: <20050209234240.GB4932@artsapartment.org> Hi. I've been busy with non-computer related things lately, so there has been very little PythonCAD development activity of late. I removed some unused code here and there and a few routines that were scheduled to disappear, but not much new code has appeared lately. While thinking about what parts of PythonCAD to work on, I began to re-examine the handling of the commands, and in general how text from the entry box at the bottom of the screen, is dealt with. Right now, when text entry can provide data for a tool the usual way to handle this is via eval(). That's all fine and good, but in view of the goal of making the program scriptable this approach is too simplistic. A bit of reading and tinkering with the 'exec' keyword demonstrated how it would easy to add the ability to store variables and procedures on a per-image basis. The key is storing in each image a dictionary that 'exec' can populate with variables, functions, etc., as well as use previous stored values. The syntax seems a bit odd though: exec cmd in gdict, ldict The variable 'cmd' above would be the text taken from the entry box, and 'gdict' is a dictionary containing the global variables used for variable lookup and storage, and 'ldict' is a dictionary for the same purpose but with a local variable scope. So, if 'cmd' looked like a = 7 Then the command above would store the variable 'a' with a value of 7 in the 'gdict' dictionary. This variable could then be used in an eval() statement eval('a', gdict) This should return '7'. If the 'gdict' argument is not supplied, then the eval() examines the globals variables defined in the context where the eval() was called, so if there is no 'a' variable defined an error is raised. The difficulty I've encountered is that I want to make processing of the entry box text very flexible, so sometimes I need to call 'exec' and other times eval(), and I haven't found a good way to accomplish this. I've started looking at the parser module in an effort to provide this flexibility as it appears to return a parse tree than can be examined prior to executing the tree contents. I'm not familiar with the parser module, though, so there are certainly some subtleties when using it that someone having done so would know. Anyone fitting that description out there and be willing to answer some questions? 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 pachi at mmn-arquitectos.com Thu Feb 10 15:45:14 2005 From: pachi at mmn-arquitectos.com (Rafael Villar Burke) Date: Thu Feb 10 15:45:20 2005 Subject: [PythonCAD] Anyone have experience with the parser module? In-Reply-To: <20050209234240.GB4932@artsapartment.org> References: <20050209234240.GB4932@artsapartment.org> Message-ID: <420B737A.6010102@mmn-arquitectos.com> Art Haas wrote: >Hi. > >I've been busy with non-computer related things lately, so there has >been very little PythonCAD development activity of late. I removed some >unused code here and there and a few routines that were scheduled to >disappear, but not much new code has appeared lately. > >While thinking about what parts of PythonCAD to work on, I began to >re-examine the handling of the commands, and in general how text from >the entry box at the bottom of the screen, is dealt with. Right now, >when text entry can provide data for a tool the usual way to handle this >is via eval(). That's all fine and good, but in view of the goal of >making the program scriptable this approach is too simplistic. A bit of >reading and tinkering with the 'exec' keyword demonstrated how it would >easy to add the ability to store variables and procedures on a per-image >basis. The key is storing in each image a dictionary that 'exec' can >populate with variables, functions, etc., as well as use previous stored >values. The syntax seems a bit odd though: > > Hi, Well... I don't have experience with parser, but thinking about the commands entry it reminded me this: Have you had a look at gazpacho [1]?. It's a pygtk app that uses a CommandManager class and a Command class that wrap "commands and arguments" and execute them. It also manages undo and redo work. The best point is that it may be safer than doing eval, as you don't allow your program do anything directly. You could take a command and do dispatching using a dict that has a key as command and a descriptor to the right Command.run(command_variables) to use. Just an idea. Hope it helps. :) [1] http://gruppy.sicem.biz/componentes From ahaas at airmail.net Thu Feb 10 15:59:53 2005 From: ahaas at airmail.net (Art Haas) Date: Thu Feb 10 15:59:58 2005 Subject: [PythonCAD] Anyone have experience with the parser module? In-Reply-To: <420B737A.6010102@mmn-arquitectos.com> References: <20050209234240.GB4932@artsapartment.org> <420B737A.6010102@mmn-arquitectos.com> Message-ID: <20050210145953.GC2387@artsapartment.org> On Thu, Feb 10, 2005 at 03:45:14PM +0100, Rafael Villar Burke wrote: > Art Haas wrote: > > >Hi. > > > >I've been busy with non-computer related things lately, so there has > >been very little PythonCAD development activity of late. I removed some > >unused code here and there and a few routines that were scheduled to > >disappear, but not much new code has appeared lately. > > > >While thinking about what parts of PythonCAD to work on, I began to > >re-examine the handling of the commands, and in general how text from > >the entry box at the bottom of the screen, is dealt with. Right now, > >when text entry can provide data for a tool the usual way to handle this > >is via eval(). That's all fine and good, but in view of the goal of > >making the program scriptable this approach is too simplistic. A bit of > >reading and tinkering with the 'exec' keyword demonstrated how it would > >easy to add the ability to store variables and procedures on a per-image > >basis. The key is storing in each image a dictionary that 'exec' can > >populate with variables, functions, etc., as well as use previous stored > >values. The syntax seems a bit odd though: > > > > > Hi, > Well... I don't have experience with parser, but thinking about the > commands entry it reminded me this: > Have you had a look at gazpacho [1]?. It's a pygtk app that uses a > CommandManager class and a Command class that wrap "commands and > arguments" and execute them. It also manages undo and redo work. > The best point is that it may be safer than doing eval, as you don't > allow your program do anything directly. You could take a command and do > dispatching using a dict that has a key as command and a descriptor to > the right Command.run(command_variables) to use. > > Just an idea. Hope it helps. :) > > [1] http://gruppy.sicem.biz/componentes I've not looked at gazpacho, but the approach they use sounds like something I would be interested in. Thanks for the tip. 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 richley at onion-switch.com Sat Feb 19 16:24:11 2005 From: richley at onion-switch.com (Ed Richley) Date: Sat Feb 19 16:24:17 2005 Subject: [PythonCAD] printing Message-ID: <200502191524.j1JFOCXR001352@localhost.localdomain> Some comments on the latest version: 1) It seems that "Print" doesn't do anything. Maybe a default printer needs to be set? 2) "Print Screen" works, but... - It defaults to a0 paper, which produces output that gv can't display - When you change to "letter" paper, it works OK, but the settings aren't sticky; you have to change paper size every time you print. And the orientation and b&w settings must be set every time, too. 3) Dimension lines seem to come out the same size as the drawing lines. This makes for an ugly drawing when done in b&w. It's usable, but finer dim lines (with arrows) would be really cool. Just some comments as I do a drawing to take someplace to actually have parts made :-). Ed Richley From ahaas at airmail.net Thu Feb 24 13:14:33 2005 From: ahaas at airmail.net (Art Haas) Date: Thu Feb 24 13:16:26 2005 Subject: [PythonCAD] Repo updates Message-ID: <20050224121433.GB3135@artsapartment.org> Hi. I've sent to the repository my latest batch of changes. The biggest changes deal with handling the text that can be entered in the entry box at the bottom of the screen. I've added a simple 'exec' statement to process the text, and the entry-event handlers of the various tools have been adjusted slightly to use a more clever form of eval(). What all these changes permit are a much higher degree of scriptability in the program. For example, when you start the program the prompt at the bottom of the screen reads Enter command: You can now enter the something like the following: a = 10; b = 20; c = 30 The program will then store the variable 'a' with the value 10, 'b' with 20, and 'c' with 30. Now, if you are doing an operation where you can enter a value in the entry box, you can use 'a', 'b', or 'c' as values in the expression. In addition to simple variable assignments, you can enter pretty much any valid Python expression. If 'exec' has a problem parsing and executing what you've typed an exception is raised and an error printed out. What makes this neat is that you can type something like the following in the entry box ... execfile("/path/to/some/file.py") ... and the contents of the file will be executed. The file must be valid Python code, naturally. Using the execfile() command you can type all your code into a file and load it in one fell swoop as opposed to entering it directly. The ability to execute code on the fly like this means you want to be careful about calling execfile() on unknown files. If you were running an interactive Python session and did an execfile() you would have the same potential for trouble if the file contains mischevious code. I still think that the long term goal will be to utilize the 'parser' module, but for now the addition of 'exec' and the enhanced eval() are good first steps. Another change now in the code is the replacement of 'gtk.TRUE' with 'True' and 'gtk.FALSE' with 'False'. The latest PyGTK release deprecates the gtk constants, so I'm being proactive in replacing them now. Even though I'm running an older (2.4) PyGTK release things appear to work without problem. As there has been relatively few changes to the code over the last couple of weeks, there will not be a new release made this month. My non-computer life is hectic now and will be for the next couple of weeks. I suspect the next release will occur near the end of March. 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 noel at peralex.com Thu Feb 24 14:32:31 2005 From: noel at peralex.com (Noel Grandin) Date: Thu Feb 24 14:32:39 2005 Subject: [PythonCAD] hatching Message-ID: <421DD76F.7020003@peralex.com> Hi I was bored, so I did some research on hatching. Basic pixel filling: http://www.cs.unc.edu/~mcmillan/comp136/Lecture8/areaFills.html http://www.codeproject.com/gdi/QuickFill.asp Vector filling: http://www.cs.umass.edu/~verts/cs32/polyfill.html http://www.cs.drexel.edu/~david/Classes/CS430/Lectures/L-05_Polygons.6.pdf http://www.xs4all.nl/~kholwerd/algdoc/filling/filling.html http://www.acm.org/tog/GraphicsGems/gems/ConcaveScan.c http://www.acm.org/tog/GraphicsGems/gems/PolyScan/ Keywords: Scan-line polygon fill algorithm, floodfill and boundary fill algorithms Cheers, Noel Grandin NOTICE: Please note that this email, and the contents thereof, are subject to the standard Peralex email disclaimer, which may be found at: http://www.peralex.com/disclaimer.html If you cannot access the disclaimer through the URL attached and you wish to receive a copy thereof please send an email to email@peralex.com