Author Topic: Extending AutoLisp - Let's start with format  (Read 12571 times)

0 Members and 1 Guest are viewing this topic.

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Extending AutoLisp - Let's start with format
« on: August 13, 2011, 08:49:56 AM »
While we know ALisp (and even VLisp) is way behind most other flavors some of the added functions can quite easily be made to work using only the normal lisp base we already have. As a start point I wanted to implement the Common Lisp's format function. This is quite a comprehensive convertion function from several different value types into a string. See the help here:
I suppose it would have been a lot simpler if we also had something like regular expressions to play with. But unfortunately the only place we can use them is through ActiveX. And of course then you end up with the lisp function not working on Mac!

Anyhow, I tried to at least do the absolute minimum (i.e. strings, decimals & scientific).
Code: [Select]
(defun rtof (num dec dig / ex m f)
  (setq ex 0 m (< num 0) num (abs num) dig (max dig 1))
  (while (> num (expt 10 dig)) (setq num (/ num (expt 10 dig)) ex  (+ ex dig)))
  (while (< num (expt 10 (- dig))) (setq num (* num (expt 10 dig)) ex  (- ex dig)))
  (strcat (if m "-" "") (rtos num 2 dec) "E" (if (>= ex 0) "+" "") (itoa ex))
)

(defun format (dest str lst / *error* DimZin format-convert format-calc current)
  (defun *error* (msg /)
    (if DimZin
      (setvar 'DimZin DimZin)
    )
    (or (not msg) (wcmatch (strcase msg) "*ESC*,*QUIT*,*EXIT*") (princ (strcat "**Error: " msg)))
  )
  (setq DimZin (getvar 'DimZin))
  (setvar 'DimZin 0)
  (defun format-convert (code val / s n d)
    (cond ((wcmatch code "*[sS]") val)
          ((wcmatch code "*$") (format-convert "2,D" val))
          ((wcmatch code "*[dDeE]")
           (cond ((wcmatch code "*`,*")
                  (setq d (if (wcmatch code "`,*")
                            nil
                            (atoi code)
                          )
                  )
                  (while (wcmatch code "*`,*") (setq code (substr code 2)))
                  (setq n (atoi code))
                  (setq s (if (wcmatch code "*[dD]")
                            (rtos (float (abs val)) 2 d)
                            (rtof (float (abs val)) d n)
                          )
                  )
                  (repeat (- n (strlen (itoa (atoi s)))) (setq s (strcat "0" s)))
                  (if (< val 0.0)
                    (strcat "-" s)
                    s
                  )
                 )
                 ((wcmatch code "#*") (rtos (float val) 2 (atoi code)))
                 ((= (type val) 'REAL) (rtos val))
                 (t (itoa val))
           )
          )
    )
  )
  (defun format-calc (str lst / s)
    (cond (current
           (cond ((wcmatch current "*[DdEeSs$]")
                  (setq s       (format-convert current (car lst))
                        current nil
                  )
                  (strcat s
                          (format-calc
                            str
                            (if (cdr lst)
                              (cdr lst)
                              lst
                            )
                          )
                  )
                 )
                 (t (setq current (strcat current (substr str 1 1))) (format-calc (substr str 2) lst))
           )
          )
          ((wcmatch str "`~*") (setq current "") (format-calc (substr str 2) lst))
          ((eq str "") "")
          (t (strcat (substr str 1 1) (format-calc (substr str 2) lst)))
    )
  )
  (if (atom lst)
    (setq lst (cons lst nil))
  )
  (setq current (cond ((= dest t) (princ (format-calc str lst)))
                      ((= (type dest) 'FILE) (princ (format-calc str lst) dest))
                      ((and (= (type dest) 'SYM) (= (type (eval dest)) 'STR))
                       (setq dest (strcat (eval dest (format-calc str lst))))
                      )
                      (t (format-calc str lst))
                )
  )
  (*error* nil)
  current
)
My next iteration of the code would be to work on Engineering Notation (i.e. having a number like 123456 display as 123.456e03 instead of the usual 1.23456e05). I'm gessing it should work with something like a format code of "~,3E".

Anyone want to give a try at incorporating other features of CL's format function are welcome! Or just simplifying / optimizing / fixing the code of course  8) ... I'm trying to steer clear of the vl-string-* functions to try and make it useful on Mac (or other) as well.
« Last Edit: August 13, 2011, 07:11:10 PM by irneb »
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Extending AutoLisp - Let's start with format
« Reply #1 on: August 13, 2011, 12:28:16 PM »
OK, fixed a small typo, consolidated, created the rtof function (for floating points) and implemented engineering notation:
Code: [Select]
;;; Code updated in original post ;;;As an example:
Code: [Select]
_$ (progn (princ (format nil (strcat "This is ENG notation ~3,3e, while this is normal scientific ~3,e\n"
"and here's decimal ~3,3d, while this is currency ~$,\n"
"and finally a string ~s")
'(123456 76543 34.6 45 "TEST"))) (princ))
This is ENG notation 123.456E+3, while this is normal scientific 7.654E+4
and here's decimal 034.600, while this is currency 45.00,
and finally a string TEST
« Last Edit: August 13, 2011, 07:10:36 PM by irneb »
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Extending AutoLisp - Let's start with format
« Reply #2 on: August 13, 2011, 12:34:15 PM »
Or to illustrate another "fix" I did  :lmao: :
Code: [Select]
_$ (format nil "As int ~d, as decimal ~3d, as engineering ~2,3e, as scientific ~2,e, as currency ~$" 123456)
"As int 123456, as decimal 123456.000, as engineering 123.46E+3, as scientific 1.23E+5, as currency 123456.00"
Allows for repeating the same value in several places in the string.
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Extending AutoLisp - Let's start with format
« Reply #3 on: August 13, 2011, 07:14:05 PM »
Actually rereading the CL docs I've just realized I've swapped around the precision & field-length codes. Not to mention I'll need to rethink the way I extract their values as there's a posibility of having more than 2 modifiers per code.

Anyhow, it's getting late  :ugly: ... I'll figure out something at some other time.
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9484
Re: Extending AutoLisp - Let's start with format
« Reply #4 on: August 13, 2011, 10:36:54 PM »
I'm not all that great with lisp any more but I would be willing to help as much as I can.

At one time I tried to recruit people to start building a standard library of functions but no one wanted to help. However I did develop a tool to help with the library assembly and use (relating to "code coupling" issues). If you want/need help I will see what I can do but please do not get your hopes up; like I said, I'm a bit out of pratice with lisp.
TheSwamp.org (serving the CAD community since 2003)

Donate to TheSwamp.org

Jeff H

  • Needs a day job
  • Posts: 6075
Re: Extending AutoLisp - Let's start with format
« Reply #5 on: August 13, 2011, 10:49:03 PM »
Not familiar with Lisp either but maybe a way to learn would be to help write a dll using .NET that lisp can call for things not able to do with lisp or hard to deal with.

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Extending AutoLisp - Let's start with format
« Reply #6 on: August 14, 2011, 06:35:50 AM »
Se7en & Jeff: Thanks for the interest. Greatly appreciated!
 
 I guess the "best" way would be to go with an ARX route, since those .Net stuff isn't actually "portable" as M$ claims (at least not to Mac/Linux). AFAICT the only way to get something truly "upgraded" for lisp would be to redo the entire Lisp interpreter in ARX. I cannot find any hint anywhere on how to start that!
 
 Anyway, I have been looking at other Lisp dialects and come across ECL (which seems to have promise). Though my C++ skills are rusty to say the least! The last time I did anything in it was in 1998. Recently I've started adding such Lisp-callable functions through .Net, but as there's some issues ... I'm starting to have the opinion that .Net's just not good enough! E.g. not running on Mac (need to compile to dylib through Mono - which still has an issue), unable to call a lisp routine directly (i.e. events / reactors can't be implemented), worse code security than Lisp (since .Net's too easy to decompile), etc. If anyone knows of a way to run DotNet from ACad for Mac, please share! That would make this a whole lot simpler.
 
 The closest thing I could find about implementing a new language in ACad is Kean's block on Python. But again that uses .Net  :ugly:
 
 I was thinking it would be possible to use ECL directly through C++. And it "shouldn't" be a huge transition, since ECL can be incorporated into C. It can even load C libraries/dylib/so directlyso liking to ObjectARX classes would be possible directly from the ECL interpreter. Thereafter the ACad specific defuns (like entget, entmod, etc.) could be implemented in ECL itself - basically wrapping the ObjectARX methods. That way you'd have an AutoLisp/VisualLisp -backwards-compatible interpreter which can now extend and run ObjectARX code. And since ECL is a near full implementation of CL you get the "new" functions from there as bonus!
 
 But the biggest reason I'm starting to think ECL is the way to go is it can already run as interpreter, compile to portable bitcode (i.e. FASL), or use a C compiler to compile to native executable. That way performance would be on par with all the current extension possibilities (even those of direct ObjectARX in C++). Not to mention the code obfuscation requirement (as with .Net's code security issues) becomes a non-issue when you compile.
 
 IMO it should be a way of getting the best of all worlds: Allow old LSP code to run as-is; make new much more powerful addons directly in Lisp; run such as true portable (no need to try and steer clear of the vl stuff which doesn't run on Mac); have a way to get true code security; have near full C++ optimizations; etc. All I can see which might cause hassles is old code using ActiveX connection to outside programs, since wrapping the vla functions to directly connect to ObjectARX could be done direct in ECL; but wrapping to the CreateObject is an infinite task.
 
 Then to go further and redo the VLIDE by replacing it with something like Scintilla. It already has CL code formatting / completion / etc. And finally speaking to the guys from OpenDCL about making an embeddable version of their suite so we can have a visual dialog IDE.
 
 So it should be a way of compiling an ARX library per ACad version, per OS/environment - which should overwrite the Lisp interpreter
 
 This thread is basically me trying to do the idea from the opposite end, though I know it's doomed to failure as much will simply be unavailable! It's like an attempt at making some of the full CL functions available to the distant (read left in the gutter) cousin AutoLisp.  :lmao:
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9484
Re: Extending AutoLisp - Let's start with format
« Reply #7 on: August 14, 2011, 10:51:20 AM »
> redo the entire Lisp interpreter
I was making a AutoLisp Parser (I guess  you would call it a "first step" towards an interpreter). But I know/knew it was a throw-away project before I started it (It was never really going to see the light of day; it was more of an exercise for me).

But back on topic:

I think I found some COM "stuff" (Let me down-play that because I haven't read the docs on it  yet; I just found it 10 minutes ago) so we could in theory tap into all that ARX `stuff'.  I will read the docs later but from what I did read it was very limited. From my readings a while back (aka my memory) g++ doesn't do COM, gcc does but not very well.

I don't have a Mac (I have Linux or BSD) and trying to cross-compile for OS X is just plain stupid, I will have to do some more reading up on the subject and give it some more thought (I'm still waiting for the coffee to finish making).
TheSwamp.org (serving the CAD community since 2003)

Donate to TheSwamp.org

LE3

  • Guest
Re: Extending AutoLisp - Let's start with format
« Reply #8 on: August 14, 2011, 01:37:21 PM »
At least for me - an x-lisper -
Another of why this was not posted at least 10 years ago... when i was way on the mood for lispy stuff... then it could be of interest.

:)

All the luck on this adventure !

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Extending AutoLisp - Let's start with format
« Reply #9 on: August 15, 2011, 09:01:41 AM »
Doing lots of research on the net I've come across an old implementation of Corman Lisp as an ARX module for R14: http://autocad.xarch.at/lisp/cormanlisp/

It's literally the ONLY piece of code (I could find after several hours of searching) which even remotely shows some promise. I've even inspected the DLL/ARX's in the acad folder to see what exported functions they have. Not too sure what's happening inside that vl.arx (which I think is the main lisp interpreter), but at least there's some indication of what's needed in the CLARX.

I've just realized (or rather remembered) why I stopped using C++ so long ago! Looking at that source code it just looks like a mess! But that's C++ isn't it?  :pissed:

Anyhow, the other option is as Jeff's mentioned: Create DotNet/ARX wrappers for lisp to work with the newer objects in the API. Basically doing what ACad should have done at the very least ... instead of wasting their time in designing new bugs to put into the new versions  :ugly:

I'd like some opinions as to which you'd think would be the most efficient & least cumbersome way forward (please give some reasons). So I (or perhaps we  :angel: ) can make an informed decision before going and wasting more time down a path which heads to a cliff-face!  :lmao:
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9484
Re: Extending AutoLisp - Let's start with format
« Reply #10 on: August 15, 2011, 10:11:54 AM »
First things first:
I'm a bit confused as to what exactly is the goal. I understand we want to "extend" Alisp but I think we should determine some hard-fast goals to reach first.

I'm all for the C++ route (I quit doing ALisp to pursue C++ [aka: higher learning] awhile ago) but obviously theSwamp's user base isn't in the same frame of mind any more (It seems most people here/now prefer using a hammer to put frosting on a cake just to show off their hammer-cake-frosting-abilities).

I think we should choose something more along the lines of a STD library of functions that can be used (Like what you started to do above). We would need to address certain issues first but I think that goal could work out to be better in the long run; -e.g. when I tried to start "the standard library project" I knew Reni's Std library had a problem of being highly coupled so I addressed that problem by making a preprocessor (The `better' being that now the ALisp users have a preprocessor to use in development). I also think our efforts may have more participants if we choose a goal that more can help with (like a standard library written in plain ALisp). After we define some solid documentation we can, in theory, get a bunch of members to just start writing code and have a committee approve/fix/adjust as needed (The desire to actually participate and learn seems to be down from what it used to be here but I think we can muster up a few people).

Benefits:
Cross-platform is less of an issue.
More potential participants
    Give a wider ability level a chance to participate.
Use of theSwamps SVN


On topic:
Now that being said; I will still try to create a small project to see if I cant tap-into a COM dll without COM (that info I think I found above) but this task alone will take a lot of time and is only a fraction of step one of our current route.

Can Jeff's wrapper work in the Mac OS X environment (I thought it couldn't--I know *nix doesn't have COM so...)?

If you need me I will be knee deep in that code you call a mess :D
TheSwamp.org (serving the CAD community since 2003)

Donate to TheSwamp.org

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9484
Re: Extending AutoLisp - Let's start with format
« Reply #11 on: August 15, 2011, 10:35:39 AM »
Has anyone heard of CORBA? I hadn't. It works on Windows and *nix.

Heres a wikipedia link.
http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture


**EDIT:
Okay, I guess that route isn't the best choice.
« Last Edit: August 15, 2011, 10:45:38 AM by Se7en »
TheSwamp.org (serving the CAD community since 2003)

Donate to TheSwamp.org

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Extending AutoLisp - Let's start with format
« Reply #12 on: August 15, 2011, 10:53:37 AM »
Thanks. That's the point! I don't want to re-invent the wheel, neither do I want to re-invent the square wheel, and I certainly don't want to rip out the hammer in order to invent these wheels! I just wanted to know which direction to follow, perhaps a combination (i.e. ARX where Lisp has no chance, and direct in Lisp where it's possible)? BTW, http://autocad.xarch.at/stdlib/ seems as an old version of such library created directly in ALisp.

As for the extension through ARX/COM/NET, it would probably be better going with C++ for portability at least. Only then we'll need to compile for each Version / OS alternative of course.

About the "mess", I only said it looks like a mess ... but that may be due to me having much more experience in VB/C#/Java/Delphi/Lisp. They're cleaner & more "elegant" languages. It's definitely not to say C++ can't be made "elegant" either, it just usually isn't done that way.

Anyhow, I was throwing out the different options available. Whatever we decide I think we should try to steer as close as possible to CL's functions, it's a quite mature language and has come a long way through many revisions. Also it's one of the main lisps used, thus making an ALisper much more able to port his knowledge to other branches as well.

Glad of the help! If you can give me some hints on how to go about the C++ stuff I'd be willing to get stuck into that side myself as well.

Anyhow, this is an example of some of the libraries I've done previously: http://caddons.svn.sourceforge.net/viewvc/caddons/Libraries/Lists.LSP?revision=56&view=markup Though many of those use vl functions which I'm unsure if they work on Mac (or BC in Wine on Linux).
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9484
Re: Extending AutoLisp - Let's start with format
« Reply #13 on: August 15, 2011, 11:14:02 AM »
Yes, that is Reni's std library I was referring to. It is highly coupled (relies on itself a lot).

C++ is going to be a big problem. We need a way for the two languages to talk to each other. COM is used in Windows but COM doesn't exist in *nix. We would need to incorporate an IPC mechanism (interprocess communications [IPC]) of some sort (CORBA is one of many D-BUS, QtDBUS, ICE are others). As far cross platform code goes, Qt is the best bet (using D-BUS--QtDBUS to be specific-) but D-BUS/QtDBUS isn't supported on Windows.

TheSwamp.org (serving the CAD community since 2003)

Donate to TheSwamp.org

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Extending AutoLisp - Let's start with format
« Reply #14 on: August 15, 2011, 11:33:11 AM »
Qt is the best bet (using D-BUS--QtDBUS to be specific-) but D-BUS/QtDBUS isn't supported on Windows.
:lmao: So you mean we need to install CygWin to have ACad work on windows! What the... Don't let Adesk hear of that! They might have to divorce from M$!

I wonder if some form of RPC could be used? I know a lot of these inter-operating programs use that instead. As a matter of fact I think it's close to what Qt does in any case. Though I can't see a way of linking to such from the ALisp side, perhaps a small ARX just to allow that might do the trick. Though in such case it might even be possible to write a OS specific connector seeing as each ARX needs separate compiling anyway. So all that's really needed is the OS specific linking mechanism.
« Last Edit: August 15, 2011, 11:36:12 AM by irneb »
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Extending AutoLisp - Let's start with format
« Reply #15 on: August 15, 2011, 11:42:34 AM »
BTW, is there some form of reflection on Arx like you get with Net? Previously I thought this should have been possible quite easily by implementing a similar idea as the vlax-import-type-library does. If there's no reflection, then I can't really see a simple way of doing this.
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9484
Re: Extending AutoLisp - Let's start with format
« Reply #16 on: August 15, 2011, 11:51:51 AM »
For the sake of this conversation: ARX == COM. ...COM is a no-go on *nix.

I'm trying to find `some form of RPC' we can use but I still don't have access to the lisp interpreter--which is in ACAD.EXE BTW--and I doubt we will find or create one (I'm just not good enough to do anything like that).  We would better off communicating via txt files, or using SOAP (communicate via XML) between C++ and Lisp applications.

I gotta run. I'll check back later.
TheSwamp.org (serving the CAD community since 2003)

Donate to TheSwamp.org

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9484
Re: Extending AutoLisp - Let's start with format
« Reply #17 on: August 15, 2011, 11:52:53 AM »
Sorry, I don't know what reflection is so I don't know.
TheSwamp.org (serving the CAD community since 2003)

Donate to TheSwamp.org

dgorsman

  • Water Moccasin
  • Posts: 2422
Re: Extending AutoLisp - Let's start with format
« Reply #18 on: August 15, 2011, 12:09:10 PM »
System.Reflection namespace

Handy little corner of the .NET environment.  Haven't played with it yet, but I've seen others use it for doing things programatically at run-time rather than having to make decisions when writing code.
If you are going to fly by the seat of your pants, expect friction burns.

try {GreatPower;}
   catch (notResponsible)
      {NextTime(PlanAhead);}
   finally
      {MasterBasics;}

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9484
Re: Extending AutoLisp - Let's start with format
« Reply #19 on: August 15, 2011, 12:40:55 PM »
Thanks for the link dgorsman.

C++ (more specifically, the LLVM/CLANG compiler does JIT [just in time] compilation) but I'm not quite sure I know where you are going with this (JIT is used to increase runtime performance).
TheSwamp.org (serving the CAD community since 2003)

Donate to TheSwamp.org

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9484
Re: Extending AutoLisp - Let's start with format
« Reply #20 on: August 15, 2011, 02:20:25 PM »
Okay, I've re-read this thread and I think I should clarify my thoughts.

An ARX is an ActiveX DLL (nothing new here; everyone knows that). ActiveX is basically COM (to be a bit more specific; "you need COM to do ActiveX" ...maybe that's a better way of saying it). We can't make ARX's in *nix (Linux or Unix) and I doubt OS X (Mac) either because we don't have COM.

So we need a way for AutoLisp to talk to something written in C++. This is what I've been looking for; a way for me to pass information to and from with plain C++. If we can get a "communications channel" open we can *MAYBE* fix one of the other Lisp implementations you have found to use `it' (but if you have the ability to share information, I don't see the need to implement anything further; just make some functions/classes/etc available to lisp--think: "public" and "retval" in VB).

FWIW, Porting this mythical `communications channel' to Windows, Mac, and Linux is not just a small problem either.

Also, the methods and functions you have available to you are all--well, most of them--in the VL.ARX. This, as we know now, is just a fancy COM server (AutoCAD is the client). The COM subject is a rabbit hole to say the least. For example: I'm sure you have seen discussions on if you should release your objects or not "(vlax-release-object)". No one besides Autodesk knows this for sure because AutoCAD is the "COM client" and it needs to do the actual Releasing. I guess another way to think about that would be: what you are doing in AutoLisp is just saying that you don't need the communications channel open any longer. Whether or not AutoCAD is closing the COM channel is not available to you, nor should it. COM is extremely fickle. If you don't create and release properly, you can do some major damage.

I don't for sure, because I don't really care about Mac versions so I don't pay attention, but I would imagine that Autodesk is saying something like: "only vanilla AutoLisp is working in Mac versions"...well, we know that is all they could ever say at this point because they would have to use a different IPC mechanism for all those VL functions.

So we have a few choices, we either invent a new method for sharing information, use an existing one, or make a standard library.  ...I vote standard library. This way everyone can contribute.


I need to do some more reading.
« Last Edit: August 15, 2011, 05:30:43 PM by Se7en »
TheSwamp.org (serving the CAD community since 2003)

Donate to TheSwamp.org

LE3

  • Guest
Re: Extending AutoLisp - Let's start with format
« Reply #21 on: August 15, 2011, 03:03:33 PM »
Nope, it is a dynamic library that it is rename to arx, then it accessed via the entrypoint, for com you have to make your project be ATL - something that it is available via the arx wizard from the sdk, where you can built your skeleton much easier. hth

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9484
Re: Extending AutoLisp - Let's start with format
« Reply #22 on: August 15, 2011, 04:04:40 PM »
are there any options for us in *nix you see LE?
TheSwamp.org (serving the CAD community since 2003)

Donate to TheSwamp.org

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9484
Re: Extending AutoLisp - Let's start with format
« Reply #23 on: August 15, 2011, 04:39:55 PM »
Oh, I think I see what you are talking about (I found some ARX source code). It is just a DLL. ...MinGW wont be able to compile this.

I'm gonna download Visual Studio Express and the Autodesk SDK now.
TheSwamp.org (serving the CAD community since 2003)

Donate to TheSwamp.org

Jeff H

  • Needs a day job
  • Posts: 6075
Re: Extending AutoLisp - Let's start with format
« Reply #24 on: August 15, 2011, 07:45:08 PM »
I do not know what all is or not supported for MAC of course COM and GUI components are examples that will limit your library unless you are wanting to support 2 wich I guess you will anyways at least compling the code for each.

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9484
Re: Extending AutoLisp - Let's start with format
« Reply #25 on: August 15, 2011, 07:59:41 PM »
*sigh* I thought I had it all figured out. I thought I figured out a way to create a DLL with MinGW that could be called from lisp (this was to reproduce the non-com arx's PeterGabriel told us about). ...I hit not just one brick wall but three. *sigh*
TheSwamp.org (serving the CAD community since 2003)

Donate to TheSwamp.org

Jeff H

  • Needs a day job
  • Posts: 6075
Re: Extending AutoLisp - Let's start with format
« Reply #26 on: August 15, 2011, 08:03:59 PM »
The attachment might shed some light
 
 
 

LE3

  • Guest
Re: Extending AutoLisp - Let's start with format
« Reply #27 on: August 15, 2011, 11:10:23 PM »
are there any options for us in *nix you see LE?

The only info I have is this:
http://www.youtube.com/watch?v=los4uycOMJg&feature=player_embedded

From here:
http://arxformac.blogspot.com/

I remember reading a list (from a knowledge base about autocad mac)... of what it is supported and not, but lost the url link... all they say that autolisp is available as long there is no dcl, objectarx is available as long no mfc it is involved... etc.

HTH

LE3

  • Guest
Re: Extending AutoLisp - Let's start with format
« Reply #28 on: August 15, 2011, 11:43:52 PM »
Oh, I think I see what you are talking about (I found some ARX source code). It is just a DLL. ...MinGW wont be able to compile this.

I'm gonna download Visual Studio Express and the Autodesk SDK now.

I remember that was a way or a workaround for this, but again lost the url link... arx it is supported for visual studio pro/standard versions since they required the mfc libraries.... afaik - go to the dev center of autodesk: www.objectarx.com - for more info.


irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Extending AutoLisp - Let's start with format
« Reply #30 on: August 16, 2011, 03:44:07 AM »
OK, so basically you can compile ARX/DBX for Mac. Only you have to not only compile for 64bit OSX code, but it needs to be renamed to *.dylib for DBXes and *.bundle / *.framework for ARXes. Now for the "tricky" bit, what about BricsCAD for linux? It seems they have an API to compile their BRXes for linux:
Quote from: Bricsys Releases Bricscad V11 Pro for Linux
...is identical to the one for Windows. The sole difference is that it contains Linux-specific link libraries, instead of ones specific to Windows...
So I guess it compiles to *.so (shared object) files.

So that means ARX/DBX works fine on Mac (as long as you don't use any MFC stuff). BRX works fine on Linux and they have:
Quote from: Bricsys Releases Bricscad V11 Pro for Linux
...the BRX Linux SDK includes the Windows Platform Emulation Layer, which provides a large set of Windows API functions under Linux.
Which probably means that some calls to MFC would work there. Wish ADesk would do something similar to MFC->Cocoa, then you could create dialogs in your ARXes - and it might be possible to run ODCL through it.

Anyhow, the next step would be to check if a acedDefun would still be callable from Lisp on Mac/Linux:
Quote from: ObjectARX Reference Guide / Defining External Functions
... The following call to acedDefun() specifies that AutoLISP will recognize an external function called doit in AutoLISP, and that when AutoLISP invokes doit, it passes the function code zero (0) to the ObjectARX application:
acedDefun("doit", 0); 
The string that specifies the name of the new external function can be any valid AutoLISP symbol name. AutoLISP converts it to all uppercase and saves it as a symbol of the type Exsubr ...
So those thing "should" work, I guess...
Doing it from Lisp is not possible. As I've mentioned before, I was thinking to use a similar strategy as was done for the ActiveX stuff: i.e. have a few acedDefuns which would create linking functions on the fly to DotNet DLL's. This "should" be possible as you can use reflection on DotNet DLL's and then create defuns to link to each, or simply use a similar idea as per vlax-invoke, vlax-get & vlax-put. But the reason I asked about reflection on ARXes: Since DotNet's not available to Mac/Linux, the reflection on DLLs is a bit useless on those systems - even if you could make those defuns.

Though it seems reflection's only available on COM (ActiveX) and Net DLLs: http://www.codeproject.com/KB/DLL/Execute_DLL_Function.asp

Maybe this thread should be split in 2 though: One for implementing CL default library functions (which would mostly be possible direct through ALisp), the other about implementing ObjectARX calls as External Subs to be called from ALisp.

Edit: Possibly I should start a few Wiki pages somewhere to use as planning for these functions? Just so we can make sure of naming conventions & standardizing argument lists!
« Last Edit: August 16, 2011, 03:47:45 AM by irneb »
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Extending AutoLisp - Let's start with format
« Reply #31 on: August 16, 2011, 06:40:01 AM »
OK I've started a Wiki on wikidot: http://alisp-ext.wikidot.com

If you want to contribute please apply to join there. I should receive notification through RSS feed so it might take a day or so at worst  :whistle: .
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Extending AutoLisp - Let's start with format
« Reply #32 on: August 17, 2011, 09:37:36 AM »
I've just come across a small utility which installs with VC. It's called DumpBin ... usually found in C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin

This thing can list all the exported functions of any compiled DLL. As sample I ran it on Vanilla 2011's acad.exe file (it works the same on any ARX/DLL as well). The first lot has weird prefixes & suffixes (perhaps something to do with their return values / argument types, though I wouldn't know). At the bottom seems to be much more familiar stuff ... which are listed in the help files as well.

Then of course this put me in mind about the .h header files found in the SDK's inc folder. How hard could it be to generate something like an XML from those. One which lists which file it comes from, what the entry point to the function is, what data types are returned and used as arguments. Then have a run-time parsing of functions from this XML. Something like an arx-invoke defun, requiring an object, the method's name, and a list of arguments. If the object is a string, then search for such DLL/ARX/EXE/dylib/so/framework/bundle/etc. and create the entry object from there, or if there's more than one in that file, then have it listed in the xml? Same applies for the arx-get and arx-put. Perhaps we could even go further and do some arx-react functions which then works on the events - using acedInvoke to call the Lisp reactor call-back function when the event occurs.

This way there's only a few functions to be written. No need to wrap the entire ObjectARX into acedDefun calls. That's handled at runtime!

And to make it into one ARX only, that XML could always be compiled into the ARX as a resource.
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

Jeff H

  • Needs a day job
  • Posts: 6075
Re: Extending AutoLisp - Let's start with format
« Reply #33 on: August 17, 2011, 09:47:57 AM »
Search google with something like 'C++ name mangling'(decorated name) for more information
But since it was compiled with VS the decorated name would be microsoft specific,
For .NET you use dumpbin.exe for PInvoke to access a funtion in ObjectArx if it is not available in .NET API
 
64bit and 32 bit will vary
 
 
http://www.theswamp.org/index.php?topic=34278.msg395750#msg395750

Jeff H

  • Needs a day job
  • Posts: 6075
Re: Extending AutoLisp - Let's start with format
« Reply #34 on: August 17, 2011, 09:54:17 AM »
A example
Quote
        [DllImport("acad.exe", EntryPoint = "?acedGetUserFavoritesDir@@YAHPA_W@Z", CharSet = CharSet.Auto)]
        public static extern bool acedGetUserFavoritesDir([MarshalAs(UnmanagedType.LPWStr)] StringBuilder sDir);

John Kaul (Se7en)

  • Administrator
  • Needs a day job
  • Posts: 9484
Re: Extending AutoLisp - Let's start with format
« Reply #35 on: August 17, 2011, 02:01:28 PM »
This post will sound goofy and over simplified but hear me out and think about the first part a bit before moving on to the second part (think about the problems, moving parts, etc).

1

I have been reimagining this process.

I imagine that the "flow" may look something like this:
Call --> ARX --> Parser --> interpreter --> ARX --> Call

The parse and interpreter steps are/can be the same I suppose but what are we planning to interpret?

Symbols:
If we add the back tick (`) to AutoLisp we would need to parse it as a function with arguments and return valid AutoLisp code to be evaluated by the AutoCAD interpreter. However, I would guess this could/would/will be a problem for grey areas like variables (-i.e. variable scope).

Statements:
We could pass a statement like:
(+ 2 2)
This would just be an evaluated expression but also have to return a value.

2

All these ideas beg the question: wouldn't it be easier to create a new language to parse/interpret to std lisp code from?

-e.g.
def foo ( )
    print (+ 2 2);

generates:
(defun foo ( / )
    (princ (+ 2 2))
    )

We can have a standalone parser/interpreter which we call to generate lisp code from.


3

...Oh my head hurts! I think it's gonna explode. :)
TheSwamp.org (serving the CAD community since 2003)

Donate to TheSwamp.org

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Extending AutoLisp - Let's start with format
« Reply #36 on: August 18, 2011, 01:30:32 AM »
I've also had an "epiphany" this morning ... though I still need to test it. And it brings me back to that ECL thing, basically I'd incorporate the ECL interpreter into the ARX as a static library (i.e. no need to runtime linking). Then just have a command (similar to the old VBARUN, VBALoad, etc.) commands to load *.LISP / *.FASL files or input CL code direct onto the command line. Probably also create acedDefuns of each as well so they can be called directly from normal AutoLisp. Then the CL code can import the header files from the ObjectARX SDK already, which means that inside the CL code you can use the entire ObjectARX library as is (as long as you have the SDK). Perhaps if you then compile to FASL it would not need the SDK anymore, don't know if there's some other way to "incorporate" the headers without infringing on ADesk's licensing. But I can't see anything wrong with compiling it ... it's the exact same idea as compiling to ARX isn't it?

Anyhow, this would then enable us to keep the old AutoLisp/VisualLisp going as-is but have an easy link between it and the ECL interpreter/compiler. It should also then not need any RPC/other form of linking as it would be internal to the ARX and thus simply an in-process library call (no OS involvement at all). What I'd like to find out though is since CL also has the same open typed variables as AL has, would it need to convert to-and-from result buffers to communicate with AL? If not it would be worth the entire thing simply for this purpose!

I'll have to investigate though!

BTW, anyone know why VSC 2010 doesn't want to even open the 2011 ObjectARX SDK's samples? The VSC 2008 works fine though, perhaps I should just stick to that.
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Extending AutoLisp - Let's start with format
« Reply #37 on: August 21, 2011, 02:53:22 AM »
OK, I'm having trouble with just being able to create ANYTHING as an ARX. Firstly I'm on Win7-64bit. So VC-Express 2008 is problematic in the extreme in generating a 64bit ARX. Done some research and even starting it from the WinSDK 64bit's command-line has no effect. I can't even set the environment in any of the ObjectARX SDK's samples from Win32 to x64 (even if I manually add a x64 environment in VC).

So I then installed a virtual VBox WinXP-32 and ACad2008 with VC-Exp 2005 inside that. Also installed the 32bit WinSDK, but it doesn't seem to come with the LIB files required. E.g. a build of the clones project gives an error of:
Quote
LINK : fatal error LNK1104: cannot open file 'mfc80u.lib'
Doing a file search throughout the entire C drive give's no results. So I'm guessing that it's impossible to compile ARX's with the Express VSC? Is this true? Anyone got a way of how they get at least one of the samples to compile. I've used the clones one as it's one of those shown in the autodesk wiki for compiling on Mac using XCode.

Edit: And FWIW ... why does the clone example even link to MFC? Nowhere does it use such UI elements as ribbons and such! It's just working with DWG dictionaries & command-line options isn't it?
« Last Edit: August 21, 2011, 03:28:11 AM by irneb »
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

LE3

  • Guest
Re: Extending AutoLisp - Let's start with format
« Reply #38 on: August 21, 2011, 03:34:38 PM »
^

You cannot use the Visual Studio express version to generate an ObjectARX application.

For more information about the minimum requirements for ARX go to: www.objectarx.com

HTH.-

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Extending AutoLisp - Let's start with format
« Reply #39 on: August 21, 2011, 03:59:46 PM »
Ahh! Thanks. Good point. Silly me didn't go check all that.  :-[

Oh well, back to the drawing board I guess ... uhm, I wonder if that's prophetic  :lmao:
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

LE3

  • Guest
Re: Extending AutoLisp - Let's start with format
« Reply #40 on: August 21, 2011, 04:09:23 PM »
Ahh! Thanks. Good point. Silly me didn't go check all that.  :-[

Oh well, back to the drawing board I guess ... uhm, I wonder if that's prophetic  :lmao:

There are some options, for example if you are an student Microsoft gives the chance to download the VS pro for free (afaik) there is a site for this don't have it at this moment, or try to buy the standard version that it is cheap compared to the pro version.

HTH.-

gile

  • Water Moccasin
  • Posts: 2261
  • Marseille, France
Re: Extending AutoLisp - Let's start with format
« Reply #41 on: August 21, 2011, 04:53:38 PM »
Quote
or try to buy the standard version that it is cheap compared to the pro version.

There's no more standard version for VS2010, but it seems possible to have an 'Upgrade version' from any Visual Studio product (even Express Edition or Evaluation)
Speaking English as a French Frog

LE3

  • Guest
Re: Extending AutoLisp - Let's start with format
« Reply #42 on: August 21, 2011, 05:04:12 PM »
Ahh! Thanks. Good point. Silly me didn't go check all that.  :-[

Oh well, back to the drawing board I guess ... uhm, I wonder if that's prophetic  :lmao:

Also, when you get the chance to get the VS compiler, I have posted several ARX of my own samples around here at the swamp, i.e:

http://www.theswamp.org/index.php?topic=39237.msg444541#msg444541

To mention a simple one - that can be use as a guide.

HTH.-

Jeff H

  • Needs a day job
  • Posts: 6075
Re: Extending AutoLisp - Let's start with format
« Reply #43 on: August 22, 2011, 10:17:09 AM »
Ahh! Thanks. Good point. Silly me didn't go check all that.  :-[

Oh well, back to the drawing board I guess ... uhm, I wonder if that's prophetic  :lmao:

There are some options, for example if you are an student Microsoft gives the chance to download the VS pro for free (afaik) there is a site for this don't have it at this moment, or try to buy the standard version that it is cheap compared to the pro version.

HTH.-

https://www.dreamspark.com/default.aspx

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Extending AutoLisp - Let's start with format
« Reply #44 on: August 30, 2011, 03:10:57 PM »
Thanks, will get to those when I've got less deadlines (make those guillotines) hanging over my head.  :o   Not exactly any kind of student ... at least not in a legal sense, so will have to dock up the payment. Will have to look at what's involved in "upgrade" from express (kind of "strange" if you think about it).

Anyhow, had a "quick" look at BricsCAD on Ubuntu. Was greatly surprised that the vl functions worked perfectly. Now might that mean that ADesk's Mac version would also work with COM?
« Last Edit: August 30, 2011, 03:18:41 PM by irneb »
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

BlackBox

  • King Gator
  • Posts: 3745
Re: Extending AutoLisp - Let's start with format
« Reply #45 on: August 30, 2011, 03:20:46 PM »
Thanks for starting this!

I've just found this thread, and have only skimmed the first page (so far).

I am not sure how much help I can offer (most of this is above my head), but I wanted to throw my name in to at least try and learn.

Cheers! :beer:
"How we think determines what we do, and what we do determines what we get."