I am interested in integrating language from another audio programming language (ChucK) into my Delphi project. I know that maybe that is possible with dynamic-link libraries (.DLLs) but I am not familiar with this.
Does anyone know how I can configure a project to get the two languages working together?
A quick glance at the ChucK documentation suggests three possible approaches, all arising from the fact that ChucK is both a language and also a virtual machine (VM) to run the programs written in that language.
ChucK is open source, so the full source code of that VM is available but is written in C++. ChucK is available either in this source code form or as a ready-to-run executable for the supported platforms.
I could find no reference to any DLL version of the VM for use within other programs. Which isn't to say that such a DLL has not been developed by others, only that I couldn't find any reference to one and it does not appear to be part of the standard distribution of ChucK itself.
I did find some source code which references a DLL in the context of ChucK but it was not entirely clear to me whether this was a DLL API for using ChucK or part of the implementation, allowing ChucK itself to be modularised or extended via DLL's.
The three options I see before you are:
Port the Chuck VM to Delphi. That is, translate all of the ChucK VM source code to Delphi. This will give you a version of ChucK implemented entirely in Delphi which is capable of running ChucK programs.
Implement a DLL API (possibly based around or starting from that link above) for the existing ChucK VM source code in C++ in a way that enables you run ChucK programs by calling into that DLL to be run by the existing C++ implementation of ChucK.
Run ChucK programs using the ChucK exe using ShellExecute(), WinExec() or CreateProcess() etc, just as you would if you wished to run any other external program from a Delphi program.
These are presented roughly in descending order of difficulty. That is, a full port to Delphi (Opt 1) is likely to be beyond your capability.
Implementing a DLL interface around the existing C++ code (Opt 2) may be possible depending on your C++ and Windows development skills.
Calling an external program (Opt 3) is relatively straightforward.
Which approach is right for you depends on the nature of your assignment, the objectives, and your confidence/skills in the areas involved.
Good luck.
An easy way to get different systems talking to each other is use Open Sound Control (OSC). ChucK has OSC receivers and senders (search for "> OSC") built into it and Delphi looks like it implements OSC as well.
OSC works over networks but you can also just send messages to your own local machine (localhost). The ChucK examples do this referenced above do this.
It's not a tight integration but it'll get the Delphi-ChucK relationship going.
Related
I’m trying to use Lua/Moonsharp API scripting. There’s a command library, but there isn’t a function that I need. My question is, am I able to create my own function, or am I limited to what’s been written?
Specifically, for a software called BobCAD a Lua plugin is available. There are lists of commands like Bcc.SetCamObjParameter, though, there isn’t the command that I need. I’m assuming that some aspects of the BobCAD software are inaccessible to API, but am I limited to the library in this plugin, or can I add my own commands? I thought that there would be some C# file somewhere in the program directory where I can read the functions and possibly learn how to create my own, but I don’t see anything like that. (Or are scripting functions set up internally to the software, and I’m only given access to what has been provided?)
(N.b. I'm not familiar with BobCAD specifically, but this answer should be generally applicable.)
Generally speaking, for use cases like this (where Lua scripting is provided as part of a larger program, or by a plugin for a larger program), it's the developer of the program or plugin who decides what API is available to Lua. In the latter case they may also be limited by what the program's plugin API allows; in the case of BobCAD you are likely limited to what the BobCAD plugin API permits, and then further limited by what parts of that API the developers of the Lua plugin chose to make available to Lua itself.
You can of course write your own functions in Lua, but in terms of actually talking to the host program you are restricted to the API that program makes available, unless they make available some mechanism (like LuaJIT's Foreign Function Interface) for reaching into the program from Lua and calling functions that were not made explicitly available -- which most do not.
As for finding "a C# file somewhere in the program directory" -- C# is a compiled language; C# libraries are generally shipped as pre-compiled CLR binaries (with a .dll extension) and do not contain source code. If the source code for BobCAD and/or the Lua plugin is available you could always modify it and re-compile it, but as BobCAD is commercial, closed-source software, I would not expect it to be available.
At that point, your options are basically:
figure out a way to do what you need with the commands that are available;
try to reverse engineer enough of the program to do what you need without access to the source code;
or look for another program that has the features you need.
I'm moving from windows programming (By windows programming I mean using Windows API) to Linux Programming.
For programming Windows, the option we have is Win32API (MFC is just a C++ wrapper for the same).
I want to know if there is something like Linux API (equivalent to WINAPI) that is exposed directly to the programmer? Where can I find the reference?
With my little knowledge of POSIX library I see that it wraps around part of Linux API. But what about creating GUI applications? POSIX doesn't offer that. I know there are tons of 3rd party Widget toolkits like gtk, Qt etc. But I don't want to use the libraries that encapsulates Linux API. I want to learn using the "Core Linux API".
If there are somethings that I should know, please inform. Any programmer who is familiar with both Windows & Linux programming, please map the terminologies of Linux world so that I can quickly move on.
Any resources (books,tutorials,references) are highly appreciated.
I think you're looking for something that doesn't exactly exist. Unlike the Win32 API, there is no "Linux API" for doing GUI applications. The closest you can get is the X protocol itself, which is a pretty low level way of doing GUI (it's much more detailed and archaic than Win32 GDI, for example). This is why there exist wrappers such as GTK and Qt that hide the details of the X protocol.
The X protocol is available to C programs using XLib.
What you must understand is that Linux is very bare as to what is contained within it. The "Core" Linux API is POSIX and glibc. Linux is NOT graphical by default, so there is no core graphics library. Really, Windows could be stripped down to not have graphics also and thus not have parts of the win32 API like GDI. This you must understand. Linux is very lightweight compared to Windows.
For Linux there are two main graphical toolkits, GTK and Qt. I myself prefer GTK, but I'd research both. Also note that GTK and Qt exist for Windows to, because they are just wrappers. If you go take a look at the X protocol code for say xterm, you'll see why no one tries to actually creating graphical applications on top of it.
Oh, also SDL is pretty nice, it is pretty bare, but it is nice if your just needing a framebuffer for a window. It is portable between Linux and Windows and very easy to learn. But it will only stretch so far..
Linux and win aren't quite as different as it looks.
On both systems there exists a kernel that is not graphical.
It's just that Microsoft doesn't document this kernel and publishes an API that references various different components.
On Unix, it's more transparent. There really is a (non-GUI) kernel API and it is published. Then, there are services that run on top of this, optionally, and their interfaces are published without an attempt to merge them into an imaginary layer that doesn't really exist.
So, the lowest GUI level is a the X Window System and it has a lowest level library called Xlib. There are various libraries that run on top of this one, as you have noted.
I would highly recommended looking at the QT/C++ UI framework, it's arguably the most comprehensive UI toolkit for any platform.
We're using it at work developing cross platform apps that run on windows, osx and linux.
It also runs on Nokia's smart phone Operating System Maemo which has recently been merged with Intel's Moblin Linux OS, now called MeeGo.
This is going to sound insane since you're asking about "serious" stuff like C++ and C (and the "core linux API"), but you might want to consider building in something else. For instance:
Java Swing (many people love it! Others hate it and call it obsolete)
Mono GTK# (C# or VisualBasic or whatever you want, lots of people say it's pretty cool, but they're not not that many people)
Adobe AIR (ActionScript, you might hate it)
Titanium (totally new and unproven, but getting a lot of buzz in the iPhone world, at least)
And many other possibilities, some of which let you work on multiple platforms at once.
Sorry if this answer is not at all what you're looking for. The "real" answers on Linux are "pick a toolkit," which is also no answer at all :)
Have a look at Cairo. This something roughly similar to GDI+ and is under the hood of some of of the few usable GUI programs for Linux i.e. Firefox or Eclipse (SWT). It wraps most the natsy and ancient Linux stuff for you into a nice API that runs on most Linux installations without locking you into a entire subsystems like GTK or QT.
There is also the docs for the two different desktop platforms: Gnome and KDE that might help you down that road.
I have the source in delphi of an open source electrical solver (OpenDSS)
Normally, when installing OpenDSS, the engine is registered as a COM component.
I want to compile the engine 8 times making 8 differente dll's that internally are exactly the same. Why? because I want to use 8 mono-core solvers at once to perform monte carlo simulations.
The problem is that by simply renaming the dll's and registering them, windows recognize them as the same COM component. So the question is; What changes shall I make in the source so when I compile the library I cheat windows?
I hope que question is clear enough, and thank you in advance.
Naively, the answer to your question is to make eight different versions of the code that are identical apart from having different CLSIDs. Keep all the IIDS of the exposed interfaces the same, but vary the CLSIDs. That allows you to register eight distinct COM servers with different CLSIDs to identify them. But you request the same IID from each COM object that you create.
This is a pretty vile solution though. It doesn't scale very well. It's expensive of memory. It's just really unwieldy. It would surely be possible to make the code threadsafe. Usually this can be done by locating the globals and dealing with them. Typically by converting them into parameters or state.
If you cannot manage that then you could create a stub executable to allow the server to run out-of-proc. Then instantiate separate instances of the out-of-proc server.
I'm currently starting to integrate "Delphi Web Script" in my application basically only as a scripting engine (interfacing with functions, classes, etc.); awesome software for the standard delphi open source quality in my opinion, but just for curiosity,
What's exactly the "web part" of the project?
How is intended to be used?
It was used somewhere with some success commercially?
Thanks!
As ain said, the original use was for PHP-like, ASP-like server-side web-page generation, but it was also capable of general purpose use, which is what I used it for. And as I did not use the "web" side of DWScript, most of the "web-oriented" features haven't been ported over (only the HTML Filter was ported actually).
The Web functionality is still available in the SourceForge repository, if someone wants to tackle the port. Though, they may be outdated beyond simple renamed methods and classes, as since DWSII, the script engine has gained various features. For instance, it is now capable of multiple thread-safe executions of a single compiled script, while the old codebase is built around the limitation that a compiled script can be executed by only one thread at a time.
On the other hand, there are some new features that could simplify the porting, the simple WebServer demo recently added uses RTTI to expose TWebResponse & TWebRequest f.i. (was manually exposed in DWSII). On the down side, that's only possible with recent Delphi versions.
AFAIK the main focus of the original author of this scripting engine was to make it possible to embed Pascal scripts into HTML pages, just like ie PHP does it. Hence the name "Delphi Web Script". While the focus of the current maintainer, Eric Grange, is on using it as a general purpose scripting engine, it should still be possible to use it for web purposes as well - for that you use the "filters" feature of the library. Check out the dwsHtmlFilter unit for HTML filter.
I want to develop an application that can retrieve information such as, DLL version, DLL build mode(debug or release), info. regarding OS, memory, processer, processes/threads, program version etc. I am developing this mainly for Windows, but it'd be good if the application supports Linux too(wherever applicable).
I am basically a java programmer, and I know C, C++ to some extent.
Which programming language should I go for, that'd make my job easy? i.e. which language has APIs to fetch these kind of information?
Well... APIs are available regardless of the language... But the easiest way to get at what you are trying to do is going to be a C or C++ app. That doesn't mean it'll be easy (getting a DLL version is easy, getting memory and processor type is easy. The other stuff is certainly possible, but you may have to roll up your sleeves and learn the win32 API).
You might want to take a look at an application that already does exactly what you are asking about (Process Explorer) before you try to develop this yourself... It's going to be a big undertaking - and the folks at Sys Internals are really, really good at this stuff, and have already done it.
You commented on Kevin Day's answer that you would prefer to use Java for this.
Java is not very well suited for this, because the information you want to get is very platform-specific, and since Java is designed to be platform-independent, there are not a lot of ways to get at this kind of information from Java.
There are some methods in classes java.lang.System and java.lang.Runtime to get information about the platform that your Java program is running on. For example, class Runtime has a method availableProcessors() that tells you how many processors are available to the Java virtual machine. Note that this is not the same as the number of processors (or cores) that exist in the computer; the documentation even says that the number may change while the program is running.
Lookup the documentation for java.lang.System and java.lang.Runtime for more information.
Most likely you're not going to get exactly the information that you need by using pure Java - C or C++ will be better suited to get this kind of platform-specific information. If you would need this information from a Java program, you could write a small DLL or shared library and use JNI to call into it from your Java program.
Since DLLs are mentioned I presume we are talking about Windows.
I would recommend using WMI queries. They look very much like SQL and give you access to many very useful classes.
e.g. all info about the OS can be found here - in W32_OperatingSystem:
http://msdn.microsoft.com/en-us/library/aa394239(VS.85).aspx
You can use WMI classes from any language including C++.
As a side note - if you start a new application from scratch consider using PowerShell - new scripting language from Microsoft.