I've been reading the D Cookbook and near the beginning there's the following sentence:
D is binary compatible with C, but not source compatible.
SAS allows users to define and call C functions from within SAS. But I'm wondering, would it'd also be possible to do this from D?
I found Adam Ruppe's answer to create a DLL here, and I tried using that to create the DLL example from the SAS documentation; however, whenever I go to call it, the dll gets loaded, and then SAS proceeds to crash (without any crash log that I can find).
Yes, you can write DLLs in D which use or implement a C API.
You have to make sure that the function signatures and calling conventions match. In the page you linked, the calling convention is indicated as stdcall, so your D functions need to be annotated with extern(Windows) or extern(System).
Related
I come from Java backgrounds and the problem of packaging is as follows then:
I can have many files under the same package, say com.parobay.io. I can then distribute this as a library, and the users will use it like this:
import com.parobay.io.Input;
import com.parobay.io.Output;
or
import com.parobay.io.*; // to import everything
So I can have a single "module (com.parobay.io) and classes defined in multiple files.
So how to I achieve the same in D? Do I have to create a directory com\parobay\io and there place two files called Input.d and Output.d or is there a smarter way?
In Java the rules are very strict, so it's hard to get it wrong. In D there are many possibilities. So are there any conventions, like one class per file, or file name equal to the name of class?
You can choose to do it basically the same as Java, though remember these items:
import foo.* doesn't work in D, but you CAN make a file called package.d in the directory which manually lists public import foo.Input; public import foo.Output; etc. which allows you to import the whole package.
ALWAYS put a module com.parobay.io.Input; or whatever line at the top of any file that is imported. Don't expect it to just work based on directory structure and filename. The directory structure actually isn't strictly necessary, it is just a convention to easily find the file. The module line at the top with the name is the authoritative thing the compiler checks.
D modules often have all lowercase names, but you can use uppercase ones if you like. I think it is nice to use a lowercase name like the class name, so you might call the module io.input and the class Input. The reason for this convention is sometimes filename case gets lost when transferring from system to system. But developers are pretty aware of case so in practice either way should work.
One class per file will work fine or you can put two tightly coupled classes together in the same file (they'll have access to each other's private members if they are in the same file).
See this page for more info: http://dlang.org/module especially search for the heading "Package Module"
Don't use two separate files for your Input and Output classes. Instead, put both classes in a single file, parobay/io.d (corresponding to the module parobay.io).
It's definitely not the convention to limit yourself to just one class per file. D modules are for grouping together code of related functionality. When someone does import parobay.io;, they expect to get all of parobay.io - classes, utility functions and whatever else is relevant. It's similar to Java's import com.parobay.io.*;.
If someone really wants to import specific parts of your module, they can use selective imports:
import parobay.io: Input; // Just the Input class of the parobay.io module.
import parobay.io: Output; // Just the Output class.
import parobay.io: Input, Output; // Just the Input and Output classes.
There are a few additional things to note about this.
Package and module names are conventionally all-lowercase.
It makes everyone's lives easier if the path to the file matches up exactly with its full module name. For example, module foo.bar.baz should be in the file foo/bar/baz.d.
In my experience, it's rare for a D module to be named after a domain name. You can prefix your module names with com or org or net if you really want to, but it's not expected like it is in Java.
Adam D. Ruppe's answer has some great points about explicit module declarations and class member visibility. It's also well worth reading the module and style pages on the official D website.
D community has three widely accepted alternatives.
Write a module named all.d which includes all modules from your package. (Literally '*' --> 'all'). After that you simply do import com.paroboy.io.all;
I see more and more that D developers use _ for this. So they write a module called _.d for this purpose. Similarly to #1, you do import com.paroboy.io._;
Relatively new addition to the D programming language is the package.d module, which can be used to import the package. More about this at the following DIP: http://wiki.dlang.org/DIP37 . If I remember well, DMD supports it since v2.064 . (Documentation: http://dlang.org/module#PackageModule)
I myself use the #1 approach because it is obvious what is going on. While #2 and #3 may be confusing to people reading D source file, especially the third one. A valid question someone may ask: "What the heck am I importing, package?? But import is only for modules!??"
Allthough nothing stops you from having separate module per-class, I would not recommend it. D is truly modular language, so take advantage of that. Group all your types in a single D module. That is my advice, and that is the "D way".
NOTE:
There is a (big) semantic difference between Java "module" and a D module, as you have probably already noticed. I am primarily a Java programmer, so I know how confusing this may be to Java programmers who are playing with D. Java classes in the same package quite often take advantage of the package-level access. However, classes within the same module behave like "friends" in C++.
Speaking about Java modules, they were supposed to come with Java 8 (true modules!), but were posponed and will hopefully be included in Java 9.
UPDATE: We reached conclusion, after a chat on FreeNode (IRC) with some members of the D-Programming-Language, that it is indeed safe now to use the package attribute. It behaves as the specification says.
I am trying to load a dll (it's not my dll) and it's written in C++
There are no exports to my knowledge, but it does what I need it to do once loaded.
assert(package.loadlib(dllfile,'')()
This throws an error, obv, "procedure not found" but the dll is still loaded, and works as intended.
if I call the above function a 2nd time, it crashes the client, so I need a checker of some sort.
my question is, is there a way to verify it's loaded?
In Lua 5.1 when using package.loadlib as the second argument you must specify the name of a function actually exported by the DLL. It is not important which, if you only need to force the Windows dynamic linker to load the DLL (that seems your case).
To discover such names you can use DependencyWalker (free tool). Open the DLL using depend.exe and look at the export function list panel (the first column has an E header label). Choose any function and use its name as the second argument (If it really doesn't have exported functions you are out of luck!). Try to choose a function labeled as C (not C++). C++ exported functions have mangled names that could cause problems.
For example, say you want to load kernel32.dll: using depend.exe you can discover that among all the exported functions there is one named AddAtomA (but any other C function would do). So you could use package.loadlib in this way:
assert( package.loadlib( "kernel32.dll", "AddAtomA" ) )
The assert call ensures that if the DLL cannot be loaded an error is issued.
To verify a DLL is actually loaded you can use ProcessExplorer (another free tool).
Make sure your script is running (you can put an io.read() statement in a suitable place to keep your script from terminating),
then open ProcessExplorer window,
select the process relative to your script (probably some lua.exe, but you can drag the "target" tool on ProcessExplorer toolbar to your script window to discover it)
and type ctrl-D.
A lower panel should appear showing all the DLLs that the selected process is using. Browse the list to see if your DLL is listed.
Hope this helps.
I know this is an odd question, but I'm wondering if this is possible. Is there any method by which code (which would be typed by a user) could be run during runtime? For example, suppose I would allow the user to type in some Core Graphics drawing code. I would want this code to be run in a drawRect method of my preview pane.
So what I would have to do would be to convert this group of strings into actual runtime code.
Is this even possible, or am I just wasting my time?
I see a few solutions:
Create a language of your own, and parse it in-application
If on mac, you could theoretically, create a function stub from what they enter in, and use GCC shipped with the application to compile the code at runtime into a dylib, and then use dylib functions to run the function you created.
On a Mac, you can have your app send text to the compiler (several come with Xcode), have the code compiled, and run the compiled result as a slave app (controlled via a socket, for instance, and copying the preview pane image pixels back via a pipe). If needed you could convert the source code text using some sort of preprocessor and wrap it in your own run-time shell.
Alternatively you could write or port a C language interpreter (there are several open source interpreters for various subsets of C), and plug Core Graphics library calls into the C interpreter's parser and run-time engine.
I do not know of a full interpreter for Objective C.
I'm trying to create an D application which uses a (third party) COM .dll so I can scrape a text box of another application so I can sound an error when a certain string shows up.
However the third party doesn't provide .lib, .def or .h files that go with the dll (atleast with the free trial version). I can create the .lib file with the implib tool but I don't see any of the library's functions in the created .lib.
Their (visual c++) samples use the #import directive to link it in however that is of no use for me ...
On a side note how can I get the proper interfaces (in a .di with boilerplate that does the linking) of the dll automatically? I ask so the correctness of the linkage doesn't depend on my (likely to be incorrect) translation of the functions. They do have a webpage which gives all functions but the object model is a bit chaotic to say the least.
From what I know, COM libraries only expose a few functions, required to (un)register the library and to create objects.
You can however view the interfaces and functions in a COM .dll using the OLE/COM Object Viewer. It seems it might be able to output header files (.h). Afterwards, maybe you could use htod as a starting point to converting everything to D interfaces.
The DMD distribution seems to include a .COM sample (chello.d, dclient.d, dserver.d), and at first glance it doesn't look like it would require any LIBs explicitly.
Unfortunately, I've never actually used COM in D, so I can't advise any further. I hope this helps in some way.
While I have yet to actually do COM work myself, I am trying to revive Juno over on Github/he-the-great. Part of the project is tlbimpd which is what will output a D file from a DLL.
I've tested the examples and successfully run tlbimpd. Please do try things out for your use and submit any issues.
I'm trying to use code contracts for some libraries I have. My library A has a reference to ThirdParty library B. Library C references A, and never uses B nor does it use the bits of A that use B. The rewriter fails though trying to find library B. The reference assembly for A exists, I was hoping that the rewriter would be just happy with that.
Any ideas on how I can build this, short of moving the bits in A that rely on B out into its own assembly?
EDIT: To answer a question, yes, there are public types in A which expose types in B. I was hoping those the analysis would end at the library A, and that it would treat B as if there was no reference assembly at all (ie, ignore it).
It seems that there is no way around this. In some regards I think its good as it helps you see where your third party dependencies are leaking.