You can subscribe to this list here.
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
(52) |
Feb
(19) |
Mar
(27) |
Apr
|
May
|
Jun
(15) |
Jul
(48) |
Aug
|
Sep
|
Oct
(11) |
Nov
(5) |
Dec
|
2013 |
Jan
(4) |
Feb
|
Mar
(19) |
Apr
(8) |
May
(9) |
Jun
|
Jul
(2) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
2014 |
Jan
|
Feb
(14) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(8) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
(118) |
Mar
(62) |
Apr
(2) |
May
(25) |
Jun
(18) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
(12) |
Nov
(13) |
Dec
(11) |
2018 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Sebastian K. <se...@hi...> - 2018-05-03 15:45:13
|
I've just release PyCAM 0.6.3. This is a bugfix release in the 0.6 stable branch - it has some important bug fixes in the DXF file importer and the CXF font importer. Debian packages are available for Jessie, Stretch, and Ubuntu Trusty, from the linuxcnc.org debian archive: deb http://linuxcnc.org/ jessie base deb http://linuxcnc.org/ stretch base deb http://linuxcnc.org/ trusty base -- Sebastian Kuzminsky |
From: Valerio B. <va...@se...> - 2018-01-01 16:31:49
|
On Mon, 2018-01-01 at 07:21 -0800, John (EBo) David wrote: > @Ruslan, maybe we should discuss timing tests. They will take a bit to > implement and track, but I have seen them save a project with the timing > changed due to a propagated bug. Do you have anything you use to > display and track this type of data? But the real question is how much > time does the overall processing take, and is it worth optimizing the > code? a simple way to keep timings is to run this: time python3 pycam/run_cli.py [predefined FLOW_SPEC] this will give times for real,user,sys > Also, when using numpy I typically set things up to do as little mixing > as possible and stick with ndarrays and floats > > On Jan 1 2018 8:07 AM, Ruslan wrote: > > @ebo, as I can see, there are just few unit tests, and I didn't > > noticed any performance metrics there. Yes, the main idea of moving > > towards numpy is because its written in C, however, as mentioned in > > your links, numpy requires additional step to convert python `list` > > to > > numpy `ndarray`, which, actually, should not be a problem. > > > > -- > You are receiving this because you are subscribed to this thread. > Reply to this email directly or view it on GitHub: > https://github.com/SebKuzminsky/pycam/issues/102#issuecomment-354658539 |
From: Reuben R. <si...@em...> - 2017-12-28 01:35:48
|
On 12/27/2017 11:03 AM, Lars Kruse wrote: > Hello, > > a bug report regarding a potential problem with our OpenGL integration that is > currently discussed. Since I have almost no clue regarding OpenGL, I would > appreciate a bit of input from you. > > The issue discussion is here: > > https://github.com/SebKuzminsky/pycam/issues/97 > > Basically it discusses the non-working OpenGL visualization for some users. > The problem appears as a log message from pycam: > > OpenGL.error.GLError: GLError( > err = 1282, > description = b'invalid operation', > baseOperation = glShadeModel, > cArguments = (GL_SMOOTH,) > ) This problem is not unique to Pycam. As far as I can figure out, it is the underlying Python3-OpenGL. I am not sure if Python2-OpenGL is affected or not. > > > Please do the following: > - install dependencies: > apt install python-gi python3-gi python-opengl python3-opengl gir1.2-gtk-3.0 > - checkout the current master > - run "python3 pycam/run_gui.py": > Do you see a 3D visualization? > Do you see the above error message? > - checkout commit 77dd887e17 (the last commit working with Python2) > - run "python pycam/run_gui.py" and "python3 pycam/run_gui.py": > OpenGL visible? Error messages? > - dpkg -l | grep -E "(glut|python3?-opengl|gir1.2-gtk-3.0|libglu?1|gobject)" > > You may post your results here on the mailinglist or in the above bug report. Will do if/when I get the time. > > I am interested in your local experiences! > > Cheers, > Lars > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > PyCAM-devel mailing list > PyC...@li... > https://lists.sourceforge.net/lists/listinfo/pycam-devel > |
From: Lars K. <li...@su...> - 2017-12-27 16:03:44
|
Hello, a bug report regarding a potential problem with our OpenGL integration that is currently discussed. Since I have almost no clue regarding OpenGL, I would appreciate a bit of input from you. The issue discussion is here: https://github.com/SebKuzminsky/pycam/issues/97 Basically it discusses the non-working OpenGL visualization for some users. The problem appears as a log message from pycam: OpenGL.error.GLError: GLError( err = 1282, description = b'invalid operation', baseOperation = glShadeModel, cArguments = (GL_SMOOTH,) ) Please do the following: - install dependencies: apt install python-gi python3-gi python-opengl python3-opengl gir1.2-gtk-3.0 - checkout the current master - run "python3 pycam/run_gui.py": Do you see a 3D visualization? Do you see the above error message? - checkout commit 77dd887e17 (the last commit working with Python2) - run "python pycam/run_gui.py" and "python3 pycam/run_gui.py": OpenGL visible? Error messages? - dpkg -l | grep -E "(glut|python3?-opengl|gir1.2-gtk-3.0|libglu?1|gobject)" You may post your results here on the mailinglist or in the above bug report. I am interested in your local experiences! Cheers, Lars |
From: Lars K. <li...@su...> - 2017-12-23 11:42:10
|
Hello, maybe "new data handling" does not sound too exciting, but in fact it is! :) I just merged a branch that I was working on for the last months. It changes the way pycam handles its data (tools, tasks, ...). Now everything is represented in simple dicts/lists and can easily be imported and exported as yaml. This allows some new ways of using pycam: - write a processing description (in yaml) on your own and run it non-interactively - use the GUI to create and export a processing description (in yaml) and load the same workspace later or simply execute it non-interactively - submit bug reports with your complete workspace setup in order to simplify reproducing problems (I will add embedding of external files (e.g. models) into the workspace settings later) - embed pycam's toolpath generator into external programs (a web application?) Feel free to take a look at the current master and report problems or suggest improvements. I think this new master can be the base of a new release quite soon. I would just like to implement the following details before publishing this release: - handle broken configuration files (e.g. missing model files) gracefully - re-add support for touch-off settings (GCode for tool changes) Documentation of non-interactive usage is currently missing. Maybe someone wants to tackle that? Happy exploring! Cheers, Lars |
From: Lars K. <li...@su...> - 2017-12-16 23:16:51
|
Hello, I am close to merging a long-standing branch, that I am currently working on. It contains around 200 commits and changes many inner details of GTK interface and other related code. Thus if you have pieces of code and merge proposals lying around somewhere hidden in your local repositories, then I would suggest to speak up now and propose their inclusion before I merge my branch. The branch is called "yaml-flow-with-gtk" - just in case anyone is curious ... (beware: I am force-pushing to this branch from time to time) Cheers, Lars |
From: Reuben R. <si...@em...> - 2017-12-16 14:06:00
|
>>> Instead I would like to use some features that are only available python3, >>> e.g. coroutines or something as trivial as "yield from". >> Off-topic: Python3 has some neat features. I wanted to have drop in >> module support for my accounting system and Python3 had support for that >> in a very fluent way. Let's say you have file(s) /file?name?.py class Module: def __init__ (self, my_parameter): variable_one = 1 /in a directory, you have no idea what the file is called, but you want to make it accessible, you would then: /import importlib.util as i_utils// //cwd = os.getcwd()// //module_folder = cwd + "/pycam/modules/"// //files = os.listdir(module_folder)// //menu = self.builder.get_object('menu11')// //for file_ in files:// // if file_.endswith(".py") and file_ != "__init__.py":// // file_name = file_.strip(".py")// // f_path = module_folder+file_// // spec = i_utils.spec_from_file_location(file_name , f_path)// // module = i_utils.module_from_spec(spec)// // spec.loader.exec_module(module)// // file_label = file_name.capitalize()// // file_label = file_label.replace("_", " ") // // menuitem = Gtk.MenuItem.new_with_label(file_label)// // menuitem.connect("activate", module.Module, 'pycam')// // menuitem.show()// // menu.append(menuitem) /I can't find the original place I got this feature, but Google 'dynamic import python3' and you will find tens of links. Or feel free to ask for explanation on anything I missed. This code was a copied and pasted from /https://sourceforge.net/p/pygtk-posting/code/ci/master/tree/src/pygtk_posting.py /line 97 with minor changes for Pycam. / /// > I am interested in this topic: could you give me a reference? > > Cheers, > Lars > |
From: Reuben R. <si...@em...> - 2017-12-16 13:04:11
|
>> I can imagine the following approaches. Please share your opinions, which of >> these approaches you would prefer as the default behaviour of PyCAM. >> >> A) always load hard-coded initial project settings; do not store any changes >> (this was pycam's behaviour up to now) >> B) load project settings from a file at startup and store the final state of >> the projects settings into the same file when exiting (without confirmation) >> C) same as (B) - but ask for confirmation >> D) same as (B) - but store changes continuously (more crash-safe) > > Based on the lack of responses, I assume that the topic was either not well > explained by me or you simply do not deem it to be really important. > Feel free to complain, if it was the former :) For myself, I barely have used Pycam. To reply to this subject might have shown my inexperience. > > Now I picked the approach based on my own habits, which are reflected by > option (C) from above. Thus settings will be handled like this: > - always load the project settings from the same file > - ask on exit if changes should be saved to that file > (optional: "remember this choice forever") > > This allows pycam to be usable with a persistent session state (tools, > processes, ...) if the user confirms this behaviour. This is what I would have picked for myself. > > Cheers, > Lars |
From: Lars K. <li...@su...> - 2017-12-16 12:36:39
|
Hello, Am Wed, 22 Nov 2017 00:50:48 +0100 schrieb Lars Kruse <li...@su...>: > But I am not sure, how I should handle (by default) the changes of > project settings that happen during an interactive (GUI) session. > > I can imagine the following approaches. Please share your opinions, which of > these approaches you would prefer as the default behaviour of PyCAM. > > A) always load hard-coded initial project settings; do not store any changes > (this was pycam's behaviour up to now) > B) load project settings from a file at startup and store the final state of > the projects settings into the same file when exiting (without confirmation) > C) same as (B) - but ask for confirmation > D) same as (B) - but store changes continuously (more crash-safe) Based on the lack of responses, I assume that the topic was either not well explained by me or you simply do not deem it to be really important. Feel free to complain, if it was the former :) Now I picked the approach based on my own habits, which are reflected by option (C) from above. Thus settings will be handled like this: - always load the project settings from the same file - ask on exit if changes should be saved to that file (optional: "remember this choice forever") This allows pycam to be usable with a persistent session state (tools, processes, ...) if the user confirms this behaviour. Cheers, Lars |
From: Lars K. <li...@su...> - 2017-12-16 12:27:22
|
Hello, Am Sun, 26 Nov 2017 03:32:38 +0100 schrieb Lars Kruse <li...@su...>: > Thus I would like to get rid of Python2 compatibility. I am glad, that there seem to be no objections - thus I will remove references to python2 and compatibility fixes in the near future. Cheers, Lars |
From: Lars K. <li...@su...> - 2017-12-16 12:21:33
|
Hello Reuben, Am Sat, 25 Nov 2017 23:01:20 -0500 schrieb Reuben Rissler <si...@em...>: > > Instead I would like to use some features that are only available python3, > > e.g. coroutines or something as trivial as "yield from". > > Off-topic: Python3 has some neat features. I wanted to have drop in > module support for my accounting system and Python3 had support for that > in a very fluent way. I am interested in this topic: could you give me a reference? Cheers, Lars |
From: Lars K. <li...@su...> - 2017-12-13 22:21:32
|
Hello, Am Tue, 12 Dec 2017 22:25:42 -0500 schrieb ad...@mm...: > I downloaded Pycam and it it seems like a nice CAM solution for me. > > Unfortunately when I want to export to GCODE it only has an EMC tools > option that is blank and contains nothing. this sounds weird. Could you please describe, which version of pycam you use and which part of the interface contains this export option, that you did not expect? > Pycam seemingly rely on tools from EMC to converto Gcode. Pycam exports toolpaths as GCode, that can be used by any machining software. Did you already create a toolpath? Is it visible in the 3D preview? Did you enter the "Toolpaths" tab, select the interesting toolpath(s) and click on "export" below? Cheers, Lars |
From: <ad...@mm...> - 2017-12-13 04:03:49
|
I downloaded Pycam and it it seems like a nice CAM solution for me. Unfortunately when I want to export to GCODE it only has an EMC tools option that is blank and contains nothing. Pycam seemingly rely on tools from EMC to converto Gcode. I tried to install all the EMC software on my Debian distribution, but unfortunately there is no functionality after that. How do you people using Pycam export to GCODE using EMC? Thanks |
From: Chris A. <alb...@gm...> - 2017-11-26 04:31:33
|
The below really is the best way to solve this. If anyone really needs to run using Python 2 then you already have a solution for that. They can run the current version of pycam. What this means is you have to keep this version archived and promise to fix "show stopper" bugs until 2020. But in reality all you have to so is keep the current pycam available. >> 1) Are you aware of an environment where Python3 or GTK3 for Python3 or >> OpenGL >> for Python3 is not available? > > IMO, if you have an environment that has no Python3.x support, you probably > won't be running a new version of Pycam either. -- Chris Albertson Redondo Beach, California |
From: Reuben R. <si...@em...> - 2017-11-26 04:01:27
|
On 11/25/2017 09:32 PM, Lars Kruse wrote: > Hello, > > pycam just went through the following migrations in the last month: > - compatibility with python2 -> python2 and python3 > - GTK2 -> GTK3 > - GtkGLext -> GTK.GLArea > > I am already using only Python3 when working on pycam - there should be > no issues at all. > > Thus I would like to get rid of Python2 compatibility. Support for > Python2 will end in 2020 anyway. Hmmm... I didn't know that before. > > Instead I would like to use some features that are only available python3, > e.g. coroutines or something as trivial as "yield from". Off-topic: Python3 has some neat features. I wanted to have drop in module support for my accounting system and Python3 had support for that in a very fluent way. > > Thus I am curious: > 1) Are you aware of an environment where Python3 or GTK3 for Python3 or OpenGL > for Python3 is not available? IMO, if you have an environment that has no Python3.x support, you probably won't be running a new version of Pycam either. All that is needed to run GTK3 with Python3 are these dependencies (and sub-dependencies of course): python3-gi gir1.2-gtk-3.0 These two come preinstalled on any newer sane Linux distro. For OpenGL and Python3 you need: python3-opengl As usual, available in your software installer. In the end, the biggest problem is going to be that old hardware will not be supported by GtkGLArea. But that is a longstanding problem and not really the fault of GtkGLArea or Python3 or ... Also note GtkGLArea was not available until Gtk3.16 with fallback support (for some old hardware) added in Gtk3.22. > 2) Are you aware of an environment with Python3 before 3.5? > Ubuntu LTS 14.04 contains Python 3.4 > How about MacOS? > > Cheers, > Lars > |
From: Lars K. <li...@su...> - 2017-11-26 02:32:50
|
Hello, pycam just went through the following migrations in the last month: - compatibility with python2 -> python2 and python3 - GTK2 -> GTK3 - GtkGLext -> GTK.GLArea I am already using only Python3 when working on pycam - there should be no issues at all. Thus I would like to get rid of Python2 compatibility. Support for Python2 will end in 2020 anyway. Instead I would like to use some features that are only available python3, e.g. coroutines or something as trivial as "yield from". Thus I am curious: 1) Are you aware of an environment where Python3 or GTK3 for Python3 or OpenGL for Python3 is not available? 2) Are you aware of an environment with Python3 before 3.5? Ubuntu LTS 14.04 contains Python 3.4 How about MacOS? Cheers, Lars |
From: Lars K. <li...@su...> - 2017-11-25 17:41:23
|
Hello Reuben, early bird catch all in the interesting things! Am Sat, 25 Nov 2017 10:44:54 -0500 schrieb Reuben Rissler <si...@em...>: > Another dependency problem with Pycam: > > [..] Now I improved the warning messages (on stdout) and the error message in the GTK dialog in order to point at the solution (install the package ...). > Which means python-opengl is not installed (in my case). Furthermore, in > pycam/Plugins/__init__.py line 73-74: > > except ImportError: > pass > > should this not be something like: > > except ImportError as e: > print "%s, try installing python-opengl" % e You are right - I omitted a comment or a message, how this situation is handled. This is better now. Cheers, Lars |
From: Lars K. <li...@su...> - 2017-11-25 17:36:18
|
Hello Reuben, Am Sat, 25 Nov 2017 10:15:28 -0500 schrieb Reuben Rissler <si...@em...>: > While trying to run master, I got this error, which turns out to be > that I didn't have Git installed. bad! Now I fixed the exception handling there - thus you can safely use pycam without git. Cheers, Lars |
From: Reuben R. <si...@em...> - 2017-11-25 15:45:07
|
Another dependency problem with Pycam: /Enabled 4 parallel local processes// //Failed to initialize the interactive 3D model view.// //Failed to setup plugin 'OpenGLWindow'// //Font directory: /home/reuben/exec/pycam-master/share/fonts// //Skipping plugin 'OpenGLViewToolpath' due to missing dependencies: OpenGLWindow// //Skipping plugin 'OpenGLViewBounds' due to missing dependencies: OpenGLWindow// //Skipping plugin 'OpenGLViewModel' due to missing dependencies: OpenGLWindow// //*** skipped 2 similar message(s) ***// //Skipping plugin 'ToolpathSimulation' due to missing dependencies: OpenGLViewToolpath// //Skipping plugin 'OpenGLViewAxes' due to missing dependencies: OpenGLWindow// //Skipping plugin 'OpenGLViewGrid' due to missing dependencies: OpenGLWindow// //Skipping plugin 'OpenGLViewDimension' due to missing dependencies: OpenGLWindow// //Skipping plugin 'OpenGLViewTool' due to missing dependencies: OpenGLWindow// //Skipping plugin 'OpenGLViewSupportModelPreview' due to missing dependencies: OpenGLWindow, OpenGLViewModel/ Which means python-opengl is not installed (in my case). Furthermore, in pycam/Plugins/__init__.py line 73-74: except ImportError: pass should this not be something like: except ImportError as e: print "%s, try installing python-opengl" % e \scold, scold Reuben |
From: Reuben R. <si...@em...> - 2017-11-25 15:15:29
|
While trying to run master, I got this error, which turns out to be that I didn't have Git installed. /Traceback (most recent call last):// // File "pycam/run_gui.py", line 49, in <module>// // from pycam import VERSION// // File "/home/reuben/exec/pycam-master/pycam/__init__.py", line 53, in <module>// // cwd=repo_dir, stderr=subprocess.PIPE)// // File "/usr/lib/python2.7/subprocess.py", line 567, in check_output// // process = Popen(stdout=PIPE, *popenargs, **kwargs)// // File "/usr/lib/python2.7/subprocess.py", line 711, in __init__// // errread, errwrite)// // File "/usr/lib/python2.7/subprocess.py", line 1340, in _execute_child// // raise child_exception// //OSError: [Errno 2] No such file or directory/ The file INSTALL.md does not list Git as a dependency. Sorry, I would fix it myself, but I just didn't get to learn Git good enough yet :( Reuben |
From: Reuben R. <si...@em...> - 2017-11-25 13:26:29
|
On 11/24/2017 10:39 PM, Lars Kruse wrote: > Hello, > > after giving this topic quite some time to rest, I made another attempt. > This time it worked out: the OpenGL visualization is working again > (now with Python3 and GTK3). Cheers and Kudos ! > Thanks to Reuben for giving it a good start. > > I was very surprised to see, that all the crude OpenGL commands, that > pycam collected over the years, can still be used without relevant > changes. Only the event handling needed a bit of adjustmensts (for the > better: I could remove a few pieces of code). I fully expected GtkGLArea to be better, but had no way of proving it. If there is one thing in favor of Gtk, it is the fact that they always improve things. Some people say they /break /things, but I choose to look at it that if you always keep on supporting old cruft, eventually you get into a stalemate. (consider X11) I was also pretty sure that it won't take a lot to get the visualizer going. However, I got bogged down by the big picture and wasn't sure what went where and how to hook up the relevant pieces of code. As a sidenote, I had spewed a bit about the deep complex hierarchy of the Gtk part of Pycam. My apologies. Since I have more programming experience in my Python app, I have discovered why Pycam is set up the way it is. > > If anyone wants to test it: feel free to checkout the master branch. Will do. I have a benchtop CNC router now. Yeah! And I need to punch some holes in plastic. > > I am specifically interested in reports from Mac users. With the old > GTK2 interface they hard a hard time to install all dependencies. I > hope this went better. > > Cheers, > Lars > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > PyCAM-devel mailing list > PyC...@li... > https://lists.sourceforge.net/lists/listinfo/pycam-devel > |
From: Lars K. <li...@su...> - 2017-11-25 03:53:00
|
Hello, after giving this topic quite some time to rest, I made another attempt. This time it worked out: the OpenGL visualization is working again (now with Python3 and GTK3). Thanks to Reuben for giving it a good start. I was very surprised to see, that all the crude OpenGL commands, that pycam collected over the years, can still be used without relevant changes. Only the event handling needed a bit of adjustmensts (for the better: I could remove a few pieces of code). If anyone wants to test it: feel free to checkout the master branch. I am specifically interested in reports from Mac users. With the old GTK2 interface they hard a hard time to install all dependencies. I hope this went better. Cheers, Lars |
From: Lars K. <li...@su...> - 2017-11-21 23:51:02
|
Hello, I am close to finishing the new processing and data handling internals. Thus it is possible (at least with my branch "yaml-flow-with-gtk") to load/save the project settings (models, tools, processes, bounds, tasks) from/to a yaml file. As a nifty side-effect you will be able to repeat your toolpath generator run at a later time even on an updated model file without going through the toolpath setup again. You can even script your toolpath generation (non-interactively). But I am not sure, how I should handle (by default) the changes of project settings that happen during an interactive (GUI) session. I can imagine the following approaches. Please share your opinions, which of these approaches you would prefer as the default behaviour of PyCAM. A) always load hard-coded initial project settings; do not store any changes (this was pycam's behaviour up to now) B) load project settings from a file at startup and store the final state of the projects settings into the same file when exiting (without confirmation) C) same as (B) - but ask for confirmation D) same as (B) - but store changes continuously (more crash-safe) Or do you have other ideas? Cheers, Lars |
From: Lars K. <li...@su...> - 2017-11-21 23:34:08
|
Hello Reuben, Am Sat, 11 Nov 2017 15:00:31 -0500 schrieb Reuben Rissler <si...@em...>: > > Additionally the changeset could affect users of the windows > > packaging (based on setuptools). > For better or worse? I cannot tell :( Seven years ago I added the file scripts/pycam_win32_postinstall.py as a post installation hook to the setup.py. The script basically creates a start menu link for pycam. The way it was integretad into setup.py seemed to have been obsoleted. Additionally I would assume, that the new setuptools "entry_points" do the start menu stuff on their own. But I cannot tell, since I do not have access to Windows machines. > Further, does anyone use the Windows version of Pycam? No one answered: probably not ... Cheers, Lars |
From: Reuben R. <si...@em...> - 2017-11-11 20:00:53
|
On 11/11/2017 11:53 AM, Lars Kruse wrote: > This changeset will rename the start script from "scripts/pycam" to > "pycam/run_gui.py", since the "entry_point" will need to reside within > the package hierarchy. > > Additionally the changeset could affect users of the windows packaging > (based on setuptools). For better or worse? Further, does anyone use the Windows version of Pycam? Reuben |