Topic: Programming with IronPython

[tjr]

After looking at the code, I think it would be easy enough for Tim to add references to AutoCAD’s COM Api, so you wouldn’t have to do this
clr.AddReferenceToFileAndPath(…)

I'm still having trouble understanding why anyone would want to get at AutoCAD through COM in PyAcad.NET when you have the entire .NET API available to you.

Why not? For simple scripts, like adding a layout, it’s much easier to use COM. While I don’t use COM much, I know it’s in the toolbox

I see your point, and it goes against what I had envisioned for PyAcad.NET, but if it's a direction people want to go then I guess it wouldn't hurt to add.

My vision for PyAcad.NET was first and foremost the thin C#/IronPython Wrapper followed by a pure python library for making it easy to work with the .NET API. For example if one wanted to draw a circle like I posted previously all they would need to do was something like:

Code: [Select]

import pyacad

pyacad.geo.draw_circle((5.55, 6.21, 0), (100,100,0))


[It's Alive!]

My vision for PyAcad.NET was first and foremost the thin C#/IronPython Wrapper followed by a pure python library for making it easy to work with the .NET API. For example if one wanted to draw a circle like I posted previously all they would need to do was something like:

Code: [Select]

import pyacad

pyacad.geo.draw_circle((5.55, 6.21, 0), (100,100,0))


Ah! I see, so in the end it will be a simple interface to the more complex .NET API.
It’s a great idea.

As far as Bricscad goes, I have only wrapped the 100 or so SDS functions, ie , entget, entmake…
I have started wrapping the DRX geometry classes as they seemed to be the best place to start. It’s a big API so it might take a while
so com and sds are the only choice now

[MickD]

OT -
That's why I'm keen on wrapping the api (ARX/BRX) to straight python, Bricscad is not likely to go .net in a hurry and if they go native linux...
\OT

[tjr]

My vision for PyAcad.NET was first and foremost the thin C#/IronPython Wrapper followed by a pure python library for making it easy to work with the .NET API. For example if one wanted to draw a circle like I posted previously all they would need to do was something like:

Code: [Select]

import pyacad

pyacad.geo.draw_circle((5.55, 6.21, 0), (100,100,0))


Ah! I see, so in the end it will be a simple interface to the more complex .NET API.
It’s a great idea.

Yes so in the end it would provide a simple interface for executing common tasks but still give them the ability to break away and hack at the .NET api in IronPython, C# or VB.NET if they needed/wanted to. Yet all would usable from the IronPython. IronPython is really an awesome package if you dig into it.

As far as Bricscad goes, I have only wrapped the 100 or so SDS functions, ie , entget, entmake…
I have started wrapping the DRX geometry classes as they seemed to be the best place to start. It’s a big API so it might take a while
so com and sds are the only choice now

Keep at it. In my eyes bringing the .NET API to another platform is more than a big deal.

[tjr]

OT -
That's why I'm keen on wrapping the api (ARX/BRX) to straight python, Bricscad is not likely to go .net in a hurry and if they go native linux...
\OT

Mick:
Don't kid yourself. You know if Bricscad were to go native linux you'd be one of the first in line hacking away trying to get Dan's .NET stuff working with Mono. It's in you and you know you wouldn't/couldn't turn down the challenge.

[MickD]

I don't know about that Tim, call me old fashioned, but give me plain C and something to script it with and you have a winning combination, only my opinion of course

[Krasyn]

It seems to be impossible to pass a python function  pointer to Autocad because IronPython doesn't produce normal msil assemblies. I think this is the reason why exceptions occurs in Autocad when you run a command after execution of this script:

Code: [Select]

import clr
import System
from Autodesk.AutoCAD.ApplicationServices import *
from  Autodesk.AutoCAD.DatabaseServices import *
from Autodesk.AutoCAD.EditorInput import *
from  Autodesk.AutoCAD.Runtime import *
from  Autodesk.AutoCAD.Geometry import *

doc = Application.DocumentManager.MdiActiveDocument
ed = doc.Editor
db = doc.Database



def docCommandWillStart(sender,e):
print 'hello'

doc.CommandWillStart += CommandEventHandler(docCommandWillStart)
How can you say entire Net api is available if you can't use reactors?

[tjr]

It seems to be impossible to pass a python function  pointer to Autocad because IronPython doesn't produce normal msil assemblies. I think this is the reason why exceptions occurs in Autocad when you run a command after execution of this script:

Code: [Select]

import clr
import System
from Autodesk.AutoCAD.ApplicationServices import *
from  Autodesk.AutoCAD.DatabaseServices import *
from Autodesk.AutoCAD.EditorInput import *
from  Autodesk.AutoCAD.Runtime import *
from  Autodesk.AutoCAD.Geometry import *

doc = Application.DocumentManager.MdiActiveDocument
ed = doc.Editor
db = doc.Database



def docCommandWillStart(sender,e):
print 'hello'

doc.CommandWillStart += CommandEventHandler(docCommandWillStart)
How can you say entire Net api is available if you can't use reactors?

PyAcad.NET doesn't generate any .NET assemblies from IronPython so that's not the issue here. I haven't tried doing reactors at all either. I will explore and get back to you.

[Krasyn]

One more problem with pyacad.net
I cannot define a subclass of  the arx.net api classes:

Code: [Select]

from Autodesk.AutoCAD.EditorInput import *
class BlockJig(EntityJig):
pass
Exception occurs
What's wrong?

[It's Alive!]

One more problem with pyacad.net
I cannot define a subclass of  the arx.net api classes:

Code: [Select]

from Autodesk.AutoCAD.EditorInput import *
class BlockJig(EntityJig):
pass
Exception occurs
What's wrong?

The way PyAcad.net is written now, Python code is executed then immediately disposed of.
Any code that needs recourses from the executed code after the code is disposed of will throw an exception.  This is why your reactors failed and maybe why your new jig class does not work.

 I think some of the work Mick is doing may resolve some of these issues.

PS:  You seem very knowledgeable about both Python and .NET and since this is an open source project, you might want to have a look and see if there is something others have missed

[Krasyn]

One more problem with pyacad.net
I cannot define a subclass of  the arx.net api classes:

Code: [Select]

from Autodesk.AutoCAD.EditorInput import *
class BlockJig(EntityJig):
pass
Exception occurs
What's wrong?

The way PyAcad.net is written now, Python code is executed then immediately disposed of.
Any code that needs recourses from the executed code after the code is disposed of will throw an exception.  This is why your reactors failed and maybe why your new jig class does not work.

 I think some of the work Mick is doing may resolve some of these issues.

PS:  You seem very knowledgeable about both Python and .NET and since this is an open source project, you might want to have a look and see if there is something others have missed

Unfortunately, I know very little about programming, I'm not realy a  programmer, I'm just a CAD user, who wants to customize AutoCAD in the most effective way. And I'm not fluent in English and have to use online translators. I doubt I can help PyAcad.net developers.
I think also that to make IronPython work with AutoCAD they have to modify it's source code. I don't know if it's legal and anyway it will demand thorough knowledges of theory of compilers, MSIL and so on.
I only hope  PyAcad.net will be finally a success

[It's Alive!]

I understand, just so you know how the project evolved, We thought it would be nice if the code could run dynamically, I.e. without having to restart AutoCAD every time as you do when testing C# modules. This is an unforeseen problem, but I am sure it will be resolved.   

[Krasyn]

I understand, just so you know how the project evolved, We thought it would be nice if the code could run dynamically, I.e. without having to restart AutoCAD every time as you do when testing C# modules. This is an unforeseen problem, but I am sure it will be resolved.   

I see. I read that Python is good for prototyping.
There is one method you probably know. With the help of PyAcad.Net:

Code: [Select]

import clr
from System.CodeDom.Compiler import CompilerParameters
from Microsoft.CSharp import CSharpCodeProvider
from System.IO import Path
pathToSource = ur'D:\Documents\through-the-interface.typepad.com\Samples\ListAttributes.cs'
cp = CompilerParameters()
cp.GenerateInMemory  = True
cp.GenerateExecutable = False
pathToArxInc = r"c:\Program Files\ObjectARX 2008\inc"

for r in ['AcDbMgd.dll','AcMgd.dll']:
cp.ReferencedAssemblies.Add(Path.Combine(pathToArxInc,r))
cp.ReferencedAssemblies.Add('System.Windows.Forms.dll')
provider = CSharpCodeProvider()
cr = provider.CompileAssemblyFromFile( cp, pathToSource );
if cr.Errors.HasErrors:
print 'error compiling'
for ce in cr.Errors:
print ce.ToString()
else:
clr.AddReference(cr.CompiledAssembly)
You can modify  the source file and run this script again without a need to restart AutoCAD.
I think that another possible way is to use AppDomain class, but I don't know how to.