Send Pythonocc-users mailing list submissions to
pythonocc-users@gna.org
To subscribe or unsubscribe via the World Wide Web, visit
https://mail.gna.org/listinfo/pythonocc-users
or, via email, send a message with subject or body 'help' to
pythonocc-users-requ...@gna.org
You can reach the person managing the list at
pythonocc-users-ow...@gna.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Pythonocc-users digest..."
Today's Topics:
1. Re: Pythonocc-users Digest, Vol 25, Issue 37 (Petar)
2. Re: Re : Anyone seen this? (Dave Cowden) ( Henrik Rudstr?m )
----------------------------------------------------------------------
Message: 1
Date: Mon, 03 Jan 2011 14:32:36 +0100
From: Petar <petar.peri...@cadcam.hr>
Subject: Re: [Pythonocc-users] Pythonocc-users Digest, Vol 25, Issue
37
To: pythonocc-users@gna.org
Message-ID: <4d21cff4.2010...@cadcam.hr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 30.12.2010. 22:15, pythonocc-users-requ...@gna.org wrote:
Send Pythonocc-users mailing list submissions to
pythonocc-users@gna.org
To subscribe or unsubscribe via the World Wide Web, visit
https://mail.gna.org/listinfo/pythonocc-users
or, via email, send a message with subject or body 'help' to
pythonocc-users-requ...@gna.org
You can reach the person managing the list at
pythonocc-users-ow...@gna.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Pythonocc-users digest..."
Today's Topics:
1. Re: writing OCC data to a db (Thomas Paviot)
2. Re: STEP with Colors export how to (petar perisin) (jelle feringa)
----------------------------------------------------------------------
Message: 1
Date: Thu, 30 Dec 2010 17:22:42 +0100
From: Thomas Paviot<tpav...@gmail.com>
Subject: Re: [Pythonocc-users] writing OCC data to a db
To: "pythonOCC users mailing list."<pythonocc-users@gna.org>
Message-ID:
<aanlktinorserb_qld8xrtianekcvu904uzzvebdou...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Dave,
Very interesting post.
Last year, I thought about a kind of 'modular' application built on top of
pythonOCC. The idea was to develop a core of basic functions/classes
extensible with user defined modules (or plugins) made available over the
internet. The module dependency is clearly an issue, and I identified the
Enthought Envisage Framework (http://code.enthought.com/projects/envisage/)
as a good solution to manage the dependencies, as well as input/outputs of
the modules. Two of my students worked on this idea to check whether or not
it was feasible. Unfortunately, they didn't go as far as expected and I
still don't have the answer.
Regarding the STEP standard, there is not any real 'interface' as we usually
understand it. STEP is mostly 'data centric' and there is still clearly a
lack of API on top of it to create/remove/manage entity instances. I would
like the pythonOCC High Level API to be as close as possible to the STEP
semantics (for the geometric part), which would not be difficult to achieve
since the OCC data model is very similar to STEP (edges, vertices, axis
placements etc.). As a consequence, this HLA could be a contribution to the
STEP community as an attempt to build an API over STEP. I'm convinced that,
if we get through this HLA issue while staying tangent to the STEP
AP203(ed.2), our work could become widely adopted around the CAD community.
At last, you talk about a 'tree of entities' in a STEP file. I'm not sure
that the topology of the relationship/instances is isomorphic to a tree
graph.
Thomas
2010/12/30 Cowdens<dave.cow...@gmail.com>
Hi, guys,
I am thinking about the method-centric approach.
In earlier discussions, it was noted ( and i think agreed by most ) that
the steps to create a particular object could be arbitrarily complex. I
think the only method-centric format that will not result in loss of
generality will be python code. ( Unless of course the file is a wrapper
with some header information and a python code additionally ).
It would be conceivable to store objects as a python script that creates
the object without loss of generality, but I think there are several
challenges with this:
- Performance would become a problem in larger models. i think there
is a real need in cad systems for 'opaque' objects-- ones you can include
and interact with, but cannot afford to rebuild every time. Examples would
be an assembly with 1000 or so nuts and bolts
- Dependency management comes into play. since python is a programming
language that can import dependencies,a script to create an object might
import libraries unavailable on another platform, or might use a different
version of python, etc. If a python script is the serialization
format,these dependencies must be considered.
- the interface is not well defined. If a object is in a set format,
for example STEP, the format defines a very specific 'interface'. in the
case of step, a single step file contains a tree of entities that exist in a
well defined structure and notation. the format defines how to infer this
structure to learn what objects are in the file. A python script, though,
could produce an arbitrary number of objects in an arbitrary strcture, and
may not do it in a standard way. So, if a python script were used, it would
need to export well-defined functions that allow a caller to get this
information.
Most of these challenges can be solved. Interestingly, I believe that
following the 'module-based' will result in cad models handled much the same
way as programming projects are. You wouldnt need a new type of repository,
you could just use svn becuse you just need to store source code.
assemblies are just python projects that import a bunch of python libraries
from others ( which happen to produce objects ). The biggest challenges,
too will be those programming projects face-- namely, dependency
management.
I suspect we would end up needing to have a way for each 'module' to
describe not only what objects it exports, but also a way to enumerate its
dependencies both in terms of runtime ( eg python libraries and such ) as
well as other objects it is dependent on ( eg, others it has aggregated )
the apache maven project impements a very similar model for java code by
using a pom.xml file ( project object model) that allows a java project to
declare this type of information. Then, maven assembles the project by
automatically finding and resolving all of the dependencies ( including
transitive ones ) from repositories storing the dependencies
------------------------------
*From:* pythonocc-users-boun...@gna.org [mailto:
pythonocc-users-boun...@gna.org] *On Behalf Of *Thomas Paviot
*Sent:* Thursday, December 30, 2010 4:00 AM
*To:* jelleferi...@gmail.com; pythonOCC users mailing list.
*Subject:* Re: [Pythonocc-users] writing OCC data to a db
Hi Jelle,
Interesting topic, this going to be a long thread!
The use of a python ORM is also the choice I would have done. In my mind,
there are two ways to model such a database:
- a "data centric" db: you store the result of the different operations you
ran (for instance a Point and a Cube);
- a "method centric" db: you store the functions that you called and the
parameters passed (for instance "create_point, 10,10,10" and "make_cube,
20,30,40").
For the data centric method, the db size will be more important than the
second solution. For each object, I would only create a key and a "STRING"
field in which I would store the output of the serialization of the python
object (with the pickle module).
The second method require less size but more computing time (since the
different operations has to be computed each time you load the model).
I have the feeling that this discussion is very close to the thread related
to data model of the High Level API. That's something that could be an
additional constraint of the HLA: "All pythonOCC HLA objects must be
serializable to an XML file in order to be exchanged/shared through a
network or stored to a database".
Cheers,
Thomas
2010/12/29 jelle feringa<jelleferi...@gmail.com>
Hi,
Recently I had enough of storing OCC's cad as files.
Sometimes all you need is a database.
Turns out that its really easy to do so. Perhaps its worth sharing how
this can be done...
Though this might be pretty trivial technically speaking, it can open up
interesting ways of collaborating on projects.
-jelle
================================================
from OCC.Utils.Topology import Topo
__author__ = 'jdf'
from sqlalchemy import *
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.orm import sessionmaker, scoped_session
from OCC.Utils.Construct import make_cube
#from OCC.TopoDS import TopoDS_Shape
#
#TopoDS_Shape.__eq__ = lambda x: TopoDS_Shape.IsEqual(x)
cube = make_cube(1,1,1)
engine = create_engine('sqlite:///jelle.db')
Base = declarative_base(bind=engine)
Session = scoped_session(sessionmaker(engine))
def comp_brep(brepA, brepB):
import ipdb; ipdb.set_trace()
print 'jajajaj',brepB, brepA
return brepA.IsEqual(brepB)
class Individual(Base):
'''used to store data about an individual
a row forms a generation
'''
__tablename__ = 'individual'
id = Column(Integer, primary_key=True)
#name = Column(String)
#fullname = Column(String)
#password = Column(String)
generation = Column(Integer)
ancestor_a = Column(PickleType())
ancestor_b = Column(PickleType())
brep = Column(PickleType(mutable=False)) #comparator=comp_brep)) #) )
fitness = Column(Float)
Base.metadata.create_all()
indy = Individual()
indy.ancestor_a = 'parent_a'
indy.fitness = 12.
indy.ancestor_b = 'parent_a'
indy.generation = 1
#indy.id = 0
indy.brep = cube
'''
to INSERT many rows very quickly, use the "executemany" style of
insertion:
connection.execute(table.insert(), [{'foo':'row1'}, {'foo':'row2'},
{'foo':'row3'}, ...])
'''
s = Session()
# s.begin()
s.add(indy)
s.commit()
s.close()
print('closed the previous db session\nlet\'s see if we can read back the
objects, that be cool...')
engine = create_engine('sqlite:///jelle.db', echo=True)
Base = declarative_base(bind=engine)
Session = scoped_session(sessionmaker(engine))
s = Session()
from OCC.BRep import BRep_Tool
bt = BRep_Tool().Pnt
for indy in s.query(Individual):
print indy.id
for i in Topo(indy.brep).vertices():
print bt(i).Coord()
================================================
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:</public/pythonocc-users/attachments/20101230/39a52305/attachment.htm>
------------------------------
Message: 2
Date: Thu, 30 Dec 2010 22:15:21 +0100
From: jelle feringa<jelleferi...@gmail.com>
Subject: Re: [Pythonocc-users] STEP with Colors export how to (petar
perisin)
To: "pythonOCC users mailing list."<pythonocc-users@gna.org>
Message-ID:
<aanlktikrt87yh_+4x=k6lvjhhcoyw-cmoghg2kuf1...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
Thank you for the script. I have made it to work. The problem was that
windows use backslash('\') character in file names, and pythonOCC uses
slash('/'). Once I have figured this out it worked perfectly. But I
still do not understand concept of "Layers" in a STEP file. What are
they used for?
I am not on SVN version. I downloaded and installed all-in-one version
from web page. Did any of the stuff change from the all-in-one version
and the latest one in DataExchange -> STEP package(except form the
write() and write_files() modules). And, if the changed did appear, is
there a tutorial about how to build pythonOCC from SVN?
Regards,
Petar Perisin
I have seen this example, and it does not generate any file in my
installation of pythonOCC (I have tried to make filename
"C:\Users\Petar\Desktop\result_export_multi.stp". It is probably because
in my installation there is no "my_step_exporter.write_file()" command. I
have only "my_step_exporter.write()" (I have installation from the web - all
in one version 0.4 with python 2.6 for windows). But even after modifying
this I don't see result_export_multi.stp file on my desktop.
That's probably due to a version conflict. Are you running the svn version?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:</public/pythonocc-users/attachments/20101230/0aa26caa/attachment.htm>
------------------------------
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
End of Pythonocc-users Digest, Vol 25, Issue 37
***********************************************
------------------------------
Message: 2
Date: Mon, 3 Jan 2011 19:48:17 +0100
From: " Henrik Rudstr?m " <hrudst...@googlemail.com>
Subject: Re: [Pythonocc-users] Re : Anyone seen this? (Dave Cowden)
To: patr...@janssen.name, "pythonOCC users mailing list."
<pythonocc-users@gna.org>
Message-ID: <b97f52ae-0ab1-4f99-91b5-63c86add0...@gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Code completion is quite variable in my opinion, especially return types of
functions... in pydev it is possible to specifiy the argument/return types in
de docstring so that pydev recognizes and completes them:
def somemethod(a, b):
'''
@param a: list
@param b: SomeClass
@rtype: OtherClass
'''
Not sure how that works in other ide's and whether these are python standards or pydev standards.
On Jan 3, 2011, at 2:10 AM, Patrick Janssen wrote:
Hi Thomas,
I am afraid that I am not an expert on this - I just did it by trial and error. I was
hoping that there might be others with a better understanding of how code completion works.
Apart from avoiding dynamic typing wherever possible, I don't have any simple suggestions.
Along the way, I hit some problems - for example
http://sourceforge.net/tracker/?func=detail&atid=577329&aid=2858499&group_id=85796
(I am not sure if that has now been fixed). And I just tried to work round
these kinds of problems as best I could.
Patrick
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
On 29 December 2010 21:24, Thomas Paviot <tpav...@gmail.com> wrote:
Do you have any hint about the "design of an API in a code-completion friendly way"? I
guess a "code-completion friendly way" deals with code-completion compliancy with most
famous python IDE (Eclipse/pydev - IPython etc.). I'm not aware of such issues and I would
appreciate any further information.
BTW, is pythonOCC code-completion friendly in your opinion?
Thomas
2010/12/29 Patrick Janssen <patr...@janssen.name>
I am OK with Python - it has many other plus points (I don't really want to
start a python versus x discussion). I just think that, wherever possible, the
python HLA needs to be designs in a code-completion friendly way.
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
On 28 December 2010 21:01, Cowdens <dave.cow...@gmail.com> wrote:
i agree that code completion is a big deal. I use python and java in my day
job, and though java is very verbose and has many issues, the code completion
and strong typing of java makes writing code much faster. python definitely
lacks ides as good as java has.
From: pythonocc-users-boun...@gna.org [mailto:pythonocc-users-boun...@gna.org] On Behalf Of Patrick Janssen
Sent: Monday, December 27, 2010 10:52 PM
To: pythonOCC users mailing list.
Subject: Re: [Pythonocc-users] Re : Anyone seen this? (Dave Cowden)
Hi all,
This discussion is very interesting - I also made a start with PythonOCC, and
somewhere along the way I got distracted by other things - partly because I
found it hard to get started with PythonOCC. An HLA would be great!
I have one thought I would like to add to the pot at this point... In order to
make the HLA learning curve as smooth as possible, code completion is really
important. But I have found that this is quite hard in python. I previously
worked on a python api for Rhino (http://code.google.com/p/design-automation/).
The rhino COM api is a functional api - so you cannot script with objects. I
found this very unsatisfactory, so instead I created an OO wrapper in python.
As I got deeper into it, I kept hitting problems to do with code completion - I
avoided as much as possible any dynamic typing, and managed to get code
completion working in most places. But I found that it is important to think
about code completion from the start.
The problem of couse is that this is to some extent dependent on the IDE you
are using - I was using pydev. So pydev will try to analyze the return type of
functions and methods, so if in the HLA you create a function that returns a
particular object, then the user should be able to get code completion to work
on that object. However... there are still many cases where problems will crop
up.
For example, Dave wrote
i can perform the union of a two objects, creating a third one, and
convieniently return the resulting object for further manipulation
A union may return one entity or (if the inputs do not intersect) more than one
entity. This means that the HLA (i.e. the function or method being used) will
have to return a list, which means that the user will not get code completion
working on the entities in that list. If the user wants code completion, they
will then have to use 'assert isinstance()' on the entities in the list.
(As far as I know, there is no better way round this... any suggestions)
Patrick
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
On 27 December 2010 23:12, Dave Cowden <dave.cow...@gmail.com> wrote:
Hi, Thomas:
I have one other suggestion also, coming from the 'agile' point of view. the
HLA is a huge and daunting task-- and thus the reason any discussions quickly
become large. I would recommend that a scope of work be decided that is
managable and allows producing something that we can get experience with,
rather than attempting to drive any particular approach ( top-down or bottom up
) for the entire scope of the HLA.
For example, perhaps we could agree that although the HLA contains much scope,
the scope that is most needed and straightforward is the creation of primitives
and basic CSG operations. The rationale would be that these are the first
operations new users are likely to perform, and are thus a good starting point.
Explicitly _out_ of scope would then be considerations of parametrics,
assemblies, fancy curves, multi-process coordination of entities, etc.
The best way I see to define this scope would be for you to approve the user
stories that the first release supports. For example:
* "as a user of the HLA, i can programmatically create a sphere by specifying its
diameter and center point in space"
* "as a user of the HLA, i can translate an object that has been created without
creating another variable reference. Preferably, the creation and translation are
accomplished in a single line"
* ".... i can perform the union of a two objects, creating a third one, and
convieniently return the resulting object for further manipulation"
Presumably these user stories would become test cases or suites for the HLA.
Something we could reach consensus on and release, however small in scope,
would be better than spending too long on discussions attempting to consider
the entire scope. I think having something conceptually simple that we can
iterate from would be very beneficial to coming up with an API that works well.
We are certain to find that we must re-work some of these initial
implementations to provide later functionality, but as long as the test cases
and user stories match well, this effort will be managable.
On Mon, Dec 27, 2010 at 8:07 AM, Thomas Paviot <tpav...@gmail.com> wrote:
Hi,
Regarding the second point (basic primitives such as point, line, circle etc.
or other entities like coord_sys, group etc.), this is exactly what we're
thinking about for the 'High Level API' (HLA) for pythonOCC. In my opinion, it
is the most important part of the pythonOCC project, since we all agree that
the OCC library is too granular in order to be easily, quickly and efficiently
deployed.
On the other hand, this could solve one of the major issue of the pythonOCC
project : the lack of documentation and/or tutorials/howtos/getting started. As
it is currently designed (a python wrapper for the OCC library), writing doc
for pythonOCC is the same thing as writing docs for the OCC project. It is
clearly not our intent, and out of our skills/free time/etc. We are convinced
that the use of both python and a HLA can really add value the OCC modeling
kernel. Our documentation efforts would then focus on the HLA.
However, the scope of this HLA has to be explicit and clearly delimited, and
the semantics of the basic constructs must be shared among the pythonocc users
or related projects. For instance, in the pycado project, you defined a 'group'
entity. According to what I read in your code, the 'group' contains a set of
basic operations/instance creation. In my opinion, this entity is not really a
'group' but rather an 'ordered set' since you cannot inverse the order of the
elements of the group. It's however a good idea, but it has to be made explicit
in order to avoid ambiguities in the use of this entity. I would like to work
about that (a Platform Independent Model-PIM) before thinking about the
implementation issues and the underlying technologies (python packages/modules,
pycado or something else scripts, SOA and webservices, MOM etc.), that is to
say before designing a set of Platform Specific Models (PSM) that would share a
consistent,complete and extensible semantics (a t
