set
> #
> EQUAL = False
> for item in topo_set:
> if topo_item.IsEqual(item):
> EQUAL = True
> break
> if not EQUAL:
> yield topo_item
> topo_set.add(topo_item)
>
> This can be done directly in the SWIG wrapper. For the TopoDS_Shape
> class, the != operator is already wrapped with python (a call to
> IsNotEqual() method). Don't know why the == operator is ignored.
> Certainly a stupid mistake from me.
Wow, that would be beautiful...
Posted pythonOCC on pypi:
http://pypi.python.org/pypi/pythonOCC/0.1
-jelle
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
Thanks so much Arthur, that's a huge step forward!
Much appreciated,
-jelle
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
Hi,
Here's a quick rewrite of a GeomPlate constraining example.
Cheers,
-jelle
from OCC.gp import *
from OCC.BRepBuilderAPI import *
from OCC.GeomPlate import *
from OCC.Utils.Topology import WireExplorer
from OCC.BRepAdaptor import *
from OCC.BRepFill import *
p1,p2,p3,p4,p5 =
gp_Pnt
(0
Hi,
I've updated my GeomPlate example to something a little more
interesting.
In the script below, a surface is not just constrained to a polygon,
and a point, but also to a radius.
scipy.optimize.fsolve takes care of the latter.
Cheers,
-jelle
from OCC.gp import *
from OCC.BRepBuilderAP
>
Hi Frank,
> I have a suggestion for the Topo class (I can implement it myself if
> you
> can let me know how you prefer to receive patches):
>
> The TopExp_Explorer class takes an optional "ToAvoid" parameter
> (e.g. if
> you want to find "free" faces that don't form part of a shell), which
> I'm not aware of any "asssemblies" stuff done with OCC, so I've been
> implementing my own part mating stuff.
That's the hottest CAD terminology I've heard in a long time.
> Does anyone know if this is redundant?
Nope, I dont think so.
Curious to see what you come up with Bryan!
-jelle
disclaimer; i'm not big on threading, however have some experience dealing
with multiprocessing / distributing jobs over a grid.
> Multithreading is a really important because it could lead to:
> - separate the modeling operations and display tasks,
this could be easy, since displaying doesn't
> I also work on the same issue. I currently get shapes from ocaf and
> use
> DisplayShapes(). It seems it's possible to render an ocaf document by
> using XCAFPrs and TPrsStd OCC packages. You can have look at this
> thread
> on the OpenCascade forum:
> http://www.opencascade.org/org/forum/thr
>
Hi Bryan,
Excuse me for the awful familiarity earlier; I've confused you with
Bryan Bishop, also on the pythonOCC list.
Please accept my apology. That's really silly of me, and explains the
tone of the previous mail.
> Yes, sorry for this. The pythonOCC codebase is changing fast so I
> c
Hi Yorik,
That doesnt look good, and I havent seen this problem before.
Perhaps something went wrong linking to python while building pythonOCC?
Are you on the SVN version?
In [1]: from OCC.gp import *
In [2]: gp_Pnt(1,1,1)
-jelle
On Apr 9, 2009, at 6:17 PM, Yorik van Havre wrote:
Hi there!
> Okay, problem solved! I rebuilt from a clean source, and it works
> fine now. I must have tweaked something I shouldn't the first time...
> I'll do some tests with FreeCAD now, and I'll be back here.
Sweet. Happy to have you onboard Yorik.
___
Pyt
Dear users,
I am a student who has developed a Feature
Recognition Algorithm which needs to be validated. I intend to use
python occ for this purpose. Any example codes or guidance in the
following areas is much appreciated:
Hi Ganesh,
Canonical feature recognition comes
> I'm in the process of writing a simple OCAF document browser. I can
> browse the TDF_Label tree OK, but accessing the attributes is proving
> tricky. Mostly, the problem is getting data out of OCC types back to
> python.
>
> Can anyone suggest how to get the content out of a
> TCollection.TCollec
> I think there's a lot to be done for OCAF.
Absolutely.
The API though doesnt seem to have share the coherence of the BRep*
API though, which is a pity.
I agree that we need to focus on OCAF, since it'll provide true rapid
prototyping capabilities for pythonOCC.
> If I can understand the
> w
Hi Peter,
With version 0.2 pythonOCC comes with a lot of examples ( which work
standalone, and do not rely on the interactive viewer ). It uses a
simple patter ( from OCC.Display.wxSamplesGUI import
display,start_display ) which creates a basic interface.
>From there on the samples & Bryan's prev
> Last march, Jelle mentioned something about work on some new tutorial
> files, but I don't know how that's going at the moment. Jelle? Any
> updates?
I thought I already replied here?
Again; the /samples directory provides a lot:
http://pythonocc.org/Releases/pythonOCC-wo0.2-demos.zip
> At the
>
Hi Bryan,
You know I really fancy your involvement in pythonOCC, but I ask you
kindly to be very precise in replying.
Thing is that noisy and incorrect statements like below than need
correction etc etc.
> The documentation is primarily meant for the Windows platform, so
> you'll have to u
I'm very sorry, that was a private message gone public.
My apologies.
-jelle
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
Right, though when referencing to the API docs, this is the actual
reference:
http://pythonocc.org/APIREF/index.html
Cheers,
-jelle
> I need to go to class, but I'll reply to the rest of your message
> later. But first this part- I am fairly certain that I'm correct about
> this. Look at the d
> I think we have a slight misunderstanding here. Python OCC and all
> it's docs are platform neutral, but I think Bryan was referring to
> the OCC docs.
Shoot. My bad.
> I have read several people saying that the older OCC5 docs are
> better than the OCC6 docs, but they are distributed in
> I realize I wrote something that is not exactly true: all Swig files,
> excepted Visualization and Misc, are generated from the
> SWIG_generator.py script.
Just to understand this right:
so how did you set the __hash__ overloader that need to be set to a
large number `manually`? do you
> I didn't notice this bug on Windows or Ubtuntu 8.04. This may come
> from
> your video driver or may be related to OpenCascade/OpenGL.
>
> Anyone else encoutered this bug?
Setting a nice shading in pythonOCC can be tricky.
Could you perhaps upload a few images such that we can see what you
m
>
Hi Bryan,
We dealt with nearly all memory issues when releasing 0.2, but this is
something nasty that we haven't been able to work around yet.
We're currently looking into this in order to find a solution.
I've been working pretty extensively on pythonOCC & topology, and so
far I haven't r
> At the end of the iteration, e.g. when ex.More() is False, the
> TopExp_Explorer instance is cleared (with the Clear() method). Then
> all
> the references to subshapes are lost and your list contains NULL
> elements.
Thanks Thomas for the precise analysis.
I'll map this back to the Topology
> Do you think Utils.Topology.Topo do this by default? Seems a big
> gotcha
> otherwise.
Not yet.
Will by the end of the day ( SVN ).
-jelle
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
> 'Reply-to' seems to work now.
Cool! Thanks Bryan, Thomas.
-jelle
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
Hi Frank,
Well, if I'd use your method in Topo._loop_topo that would be pretty
need, right?
Cheers,
-jelle
On Apr 21, 2009, at 4:25 PM, Frank Conradie wrote:
Ah, fantastic! I was going to post the same issue here, but have
been just swamped at work. My work-around was to add all found
> I'm surprised that the same issue occur with TopoDS_Iterator.
> TopoDS_Iterator does not have any ReInit or Clear method. Do you
> have a
> piece of code that produces this bug?
Thomas,
I understood Frank used a TopoDS_Iterator to avoid the issue Bryan
described?
-jelle
__
>> Is there a possibility of joining
>> them together so that after importing them to another package there
>> is no boundry in between them?
Of course this would require the surfaces to share the same plane.
___
Pythonocc-users mailing list
Pythonocc-u
> No, it has the same problem as the explorer - I used
> TopTools_SequenceOfShape to work around the issue. I will try and find some
> time tonight to send an example.
Ah, now I remember ;')
Many thanks Frank, I look fwd integrating your feedback!
Cheers,
-jelle
>
Dear Bryan,
Thank you *so* much for the very impressive demo!
This really is a gem!
Many thanks,
-jelle
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
Bryan,
I'm asking you kindly to channel your efforts at
http://code.google.com/p/pythonocc-examples/
to the pythonOCC repository.
Note that I don't think its ok to put work of other ( there is code of
Bryan Cole here and of Thomas & myself ) in a SVN without explicitly
asking for permiss
> I think you're getting your Bryans confused! I (Bryan Cole) set up the
> pythonocc-examples repository today, as a dumping ground for my test
> code which other interested parties may access. All the code is my
> own.
Ai! I did it again ;')
I'm very sorry, please accept my apologies ( hearing
Hi,
This weeks there have been some really constructive comments on the
Topology.py module.
This is fixed in the SVN version. I added unit tests to make sure
these bugs wont resurface.
brutus:Utils jelleferinga$ py Topology.py
..
---
Hi Frank,
I just committed a new version that hopefully solves your problem.
I added basic unit tests, but have not added a test for the __hash__
issue you identified.
It would be great to have your feedback on this actually, a method for
asserting that hashing works properly would be *reall
> I more-or-less live inside eclipse + 2-3 ipython sessions.
> I only wish Pydev could actually use ipython as it's embedded shell.
So do I.
>> ( Have a look at ipdb too! )
> ooo I havn't tried this.
Its pdb, but throws in some ipython features like type completion.
Not yet very polished, but wo
> Can anyone comment on what NIS (New Interactive Services) is? I see
> there are NISViewer subclasses, but I wonder what this functionality
> provides over AIS. There's nothing in the docs that I can find.
NIS ( New Interactive Service ) is a replacement for AIS ( Advanced
Interactive Services ).
> OK, This really is committed now! Copying files between repositories
> got
> SVN all confused (and me as well).
Great! Thanks Bryan.
I noticed that the SVN version raises an exception, are you seeing
that too?
raise Exception("Failed to solve for edge")
Exception: Failed to solve for
>
> I starting to set up PythonOCC on an Intel Mac and have a question
> that
> Drew also has:
>
> I have installed the Intel Mac openCASCADE package from here
> successfully-http://www.pythonocc.org/Releases/OpenCASCADE6.3.0.pkg
>
> on the wiki there is a set of export lines to put in .bash_prof
> Thanks a lot for your offer to help! I'm preparing for my Ph.D.
> prelim, so it might be a few weeks until I get a chance to get back to
> my hobbies. OpenCascade installed without throwing any errors or
> warnings on both mac os x and debian.
Great! Good to hear you're making progress.
Welcom
> I'm not sure if this has been debated previously, but I would very
> much
> like the pythonOCC wrappers to rename OCC class so as to remove the
> package prefix from the name.
>
> I am not fond of the lazy import syntax i.e.
>
>from OCC.BRep import *
>blah = BRep_Builder(...)
>
> I like your suggestion. It makes the code more compact (which seems
> like
> a pythonic kind of idea) and less redundant. I think it makes code
> more
> readable too. The only drawback I see is that it departs pythonOCC
> code
> further from straight C++.
I don't see how Arthur?
We're not
> I too am a pydev user. OK, the auto_completion issues isn't a problem
> when using wildcard imports, but this effectively forces us to use
> wildcard imports which is ... unpythonic!
True. Can't argue against that.
>> Doing the namespaces differently is non trivial,
>
> I'm not proposing to cha
> Oh, I thought the idea was to remove the "BRep_" part of the class
> names. Sorry if I misunderstood!
> - Frank
No worries, that would be silly ;')
Just going from `from OCC.BRep import *` -> `from OCC import BRep`
-jelle
___
Pythonocc-users mailin
> Very interesting post actually. I worked all the day with Jelle for
> the
> PDE2009 presentation and read with attention this discussion. Here
> is my
> answer in 3 points:
>
> 1. I'm ok with the idea
> To be honest, I already thought about the class renaming a few months
> ago. I always had
> Please do post some notes on the wiki, when you get a chance. I
> took a
> quick shot at setting it up on my Mac, but ran out of steam with the
> wxGtk install. I might try again this coming weekend on my Ubuntu
> machine.
Ai, guys I'm really sorry about the wxGTK hickup...
Its seems a *ma
> I didn't try again with Linux, but slept on the problem, and figured
> out that my active python installation on os x was looking in the
> wrong directory. I added a symlink to the correct directory as a hint
> for macports users. I'm working on condensed set of install
> instructions for the c
Hi Bryan,
My feeling is that the discussion is getting a little out of control;
the renaming we have in mind isn't a big deal really.
As far as I'm concerned there is only one option that is worth
considering ( renaming classes / methods is _not_ acceptable )
Which is moving from `from OCC.BR
> Here is my cleaner, but incomplete (no gui) set of install
> insructions.
>
> http://www.pythonocc.org/wiki/index.php/OS_X_Installation_Instructions_using_Macports_as_much_as_possible
>
> If someone else thinks it's an improvement on the current state of the
> old version, promote it to the mai
> from OCC import BRep
> bb = BRep.BRep_Builder() --becomes--> bb = BRep.Builder()
Hmmm...
Perhaps Frank is right.
Its closing in on me too ;')
Yep, why not go for it.
-jelle
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org
> Just updated the FeatureTreeDemo in SVN. My understanding of TNaming
> has
> improved (one should track shape faces, rather than edges). It's now
> much more robust. Let me know if you experience problems.
What's strange is that it seems that we're not glancing the same
program?
Is your SVN
On Apr 30, 2009, at 2:23 PM, thomas.pav...@free.fr wrote:
>> Hi Thomas,
>
> Hi Jelle,
>
>> The gp module is interesting, since there is a OCC.gp.gp module.
>> Right now we can call: from OCC.gp import gp; gp.DX()
>
> You have to instanciate the gp class before calling the DX method:
> gp().DX()
> Yes, this is great. Thank-you Thomas!
I'm all for it too; I'm sorry it took you ( Frank, Bryan ) too much
effort to convince me, seems an evident improvement.
> Once this is in SVN, I'll start on converting the sample-scripts.
Me++
Cheers,
-jelle
__
> OK, I finally understand what Jelle is saying. The gp class is the
> only
> one which does *not* have a prefix i.e. There is no OCC.gp.gp_gp()
> class; it's OCC.gp.gp() instead.
Yep, that's the only one.
> There needs to be a catch for cases where there is no prefix (i.e. no
> '_' in the name
scons is very much WIP, setup.py is well polished.
perhaps you're OCC directory is not set correctly in enviroment.py
( look for OC_INC / OCC_LIB )
cheers,
-jelle
On Apr 30, 2009, at 6:42 PM, Stephen Waterbury wrote:
> I've tried both the setup.py and scons methods, and both fail.
> Is there
>
Hi Stephen, Arthur,
> Ah, there we have a problem, I think. You have installed OCC 6.2.7,
> but Thomas
> is wrapping OCC 6.3. I think that will do something odd. I'm not
> certain (Jelle,
> Thomas?), but I think you need to manually install OCC 6.3. Is there
> something
> like an unstable
The wiki was pointing to the outdated lib that Stephen mentioned before.
Got rid of the link. Sorry for the inconvenience.
On Apr 30, 2009, at 10:03 PM, Arthur Magill wrote:
> Ah, there we have a problem, I think. You have installed OCC 6.2.7,
> but Thomas
> is wrapping OCC 6.3. I think that w
> Thanks, Arthur -- it looks like the wiki needs to be revised: in the
> "Install Linux" section, the Debian and Ubuntu paragraph has an Ubuntu
> link that points to the Ubuntu packages for opencascade 6.2-7 -- this
> is apparently unhelpful. (This is a typical problem for open source
> projects
Hi,
It seems pretty unreasonable that its still hard to get pythonOCC
going on linux.
win32 is doing just fine ( ( even) more power to you Thomas ) and osx
are doing relatively ok ( osx has some troubles with the wxGTK
dependency, but pythonOCC works as advertised )
I wonder what options ar
> I admit I trusted info that are written on the wiki and did not take
> (precious) time to check each entry. I agree with Jelle that having
> wrong info is worse than having no info at all. I remember an old
> discussion we had on the older pythonocc-ml, and someone said: "A wiki
> is better than
> Excellent, thanks Marco.
Yep, happy to have 2 volunteers ;')
> I have made some changes to the wiki pages. I have now split the page
> into "installing OpenCASCADE" and "installing pythonOCC".
Great, thanks Arthur good idea.
> I think this
> will make it easier to troubleshoot where users are
It's been a while, but i'm back to work on my slicer project finally.
Hi Dave,
Good to have you back ;')
i have made good progress the last couple of days-- i hope to
upload what I have soon. i have sliced a shape and viewed in a
viewer window ( thanks for samples, Thomas!).
Great, did
> I have been attempting to set up pythonOCC on linux (Ubuntu8.04 for
> what
> it's worth)
Thomas recently made a binary for Ubuntu, its sure is worth checking
this out:
http://www.pythonocc.org/Releases/Ubuntu_8_04/
Since we havent tested this binary, this release has not been
announced, s
> My goal is to generate family of part drawings
> automatically, so this is a step in the right direction.
That's a very interesting goal Dan.
I've been trying to get Postscript output from OCC, but havent
completely managed yet.
I recently added an example how to get a hidden line drawing fro
> This might be a clue:
import wx
import wx.aui
import wx.py
from wxDisplay import GraphicsCanva3D
This is really weird; GraphicsCanva3D is a class of the 0.1 release
which is __really__ outdated.
Are you sure you're on pythonOCC 0.2?
-jelle
>
Thanks for your feedback Dan.
Happy to hear the Ubunutu binaries work as advertised ( great job
Thomas! ).
Good to have your feedback, such that we can provide easy setup on
linux too.
One distribution down, lots to follow.
Cheers,
-jelle
> Then I missed this in my .bashrc script:
>
> exp
> Sure, how do I get editing permissions?
You just have to register.
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
hi Dave,
this was an issue with occ.utils.topology.py, which has been fixed in
the SVN some time ago. it would be best if you can upgrade to:
http://pythonocc.org/Releases/daily/pythonOCC-PDE2009.win32-py2.5.exe
cheers,
-jelle
On Wed, May 6, 2009 at 4:05 AM, Dave Cowden wrote:
> Hello, everyon
e ( texp.More() ):
>face = ts.Face(texp.Current());
>faceList.append(face);
>texp.Next(); # if there's no 'next' shape, pointers are
> destroyed
>texp.ReInit() # Add this line so pointers are recreated before the
> list is returned
>return
> Your Topology.py script is not buggy!
Feww
What arrogance to think that topology is handled by this module.
Still, it works:
for f in facelist:
dumpTopology(f);
->
from OCC.Utils.Topology import Topo
for f in Topo(box).faces():
dumpTopology(f)
Face:27861
. Wire:27913
.. Edge
> Much more elegant solution actually. It's a better fix than mine.
Its true that handling topology isnt that easy, and can cause obscure
bugs.
In that sense its cool that Topology.py abstracts these issues.
-jelle
___
Pythonocc-users mailing list
P
> Wow!
>
> I didn tknow about this topology module-- I will try using it
> instead! It
> should make my code much better.
Happy to be of help Dave ;')
Did you see the multi proc. slicer example we made?
Thought you would like that ;')
-jelle
___
Pyth
> No actually I wasn't able to find where it is. Do I need to check
> out the
> latest svn version to see it?
Yes there's interesting material to be found in the SVN.
It'll also give you some of the data you need to make the examples work.
Check in out in samples/Level2/Concurrency
-jelle
___
On May 6, 2009, at 7:22 PM, Dave Cowden wrote:
> Ok most excellent I will get latest svn and check out the samples.
> I'll also use topology.py if it is in the wo0.2 version.
Again, I recommend the pythonocc.org/Releases/daily version ( the PDE
one is the most updated )
> I'm not sure i'm c
Hi Dave,
Good to hear your making progress.
We've noticed that the .Delete method does absolutely nothing in some cases.
What happens if you call .Destroy rather than .Delete ?
Currently we're working on overloading __del__ such that this type of
thing can be done in slightly more pythonic synt
Hi Dave,
Concerning the wires; it might be that with BrepAlgoAPI_Cut you might
be introducing more issues than you solve, and performance will be
really poor for sure in terms of how many slices you'll generate per
second. What is the exact problem you need to fix regarding the wires
you mention?
>> - The shapeTypeString(shapetype) function is very convenient and could
>> be added to the Topology module,
+1
will add it when I return to Paris tomorrow.
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonoc
> I am really interested in your slicer. It looks like something that
> could be used in the pursuit of slicing up solids for use with
> dimensioned drawings (cross sectional views). It looks like a very
> interesting project.
Hi Dan,
How are you progressing with the dimensioned drawings?
Recent
> I am still in early learning mode here. I am slow, but persistant. The
> more samples I study, the more I understand. Bring on more samples :)
Hi Dan,
Your persistency is appreciated, same here ;')
The sample I mentioned is a really good starting point for you, I'm
sure!
-jelle
Hi,
I've added a "Context.py" file on SVN, in the Utils folder.
The idea here is to use python 2.5 `with` statement, for checking
whether an operation IsDone() or it raises an AssertionError, printing
a specified error message.
In the case presented below, when the Vertex would not build
su
> That would be excellent-- can you give me svn write please? I'll put
> OCC
> Slicer in either tools or in samples, whichever.
( thanks for contributing Dave! )
Tools would be the place.
Samples is there to explain by example how the API works.
-jelle
___
I've got some pretty cool news to report.
As of today ( ok, this morning ) pythonOCC has parametric &
topological associativity!
I've come up with a demo that allows you to simple set parameters
which will trigger topological & parametric updates.
Many thanks to Sioutis ( who works on the GE
> Wow, this looks totally awsome! Can you explain a bit how it works?
> I'm curious... Can any shape receive parameters? Did you add all
> this "by hand" or did it exist somewhere hidden in OCC?
Thanks!
Its pretty basic.
I've made a class Parameters.
On instantiation you give it a Geom_Engine
> Wow, that's pretty impressive indeed, jelle.
Thanks Dave!
We'll start working on wrapping these ideas in pythonic modules, while
working our way up too a more high level API.
Cheers,
-jelle
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
Hi, there are several ways of doing so.
Have a look at the documentation:
$CASROOT/OCCTDocumentation6.3.0/Visualization/html/classV3d__View.html
So, practically speaking:
pdb> view = display.GetView().GetObject()
ipdb> view.Convert(1,1)
Out[0]: (-49.84375, 37.34375)
ipdb>
What works well when
Hi,
I'm curious whether someone on this list has an idea how to extract
bezier paths of fonts.
This way, I would be able to built some support for building text
elements ( as faces, wires ).
That could be quite convenient when building files for fabrication
( instructions, tagging, that sor
I recall Bryan Bishop brought up the topic of part mating a few months
ago.
I stumbled upon a link that is interesting with this regard:
http://olivier.coma.free.fr/opencascade/opencascade.html
especially the ppt:
http://olivier.coma.free.fr/opencascade/file/IDMME.zip
Cheers,
-jelle
Hi Dan,
Something that is perhaps of interest to you is that pythonOCC
supports the pickling protocol too.
So, you can dump & load TopoDS_* objects too.
Cheers,
-jelle
On Jul 5, 2009, at 4:21 PM, Dan Falck wrote:
> Hi Thomas,
>
> Thanks for the link. Thank you for the wonderful project too!
Hi Nathan!
Welcome to PythonOCC, we're very pleased you seem to like it!
Regarding the concatenation issue of beziers -> splines, here's how I
do it:
where __inner is a list of Geom_Curve instances
comp_curve = GeomConvert_CompCurveToBSplineCurve(__inner[0])
for i in __inn
Hi,
It seems to my you are using the 0.2 release.
The thing is, we've made a lot of improvements since this release and
plan to release 0.3 very soon.
The current daily release reflects these improvements, and can be
considered a release candidate:
http://www.pythonocc.org/Releases/daily/
Hi Vladimir,
> Thank you!
> Where is the daily or 0.3 release for Linux (Fedora 7)?
Sorry, since there are so many different linux distros, its hard to
support it ( say we provide binaries for one distro, we'll get flamed
by users of another distro ).
On the wiki some pretty good documentatio
Hi Vladimir,
> I am sorry, but I don't install sg0.3 from svn:
> Error ... SGEOM_wrap.c:5710: undefined reference to
> `GEOM_Engine::GetUserDataLabel(int)
Ah, this is due to the fact that 0.3 has a dependency of GEOM:
http://occ.borland.googlepages.com/opencascadeborlandbdsport
Thanks to the e
> oh it works ! the compilation is started, I hope it will compile fine.
Terrific Sebastien, Thomas!
Great news.
-jelle
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
> Hi all !
>
> After 7441 seconds of compiling it finally succeeded !
> After few tests pythonocc wo0.2 seems to work on python 2.6 under
> windows xp :)
>
> I can provide the windows installer if needed.
>
> Now I will try with the svn version.
>
> Thank you Thomas !
Sweet! Yes, it would be rea
> Jelle, is this line really unuseful (I guess you added it in
> OCCViewer.py)? Can you please commit your changes to the repository
> when it's fixed (I don't know this part of code since it does not
> come from me).
Hi I noticed too that this doesnt work well in the Viewer2d.
I've wrapped
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
Hi all !
After successfully compiling PythonOCC with Python 2.6.2 on Windows
XP, I tried with Python 3.1 and it works !
There are somes changes to do about relative import in OCC lib but
as you can see in the attached picture, some basic tests simply work !
I have convert some scripts using 2t
Hi,
For those of you who have come to rely on PAF, some good news; we've
managed to optimize the framework quite a bit in terms of speed.
PAF abstracts away nearly all of the intrinsics of parameters and
associativity, but was much slower than the initial examples.
This has been fixed, PAF is
1 - 100 of 385 matches
Mail list logo
