I am starting a new project with some 3D CAD objects to be generated from a specific domain data. I can code it with c++ using OpenCascade but I prefer to use Python if possible. There are two popular occ python bindings: pyOCCT and PythonOCC, both projects are active and up to date with occ 7.4 but it will be great to have an advice from someone who knows both. As pyOCCT is a newer project, I suppose it solves something that PythonOCC does not, but it is not clear what was the motivation to create a new binding. I will need some web rendering support, apparently PythonOCC already support web rendering.
A little background: I was working on a project and using pythonocc. It's a great project, but at the time was stuck on OCE (OpenCASCADE Community Edition) v6 and OpenCASCADE (official) had since released v7+ with a lot of performance improvements. I attempted to update pythonocc wrappers to v7+ but with 7+ they made much more use of c++ templates and I couldn't get a handle on how to do this in SWIG. When I tried doing this with pybind11 it seemed like a more natural fit (and I was able to get it working). So, I started pyOCCT to wrap OCCT 7+ using pybind11.
Since then, pythonocc has updated its wrapper process and now targets OCCT, so you can't go wrong with either if you are just looking for access to OCCT in Python. Pythonocc has a larger user base so you will likely find more people to collaborate with.
I've tried to keep up with SMESH and recently started up a pySMESH project for CAE applications if that is relevant to your work. That is only compatible with pyOCCT. Though again, with some extra effort you could probably write SWIG wrappers for SMESH instead of pybind11 ones if you really wanted to, making it compatible with pythonocc.
pyOCCT is based on pybind11 template library which is simple and powerful. PythonOCC is based on SWIG which is rather complicated. I have tried both, pyOCCT looks more attractive and perspective, especially if you need to add your own wrappers for some purpose. However, I do not use web rendering at all.
Neither. Use CadQuery's OCP instead, because OCP is the only OCCT Python wrapper to internally use a sane clang-based binding generator. OCP is thus roughly analogous to PySide2, which also internally uses a sane clang-based binding generator to generate its Python bindings.
Meanwhile, pyOCCT uses the hand-rolled pybind11 binding generator that requires C[++] headers to be modified with pybind11-specific macros. Since pybind11 does not leverage clang, neither does pyOCCT. Bizarrely, there's actually a downstream binding generator ambiguously named "Binder" that does leverage both pybind11 and clang. Of course, pyOCCT doesn't use Binder.
All else being equal, what you're usually looking for when choosing between higher-level language bindings to lower-level language frameworks is whether those bindings use clang or not. Prefer clang-based bindings to ad-hoc bindings that try (and usually fail) to parse C[++] with hand-rolled lexers and parsers. C[++] is a dark pit of lexical, syntactic, and semantic edge cases you never want to parse with non-standard toolchains.
Trust clang. Distrust everything not clang. This is the way.
Related
For the sake of experimentation, I am looking for a way to modify some of Ruby's base code, specifically the parser. I was wondering if this was possible to do at all, let alone using a Gem.
I have narrowed the code I need to change to static int yylex() within parser.c. I was going to try to use an alias, but that seems to require that I change parser.h, which cannot be done within a Gem, as I understand.
Can this be done from a Gem?
No.
The only base C code that gems have access to is that exposed by the Ruby headers.
The parsing/lexing code is not exposed there.
If you want to define custom syntax, I would try (in order):
Loosen your requirements a bit and define a DSL. Ruby has insanely powerful metaprogramming features that can take anything you might do statically in a script and instead do it dynamically during runtime
Write your custom parser in Ruby and emit valid Ruby which you then eval. Ugly, and probably a little slow, but will allow you to do anything you want.
Modify the mruby parser instead. mruby is designed for embedded applications where you want to be able to highly customize the capabilities of the VM. I doubt that they had the parser in mind, but still it might be more feasible than messing around with MRI.
I would like to know which FFI interfaces are supported and functional in Pharo 4, which ones are recommended (if any), and if there are some big changes planned in the future Pharo versions.
Especially I would like to know which stable FFI callback mechanism is available, and what are its restrictions and limitations.
Sorry for taking so long.
Currently, in Pharo you have two possibilities (and three packages –projects– to tackle them).
Out of the box in Pharo 4 you have NativeBoost-FFI who uses ASMJIT as a backend to generate native calls. That means super fast calls, but not so fast callbacks (because it uses some hard trick to make the VM calls back properly).
You can find examples of it all around the source-code, you can take a look specially at NBBasicExamples class.
You also have FFI plugin which implements a more traditional approach. You have to packages to handle this:
FFI, who implements callouts using pragmas (no callbacks). You can install it from the configurations browser and it comes with a set of examples.
AlienFFI, another package to handle same library FFI handles, but implementen a more "alien" approach (each function is an object, not a method). This implements callbacks properly and with good performance.
Installation is a bit more tricky because it has not been (yet) tested in Pharo 4 (so it is not in the configurations browser) but it should load fine.
You can find it here: http://catalog.pharo.org, along with instructions on how to install it (name is OldAlien, because of historical reasons).
All of them are very stable, but we will do some changes in the close future:
We will add a backend for NativeBoost-FFI to use the FFI plugin. The reason is our difficulty to maintain current version and the fact we can find more maintainers willing to work in C than in ASM :)
This change should be backward compatible so you are safe-to-go with NativeBoost.
Hope this info works for you.
Variations of this question have been asked, but not specific to GNU/Linux and C. I use Komodo Edit as my usual Editor, but I'd actually prefer something that can be used from CLI.
I don't need C++ support; it's fine if the tool can only handle plain C.
I really appreciate any direction, as I was unable to find anything.
I hope I'm not forced to 'roll' something myself.
NOTE: Please refrain from mention vim; I know it exists and what its capabilities are. I purposefully choose to avoid vim, which is why I use Komodo (or nano on the servers).
I don't think that a pure console refactoring tool would be nice to use.
I use Eclipse CDT on linux to write and refactor C-Code.
There exists also Xrefactory for Emacs http://www.xref.sk/xrefactory/main.html
if a non console refactoring tool is o.k for you as well.
C-xrefactory was an open source version of xrefactory, covering C and Java, made available on SourceForge by Marián Vittek under GPLv2.
For those interested, there's an actively maintained c-xrefactory fork on GitHub:
https://github.com/thoni56/c-xrefactory
The goal of the GitHub fork is to refactor c-xrefactory itself, add a test suite, and try to document the original source code (which is rather obscure). Maybe, in the future, also convert it into an LSP C language server and refactoring tool.
C-xrefactory works on Emacs; setup scripts and instructions can be found at the repository. Windows users can run it via WSL/WSL2.
You could consider coding a GCC plugin or a MELT extension (MELT is a domain specific language to extend GCC) for your needs.
However, such approach would take you some time, because you'll need to understand some of GCC internals.
For Windows only, and not FOSS but you said "any direction..."
Our DMS Software Reengineering Toolkit" with its C Front End can apply transformations to C source code. DMS can be configured to carry out custom, complex reliable transformations, although the configuration isn't as easy as typing just a command like "refactor frazzle by doobaz".
One of the principal stumbling blocks is still the preprocessor. DMS can transform code that has preprocessor directives in typical places (around statements, expressions, if/for/while loop heads, declarations, etc.) but other "unstructured conditionals" give it trouble. You can run DMS by expanding the preprocessor directives out of existence, or more imporantly, expanding out the ones that give it trouble, but mostly people don't like this because they prefer to keep thier preprocessor directives. So it isn't perfect.
[Another answer suggested Concinelle, which looks pretty good from my point of view. As far as I know, it doesn't handle preprocessor directives at all; I could be wrong and it might handle some cases as DMS does, but I'm sure it can't handle all the cases].
You don't want to consider rolling your own. Building a transformation/refactoring tool is much harder than you might guess having never tried it. You need full, accurate parsers for the (C) dialect of interest and just that is pretty hard to get right. You need a preprocessor, symbol tables, flow analysis, transformation, code regeneration machinery, ... this stuff takes years of effort to build and get right. Trust me, been there, done that.
Introduction:
I am currently developing a document classifier software in C/C++ and I will be using Naive-Bayesian model for classification. But I wanted the users to use any algorithm that they want(or I want in the future), hence I went to separate the algorithm part in the architecture as a plugin that will be attached to the main app # app start-up. Hence any user can write his own algorithm as a plugin and use it with my app.
Problem Statement:
The way I am intending to develop this is to have each of the algorithms that user wants to use to be made into a DLL file and put into a specific directory. And at the start, my app will search for all the DLLs in that directory and load them.
My Questions:
(1) What if a malicious code is made as a DLL (and that will have same functions mandated by plugin framework) and put into my plugins directory? In that case, my app will think that its a plugin and picks it and calls its functions, so the malicious code can easily bring down my entire app down (In the worst case could make my app as a malicious code launcher!!!).
(2) Is using DLLs the only way available to implement plugin design pattern? (Not only for the fear of malicious plugin, but its a generic question out of curiosity :) )
(3) I think a lot of softwares are written with plugin model for extendability, if so, how do they defend against such attacks?
(4) In general what do you think about my decision to use plugin model for extendability (do you think I should look at any other alternatives?)
Thank you
-MicroKernel :)
Do not worry about malicious plugins. If somebody managed to sneak a malicious DLL into that folder, they probably also have the power to execute stuff directly.
As an alternative to DLLs, you could hook up a scripting language like Python or Lua, and allow scripted plugins. But maybe in this case you need the speed of compiled code?
For embedding Python, see here. The process is not very difficult. You can link statically to the interpreter, so users won't need to install Python on their system. However, any non-builtin modules will need to be shipped with your application.
However, if the language does not matter much to you, embedding Lua is probably easier because it was specifically designed for that task. See this section of its manual.
See 1. They don't.
Using a plugin model sounds like a fine solution, provided that a lack of extensibility really is a problem at this point. It might be easier to hard-code your current model, and add the plugin interface later, if it turns out that there is actually a demand for it. It is easy to add, but hard to remove once people started using it.
Malicious code is not the only problem with DLLs. Even a well-meaning DLL might contain a bug that could crash your whole application or gradually leak memory.
Loading a module in a high-level language somewhat reduces the risk. If you want to learn about embedding Python for example, the documentation is here.
Another approach would be to launch the plugin in a separate process. It does require a bit more effort on your part to implement, but it's much safer. The seperate process approach is used by Google's Chrome web browser, and they have a document describing the architecture.
The basic idea is to provide a library for plugin writers that includes all the logic for communicating with the main app. That way, the plugin author has an API that they use, just as if they were writing a DLL. Wikipedia has a good list of ways for inter-process communication (IPC).
1) If there is a malicious dll in your plugin folder, you are probably already compromised.
2) No, you can load assembly code dynamically from a file, but this would just be reinventing the wheel, just use a DLL.
3) Firefox extensions don't, not even with its javascript plugins. Everything else I know uses native code from dynamic libraries, and is therefore impossible to guarantee safety. Then again Chrome has NaCL which does extensive analysis on the binary code and rejects it if it can't be 100% sure it doesn't violate bounds and what not, although I'm sure they will have more and more vulnerabilities as time passes.
4) Plugins are fine, just restrict them to trusted people. Alternatively, you could use a safe language like LUA, Python, Java, etc, and load a file into that language but restrict it only to a subset of API that wont harm your program or environment.
(1) Can you use OS security facilities to prevent unauthorized access to the folder where the DLL's are searched or loaded from? That should be your first approach.
Otherwise: run a threat analysis - what's the risk, what are known attack vectors, etc.
(2) Not necessarily. It is the most straigtforward if you want compiled plugins - which is mostly a question of performance, access to OS funcitons, etc. As mentioned already, consider scripting languages.
(3) Usually by writing "to prevent malicous code execution, restrict access to the plugin folder".
(4) There's quite some additional cost - even when using a plugin framework you are not yet familiar with. it increases cost of:
the core application (plugin functionality)
the plugins (much higher isolation)
installation
debugging + diagnostics (bugs that occur only with a certain combinaiton of plugins)
administration (users must know of, and manage plugins)
That pays only if
installing/updating the main software is much more complex than updating the plugins
individual components need to be updated individually (e.g. a user may combine different versions of plugins)
other people develop plugins for your main application
(There are other benefits of moving code into DLL's, but they don't pertain to plugins as such)
What if a malicious code is made as a DLL
Generally, if you do not trust dll, you can't load it one way or another.
This would be correct for almost any other language even if it is interpreted.
Java and some languages do very hard job to limit what user can do and this works only because they run in virtual machine.
So no. Dll loaded plug-ins can come from trusted source only.
Is using DLLs the only way available to implement plugin design pattern?
You may also embed some interpreter in your code, for example GIMP allows writing plugins
in python.
But be aware of fact that this would be much slower because if nature of any interpreted language.
We have a product very similar in that it uses modules to extend functionality.
We do two things:
We use BPL files which are DLLs under the covers. This is a specific technology from Borland/Codegear/Embarcadero within C++ Builder. We take advantage of some RTTI type features to publish a simple API similar to the main (argv[]) so any number of paramters can be pushed onto the stack and popped off by the DLL.
We also embed PERL into our application for things that are more business logic in nature.
Our software is an accounting/ERP suite.
Have a look at existing plugin architectures and see if there is anything that you can reuse. http://git.dronelabs.com/ethos/about/ is one link I came across while googling glib + plugin. glib itself might may it easier to develop a plugin architecture. Gstreamer uses glib and has a very nice plugin architecture that may give you some ideas.
Are there any plugins or built-in methods in Vim for performing refactoring on C or C++ code, something like the refactoring tools in Eclipse?
I'm especially keen on the extract method refactoring tool from Eclipse that will determine parameters from new methods and typically also guess a variable to use as the return value.
No, although Vim is a good environment for editing, and can be customised in a lot of ways (code folding, syntax colouring, macro expansion etc.) most of these are done on the syntax level, rather than the semantic level. Even the code folding just matches up opposing braces.
To do a proper refactoring, you have to have a lot of semantic knowledge about the AST, what variables are declared in which scope, and so on. IDEs like Eclipse build up a cache of the variables defined in each lexical scope, so that they can quickly refer back to where they are used in terms of determining what to rename and where.
That's not to say that you can't do some things syntactically; after all, one can just take out a block of code and put it into a separate function easily enough. You might even be able to guess at some parameters (e.g. find a list of the variables, find out which ones have local declarations, remove them and what's left are your parameters. But Eclipse also does other things—like figuring out whether any variables are modified in the function, and ensuring they're passed back by the return value. It also checks for any thrown exceptions, and add them to the list.
The net effect is that whilst you may be able to approximate some of these in Vim, you really aren't going to be able to get this working in a Vim-only enviornment. You could either use a Vim-like keybinding in Eclipse proper, or look at eclim. From the home page:
The primary goal of eclim is to bring
Eclipse functionality to the Vim
editor. The initial goal was to
provide Eclipse’s java functionality
in vim, but support for various other
languages (c/c++, php, python, ruby,
css, html, xml, etc.) have been added
and several more are planned.
Eclim is less of an application and
more of an integration of two great
projects. The first, Vim, is arguably
one of the best text editors in
existence. The second, Eclipse,
provides many great tools for
development in various languages. Each
provides many features that can
increase developer productivity, but
both still leave something to be
desired. Vim lacks native Java support
and many of the advanced features
available in Eclipse. Eclipse, on the
other hand, still requires the use of
the mouse for many things, and when
compared to Vim, provides a less than
ideal interface for editing text.
That is where eclim comes into play.
Instead of trying to write an IDE in
Vim or a Vim editor in Eclipse, eclim
provides an Eclipse plug-in that
exposes Eclipse features through a
server interface, and a set of Vim
plug-ins that communicate with Eclipse
over that interface.
This not only gives an Eclipse-like environment, it is Eclipse. But you still get the navigation and text editing features of vim. It sounds like this might suit your needs, although the documentation on refactoring support doesn't indicate that it provides an extract method functionality.
I've written a generic refactoring plugin. C++ is one of the primary languages handled (as it's my primary language at work). Method extraction is supported.
For C++, the plugin is able (thanks to ctags) to deduce most (but unfortunately not always all -- thanks to ctags...) of the variables coming in and out of the extracted function.
I still have to write a little dialog box to select how the in/out variables shall be exchanged (const ref, rvalue ref, copy, pointer, tuples, struct, and so on) (BTW, help is welcome as GUIs are not my thing ^^').
After searching high and low for vim with refactoring for C++, this is the best solution I have come up with.
Visual Studio 2013 and higher - Great IDE for C++ development and debugging, but does not have sufficient refactoring or vim
Install the vsvim plugin - Now, you have all the vim navigation, searching, string replacement, etc. (Some advanced features are not supported)
Install Resharp C++ - Great for refactoring at the cost of speed. It makes it a bit clunky, but if you want to infer auto generate methods/variables, rename local/global/method variables or functions, Search for usages in the solution, and more features, makes it extremely worth it.
This is the best combination I found for C++ development, debugging and refactoring. Makes me at least 3x - 5x faster. Hope it helps you as well.