I need to use an expression language and there are many to choose from. MEL has stood out as very easy to understand and powerful. However, Mule Expression Language is in the mule core library in maven.
Can MEL work as a standalone expression language outside of the MuleESB like Spring Expression Language, for instance.
No. MEL is only implemented in Mule ESB/Runtime. Note that it has been deprecated by DataWeave since Mule 3.7.
Related
I am trying to write a GDB frontend. I use GDB for debugging embedded targets, especially with ARM processors. I have used Eclipse before, but I didn't like it very much. At work, we use Lauterbach Trace32, which is one of the most comfortable debuggers I have ever used. That's why I started a project where I try to implement a very similar application as a GDB frontend, which is specialised to embedded debugging.
However, I already have implemented some very basic commands, like viewing the source code, viewing registers of the target etc., which works well. Currently, I am implementing breakpoints. But for this I need some help.
I use Qt (with Qtcreator) on Linux for my project, so I have set up a QProcess for the gdb running in the background. I use the GDB Mi2 interface to communicate with gdb. Then, using write() I can send commands and with a SIGNAL, I can receive the responses from GDB. This works well, but the answers from GDB in this MI format are very ugly to parse. Could anyone give me a hint how this can be done in a elegant way? I tried BOOST to build a parser, which worked, but this is a much too complicated way in my opinion. Is there some better way to parse the GDB responses?
There's no truly great way to parse MI. MI is quite old and so predates the widespread adoption of XML and JSON. Also, even more unfortunately for you, there are a few known MI emission bugs in gdb (search bugzilla and the list archives) -- spots where gdb's MI output doesn't conform to the MI grammar. These have gone unfixed because it was judged that changing the output (without bumping the MI version number, something nobody seems to want to drive) would break existing parsers without much corresponding benefit.
The good news is that there are a few reusable parsers already in existence. So I would suggest using one of those. The parser in nemiver is written in C++ and is a reusable library. However as you're already using Qt you might check out the parsers in Qt Creator or KDevelop.
It might also be possible to roll your own gdb interface by programming gdb in Python. However, there are likely to be some holes in gdb's Python API, so I would only recommend it if you also want to get into hacking on the gdb Python layer as well.
There is the pygdbmi python library for exactly this purpose (it did not exist when you originally asked your question) https://github.com/cs01/pygdbmi
gdbgui is a frontend that utilizes pygdbmi: https://github.com/cs01/gdbgui
Have fun!
Disclaimer: I am the developer.
Qt Creator itself has a parser for (some superset of) the MI protocol, see plugins/debugger/debuggerprotocol.{h,cpp} in its sources. This (superset) protocol also used to capture data from Qt Creator's "pretty printing" produces and also serves as the debugger->frontend channel for the LLDB integration.
The protocol implementation is fairly well separated from the rest of Qt Creator's debugger plugin. It should be re-usable.
We are developing a library for complex event processing.
Is there any standard or widely accepted language with clear semantics that we could based on?
After some research it seems all available options are vendor/platform specific.
Yes there is no common CEP language now, Most of the venders are either using a SQL like language or a UI based tool.
SQL like language seems to be the more feasible approach due to easy of development of a CEP engine,
We have tried to come up with a SQL like language for a Java based CEP engine.
This might be helpful for you.
Suho
i know but i have no more idea about it and i don't know perfectly so and they both are use for ejb framework.
Both xdoclet and middlegen were tools for generating code for the EJB 1.x and EJB 2.x frameworks, which were a real pig to use on their own. However, EJB 2.x is now obsolete, and so are those tools. Comparing and contrasting them is, as a result, pretty pointless.
I'm toying with the idea of writing a command line interpreter and I suspect that a functional language such as Clojure is well suited to this task.
I am however 5 years out of a CS degree and my only experience with functional languages was a harrowing experience with Haskell in a third year languages course.
So, is a language such as Clojure ideal for this task? If not, what is an ideal language.
Loose requirements:
Has to run on a JVM
Provide an interactive shell where users enter commands with a CLI like syntax
User commands ultimately end up making calls to a remote service using SOAP.
Thanks!
You can approximately do that out-of-the-box with Clojure and Scala, and with Java if you add BeanShell. You might look at the REPL facilities they already have.
I imagine that's suited only for sophisticated users. But really, it's hard to imagine a language that wouldn't do a fine job on a CLI.
Deciding between platforms, the more of a modern system it is, the more it will have scripting language convenience.
I certainly know what I would use given your requirements: JRuby. (It has an out-of-the-box REPL, too.)
I don't think a CLI has any specific requirements language-wise; you could probably do just as well writing it in Java or Scala. Ultimately I think language choice is down to:
Which ones you are most comfortable working with.
Which ones have adequate library support for what you want to do (i.e. web services).
I'm looking for a fast language (ie. a language that can be compiled natively to achieve performance not more than 3 or 4 times slower than C), which supports portable continuations. By this I mean a continuation that can be serialized on one computer, and deserialized on another.
I know that SISC can do this (a Scheme implementation in Java), but its slow. Ditto for Rhino (a Javascript implementation in Java).
Did you checked OCaml ? It can be compiled and should be marginally slower than C.
Continuations and delimited control
Scala 2.8.0 will allow continuations, and they'll be portable.
While I agree that dialects of Caml might be an excellent choice I feel I have to mention Gambit Scheme. Together with Termite, an erlang-like framework it has support for serializing continuations, sending them over the wire, and much more.
It compiles to C-code.
Its possible to do serializable continuations in Java using Apache JavaFlow - if you do go that route then the Swing Continuations library at:
http://www.exploringexcellence.com/swingcontinuations/download.html
makes it the coding a lot more pleasant.