Re: Dabo in 30 seconds?
Ed Leafe wrote: > Should we have defensive code for every possible broken installation? We use > a lot of the Python standard library modules, many dbapi-compliant modules, > and, of course, wxPython. If someone mis-installs one of the pre-requisites, > do you expect Dabo to catch that and present you with a diagnostic message? > I'm serious here: I want to know what people consider acceptable for a > software package that relies on other packages. Every possible broken installation != checking for missing dependencies. It can be difficult/cumbersome/result in code bloat to constantly check for module A, feature B enabled in module C, etc. Further, you're certainly going to miss some at first. But as bug reports come in (like this one), add them to a list of checks performed in a checkconfig script. This script can be run at installation and/or by the user when something like this goes wrong. You could also have checkconfig print out useful features about the environment it's running in to help make bug reports better. Building something like this takes time, but every minute spent on it now is 10-20 minutes saved in handling the same old bug report in the future. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to determine that if a folder is empty?
Mike Meyer wrote: > Just out of curiosity, is there an OS out there where you can have the > permissions needed to delete a directory without having the > permissions needed to create it appropriately? Not an OS, but AFS has a wider set of permissions (RLIDWKA - which, if I remember correctly, are read, look, index, delete, write, lock, administrate). -- http://mail.python.org/mailman/listinfo/python-list
Re: python for microcontrollers
Paul Rubin wrote: > I don't think you want to do this. Runtime type tags and the overhead > of checking them on every operation will kill you all by themselves. > Processors like that haven't been used much as Lisp targets either, > for the same reasons. Pick a different language. I was thinking that you could avoid this by adding some type inference to Python and/or reducing everything to two basic types (strings and ints), but the end result would require a lot of work and not look much like Python. For a PIC, I'm not even sure I'd want to use C++. Then again, I'm not much of a fan of BASIC stamp modules, either, so... -- http://mail.python.org/mailman/listinfo/python-list
Re: Using python for a CAD program
baalbek wrote: > CAD systems available today (Autocad, Archicad, Architectural Desktop, > etc) have one huge flaw: they don't store data to a SQL database, but to > binary files. There's a reason for this. Most CAD data is not in a form (First Normal Form) suitable for a relational database. In addition, the sheer number of objects involved in each operation brings performance to its knees. Finally, most RDBMS provide (and are optimized for) transactional semantics -- for a CAD system, this is wasted overhead. People dabbled in this years back but quickly discovered just how different they are. If you have access to it, you should take a peek at the source for the OpenAccess database. Although this is for chips, I suspect some of the same design principles would go into designing a CAD database. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using python for a CAD program
Paddy wrote: > Unfortunately, Cadence got their first with their DFII environment for > Schematic based design and their Lisp based language SKILL Well, SKILL (a Franz Lisp derivative) is very old and has some peculiar design quirks. Interfacing with anything not written by Cadence or not written in SKILL is painful, at best. Interestingly, Python is being used as an extension language for the OpenAccess database. LSI Logic had a Python wrapper for 2.0 (it looked like they used SWIG). I had written one for 2.1, but never was able to release it before my company was acquired by Cadence (and that project quashed). There is some interest... just not quite critical mass. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using python for a CAD program
Terry Hancock wrote: > I disagree that transactions are bad for CAD -- they may have > a different semantic role and the needed granularity may be > different, but the need to roll data back to an earlier revision > is just as present in drawings as it is for code or financial > transactions. Sure, but that's called source control. So you do need transactions, but for the entire database state, not on database operations. (This was certainly true at Cadence -- there was a thriving third-party market for handling source control on CDBA databases, and I never encountered any code which operated on the database in a transactional manner. OpenAccess did have some basic support for transactions, but I never heard of anyone using them.) Some kind of transactionality is needed for undo/redo, but this is usually done in a different (some might say "more efficient", others might say "hackier") method than how transactions are implemented for RDBMS (that I've dealt with, anyway). I suspect this can be attributed to two major factors: concurrent access is never an issue in such systems, and the number of database objects representing a given state is far larger than in, say, e-commerce. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using python for a CAD program
baalbek wrote: > No, concurrent access is highly relevant; for example, on a team of > about 50 architects working on design and production drawings for a new > hospital, each floor was one 'drawing' (dwg file), and thus stored on > disk as a separate entity from the other floors. > > Now, only one architect could work on one floor at any time! And as info > from the project goes (sums and statistics of data, for example areas), > the only reliable (an efficient) way to gather this was to hack an > in-house application that collected the desired info from the various > binary dwgs stored on disk, and saved this data this to a RDBMS, for > further report processing. You have two orthogonal thoughts going here. It makes sense to collect statistics from a given drawing into an RDBMS in such a way that, whenever a design is checked in, the statistics are synched with the RDBMS. Further, such a system could (and should) make sure that no previous checkin has been clobbered. This is a classic source control system. I'd be surprised if there aren't plenty of add-ons which do this. At Cadence, we provided hooks for such systems to automatically collect necessary information. This does not mean the design itself should be stored as an RDBMS. As I've stated previously, CAD data (both electrical and, it appears, mechanical) does not lend itself to RDBMS relationship modeling. What you want is an easy way to manage the information, not dictate the storage format of the information. > And just to work on one small area of a huge floor, the architect has to > load the whole freaking floor... I don't have any architectural experience, so I can't say whether this makes sense or not. However, I think of this as being akin to complaining, "Just to edit a single function, I have to load the entire source file/check out the entire module/rebuild and rerun all the tests!" Not that this is necessarily an invalid idea. However, my experience with Cadence's tools makes me believe the existing behavior might just be the lesser of two evils. CDBA has a strict library/cell/view hierarchy; the checkout granularity here is (usually) at the view level (that is, when you lock a design, you're locking the view). Two designers could edit two different cells or views in the same library. This leads to all kinds of data inconsistency problems -- cell borders aren't lining up in a layout, for example, or the cached data isn't valid, etc. It's a nightmare. The newer OpenAccess system has an option to manage this at the library level. Unfortunately, this is rarely enabled due to backwards compatibility. -- http://mail.python.org/mailman/listinfo/python-list
Re: Using python for a CAD program
baalbek wrote: > David Cuthbert wrote: >> This does not mean the design itself should be stored as an RDBMS. As >> I've stated previously, CAD data (both electrical and, it appears, >> mechanical) does not lend itself to RDBMS relationship modeling. > > I simply do not agree with this. > > A CAD program (like Autocad) is nothing > but an advanced database editor: the program loads data from a binary > file and creates its object (in memory) from the tables that it reads > from the file on the disk. Well, then, good luck with this. Let us know when you've rediscovered that simply structuring data in a table does not make an RDBMS. -- http://mail.python.org/mailman/listinfo/python-list
