Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

I'd better learn LISP or C ++ to create extensions for BricsCAD

Ciao

Utilizzo il profilo di mio fratello perchè quello che ho fatto io non mi permette di fare domande (pietro_72_)

Ho l'hobby per la programmazione e sempre mio fratello m'ha chiesto se potevo fare una piccola estensione BricsCAD per collegarlo a CNC

Oltre a imparare ad usare BricsCAD quale linguaggio mi conviene inparare per provare a realizzare qualche estensione, LISP o C++ ?

Conosco un po' Python 2.xx, PHP e Javascript e correlati (PyOpenGL, Tkinter, PIL, SVG, x3dom), sto provando a realizzare un estensione per esportare in 3D da QCAD, si può vedere qualcosa sul mio sito (anche se inizio vari progetti ma poi non li completo :-D)

Pietro
http://creativitainformaticart.altervista.org/

Translation through Google

Hello

I use my brother's profile because what I did does not allow me to ask questions (pietro_72_)

I have a hobby for programming and my brother always asked me if I could make a small BricsCAD extension to connect it to CNC

In addition to learning to use BricsCAD what language should I use to try to make some extension, LISP or C ++?

I know a bit about Python 2.xx, PHP and Javascript and related (PyOpenGL, Tkinter, PIL, SVG, x3dom), I'm trying to make an extension to export in 3D from QCAD, you can see something on my site (even if I start various projects but then not complete them :-D)

Peter
http://creativitainformaticart.altervista.org/

