I would like to see the DotNet support interaction with Visual Lisp. It would make the transition a go little easier for us lispers
Daniel
Printable View
I would like to see the DotNet support interaction with Visual Lisp. It would make the transition a go little easier for us lispers
Daniel
I think I would rather see autocad support .NET fully. Maybe even VBA.NET?
Visual Studio Tools for Applications is the .NET equivalent of VBA and provides both VB & C# syntax. Personally I think if lispers want to use the .NET API they should learn VB or C#. I think Autodesk should focus effort on improving the .NET API and developing comprehensive documentation independent of the ObjectARX documentation.Quote:
Originally Posted by scottden
Regards - Nathan
Let me clarify, I think the .NET API should be able to interact with visual lisp the way ObjectARX can. I.e. like acedDefun() calls. If I can build one function at a time using C#, it would make porting lisp applications much easier.
Should be no reason anymore for not having this. .NET is even already available in CommonLisp (although the extension won't work as-is in AutoLisp). See this (http://www.weitz.de/rdnzl/).
Unfortunately AutoLisp is quite far removed from CommonLisp after 20+ years of seperate development. Not to mention that ADesk only used a portion of LISP to begin with when they created their ALisp interpreter.
But as can shown by this extension, it should not be that difficult to implement even in ALisp / VLisp. Basically just a form of interface to the .NET libraries. Very much the same as the VLisp's vlax mehods which interface with the COM / ActiveX libraries.
Admittedly, .NET & RDNZL are both a bit over my head, but I would like very much to learn (and have access to) .NET for my work. I am presently relegated to using VLIDE.Quote:
Originally Posted by irneb
Can you (or someone else?) clarify if RDNZL provides the capability to manipulate the SSM / .DST?
I have been wanting to do this for a very long time using Visual LISP, and have been informed that only .NET has this capability. If RDNZL is unable, then I might try adding Visual LISP support for SSM / .DST to the API Wish List!?
Any feedback would be greatly appreciated. :beer:
Unfortunately the biggest problem is due to AutoLisp not evolving as the other branches of Lisp has. It was originally taken from XLisp in the mid 80's and has not grown (in Lisp terms) at all. E.g. it has no object orientation as Common Lisp has; no way of defining optional arguments to a function; ratio / complex / vector / structure / hash table / class data types aren't included; many standard functions aren't available (e.g. floor, ceiling, round); etc. Never mind added library access like DotNet (or even direct ObjectARX) ... the only thing ADesk deemed important enough was ActiveX, but only because someone else already did it for them: when Vital Lisp added these in the 90's, ADesk purchased it and renamed it to Visual Lisp.
What I'd suggest to ADesk is to upgrade the AutoLisp / VisualLisp interpreter to match something like Common Lisp / Scheme. That way the old LSP files should still work, but the AutoLisp fraternity would have a huge extra feature set in a language which they're quite familiar with already.
I've bitten the bullet myself and started some stuff in VB.Net. It's a bit hard to get round at first, and (no matter what anyone tells you) DotNet is not as "simple" to use as AutoLisp (or even VBA) was. You have to create several extra stuff just to do the simplest of tasks. A lot can be done automatically through the VB.Net AutoCAD wizards, but you still need to know exactly where and what to add / remove / modify. The learning curve is a bit steep but the benefits are huge.
BTW, there are others who actually want a different language completely. E.g. PyAcad (Python-AutoCAD) is an extension to include a Python interpreter in AutoCAD / IntelliCAD. Such ideas could make it even simpler for the non-programmer to start customizing their ACad, since there are languages which are a lot less steep to learn, e.g. Compare the following:
C code:Lisp code:Code:void foo (int x)
{
if (x == 0) {
printf ("\nThe value is Zero");
} else {
printf ("\nThe value is ");
printf (x);
}
}
Python code:Code:(defun foo (x)
(if (= x 0)
(print "The value is Zero")
(progn
(print "The value is ")
(princ x)
)
)
)
Pascal code:Code:def foo (x) :
if x == 0 :
print "\nThe value is Zero"
else :
print "\nThe value is "
print x
Which looks the least cryptic to you?Code:procedure foo (x : Integer);
begin
if (x = 0) then
writeln ('The value is Zero')
else
writeln ('The value is ', x);
end;
A full "dot-NETting" of LSP may have been deemed a waste of time given the new Mac OS port. We can always hope they are working on upgrading the VLISP editor with both systems in mind *without* messing things up too badly.
Thanks for the info Irneb!
*Many* of the "New Features" for AutoCAD (specifically those pertaining to 3D modeling) were culled from Maya (i.e., view cube, prospector, etc.).
Sidebar... I have screen shots of Maya in the early 2000's of the View cube, etc. before AutoCAD ever purchased Maya. lol. What AutoCAD *needs* to cull next from Maya is the "Hot Box!" (Yes, that's an actual feature) ... Alas, I digress.
Back on topic... Interestingly, Maya has (for a long time) had Python support, along with MEL. I wouldn't be surprised if the Python interpreter was available in the near future (to Win OS), *especially* as AutoCAD is now making (short?) strides toward supporting an OS X platform.
Beta testing AutoCAD for Mac, AutoCAD supports LISP, but had no VLIDE which I found to be ridiculous. In contrast, I understand the need for a third party app for .NET development (i.e., Visual Studio), but for LISP!? Autodesk really fell flat in my opinion.
I wouldn't mind using Python myself, with the following caveats:Quote:
Originally Posted by RenderMan
Now here's a "biggie" :mrgreen:. Since the Mac version, what's happening to DotNet? I thought it was only on M$ operating systems? Sorry, you tested this - I've yet to have the pleasure.
- There needs to be some way of interacting directly with existing LSP files and PY files - so not everything needs to be rewritten in PY.
- Alternatively there must be a translator from LSP to PY (similar to C# and VB.Net) which has no hangups whatsoever.
- We'll need an integrated PYIDE same (if not better) than VLIDE. You're correct, I'd hate to debug a LSP without VLIDE ... same would go for PY (or whatever else). Fortunately there are ways to setup ACad to have the debugging work properly in VB.Net / C#.
That *IS* the question, isn't it!?Quote:
Originally Posted by irneb
Seemingly all 'flavors' of AutoCAD are shifting that way (toward .NET), for example look at Revit.
You'll find this interesting:
Quote:
Originally Posted by Wikipedia, Carbon (API)
... Perhaps will there be an Objective-C based IDE in the future? :mrgreen:Quote:
Originally Posted by Wikipedia, Cocoa (API)
Now there's a thought! I just think ADesk is letting themselves up for some huge amounts of extra libraries and / or inconsistencies. They'd be better off making use of an interpreted language (i.e. AutoLisp or such) - since they'll then not need to have several different API's for each platform (e.g. what if they also add a Linux-Gnome version of ACad? Do they then need yet another library for X11?).Quote:
Originally Posted by RenderMan
I'd think the easiest method would be to leave the DotNet stuff as is, but create a wrapper-translator library to match DotNet to the native OS's libraries. Similar (but in reverse) to what Delphi/Kylix does with its Borland Foundation classes mapping onto the Windows libraries as well as the Linux libraries - no need to modify source code to compile for another platform.
I too would be interested in a reply regarding the .NET API when used on a Mac version of AutoCAD. I am a Mac user at home and would definitely prefer an OSX version of AutoCAD over a PC platform anyday. The main concern I have is the intergration of custom routines on a Mac OS versus a PC OS. Any information would be greatly appreciated.
At present: No. You will only be able to use LSP addons until ADesk makes some form of runtime DLL converter / linker for Mac. And I don't think the extended Lisp (VLAX stuff for ActiveX/COM) would necessarily work on Macs as well. So you're stuck with only working Lisp as a macro language (i.e. sending commands to ACad) or working with DXF data.Quote:
Originally Posted by eptownie1988
See why I think ADesk should rather just extend AutoLisp to work with the new stuff?
I find it interesting that you post this today, as just yesterday I dove into writing an XCode application (using Cocoa/Objective-C) for fun. lolQuote:
Originally Posted by irneb
I for one *hope* that given OS X 10.6 (Snow Leopard) has a dominant C-based environment, and I'm sure Lion will have (later this year), that it will be possible (some day) for AutoCAD-Mac to have some sort of overhead that will support cross-platform development, given .NET's Common Language Runtime (CLR).
Perhaps (one day) an extension can be developed for Visual Studio, to allow this port-ability (pun intended).
As for Visual LISP on PC - I do wish that Autodesk would better empower ActiveX as, for example, in many Civil 3D Aec* entities, vlax-dump-object yields no results. I now am *forced* to use .NET which is a shame, given the VLIDE being built in (i.e., no 3rd-party install of VS).
... Guess that's why this thread is posted in the *Wish List* forum! :lol:
Does anyone know if M$'s replacement for VBA (called VSTA) works on Mac versions of M$ programs? I'm thinking stuff like MSO 2011 for Mac. If so then it's "really" time for ADesk to do a "true" replacement of VBA instead of just sticking their head in the sand with this .Net stuff. I know the main issue with porting to Linux is due to the .Net stuff not wanting to work too well in Wine - probably the same for Mac as it is actually a BSD (also derived from Unix as Linux was - just uses Coco instead of WinX11 / Gnome / KDE / etc.).
But I still think they'd be much better off just extending AutoLisp to directly work with everything .Net can do (actually everything ARX can do since .Net is also still behind that). Perhaps extend the ActiveX libraries, but I think that won't help Macs too much though - still DLL / OCX files. It should become native to AutoLisp (like those layerstate functions were added in 2000 or so).
If they feel AutoLisp is too cumbersome / old / restricted / etc., then by all means add another scripting language like Python / Perl / JS / VBS / Ruby or even Java. Or even just upgrade the 20+ year old AutoLisp engine to one of the Current Lisp engines - that way there'd be very little porting needed from old LSP files.
And while they're at it extend the old defunct DCL language. Maybe have something similar to Mozilla's XUL.
Actually I've started a wiki on this subject. For planning on how to go about making such available to AutoLisp: http://alisp-ext.wikidot.com/
Let's face it, ADesk has some sort of aversion to lisp and simply wants to kill it through attrition! They've been trying for more than 10 years now, and it won't die. To the point where we've come full circle and find all these new programming languages like Python, Perl, Ruby, etc. having concepts exactly the same as Lisp had in the 60's.
And now also the stuff is creeping into C++/C# even. But still ADesk cannot see why they should even consider making AutoLisp into something comparable to its other big brothers.
Resources - time, money, manpower. And, the people in charge of implementing any LISP upgrade are professional programmers. I'm sure to them LISP in AutoCAD "isn't a REAL programming language", C#/VB .NET "just isn't that hard to learn" and "if you can't handle it get a real programmer to do it for you". But I could just be feeling pessimistic today :)
Yeah well ... if that is their opinion, then all I can say is: :screwy:
The only reason that AutoLisp is an inferior language to C++ is because THEY'VE NEVER UPDATED THE DAMNED THING IN 15 YEARS! If they made something comparable to CL then you'd have seen hundreds of user created addons which would surpass even ADesk's own vertical products in both functionality, efficiency & robustness!
Lisp is JUST THAT MUCH BETTER A LANGUAGE ... and I speak from experience! In all of C, C++, C#, VBA, VBS, VB, VB.Net, Java, JavaScript, PHP, ASP, Pascal, Delphi, ObjectPAL, and Lisp! Of all of them? My favourite is still Lisp!
I think this is funny given recent events at work.Quote:
Originally Posted by dgorsman
I'm Beta testing my state's DOT Civil 3D 2012 'Kit' which is meant to mirror their long time Microstation 'Kit'. Anyway, your comment is funny to me because they are NET obsessed, especially given their background in NET development for MS.
They do almost all of their coding in NET, not ARX, and then they don't know how to properly configure their development.
It's riddled with errors (not custom error messages) when their .NET commands are invoked in Drawing1.
They use a SCR in the App Icon (/b switch) to turn the ribbon on, and CUILOAD their CUIx file instead of simply using (setvar 'ribbonstate 1), and Enterprise CUI in their Profile respectively.
They took LISP code I provided them (defuns) earlier this year, and File Copy+Rename as ACAD.lsp which serves no purpose once you open another drawing, unless you SAVEAS. They should be using *.MNL instead anyway.
Never mind that they don't know how to enable demand loading of their NETLOADS via the registry, so I informed them (thanks to what I learned from Kean! LoL). So instead, they NETLOAD them all via SCR (mentioned above), then their Ribbon button macros are something like:
<<SmacksForehead>>Code:
^C^C_netload;<FileName>.dll;<CommandName>
These 'ubber-smart, professional programmers' have no clue how to deploy AutoCAD, let alone Civil 3D... But I guess their Windows forms are cool, ya know, for public workers. LoL
They're exhausting to continually correct. Especially for free. But I'm going to have to work with this 'Kit' at some point, and I'm trying to make sure it's fully operational.
<<Sigh>>
In any event - I'm still going to learn .NET development, because I don't know what the future has in store for me. If I end up not doing CAD for the rest of my life, I'd like to know that I have as many skills at my disposal as possible.
But under the assumption that I am able to continue doing CAD (and pay the bills!), then I too wish that ADSK would enhance VLIDE+API. I really began to notice just how much I enjoy LISP when jumping back and forth between C#/VB.NET and LISP. I kept writing code that was more complex than it needed to be... not declaring every data type (among other luxuries) is something I now can actually appreciate. LoL
Couldn't find anything newer in my quick search, note LISP's position in the results:
http://through-the-interface.typepad...250511e970c-pi
linky
Yep, and for those "professional" ASM'ers / C'ers / C++'ers / Net'ters who think Lisp is just not a language to consider: http://www.lispworks.com/products/my...d_legends.html
It actually sounds more like the other way round to me! Think about this:
- A language where you have very little to actually program (between 5 and 10 times less than those C/C++/C#/VB.Net textbooks to draw a line);
- Debugging is a breeze due to being able to run as interpreted and compiled interchangeably & mix-ably.
- Compilation can be fine-grained for safe/fast/extreme optimizations all the way between an entire project, a single file, a group of function, a single function, or even just one or more lines inside a function. Try that one with C!
- And then if you think it doesn't compile as efficiently ... most implementations of Lisp actually use a C compiler to produce native code ... so no, that's the exact same optimization you get from your own C compiler (never mind the slow, inefficient, and bloated C# / VB.Net)
- You don't need to worry about errors since it won't crash the entire system, not even the calling function;
- No need to know every little detail of compiled libraries if you want to reuse them, not to mention this same flexibility is available when communicating between Lisp and other languages;
- The code can extremely easily modify itself to suit an un-thought-of situation, allowing for general purpose programs, without needing to think of every possible eventuality
- The object orientation is so far in excess of what C++ / C# / VB attempts to even get to as to be in a CLASS of its own! Not even a benchmark to aim at for the others, rather a god in comparison to some pond-scum. Actually it was the very first OOo language to receive any form of standardization certificate and that from ANSI - while C was still floundering about with trying to affix some OO code to what's now known as C++. While the others were still grappling with concepts of inheritance, Lisp CLOS was evolving into something which took the concept of poly-morphism to all aspects of OO - back-and-forth between type / class / instance / method / property / etc. at any time including runtime. Thus CLOS is not just a Programming OO system, but also an Executing Modular Replaceable Object Orientation system - the others have no such concept at all!
- Absolutely consistent code, there's extremely simple grammatical rules, unlike the incredibly complex C / C++. Even much more consistent than the "try to be consistent" C# / VB.Net
- Built in types are at least comparable to the others, and in most cases in excess: E.g. you have to program your own Linked List in C, not so in Lisp!
- Extending the built-in types can even be done after you program has been compiled! Once you notice you need something extra, just run the code to add it - no need to even recompile to various platforms.
- Multi-tasking is built-into the very essence of Lisp. Even providing a portable threading concept - with C you need to do your threading native to the OS, so you can't simply recompile to a different environment.
Aaggghhh! I give up! If someone still believes C/C++ or even those DotNet things are "good" languages to waste your time in, then they're masochists - actually deriving pleasure from making their lives as difficult as possible.
... Or, as in my case, I'm going to be switching back-and-forth between Civil 3D and Microstation.Quote:
Originally Posted by irneb
LISP, while I truly enjoy developing with it, is only (partially) supported by one of the platforms I am expected to work with (C3D). Whereas .NET is supported by both, and with enhanced feature exposure.
Now, if you've got a way to extend LISP, I'd love to hear about it..? (<- Way above my skill)
Irneb, I saw the Wiki page you created (briefly)... so where does one begin to create the (vl-load-arx) type library functionality?
At present I'm not going down that road, though to make such would be a form of acedDefun. The original idea would have been to create a defun for each method / property of an entity.
What I'm now considering is (seeing as it's impossible to overwrite the AutoLisp interpreter inside the ACAD.EXE file) I'm working on implementing a secondary lisp interface. One which works similar to what the old VBA did (i.e. have CL-Load, CL-Run, etc. as commands, but also as AutoLisp defuns). That way you can at least call a *.lisp file to run in ACad.
The reason I'm not attempting to simply extend all the methods to defuns is it would be a huge task if I can't get some form of runtime code generation. In C++ that's just way too complicated, though in CL it's par for the course!
After I've got ECL working inside ACad I'll look at implementing acedDefuns from CL itself ... thus creating a direct link between ALisp and ECL - and using acedInvoke to also have a reverse link. That way old LSP/FAS files would work through the normal AutoLisp/VisualLisp interpreter, yet be able to communicate with the new LISP/FASL files loaded into the ECL interpreter - which in turn can link to ObjectARX classes (and if I further implement RNDZL it can link to DotNet as well). You see, all I need to do in order to have ECL link to ARX files is import the C++ header files (*.H) from the SDK - then it can generate CLOS classes from those directly and much more easily then generate the acedDefun's on the fly. If I wanted to do such in C++ I'd have had to code each one of those manually ... painful aint it?
Thus you can use your old code as is, and have anything new in the LISP file - able to extract data to and from each other. At least that's the plan. It's not perfect, but ADesk makes it impossible to make it perfect! The only spot where I'm bumping my head as yet is to get the C++ ARX which loads ECL as an in process interpreter. I'm trying to follow a similar path to what Kean did with that Python interpreter, though not implementing it through DotNet.
The reason I don't want it through DotNet is 2 fold: DotNet doesn't have a way of directly calling an AutoLisp function (so there's little change of making stuff like reactors and call-backs). But more importantly, I'd like this thing to work on all versions of ACad (even on Mac).
Speak of the devil:
New AutoLISP Functions in AutoCAD 2012 for Mac
^^ Posted today
It's no ARX equivalent, but at least they enhanced something!
8) Irneb, just curious, have you made progress with this?
Tom