The implementation of ScrumJet on GitHub (as of this writing) shares essentially identical functions between the storage modules for tasks, categories and boards. This was achieved by moving the identical code which makes heavy use of the ?MODULE macro into scrumjet_datastore.hrl. Each of scrumjet_task.erl, scrumjet_category.erl and scrumjet_board.erl include scrumjet_datastore.hrl and have no functions defined locally.
This works very well when there is nothing wrong. However, if I need to debug, then the debugger brings up the empty module instead of the header file where the functions are defined.
Does anyone know how to make the Erlang debugger work for functions in includes?
Using includes in Erlang to share implementations of functions is not generally a good idea. It has some uses, but it should be avoided in regular application code.
As I mentioned back in 2009 I followed Zed and Adam Lindberg's advice and used a datastore module with parameterized methods instead.
Related
In C language, we use #include statement and using statement in C# to be able to attach its build-in function. But in Lua, we dont need to do anything, then we can use the coroutine, table, io, etc.
It's because Lua "pre-imports" some of the libraries for you. You can re-configure your copy of Lua to load a different set of libraries. See lualib.h file in the Lua distribution for the list of pre-loaded libraries.
The Lua interpreter exports all basic functions and library tables to Lua programs by calling luaL_openlibs before running the program.
EDIT:
Why don't all languages do this?
It's a trade-off. If a language exposes its entire standard library by default, it saves us a lot of boilerplate. On the other hand, it can pollute the namespace, use more memory, and increase startup time. Lua's standard library is small, so it doesn't cost very much. Most compiled languages try to be as lean as possible, so they make us import everything explicitly.
Just curious - are protocol buffers usable with F#? Any caveats etc.?
I'm just trying to answer this question myself.
Marc Gravell's protobuf-net project worked out-of-the-box with F# because it uses standard .NET idioms. You can use attributes to get serializing without having to write .proto files or do any two-stage compilation, or you can generate the necessary code from standard .proto files. Performance is good for .NET but a lot slower than alternatives like OCaml's built-in Marshal module. However, this library forces you to make every field in every message type mutable. This is really counter-productive because messages should be immutable. Also, the documentation leaves a lot to be desired but, then, this is free software.
I haven't managed to get Jon Skeet's protobuf-csharp-port library to work at all yet.
Ideally, you'd be able to serialize all of the built-in F# types (tuples, records, unions, lists, sets, maps, ...) to this wire format out-of-the-box but none of the existing open source solutions are capable of this. I'm also concerned by the complexity of these solutions: Jon Skeet's is 88,000 lines of C# code and comments (!).
As an aside, I am disappointed to see that Google protocol buffers do not specify standard formats for DateTime or decimal numbers.
I haven't looked at Proto# yet and cannot even find a download for Froto. There is also ProtoParser but it just parses .proto files and cannot actually serialize anything.
There isn't an F# specific one listed here, but there is an OCaml one, or there is a .NET "general" one (protobuf-net).
In all honesty, I simply haven't gotten around to trying protobuf-net with F# objects, in part because I simply don't know enough F#, but if you can create POCOs they should work. They would need to have some kind of mutability (perhaps even just private mutability) to work with protobuf-net, though.
If you are happy to generate a C# DTO and just consume that from F#, then protobuf-net or Jon's port should work just fine.
I'd expect both my own port and Marc Gravell's to work just fine with F#, to the same extent that any other .NET library does. In other words, neither port is written in a way which is likely to produce idiomatic F# code, but they should work.
My port will generate C# code, so you'll need to build that as a separate project for your serialization model - but that should interoperate with F# without any problems. The generated types are immutable (with mutable builders) so that should help in an F# context.
Of course, you could always take the core parts of either project and come up with an idiomatic F# solution too - whether you port the whole project to F# or use the existing libraries with an F# code generator and helper functions, or something like that.
I recently wrote a binding for a C library using SWIG. While a good deal of it was straight forward and used only basic SWIG functionality, I ran into trouble when I needed to support one function which took a C callback as an argument, which is not supported for SWIG. I solved this by writing Python-specific code to provide a custom callback in which I called the Python 'eval' function to evaluate a supplied Callable.
While this worked nicely, it was unfortunate for me.. I had been hoping to use SWIG to take advantage of its support for tens of languages, but now I'm stuck having to figure out callbacks in every single language I wish to support. This makes my binding work magnitudes less useful, as I now have to solve the same problem many times, manually--the opposite of the point of using SWIG.
Are there any tool like SWIG that also handles C callbacks?
It's a bit rounadabout but if you recompile the C project in C++ or create a C++ extension, then you can take advantage of virtual function overloading.
Most SWIG language module have support for directors which allow a class in the target language to derive from a class in the C++ library. This way any overridden virtual function act as a callback.
I'm working on Windows XP/Delphi 7. I need to add some procedures (or functions) inside a program that is running, and I do not want to re-compile it once again after I finished it.
I just have a host application with 5 functions to send different types of alarms, but there are other new alarm types, so I have to do new functions to send those alarms, but I should not re-build the host application. I have a class named TAlarmManager that it's invoked calling those functions.
Maybe a plugin?? OK, but how can I "insert" new functions??? Tutorial, manual, book, etc.. for learning about this, or any advice on how to do this???
I have studied plugins (I'm totally new on this theme), but no one "talks" about adding functions to a host application. It seems to me that plugins add functionality from itself, I mean, they have been developed with self code to do something, not to "add" code to the host application... How can I do this??
For the technical side: How does the Delphi IDE do it? That would be the first place for me to look.
To understand plugins, you must understand that you can't add new functions. You could but since the old code doesn't know how to call it, they wouldn't be called.
So what you do is you add a "register" or "start" function to your plugin. That start function gets a data structure as parameter which it can examine or extend. In your case, that would be the list of alarms. Alarms always work the same (my guess), so it can add additional alarms.
The main code will then, after registering all plugins, just walk over the list of alarms and invoke the standard alarm function on each of them. It no longer cares where each alarm comes from and what it really does.
The key here: You need to define an interface which both sides subscribe to. The main code calls the interface functions and your plugin code implements them.
Another option available is to use a scripting component to your project. One which works quite well is PascalScript. This would allow you to load external scripts after the fact and then run them as needed to interact with your application. As Aaron suggested you will also need to still provide an interface of some sort for your script to interact with your application.
See also Plugins system for Delphi application - bpl vs dll? here on Stackoverflow.
I'm not quite sure what you mean by "alarms", so I'm making a couple of assumptions.
1) If you don't need additional code for the alarms, I would try to make them data driven. Keep the different kinds of alarms in a database or configuration file, which makes it easy to update applications in the field without recompiling or reinstalling.
2) If you need special code for each alarm, you could use run time packages as plug-ins for your application. Search for Delphi runtime packages to get some ideas and tutorials. Here are a couple of links I found:
http://delphi.wikia.com/wiki/Creating_Packages
http://delphi.about.com/od/objectpascalide/a/bpl_vs_dll.htm
3) Scripting, as skamradt already mentioned. If it makes sense for your application, this could also let your customers write their own add-on functionality without requiring a recompile on your part.
You almost definitely want to use Pascalscript, as skamradt suggests. You should start here, and seriously consider this option. There are many possibilities that come out of being able to serialize live code as text. The only downside is possibly speed of execution, but that may not matter for your application domain. I would have upvoted skamradt, but I don't have enough reputation to upvote :)
Some time ago I was looking at a situation sort of like what you're describing.
My answer was .DLLs. I put the variable code in a .DLL that was dynamically loaded, the name specified in a configuration file. I passed in a record containing everything I knew about the situation.
In my case there was only a success/fail return and no screen output, this worked quite well. (It was commanding a piece of machinery.)
This sounds like a place where a scripting language or "Domain Specific Language" may make sense. There are several approaches to this:
Implement alarm functions in VBscript (.vbs files written in notepad) that accesses your Delphi code via COM API. Using the COM API gives you access to a large range of programming tools for writing functions, including Delphi. This is the most clumsy solution, but easiest to do. It may also be a benefit to your sales process, and it is always good to think about how to sell things.
Implement your own function language in Delphi. This way you can make it so easy, that your endusers can write their own alarm functions. If you do it as an expression evaluator, you can write an alarm as 2*T1>T2. There are several expression evaluators out there, and you can also write your own if they don't match your needs.
Use a predefined programming language inside your Delphi application, for instance, "Pascal Script", see http://www.remobjects.com/ps.aspx
You should take a look at PaxCompiler, like PascalScript it allows to load scripts, but you can even precompile them before for more performance. Look at the demos section for the solution of your problem.
As a side note, the web page really looks bad, but the package is really powerful and stable.
I think that the scripting solution it's good for this situation.
There are many scripting packages that you can evaluate:
Context Scripting Suite
Fast Script
RemObjects Pascal Script
TMS Scripter Studio
paxScript
Other packages that you can find on Torry, DSP, VClComponents,...
Regards.
Although I do more or less understand what a language binding is, I am struggling to understand how they work.
Could anyone explain how do you make a Java binding for WinAPI, for example?
You'll find much better results if you search for Foreign Function Interface or FFI. The FFI is what allows you to call functions that were written in a different language, i.e., foreign ones. Different languages and runtimes have vastly different FFIs and you'll have to learn each one individually. Learning an FFI also forces you to know a little more about the internals of your language and its runtime than you are ordinarily used to. Some FFIs make you write code in the target language, like Haskell (where FFI code must be written in Haskell), and others make you write code in the source language, like Python (where FFI code must be written in C).
Certain languages don't use the term FFI (though it would be nice if they did). For Java, it's called Java Native Interface, or JNI.
Languages (usually) have defined syntax for calling "native" code. So if you have library that exports method foo(), making a biding would mean that you will create, in you example, Java class with method foo(). That way, you can call MyBinding.foo() from the rest of a code, it will make no difference whether it was pure Java method or compiled C code.
Again for Java, you probably want to look at JNI documentation. Other languages have similar mechanisms. There are tools like SIP that will take bunch of C(++) header files, and produce Python bindings for it. I guess other languages could have similar tools as well.