Comments

  • Now it seems to work, thanks

  • Hi,

    For BricsCAD programming I would recommend you to invest into C++. Main reasons is if you work with CNC, rather you will work with 3D solids topology and geometry. This is allowed only on C++, LISP has no API to query face info.

    For programming BricsCAD it is sufficient to have C++ basics on C++ 11 level, understand memory management, virtual functions and some easy templates as smart pointers.

    Thus these books will be sufficient:
    https://www.amazon.com/gp/product/B00DUW4BMS/ref=dbs_a_def_rwt_hsch_vapi_taft_p1_i1
    https://www.amazon.com/Standard-Library-Tutorial-Reference-ebook/dp/B0085MNPQ6/ref=sr_1_1?keywords=stl&qid=1571975524&s=digital-text&sr=1-1

    The hard thing will be BRX API itself, i.e.:
    - accuracy in opening/closing objects
    - traversing the topology of the BRep
    - transactions
    But you can always open SR and we will share some sample code on working with BRep

    Best regards,
    Egor

  • @Egor Ermolin said:
    Hi,

    For BricsCAD programming I would recommend you to invest into C++. Main reasons is if you work with CNC, rather you will work with 3D solids topology and geometry. This is allowed only on C++, LISP has no API to query face info.

    For programming BricsCAD it is sufficient to have C++ basics on C++ 11 level, understand memory management, virtual functions and some easy templates as smart pointers.

    Thus these books will be sufficient:
    https://www.amazon.com/gp/product/B00DUW4BMS/ref=dbs_a_def_rwt_hsch_vapi_taft_p1_i1
    https://www.amazon.com/Standard-Library-Tutorial-Reference-ebook/dp/B0085MNPQ6/ref=sr_1_1?keywords=stl&qid=1571975524&s=digital-text&sr=1-1

    The hard thing will be BRX API itself, i.e.:
    - accuracy in opening/closing objects
    - traversing the topology of the BRep
    - transactions
    But you can always open SR and we will share some sample code on working with BRep

    Best regards,
    Egor

    What about .NET? Isn't is easier to learn than C++? What is the long run benefit in investing in C++? I don't have access to BRX SDK to judge the help, but the help for .NET is badly missing !

  • thanks for now
    I am more attracted to C ++ (in addition to Qt) also due to the possibility of creating applications or parts of applications that are faster than those that can be realized with interpreted languages in addition to the use of extending various CADs, in addition to the fact that with the right compilers the version of the program for multiple operating systems.
    I don't know much about .Net, but does it only work on Windows or does it also run on different operating systems?

  • Hi,

    I don't have yet experience on implementation of .NET, but can estimate pros:
    - guess it is more easy than BRX C++
    and cons:
    - it is updated with some delay in comparison with BRX API, so missing feature will first appear in C++
    - .NET is an extra wrapper layer so potentially may have more bugs than BRX

    For BRX the most tough part is to start the first application but you can find good samples in C:\Program Files\Bricsys\BricsCAD V19 en_US\API\brx . But for sake of the truth, there are .NET samples too C:\Program Files\Bricsys\BricsCAD V19 en_US\API\dotNet

    Best regards,
    Egor

  • OK, thanks
    Best regards also from me
    Peter

  • Having to learn c++ to use an API is bits. Every event API our there is based on .NET. No way should you need C++ to use an API, this is massive issue for me of the API requires C+
  • @tslewis71 said:
    Having to learn c++ to use an API is bits. Every event API our there is based on .NET. No way should you need C++ to use an API, this is massive issue for me of the API requires C+

    1. .NET is Windows only (despite the Mono project)
    2. C++ is available on all Windows/Linux/Max platforms, even for BRX
    3. C++ is much more performant than any .NET language
    4. C++ provides much more features - i.e. when a problem arises with .NET, there is for 98% always a solution at C++ level, but not at .NET level
    5. .NET was designed as "clean-room system", only fully compatible and workable with .NET host applications; but there is a massive design fault, when it comes to co-operation of .NET modules, to work with core C/C++ modules - .NET was never intended to work that way; and lhe later added "mixed-mode" is a hack, which can not fully solve the co-operation issues with native module; as conclusion, .NET is nice when a) performance does not matter and b) if the host system (for an extension module) is also plain .NET
    6. a C++ based API is the standard for APIs; and as C/C++ is older than .NET, the majority of APIs is in C/C++, naturally ... and .NET has to co-operate with real world (overlooked by MS, "fixed" by mixed-mode), but as mentioned, .NET is a "clean-room system"
    7. and besides, C++ language is clearly not that far away from C/C++/Java etc. :-)
  • Thanks for the summary Torsten. :)

    Does LISP run on the Linux version of BRX?

    What are the chances of linux BRX working with Mono so we can deploy our .NET solutions to linux BRX?

  • Mm ok, I guess you are the expert in APIS then. I have worked I multiple apis for various AEC programs from Tekla to sap to gsa to robot, NONE of them require one to code in c++ zero. The reason for .net is to allow non code experts to utilize apis, I’m not going to change career to be a computer scientist to learn c++. Please show ex panes or commercially available APIs that require one to code in c++? The whole point of an api is for it to be accessible to the masses - I’m not trying to access the kernel through c++
  • Calm down, take a breath.

    No one said you had to use C++. If you want to use .NET or LISP, you'll probably be alright.

    It's just that the C++ code runs a little closer to the CAD metal so to speak, you can pull stuff off with C++ that is more difficult or not possible with .NET.

  • Dear All,

    "Does LISP run on the Linux version of BRX?"

    you mean whether Lisp is available on BricsCAD Linux/Mac ?
    Yes, both Lisp + BRX C++ are available on Linux + Mac (while .NET is Windows only) :-)

    @tslewis71
    Yes, I know ans respect your position ... no doubts, that .NET can be useful ...

    "The reason for .net is to allow non code experts to utilize apis,"
    hmmm - but it requires some level of understanding of programming language(s) and code logic, right ? :-)
    From that point, programming in .NET languages is not that different from programming in C or C++ (the BRX API supports @tslewis71 and who says that C++ is complicate ? That is a kind of FairyTale, telling about C/C++ from the .NET programmers ...
    I could easily say the opposite :-)

    "I’m not going to change career to be a computer scientist to learn c++"
    ??? C and C++ are not that complicate to undderstand ... even Java has it's roots in a C++ (ObjectOriented) language ...

    But as mentioned, .NET API is available under BricsCAD Windows, no@tslewis71

    "Please show ex panes or commercially available APIs that require one to code in c++?"
    Easily :-) AutoCAD, MicroStation, ACIS, .... any 2d/3d CAD engine & Modeler have C/C++ APIs ... because of mentioend performance advantages of C/C++

    "The whole point of an api is for it to be accessible to the masses" Yes and No ... APIs originate from the need + intention to give professionals the ability to extend the CAD core (see AutoCAD's history with introduction of AutoLISP - that was the BigBang) ...
    which programming language is provided / used, depends on tons of conditions ... never put your point of view into foreground, there is always much more than you would assume (old programmer's rule :-) )

    many greetings & Merry Christmas :-)

  • Hello, tslewis71,

    maybe it was not clear from this task here ... there IS a .NET API available for BricsCAD, even installed with BricsCAD, see ./API subfolder :
    - Lisp
    - BRX C++
    - .NET
    - COM
    - TX (the core C++ SDK, slightly different from ARX/BRX C++)

    So as you see, not only .NET, but a wide range of APIs, mainly for (application-level) compatibility with AutoCAD ...
    many greetings !

  • edited December 2019
    I know the flames are strong from real coders but your comments are so in depth and are a bit Over my head which is why likely we have APIs in the first place to make the process of coding for non experts easier,

    With all due respect, C++ is a very difficult and obtuse language to learn for us non experts.

    . Net ie vb.net and c# also allows a simple hobbyist coder to have simple access to all the .net methods and libraries which are thoroughly documented online - I/o file operations, LINQ, system.drawing methods etc etc Another massive advantage of an api that is of a . Net flavor.

    I am just starting the api journey in bricsys but already I have seen that there is not one single api to access all functionality in one single flavor and one has to learn bits and pieces in different languages, again, I’m just starting with bricsys.

    If you study APIs such as used for rhino, grasshopper and dynamo they provide full exposure to the program with out having to code in lisp/c++, Tx. They are based around .net and python - which I’m not a fan of.

    I believe to access the BIM workspace in bricsys for instance this is not exposed in a . Net flavor ie c#\vb.net. Having to learn c++/lisp/bra to do this will be extremely painful. At least for my limited brain. Just my 2c
  • @tslewis71 said:
    I know the flames are strong from real coders but your comments are so in depth and are a bit Over my head which is why likely we have APIs in the first place to make the process of coding for non experts easier,

    With all due respect, C++ is a very difficult and obtuse language to learn for us non experts.

    . Net ie vb.net and c# also allows a simple hobbyist coder to have simple access to all the .net methods and libraries which are thoroughly documented online - I/o file operations, LINQ, system.drawing methods etc etc Another massive advantage of an api that is of a . Net flavor.

    I am just starting the api journey in bricsys but already I have seen that there is not one single api to access all functionality in one single flavor and one has to learn bits and pieces in different languages, again, I’m just starting with bricsys.

    If you study APIs such as used for rhino, grasshopper and dynamo they provide full exposure to the program with out having to code in lisp/c++, Tx. They are based around .net and python - which I’m not a fan of.

    I believe to access the BIM workspace in bricsys for instance this is not exposed in a . Net flavor ie c#\vb.net. Having to learn c++/lisp/bra to do this will be extremely painful. At least for my limited brain. Just my 2c

    Fully agree! Add to this very poor documentation, no active development community - compared to say AutoCAD, Rhino or SkechUP! No way to learn C++ or LISP!

  • @CADMebel said:
    Fully agree! Add to this very poor documentation, no active development community - compared to say AutoCAD, Rhino or SkechUP! No way to learn C++ or LISP!

    AutoDesks's LISP documentation is pretty good, I don't know about their C++ documentation. But if you have good documentation for their .NET API, I'd love to get a link, because I find what they have pretty bad. My understanding and experience so far is that BricsCAD development is fairly parallel to AutoCAD, with a few quirks as to be expected in a newer platform.

    For a good developer community, check out the swamp some knowledgeable people there working in both AutoCAD and BricsCAD.

  • Although I'm using BricsCAD daily at work, for my personal projects I decided to use Rhino - much better overall in terms of API documentation, community and help. Also I don't like the direction BricsCAD is taking - too much BIM, lack of new 3D tools development and this mixing of BIM, CAD, mechanical, sheet metal and etc. is getting confusing! We have xrefs, blocks, dynamic blocks, components, parametric blocks, layers, structure panel, layers panel, components panel, mechanical browser ...! Even we are using Platinum all the other stuff is there - too much "Unable to recognize command "XXXXXXXX". This error can occur when the command is not supported for the active license."

  • AutoDesks's LISP documentation is pretty good, I don't know about their C++ documentation. But if you have good documentation for their .NET API, I'd love to get a link...

    Check out Kean Walmsley's blog, Through the interface.
    For those considering lisp, .net, or c++, the biggest thing for most users is simplicity and not crashing cad.
    Lisp and .net are exactly that - simple enough and generally safe.
    It used to be that c++ had to be used for certain critical things. You can do most with .net now though, as it has transactions and so on.
    If someone that had little programming experience got steered to c++, that is a mistake IMO.
    You should at least learn .net first, as you can get more done fasterer, and learn about the structure of a dwg.
    A career programmer should consider all API's, as you will need them to implement tools at real companies.
    For instance, just managing the cad startup is best done with lisp. You don't want a compiled thing running you cannot troubleshoot on the spot on a remote machine.
    There are so many circumstances that would cause one to lean one way or the other, but I argue you learn from the bottom up:
    LISP, .net, then c++ if you need it.
    The cool thing is .net and c++ can make non cad programs so there are tons of help on the internet on stack overflow, adesk forums, theswamp.org....
    For those looking for lisp help, adesk customization group and theswamp.org are the hangouts. The you have blogs and afralisp.com for non-live help.
    Some say don't mention autodesk here. I believe the right answer is what to post, not politics, so oh well.

  • I see the flames have died down here ... so here I am!
    ok, ..NET is not "slow". If you want slow, do VBA. If you want really slow, do Lisp. .NET, it calls into the *.CAD C++ APIs so of course it is slower but how fast do you need to go? I have written quite a few apps in .NET for *.CADs and they're plenty fast enough for me. File IO tends to be the bottleneck more often than not, even on NvME SSDs but more obviously across networks.

    Here's a thread on C++ vs c# performance: https://stackoverflow.com/questions/145110/c-performance-vs-java-c if that's still important to you.

    What all these discussions fail to account for is your development time - add that to the execution time to get your real elapsed time. Now which language is faster? The one you know! Yeah, especially the "slow" ones.

    If you feel you need to work your way up to C++, @James Maeding 's post is good advice.

  • @Ewen Wallace said:
    If you want really slow, do Lisp.

    Have you done some serious testing with BricsCAD Lisp, which is generally much faster than AutoLisp, that substantiate this statement?

  • “Have you done some serious testing with BricsCAD Lisp, which is generally much faster than AutoLisp, that substantiate this statement”

    No. I was not aware BricsCAD Lisp was faster. I have written the same routines in the otherCAD in Lisp and C# and seen big performance differences. Well, maybe I just suck at Lisp? COM interop is a big factor for Lisp too. .Net has libraries for things like Excel interaction which are lots faster than COM.

    I moved away from AutoLisp years ago because .NET ran so much faster (for me. And the brackets. You’re still uneasy about the missing bracket 2 sentences who, right?

    Interesting point, if the syntax of a language doesn’t gel with you then you should try others. VB & C# are the obvious examples there. Whatever works for you is what works, eh.

    Thank you for letting us know about Lisp’s speed in BricsCAD.
  • Just as another data point, a friend of mine writes similar LISP routines to my C#(.NET) routines, and I don't think his LISP is slower than my .NET code. Could be that I'm bad at .NET, along with the fact that he's a ninja in LISP. We've tested similar routines on identical datasets, and it's hard to say which is faster. His LISP development is certainly faster, (no need to compile)

    Creating forms and palette interfaces is easier in .NET for sure though.

  • Interesting @Atook - looks like I stand corrected on that one. Anyone else got real-world experience? I'd like to hear more about this.

  • This idea of slow is quite relative. I don't think anyone using lisp will care about the speed difference between acad and bcad.
    The more important thing is how you use lisp.
    If you issue a bunch of "(Command "this" "that" "theotherthing"...), that will be the slowest way you can do anything.
    The next best thing is calling (Entmod...) if you are modifying things.
    The next best is (Entmake...), which is as fast as you can go in lisp - having said that, I wonder if the com interface functions like VLA-ADD.... are faster.
    I doubt it, here is why:
    The lisp and com API's use a single "database transaction" per entitiy mod or make. Jerry Winters mentioned this way back in 2006 AU.
    People that have never seen arx or acad .net code have no idea about this, and its one of those golden nuggets to discover.
    If you want speed, use .net or c++ api, and you can do as much as you want in a single transaction. Its 1000x faster.
    Not only that, you can make entities in memory and show them on screen, in place of what grdraw/grvecs does in lisp, and 1000x faster.
    I'm sure the c++ guys can offer other speed ideas, but that single transaction one is the key.
    My advice, learn both lisp and .net (C#), don't bother with c++ unless you intend to do really special things, in which case you will not need my advice as you know what you are doing.

  • If you are interested in learning more about the speed of BricsCAD Lisp, and how you can make your Lisp code run faster check out the LDSP.

  • @Roy Klein Gebbinck
    Another good point. In acad, you can compile a lisp "project" to .vlx, which cannot be decompiled, and also, super important, you can compile to "separate namespace".
    That means the global vars and functions in your prog cannot be accessed or overwritten by other lisps/progs in the session.
    That is a big deal to me as I commonly tweak functions by the same name in different lisp files.
    You cannot compile to "separate namespaces" with bcad. The .des files it creates are not separate namespace.

    The really cool thing about compiling to .vlx and .des though, is you get one file to load, even from a project with 100 files.
    That, and the code is gibberish if looked at in text editor.
    I highly recommend using the LDSP to compile to .des for those reasons.
    Note that I generally do not accept .des files from others, except developers I know and trust. Same with .vlx or .net dll's.

  • @James Maeding

    Quote from the LDSP:

    Since BricsCAD V18.2, the LISP engine supports the "VLX NameSpace" feature for DES encrypted LISP files, which allows to isolate LISP symbols (functions, variables) to the scope of the particular, DES encrypted LISP file.

  • @Roy Klein Gebbinck
    Yah, keeping up with Torsten is not easy. Awesome!

  • @James Maeding said:
    @Roy Klein Gebbinck
    Yah, keeping up with Torsten is not easy. Awesome!

    Sure is.
    Torsten has implimented dos_mkdir with the new V20.2.02 update amongst other things :-)

    : (dos_mkdir "c:\\temp\\mysubfolder\\anothersubfolder")
    "c:\\temp\\mysubfolder\\anothersubfolder\\"
    

    Regards,
    Jason Bourhill
    BricsCAD V20 Ultimate
    CAD Concepts

  • Hmm, I replaced doslib a few years ago in my apps, making lisp functions using .net.
    Many people do not realize you can do that. Then you have the billions of .net programmers out there for help.
    The main thing that got me started on that was a decent folder selection/creation dialog.
    I ended with:

    super handy as you can copy and paste paths, make new folders, and select multiple paths at once.

    dlg.jpg
    492 x 494 - 79K
    dlg.jpg 78.8K
Sign In or Register to comment.
Origami
Origami is the Japanese word for paper folding. ORI means to fold and KAMI means paper and involves the creation of paper forms usually entirely by folding.

Powered by VanillaForums, Designed by Steam