Note: This was originally posted with incorrect error message and is now corrected.
Am trying to compile the Agda source code associated with the paper Total Parser Combinators by Nils Anders Danielsson. The source code is available here github. When compiling I am getting the following error:
Not in scope:
return′
at parser-combinators-master/TotalParserCombinators/Parser.agda:99,46-53 when scope checking return′
I am using Agda version 2.6.2 and have updated std-lib using cabal (according to instructions on Agda Wiki) and the agda/libs/agda-stdlib/README.agda states
This version of the library has been tested using Agda 2.6.2.
I am very much not not an Agda expert; my motivation is the paper as opposed to the code per se. It would, however, be extremely useful to have the code working.
Any pointers on where to look, what to check or to try greatly appreciated.
Related
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.
I am evaluating Keil Microvision IDE on STM32H753.
I am doing compiler comparison between ARMCC5 and AC6 in the different optimisation levels. AC6 is based on Clang.
My code is not using memcpy and I have unchecked "Use MicroLIB" in the project settings , However a basic byte per byte copy loop in my code is replaced by a memcpy with AC6 (only in "high" optimisation levels). It doesn't happen with ARMCC5.
I tried using compilation options to avoid that, as described here: -ffreestanding and -disable-simplify-libcalls, at both compiler and linker levels but it didn't change (for the second option, I get an error message saying that the option is not supported).
In the ARMCLANG reference guide i've found the options -nostdlib -nostdlibinc that prevent (??) the compiler to use any function of a standard lib.
However I still need the math.h function.
Do you know how to prevent clang to use functions from the Standard C Lib that are not explicitely called in the code ?
EDIT: here is a quick and dirty reproduceable example:
https://godbolt.org/z/AX8_WV
Please do not discuss the quality of this example, I know it is dumb !!, I know about memset, etc... It is just to understand the issue
gcc know a lot about the memcpy, memset and similar functions and even they are called "the builtin functions". If you do not want those functions to be used by default just use the command line option -fno-builtin
https://godbolt.org/z/a42m4j
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.
I've got a weird macro that I'm debugging and I can't seem to figure out how to get the output of the preprocessor. I'm looking for the equivalent of GCC's -save-temps. I've tried passing dpp to compile:file/2, but it seems to generate a parse tree, not preprocessed Erlang.
compile:file("t.erl", 'E'). as mentioned by Anton is great, but doesn't help with macros that cause syntax errors. Lacking a way to debug complicated macros, I'm leaning toward doing my metaprogramming by writing programs that generate code.
Try one of these:
compile:file("t.erl", 'P').
compile:file("t.erl", 'E').
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.