Topic: PyAcad.NET 0.6.2 Released

[tjr]

I have just released a new binary version of PyAcad.NET for AutoCAD 2008. You can get it at: http://code.google.com/p/pyacaddotnet/downloads/list

Some of the big changes in this release are:

• Switched from the standard IronPython package to the FePy package. This means the python standard library is available to use in PyAcad.NET programs.
• Started working on a pyacad python class to simplify working with the unpleasant features of AutoCAD's .NET api. Only features for exchanging strings between lisp and .NET implemented currently.

If you want to give it a shot download it, unzip it to something like C:\pyacaddotnet, netload PyAcadDotNet.dll and check out some of the samples. in the c:\pyacaddotnet\samples directory. Most samples aren't anything great but you can load the *.py files using the pyfile command. Lisp files can be loaded via appload and then executed.

One sample that should somewhat impress some are the lispwinforms.lsp and the lispwinforms.py. This is an example in which we pass a string from lisp to our IronPython application and display it in a textbox of a .NET forms application. From the .NET forms application we can then modify the value, hit submit and the new text is returned to the lisp application.

If anyone has any questions or comments by all means let me know.

[It's Alive!]

Nice work,

I wonder if you can do some sort of enum class for easier handling of ResultBuffers, as they will be needed if the end user wants to do any work with Xdata or DXF codes.  (or use the  .net API’s enum classes)

But it is important to “Hide” the ResultBuffers that get/return data for lisp as you did, Since those are static.

[tjr]

Thanks Dan.

What I have in place now for the pyacad python class was basically a quick hack to see if I could do what needed to be done. To be honest with you the only reason I only have the text part implemented is because I couldn't find the other type codes needed. I had gotten 5005 from some code you had given me and I rolled with it. I will add anything else needed once I can find the type codes. However I am thinking about staying with the basic setup I have now; addReturnString, addReturnInt, addReturnFloat, etc. and then a final submit(like) function call as I can't think of a better way to do it. Of course it doesn't help that I have nothing more than an elementary understanding of lisp.

I am just hoping at some point people get somewhat interested in this project. I am still uncertain what is stopping them as I can't think of anything this project doesn't have. It gives you full access to AutoCAD's .NET libs as well as almost any other .NET lib out there. Since the inclusion of the python standard library it also gives you the power that comes with it. If I were a lisp hacker I would seriously take a rainy Saturday and investigate what this package brings to the table. It's dynamic like lisp so development is very rapid development (no build required). It is also 10x at least the power of lisp as far as overall capabilities go. How many lisp programmers can type something like:

Code: [Select]

import calendar
print calendar.month(2008, 5)
and get the calendar for the current month?

[Kerry]

To be honest with you the only reason I only have the text part implemented is because I couldn't find the other type codes needed. I had gotten 5005 from some code <SNIP>

http://www.theswamp.org/index.php?topic=15868.msg192407#msg192407

[MickD]

...

I am just hoping at some point people get somewhat interested in this project. I am still uncertain what is stopping them...

I'm sure there are a few, myself included, very interested in this project, time is my limiting factor at the moment but I'll jump in when I get time.

One thing that does concern me though is Python is a great scripting language, while also being a powerful language in its own right, and that's why VB has done so well also. They take away all the 'safety' coding normally associated with 'C' styles and hides it behind wrappers. Things like transactions, opening/closing db's for read only/write etc. These are more complex tasks that you wouldn't normally expect in VB or Python, sure there's error handling but the nitty gritty is handled below the surface.
What I'm trying to say is that writing .net in Python will be similar, in structure at least, to writing C#. Look at VB.net and how much more difficult/complex it is to write using .net, no more 'ModleSpace.Add(MyLine)', it's all transactions, getting bt's and btr's etc etc.
Much more coding than what you'd expect in a higher level language.

Having said that, I'd rather write in Python than VB.net any day and there is every possibility of writing a library to handle the more mundane tasks and make it more 'Python-esque', so keep up the good work Tim and I'll jump in soon

[FengK]

Tim, I'm waiting for that rainy Saturday as well. Thanks for your work. I recently tried automating AutoCAD with comtypes and the result was good. I'll try see if I can ran it with pyfile command from PyAcad.NET. If so, it would be much easier to share Python codes with those who don't want to install Python.

Update: I did a quick test. It seems comtypes can't be used in IronPython or FePy.

[tjr]

To be honest with you the only reason I only have the text part implemented is because I couldn't find the other type codes needed. I had gotten 5005 from some code <SNIP>

http://www.theswamp.org/index.php?topic=15868.msg192407#msg192407

Kerry:

Thanks, that is just what I needed.

[tjr]

...

I am just hoping at some point people get somewhat interested in this project. I am still uncertain what is stopping them...

I'm sure there are a few, myself included, very interested in this project, time is my limiting factor at the moment but I'll jump in when I get time.

One thing that does concern me though is Python is a great scripting language, while also being a powerful language in its own right, and that's why VB has done so well also. They take away all the 'safety' coding normally associated with 'C' styles and hides it behind wrappers. Things like transactions, opening/closing db's for read only/write etc. These are more complex tasks that you wouldn't normally expect in VB or Python, sure there's error handling but the nitty gritty is handled below the surface.
What I'm trying to say is that writing .net in Python will be similar, in structure at least, to writing C#. Look at VB.net and how much more difficult/complex it is to write using .net, no more 'ModleSpace.Add(MyLine)', it's all transactions, getting bt's and btr's etc etc.
Much more coding than what you'd expect in a higher level language.

Having said that, I'd rather write in Python than VB.net any day and there is every possibility of writing a library to handle the more mundane tasks and make it more 'Python-esque', so keep up the good work Tim and I'll jump in soon

Mick:

You are 100% correct, when it comes down to it you still have to deal with the API it's in a .NET fashion. However my goals for this project are two fold. First and foremost was the C# assembly to make IronPython code run inside AutoCAD's .NET API. With a lot of help from Daniel I am confident that that goal was sufficiently completed; for the time being at least.

The second goal was to create a python helper library for the exact reasons you have mentioned. I have the bare bones start in the pyacad python package I have created that is used for the exchange of data between lisp and IronPython. This library will be my main focus now so hopefully I can get some time to get something constructive done with it.