I have developed a commercial extension for the Unity3D game engine in F#, it's a piece of code which extends the editor with advanced node/graph editing features. F# is perfect for this due to the nature of immutability and DU's.
But, to my question: I realized that the license for the FSharp.Core.dll which comes with Microsoft .NET/Visual Studio probably doesn't allow you to re-distribute it with a commercial project? How would I go about finding out if this is the case or not, and if it's not is there any way to create my own compiled version of FSharp.Core.dll which would run on Unity3D?
The reason I ask is because Unity3D uses Mono 2.6 (albeit a modified version, to my understanding) under the hood, and there is no FSharp.Core.dll bundled with the editor, so I need to supply my own with my extension.
See: Is F# 3.0 runtime redistributable?
The answer is of course Yes. The language would be pretty useless if its core library wasn't re-distributable...
Related
I have been doing some programming in VB.NET on Visual Studio Express 2015 for Desktop. I recently started looking into F# and like the functional paradigm. As a result I have been trying to find a way to use VSE2015 as my IDE for F#. However, I have hit some problems. First of all, it has been difficult to find out if it is officially supported. The .NET blog suggests that it is (at least version 3.1.1, and the announcement for 4.0 RTM does not mention otherwise), but when I try to install F# Tools (4.0) it seems to choke on some components called VWD and WD(?). 3.1.1 seems to install OK, but then I still can't open any F# projects (fsproj). When I try to install FSharpVSPowerTools, it tells me that my platform is not supported.
Am I trying to do something that is not possible? Have I missed some steps? Any pointers would be appreciated. Thanks.
(Incidentally, I can't use the Community edition because of the licensing restrictions)
Edit: I have tried VS Code, but it works differently from VSE, and I would have to do a whole more learning. In addition, I want to use the VS template for creating XLL's. Edit 2: it has been pointed out that you can reference excel-dna in VS Code, but setting it up is not as straightforward as in VSE2015 (at least for VB.NET and C#.NET.
I would like to play around with F# on my Linux box, but I struggle to find up-to-date versions of the relevant files. The F# cross-platform packages are from 2010 and the plug-in seems to be for Monodevelop 2.4 (I have 2.8 installed, which is not the newest anyway...). Is the project still alive? Am I looking at the right place?
F# cross-platform package is pretty outdated. Depending on which Linux distro you're using, F# may be distributed with Mono 2.10.x (check Mono homepage for details). Otherwise, you should build F# compiler from source for latest version.
The original F# binding does not work with MonoDevelop 2.8. Fortunately, the F# binding is being actively developed by Scott Stephens under a Google Summer of Code project. There are first positive sights as being mentioned here. For discussion, you can post on F# Open Source Community Group or ask questions here.
The F# addin for Monodevelop is still developed as of 2014 and is available from addins.monodevelop.com.
In the Build 2011 keynote and demos, they were always talking about C++, C#, Visual Basic and JavaScript. Can't I build Metro style Apps with F#? Or is it safe to say that if it works with C#, then it works with F# as well?
Or is it eligible to say if it works with C# then it works with F# as well?
Yes, that's how it is supposed to work. In addition to javascript and C/C++, any CLS compliant language that runs on top of the CLR will have access to the WinRT API.
Unfortunately in the VS 2011 Express edition you don't get tooling support but I guess this will be added progressively or to other editions:
Don talks about this a little around 7:40 into his talk.
http://channel9.msdn.com/Events/BUILD/BUILD2011/SAC-904T
I had the same question and created a blog post: Create a Metro App in F# (NOT)
There are a few issues:
You cannot reference ordinary .NET dll’s (even in C#). They have to
be have recompiled with a “reference” to the WinRT. Because of this
you cannot reference the F# dll. I think this will be solved when F#
3.0 get released (source: Understanding F# slide from Don Syme at
build).
The ability from F# to create Metro apps. This has to be
built by the F# team. This is an open question. This is the all-F#
approach (In WPF it is today possible but not recommended).
Tool support for creation Metro front-end projects. This will be not the case for the
F# 3.0 release. (source: Understanding F# slide from Don Syme at
build).
Using Visual Studio 11 Developer Preview (Full, not Express), I was able to reference and run F# code from a C# Metro style application with the following caveats:
You will get a build warning saying that the project can't be referenced, even though Visual Studio will still allow you to add it.
You must remove all references to all DLL's in the F# project, including FSharp.Core.
By following these steps it is possible to run F# code from a C# Metro style application, but it is nearly impossible to write any useful code in F# without references to the core language libraries. Let's hope they update the libraries to be WinRT compatible soon.
The question has been answered here:
Windows 8 and F#
Although you cannot create and design Metro apps directly in F#, you can still create so called Portable library in F# with all Models and ViewModels and use it in another Metro projects. It's not ideal, but it works.
I ported my stock chart library for .NET3.5-4.0 to Portable library,it works quite well on Metro with C# Metro application and some my Metro UI bridge.
I'm convinced that I can use F# to make Metro application in many parts.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Will the next version of Delphi be released with cross platform support and Qt based components? If so, do we have to distribute with Qt? (I don't know anything about Qt)
How can Qt help the Delphi world, and why did many programmers using C++ start using Qt with, and what will happen to VCL?
do we have to distribute with Qt
Probably. A lot depends on how it will be implemented, and how Qt will be linked to executables. There are also interesting implications depending on what kind of Qt license is used. The LGPL is not the MPL or the BSD...
why many programmers using c++ started
using Qt with them
Qt is a C++ library, and C++ developers use it directly. It makes sense to use it from C++ to write portable applications. It makes a lot less sense to create a wrapper over a wrapper, what the Qt/VCL would be. They will take that road because it's faster to deliver a cross-platform framework that way, but they didn't learn anything from the mistakes they made (CLX, VLC.NET) and will repeat it again. They will have to map a library written with its onw design to the Delphi library design, and it means a lot of compromises without any control over the underlying framework. IMHO, it will be a failure like the CLX and the VCL.NET.
There will be a new VCL+ library, released together with the VCL "classic" library.
As far as we can tell, this VCL+ library will be based on Qt 4.
And the "classic" VCL will remain, but targeting Windows only.
Since Qt is C++ based, there will be a dll containing a "flat" version of the library, ready to be accessed from Delphi code. This dll will have to be released with your application. Since Qt can be statically linked, I guess this dll will contain all necessary Qt code, ready to run on Windows/Linux/MacOsX. But another possibility will be to have a "flat" dll which will be able to call other Qt dll, which could be upgraded on purpose, when a new official Qt update will be released: it could be better not to rely on EMB to follow the Qt upgrades, that is not to buy a new Delphi license to have access to the updated Qt framework.
I suspect the way Qt will be used by Delphi programmers will be far away from how c++ programmers use the library. Qt relies heavily on macros and pre-compilation (compiling a Qt application is very time consuming), whereas Delphi will rely on components and more classic class orientation (which compiles quickly).
We can only guess from what was done with the CLX library, when Borland released Delphi and Kylix based on Qt 2. I hope they have learned from this experiment (CLX was never widely deployed/used). But Qt 4 is definitively much more attractive than Qt 2 was.
What we don't know yet is how deep the VCL+ will rely on Qt Core. Will some part of the RTL be translated into better matching the Qt design? For example, will multi-threading and sockets call the corresponding parts of the Qt Core? It could make sense, for cross-platform compatibility, not to reinvent the wheel, since Qt engineers already made the hard work and maintain it...
Well, according to their previous roadmap, current version (Delphi XE) was supposed to provide cross-platform support; that is, compiling your project for different platforms (Win, Mac, Linux), not porting the IDE to those platforms. But they didn't provide it, and postponed it to future releases.
The current roadmap is still vague; it says they will provide it, but no specific time frame (except for 64-bits compiler preview). Embarcadero has postponed expected features (e.g. 64-bits support, or cross-platform support) without informing the customers properly a few times, for example, most (if not say all) of their customers had no idea cross-platform support was excluded from XE up to a few weeks before the official release. So it wouldn't be a surprise for me to see they postponing this again or totally dismiss their current roadmap.
For Qt, according to Mike Rozlog, Delphi product manager, in his interview with Delphi Podcast; their cross-platform support would be based on their previous cross-platform library (CLX) which was available in Delphi 6 and Delphi 7. Even he mentions that most of existing CLX-based apps might compile successfully using the new cross-platform feature. So if this hasn't been changed, then Yes, it will be a Qt base solution. CLX was also based on Qt library.
If it is Qt-based, then you have to deploy Qt runtime library too. In Linux it shouldn't be an issue, cuz as far as I know, most of Linux distros already have Qt runtime installed. For Windows, I know it is not installed by default. I don't know about Mac OS.
How can Qt Help the Delphi world
Qt is a popular and well-established cross-platform framework which is owned and developed by Nokia, and is published for free (LGPL license). Delphi is probably just supposed to use Qt GUI widgets for cross-platform GUI support, but Qt itself consists of many different libraries for almost anything, and just a GUI framework.
why many programmers using c++ started
using Qt with them
You should ask this from C++ developers, but as far as I can say; Qt is a proven cross-platform framework, has a nice IDE and UI designer (Qt Creator), can be easily integrated with popular development tools (e.g. Visual Studio), has good support, you can find Qt port for almost all major programming languages, and Nokia is using it as the base software framework for their current and future mobile platforms (e.g. Symbian^4 and MeeGo).
what will happen for VCL
Again referring to Mike Rozlog; they are going to keep VCL as a Windows-based framework, and provide a new framework for cross-platform development which is similar to VCL.
Is there an F# compiler (plugin?) for SharpDevelop? I use SharpDevelop on my netbook for hobby development and it would be cool to program in f# on it.
If you install the F# compiler, SharpDevelop 3.0 automatically supports it. (Oh well. At least people will get a good answer now.)
On Windows, I settled on Visual Studio Shell and the May F# CTP.
There's a rather old (Aug 2008) F# Plugin for MonoDevelop. Read more on its Wiki page.
For the F# compiler, download the xip file from the F# May 2009 CTP page. there are certain known issues with running it on Mono, just search for "F# Mono" for more info.
Now Visual Studio 2010 supports F#. However, that doesn't include the Express editions, so if you're looking for F# IDEs for free, then there's a MonoDevelop plugin (which needs v2.6 IIRC), you can install Visual Studio Shell Integrated and add FSharp to that, or SharpDevelop.
Of these, I'd probably recommend the Visual Studio Shell over the others as it seems to have the best integration between the editor window and the F# Console window. However, if you're interested in doing things cross-platform, then look at MonoDevelop, as you can make sure that something will work on Mono.