I recently got assigned a task to convert a few algorithms written in matlab to VB.NET (or C# if VB.NET isn't efficient).
The matlab code itself consists of a lot of matrix algebra. I initially looked through here and found there was a Matlab Coder that wrapped the matlab code but when I presented that option I was told it isn't desirable.
I am stuck in a sense that I don't know how to approach this with the proper tools.
Is it normally acceptable to grab libraries (http://www.codeproject.com/Articles/5835/DotNetMatrix-Simple-Matrix-Library-for-NET or http://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=907&lngWId=10, these are the only ones I could find) to implement these algorithms or is that generally frowned upon?
Do I need to reinvent the wheel and implement my own algorithms for the algebra (matrix multiplication, choleksy decomposition etc)?
Basically, I am not sure what the accepted way of accomplishing this task is, any input would be appreciated. I apologize if this isn't allowed in here, this is my first time posting but I am a long time lurker.
You have several possibilities.
If your application can bear the loading time of MCR, you can use Matlab .NET Builder. It will compile a .NET class, which will run MCR silently underneath. All of your clients will be forced to install MCR on their computer.
If your code must be native you can either rewrite the code, or use Matlab Coder, which will convert the code into unreadable, native c++ code.
If you choose to rewrite the code, I would recommend finding an implementation of LAPACK linear algebra routines on .NET, as Matlab is based on them.
Code like that is published so it can be used and learned from. Just make sure the code's license (if any) is acceptable for your situation.
You can access Matlab functions from VB.net through COM interface
http://www.mathworks.com/help/matlab/matlab_external/view-matlab-functions-from-visual-basic-object-browser.html
Related
I really like F# but I feel like it's not succint and short enough. I want to go further. I do have an idea of how I'd like to improve it but I have no experience in making compilers so I thought I'd make it a scripting language. Then I realized that I could make it a scripting language and interpret it using F# but still get pretty much 100% performance thanks to F# having the inline option. Am I right? Is it really possible to make a script interpreter in F# that would go through my script and turn it into lots of functors and stuff and so get really good performance?
I really like F# but I feel like it's not succinct and short enough. I want to go further. I do have an idea of how I'd like to improve it but I have no experience in making compilers so I thought I'd make it a scripting language.
F# supports scripting scenarios via F# Interactive, so I'd recommend considering an internal DSL first, or suggesting features on the F# Language UserVoice page.
Then I realized that I could make it a scripting language and interpret it using F# but still get pretty much 100% performance thanks to F# having the inline option. Am I right?
Depending on the scenario, interpreted code may be fast enough, for example if 99% of your application's time is spent waiting on network, database or graphics rendering, the overall cost of interpreting the code may be negligible. This is less true for compute based operations. F#'s inline functions can help with performance tuning but are unlikely to provide a global panacea.
Is it really possible to make a script interpreter in F#
As a starting point, it is possible to write an interpreter for vanilla F# code. You could for example use F#'s quotation mechanism to get an abstract syntax tree (AST) for a code fragment or entire module and then evaluate it. Here's a small F# snippet that evaluates a small subset of F# code quotations: http://fssnip.net/h1
Alternatively you could design your own language from scratch...
Is it really possible to make a script interpreter in F# that would go through my script and turn it into lots of functors and stuff and so get really good performance?
Yes, you could design your own scripting language, defining an AST using the F# type system, then writing a parser that transforms script code into the AST representation, and finally interpreting the AST.
Parser
There are a number of options for parsing including:
active patterns & regex, for example evaluating cells in a spreadsheet
FsLex & FsYacc, for example to parse SQL
FParsec, a parser combinator library, for example to parse Small Basic
I'd recommend starting with FParsec, it's got a good tutorial, plenty of samples and gives basic error messages for free based on your code.
Small Examples
Here's a few simple example interpreters using FParsec to get you started:
Turtle - http://fssnip.net/nM
Minimal Logo language - http://fssnip.net/nN
Small Basic - http://fssnip.net/le
Fun Basic
A while back I wrote my own simple programming language with F#, based on Microsoft's Small Basic with interesting extensions like support for tuples and pattern matching. It's called Fun Basic, has an IDE with code completion and is available free on the Windows Store. The Windows Store version is interpreted (due to restrictions on emitting code) and the performance is adequate. There is also a compiler version for the desktop which runs on Windows, Mac and Linux.
Is it really possible to make a script interpreter in F#
So I guess, the answer is YES, if you'd like to learn more there's a free recording of a talk I did at NDC London last year on how to Write Your Own Compiler in 24 Hours
I'd also recommend picking up Peter Sestoft's Programming Language Concepts book which has a chapter on building your own functional language.
I am planning to write a compiler (including parser) in OCaml to parse and run VBA or/and VB programs. I have done this for simple imperative languages, but I am not sure how to handle the "object" features of VBA or/and VB...
Does anyone know if there is any existing work that I can inspire?
Not an OCaml solution (but OP asked):
Our DMS Software Reengineering Toolkit is general purpose program analysis and transformation machinery. It is intended to be a convenient foundation for custom software engineering tools for computer languages, with the goal being to help the tool engineer get his job done, rather than spending his time reinventing the wheel. In particular, many people think that getting a parser is the big part of the job. This is simply false. See Life After Parsing.
DMS has production front ends for many languages, both modern and legacy, including Visual Basic in its variety of dialects (VB6, VBA [essentially the same as VB6]) and VB.net.
By production I mean have been applied to real code systems of significant size and handle all the corresponding parsing issues. This is pretty hard for legacy languages, e.g., VB, especially the older dialects because such languages are generally poorly documented (VB6 and VBA especially so). The only way to get this right is to build a draft parser, run it against reality, and revise until lots of code goes through sensibly. This often takes longer than doing the draft parser because it isn't easy to understand the errors (they're undocumented!), you have to decide if they are real or the code base just has junk (more often than you'd think), guess what it means for the grammar and try it all again.
These front ends as a minimum parse source code and build ASTs; they can also invert this process to regenerate legal compilable code with the comments back as source text files. The VisualBasic front ends do this. Some of our other front ends (C, C++, Java, COBOL) go further: name/type resolution, flow analysis, etc.; they do that by collecting key program facts from the language-specific AST and then apply DMS-supplied machinery to compute the results. This would be possible for VisualBasic, too, if such facts were useful.
For an example of a tiny OO language written in OCaml check out the source code for boa at: http://andrej.com/plzoo/.
The OO flavour is not class based though so I'm not sure how useful it will be.
I've used Teleflex, developerfusion, and SharpDeveloper, and all these, to convert C# to VB, but as most know, there are always errors, and modules left out, and such.
Does anybody know of a good VB editor, preferably freeware, and can handle translated VB and offer suggestions to correct it for you?
Visual Studio underlines things and offers suggestions on some things, but other things it just underlines and leaves you to the guesswork, which doesn't help a non-coder like me.
Non-coders shouldn't be translating C# to VB.
No code translator will take care of everything for you. Even if it works programmatically, there are design patterns and code standards that are different for each language. Hire a programer.
No. And it's not always possible to convert C# to VB. Some features of C# have no equivalent in VB.
Unsafe code (e.g. pointers)
Iterators (yield)
Conversely some features of VB have no equivalent in C#.
Exception filters
XML literals
Why do you need to convert the code anyway? What's the business case?
VB and C# are different langages, so even the best translator in the world will miss some things. The person doing the translation shouldn't be a "non-coder" and should know at least some VB, so when a compile error is shown, he knows what to do with it, or at least knows how to search on the web (or ask on SO) to know how such part of code can be translated to VB.
Although vb.net and C# are both designed around the same .net framework, and consequently feature very similar features that work mostly the same way, many corner cases are handled differently by the two languages. While one could argue ad nauseum about whether a statement like myStruct = new myStructType(someParams) should affect the value of myStruct before the constructor completes (in C#, it does not; in vb.net, it does), and it's probably good to avoid designing code around corner cases, it's doubtful that any translator--much less a freeware one--will detect all of the corner cases and ensure that code which (possibly accidentally) relies upon them will still run correctly.
Which one would you prefer to extract a sub-string from the given string and why?
I am thinking that since Left and Right are VB functions and not .NET functions, they may cause problems in the future in terms of compatibility.
Please clarify my thoughts on that.
Use whichever makes most sense i.e. makes that piece of code easier to read.
I don't know why you'd think that they'd cause problems in the future, they're functions, they're provided as part of the VB.Net Language set, there is no earthly reason why they would be removed, and even if they were, they would be trivial to re-implement.
Use 'em, cause you ain't gonna lose 'em
When given the choice between a feature that is from Microsoft.VisualBasic vs a comparable feature that is provided in the core framework assembiles, I tend to stick with the latter in most cases.
I do this for various reasons:
It tends to be understood by more developers. (e.g. C# guy looking at my VB.NET code).
You're more likely to find online help (message boards, stackoverflow, etc) for the core framework version than you are for the VB-ized version.
Using them gives your code a "legacy" feeling to it. It's like making use of the Call statement.
Makes it easier for another person to "copy and paste" VB.Net code into their C# (or other .NET language) project and have it be one less language translation point/hangup. (Unlikely this is a real concern/reason, but I know I've many-a-time "copy and pasted" example C# code into my VB.Net project and anything that doesn't cause road blocks in the translation process (e.g. usage of yield) makes my life easier.)
While completely inconceivable they are going away (as most of these keywords/statements are a BASIC language construct), they do feel more likely to become marked obsolete than any of their core framework counterparts. Especially as VB6 is becoming more and more of a distant memory and the VB.NET language takes on a life of its own in conjunction with the core .NET framework advancing.
One notable exception to this, I tend to make use of the My namespace proxies offered; My.FileSystem.ReadAllText(...) is just sexy. :P
Do you work alone?
If no, the decision is simple.
If your team members have C# background, use Substring.
If your devs have some VB6 background, use Left and Right.
If you ain't sure, ask them.
.net SubString will throw if start + length is > than the string length where VB Left() will return the entire string if a length greater than the string length is provided. That's a substantial behavioral difference.
Also, given .Net Standard, avoid Microsoft.VisualBasic.
Yes, I know this is > 10 years old, but ended up here when trying to port some really old code. So, thought I'd share the difference.
I'm looking at adding scripting functionality to an existing codebase and am weighing up the pros/cons of various packages. Lua is probably the most obvious choice, but I was wondering if people have any other suggestions based on their experience.
Scripts will be triggered upon certain events and may stay resident for a period of time. For example upon startup a script may define several options which the program presents to the user as a number of buttons. Upon selecting one of these buttons the program will notify the script where further events may occur.
These are the only real requirements;
Must be a cross-platform library that is compilable from source
Scripts must be able to call registered code-side functions
Code must be able to call script-side functions
Be used within a C/C++ codebase.
Based on my own experience:
Python. IMHO this is a good choice. We have a pretty big code base with a lot of users and they like it a lot.
Ruby. There are some really nice apps such as Google Sketchup that use this. I wrote a Sketchup plugin and thought it was pretty nice.
Tcl. This is the old-school embeddable scripting language of choice, but it doesn't have a lot of momentum these days. It's high quality though, they use it on the Hubble Space Telescope!
Lua. I've only done baby stuff with it but IIRC it only has a floating point numeric type, so make sure that's not a problem for the data you will be working with.
We're lucky to be living in the golden age of scripting, so it's hard to make a bad choice if you choose from any of the popular ones.
I have played around a little bit with Spidermonkey. It seems like it would at least be worth a look at in your situation. I have heard good things about Lua as well. The big argument for using a javascript scripting language is that a lot of developers know it already and would probably be more comfortable from the get go, whereas Lua most likely would have a bit of a learning curve.
I'm not completely positive but I think that spidermonkey your 4 requirements.
I've used Python extensively for this purpose and have never regretted it.
Lua is has the most straight-forward C API for binding into a code base that I've ever used. In fact, I usually quickly roll bindings for it by hand. Whereas, you often wouldn't consider doing so without a generator like swig for others. Also, it's typically faster and more light weight than the alternatives, and coroutines are a very useful feature that few other languages provide.
AngelScript
lets you call standard C functions and C++ methods with no need for proxy functions. The application simply registers the functions, objects, and methods that the scripts should be able to work with and nothing more has to be done with your code. The same functions used by the application internally can also be used by the scripting engine, which eliminates the need to duplicate functionality.
For the script writer the scripting language follows the widely known syntax of C/C++ (with minor changes), but without the need to worry about pointers and memory leaks.
The original question described Tcl to a "T".
Tcl was designed from the beginning to be an embedded scripting language. It has evolved to be a first class dynamic language in its own right but still is used all over the world as an embeded language. It is available under the BSD license so it is just about as free as it gets. It also compiles on pretty much any moden platform, and many not-so-modern. And not only does it work on desktop systems, there are variations available for mobile platforms.
Tcl excels as a "glue" language, where you can write performance-intensive functions in C while still benefiting from the advantages of a scripting language for less performance critical parts of the application.
Tcl also comes with a first class GUI toolkit (Tk) that is arguably one of the easiest cross platform GUI toolkits available. It also interfaces very nicely with SQLite and other databases, and has had built-in support for unicode for quite some time.
If the scripting interface will be made available to your customers (as opposed to simply enabling your own engineers to work at the scripting level), Tcl is extremely easy to learn as there are a total of only 12 rules that govern the entire language (as of tcl 8.6). In fact, Tcl shines as a way to invent domain specific languages which is often how it is used as an end-user scripting solution.
There were some excellent suggestions already, but I just wanted to mention that Perl can also be called / can call to C/C++.
You probably could use any modern scripting / bytecode language.
If you're willing to put up with the growing pains of a new product, you could use the Parrot VM. Which has support for many, if not all of the languages listed on this page. Unfortunately it's not done yet, but that hasn't stopped some people from using it in a production environment.
I think most people are probably mentioning the scripting language that they are most familiar with. From my perspective, Tcl was designed specifically to interface with C, so your problem domain is tailor-made for the language. However, I'm sure Python, Perl, or Lua would be fine. You should probably choose the language that is most familiar to your current team, since that will reduce the learning time.