Can't build GrainLib (only interfaces) with Microsoft.Orleans.CodeGenerator.MSBuild 3.0.0 package
error:
Exc level 0: System.NotSupportedException: Projects of type .fsproj are not supported.
Is there workaround?
Upd
After Arshia001 explanation i return to finding errors in F# silo configuration and solved my problems by applying WithCodeGeneration instead WithReference and applying it for every assembly.
.ConfigureApplicationParts(fun parts ->
parts.AddApplicationPart((typeof<IMyGrain>).Assembly)
.WithCodeGeneration()
.AddApplicationPart((typeof<MyGrain>).Assembly)
.WithCodeGeneration() |> ignore)
it seems there are lot of issues with orleans documentation and examples.
Unfortunately, no. I once started a discussion around adding first class F# support to Orleans, but it died down pretty quickly since nobody else seemed to be interested at the time.
You can always use runtime serializer generation. They do have an official F# sample too.
Related
Since Xamarin.iOS doesn't support code generation at runtime, why do Compile() and DynamicInvoke() work as expected?
For example, the following code works fine:
var lambda = Expression.Lambda(
Expression.Add(
Expression.Constant(1),
Expression.Constant(2)
)
);
var f = lambda.Compile();
var result = f.DynamicInvoke();
// result==3 at this point
Is Xamarin evaluating the expression tree at runtime instead of emitting IL code?
On platforms that support code generation, Reflection.Emit-based LambdaCompiler is used.
If that's not available, the expression is interpreted using the interpreter. For example, there are classes that interpret Constant and Add.
The details of the Xamarin limitations are here.
You don't seem to be using anything in the Reflection.Emit namespace, which is the big no-no. Your code must still be AOT'd. Otherwise, I would imagine it would not work.
But there HAVE been examples of [native] developers thwarting the iOS static analysis tool and circumventing the dynamic code restriction. I tried to locate the article, but couldn't find it.
Anyway, I don't think your scenario exemplifies that. Your code example will still be AOT-compiled.
But you raise a really good question: at what time does the expression get evaluated?
EDIT:
Another SO answer on the same topic: What does Expression.Compile do on Monotouch?
There's also some good info on Expression.Compile() and "full AOT" here:
http://www.mono-project.com/docs/advanced/aot/
EDIT:
After reading some more, I think I know what's going on here. It's not that Expression.Compile() won't work...it's that when your iOS app bundle is subjected to the iOS static analysis tool when you submit it to the app store, it will not pass the analysis, because it is dynamically generating code. So, sure, you can use Expression.Compile(), but don't expect it to be accepted into the app store. But as mentioned by #svick, if you use the "full AOT" compile option, your Expression.Compile() will probably fail at runtime, or perhaps even fail compilation.
In the documentation it says, 'source' can be either str or AST object
When trying to compile my ast root:
dl = compile(newRoot, '<string>', 'eval')
I get this Exception:
expected str, got Module
I am using the last version of IronPython.
Is there an idea why this does not work? all the examples I found seem to do it this way with no issues.
Is there a workaround to compile an AST object?
Thanks!!!!
PD: I found this issue but seems to have no activity: http://ironpython.codeplex.com/workitem/32526
First off, IronPython does not support this.
It's actually quite hard to support in IronPython (and I didn't know it needed to be supported until today). IronPython's _ast module is a wrapper around its own AST, and currently only implements conversion from IronPython AST => CPython AST, but not the reverse. It's a fair bit of (honestly, quite tedious) work, so I'm not sure when it will get fixed.
If there's a popular program or library that's broken because of this that moves it up the priority list, and patches are always welcome.
It only recognizes top-level non-function value declarations.
e.g. let a = 2
and doesn't produce documentation for functions or type definitions.
I've checked the xml documentation file and it has all the /// comments I put in the source, but none of them (except for the top level values) show up in the resulting html.
Yes, using C#-centric tools for F# documentation generation is usually pretty horrible. We started an alternative project a while ago, but it is not yet as mature as SandCastle: http://bitbucket.org/IntelliFactory/if-doc
I'm trying to make an example I've found on the net work. It's a 3D fractal in F#. Here it is: http://tomasp.net/blog/infinite-cheese.aspx. The source code is available for download at the end of the article. The article and the sample were written in 2007, so I think the code is just slightly obsolete. There is one block of code that causes error and the code won't compile:
// Returns a cube with filtered sides
let private get_cube(incl_sides) =
[ for (side,trigs) in cube
when Set.mem side incl_sides
->> trigs ]
The when keyword is underlined, and the error message goes as follows:
Unexpected keyword 'when' in expression. Expected '->' or other token.
I can't figure out what's wrong with this. In an attempt to understand the code better, I searched the langauge specs. As far as I know, there is nothing about the Set.mem function or the ->> operator. Do you have any idea what could be wrong?
Try
[for (side, trigs) in cube do
if Set.contains side incl_sides then
yield! trigs]
The language has undergone a lot of changes since that code was written. In particular, the ->> operator has been replaced by yield!, Set.mem has been renamed to the more descriptive Set.contains, and comprehensions now use if ... then instead of when.
Yes, the version of the source code that is linked from the blog post is a bit old. You can find the latest (updated) version in the F# samples project on CodePlex. I think there may be some other changes, so it is best to get the version from CodePlex. (It includes FractalSimple.fs which is simpler version and Fractal.fs which also removes cube sides that are not visible).
The project contains standard Visual Studio 2008/2010 .fsproj project. The original version on the blog was written using F# CTP (from VS 2005 times) which had a completely different Visual Studio integration and used an obsolete .fsharpp project format (before MSBUILD format existed).
The when and ->> constructs have been used as a lightweight syntax for writing queries, but are now deprecated, to keep the syntax inside comprehensions consistent with the rest of the language. As kvb points out, you can use ordinary if .. then and the only non-standard thing is yield!, which means return all elements of the given sequence.
I want to make my Application configuration as F# file wich will be compiled to dll. (like XMonad configuration with xmonad.hs on haskell). I found it more interesting and just better way then using XML serialization.
So is there any way how can I compile single file (or more) to Library with some configuration like
module RNExcel.Repository
open RNExcel.Model
type ExpenseReportRepository() =
member x.GetAll() =
seq{ yield {Name="User1"
Role="someRole"
Password = "123321"
ExpenseLineItems =
[{ExpenseType="Item1"
ExpenseAmount="50"};
{ExpenseType="Item2"
ExpenseAmount="50"}]}
yield {Name="User2"
Role="Estimator"
Password = "123123"
ExpenseLineItems =
[{ExpenseType="Item1"
ExpenseAmount="50"};
{ExpenseType="Item2"
ExpenseAmount="125"}]} }
my idea was to run shell .... and msbuild the project , but I don't think it will works for every user with .net 4
Check out the F# Power Pack, specifically the FSharp.CodeDom library. You can use this library to compile F# code at run-time and, with a little Reflection thrown in, can likely achieve your goal of code-as-configuration with minimal fuss.
I think that using CodeDOM provider from the PowerPack as Ben suggested is a way to go. I'd just like to add a few things (and it didn't fit into the comment box).
To parse and compile the F# code with the configuration, you need just to compile the source file that the users write using F# PowerPack. The compilation part of PowerPack is complete and works just fine. It invokes the F# compiler under the cover and gives you the compiled assembly back. The only problem is that the users of your application will need to have F# compiler installed (and not just the redist).
The incomplete part of F# CodeDOM provider is generating F# code from CodeDOM trees (because the trees were not designed to support F#), but that's not needed in this case.