On Jan 7, 2011, at 3:24 PM, Thomas Paviot wrote: > 2011/1/7 Henrik Rudstrom <hrudst...@googlemail.com> > Hello all, > > Hi Henrik, > > I've been watching this thread from the sideline for a while, very > interesting thread, but i havent had time to share my thoughts yet. so here > we go. > Although the idea of a standardized api across platforms and all the > possibilities for collaboration/online services has a lot of potential, i > think it will become a very big undertaking and i agree with Dave that we > should limit our scope and start simple. > > Although im not against it, i see some dangers with building a new api on top > of open cascade, even if we start with a very delimited scope; it will be a > lot of work to develop our own set of sematics (the OMG CAD looked > interesting though, but i got the impression that opencascade has much more > functionality than what is covered by OMG) > It will be difficult to cover everything in a consistent manner, so the risk > is having still the granular c++ like opencascade api with some apis built on > top that are good for some purposes but not all, this can make it very > daunting for new users (and still for me) to figure out when i can use a nice > abstracted function or when i have to go down to 'pure' opencascade. > > I agree with all the points you mentioned. You're especially right dealing > with the "granularity" issue. The big deal is how to go from low level data > models (very granular, like the STEP data model, or even OpenCascade) to high > level functions (or services), less granular, without loosing any semantics. > > Mostly when the high level api subject comes up on the list it seems that > most of the issues people have are with the programming paradigms of > OpenCascade, not necessary the semantics of opencascade. In my opinion, if we > could strip away all c++ artifacts of opencascade i think the semantics of > opencascade as it is is quite decent. > > I understand. If the OCC semantics is good enough for your needs, let's say > it's ok. There might be a confusion I'd like to talk to you about our: the > lack of a clean, simple, explicit and shared CAD API is a major issue that > still has to be solved. This is a 'research' point of view (which is part of > my daily job). On the other side, we all agree that the OpenCascade API is > huge, with weird naming conventions, and that an overall clean-up is > required. It's not practical. This is a 'pythonocc developer' viewpoint. > Regarding the first point (the issue) and the second point (pythonocc is not > practical, poorly documented etc.), I'd like to join these efforts.
It is indeed a bit confusing, i think the term High Level API leaves a lot of room for interpretation; high level in terms of CAD operations or in terms of programming. it might be a bit too general term. Also if High Level refers to High level CAD operations im also a bit curious what you (and others) see as (generic) high level operations? correct me if im wrong, but once you get beyond the basic functionality of a solid modelling kernel things start to become more specific to certain types of design/production methods etc. If High level referes to high level in terms of programming paradigms, ie abstract away all the boilerplate code/cleanup the api (a loss-less compression of the api if you will) would give a good overview for further iteration. > However, I don't want to impose my views here. This ml is a 'pythonocc-users' > ml, so if pythonocc users just request for a polish of the API, let's go with > it. . I just speak for myself ;) maybe i can clarify my point by first quoting you earlier in this thread: "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." My main point is that opencascade already has these entities, but they are kind of buried in boilerplate code and wierd syntax. I'm just a bit afraid that it might become messy if we start building a paralell structure of entities on top of the existing one. > > Maybe the recent discussions related to high level api, as I understand it, > or the db storage, have nothing to do in this ml. I would understand if I > bore anyone with this kind of stuff. A pythonocc-r&d or pythonocc-dev ml may > be better. If only one, two or three people here are interested in discussing > a midterm or longterm future of the project, let's move away. We could then > leave this ml to practical discussions about how tos, faqs etc. and small API > improvements. Dont get me wrong, i dont find it a bore at all quite the opposite, but sometimes it is not so clear what the purpose of the discussion actually is. > > But one thing is sure : I will work on that topic for the first 6 months of > 2011 in my research activity. Maybe I have to wait for a few months before > coming back here with solutions and proposals, rather than questions. :) > > > A while back i was playing around with pygccxml (a c++ parser that can be > used for code generation) to get an idea of what could be done to make > opencascade more user friendly without having to manually write all the > wrappers. There are quite a lot of things that could be done with the > wrappers to make them more compact and 'pythonic' without manually writing > all the code: > > - Handles (i believe Thomas managed already to get rid of those, havent > tested that) > - The collections classes: Array1Of.... the methods of these classes could be > rewritten to conform to the list/set/etc interfaces of python and all methods > that accept these collections could have some aout generated code that > converts standard python lists to these classes if necessary (i already have > the code to identify all the collection classes) > - The strictness of arguments in general could be loosened or some classes > could be merged ( for example gp_Pnt/gp_XYZ/gp_Vec/gp_Dir) are basically the > same thing > - Geom and gp could be merged or autoconverted between > - A lot of the algorithms classes that need to be initialized, executed and > then a method call to return the object of interest follow similar patterns > that could merged into a single method call, for example the sequence: > cut = BRepAlgoAPI_Cut(shape1, shape2) > cut.Build() > cutted_shape=cut.Shape() > - There still are a lot of method calls that takes a pointer to an object > that serves as the return value > - We could add a simple regexp to rewrite the CapitalizedMethodNames to > pythonic_underscored_method_names > - Eliminate the prefix of all the classes and implement them as python > namespaces: > Geom_Point -> Geom.Point or > from Geom import * > p = Point(...) > - then there is a lot of adapters etc that i havent looked too much at. > > Many of these patterns can be identified with pygccxml queries and used to > add code to the wrappers. Some would require manual specification of classes > and methods that belong to a pattern. > > Im not sure i would call it a high level api anymore, but i think it would > alleviate a lot of the need for a general high level api. > > what do you guys think? > > I love your pygccxml/SWIG suggestions. Get ready to commit! I think i sent you some of that code sometime after the pythonocc 'conference' in oslo this last year (which was based on your existing swig generator code but i was so rude to refactor it beyond recognition) Im getting in the mood to revive it, but i'd like to know that if it will fit in the big picture and that my assumptions are right before i spend too much time on it. > > > Henrik > > Thomas Henrik > > > > > > > > > On 27 December 2010 16: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 top-down approach). > > I will post a new entry in the coming days, to sum up the exchanges related > to the "have you seen this" thread and suggest a way/plan to let everybody > interested in this work contribute the development of the HLA (the dual > bottom-up approach). > > Cheers, > > Thomas > > 2010/12/23 julien blanchard <julien...@yahoo.fr> > > Hi, > > The layer above python was matching the best with our goals, in fact, I see > two > main parts in our project: > - the "IDE part" providing an optimized syntax for CAD and an efficient > graphical visualization (by updating only components being modified in the > script since last refresh) > - the high level API written in pure python. This API should be used both in > python project and pycado projects. > For now, the API contains the following primitives (can have several > "constructors"): > coord_sys (coordinate system), point, line, circle, vector, surface, solid, > group (a group can join any primitive) > > Julien. > > ----- Message d'origine ---- > De : Dave Cowden <dave.cow...@gmail.com> > À : pythonOCC users mailing list. <pythonocc-users@gna.org> > Envoyé le : Mer 22 décembre 2010, 19h 35min 20s > Objet : Re: [Pythonocc-users] Re : Anyone seen this? (Dave Cowden) > > Hi, > > I am not a fan of pre-processors and scripts that are not pure python. > I think that such an architecture is unnecessary in a dynamic > language like python or javascript. Is it not possible to accomplish > the abstractions without pre-proccessing or another layer of syntax > above python? > > > > > _______________________________________________ > 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 > > > > _______________________________________________ > 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 > > > _______________________________________________ > 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
