I'm trying to use the haskell-src-exts package to parse Haskell modules. Currently, I'm trying to parse the acme-io package's module, but I keep getting this error no matter what parse mode I try:
*** Exception: fromParseResult: Parse failed at [System/IO/Unsafe/Really/IMeanIt] (1:57): TemplateHaskell is not enabled
The module mentioned makes no references to TemplateHaskell, not in it's LANGUAGE pragma, nor is there a $ anywhere in the source file.
I'm wondering if my parse mode has something to do with it - here it is:
defaultParseMode { parseFilename = toFilePath m
, baseLanguage = Haskell2010
, extensions = []
, ignoreLanguagePragmas = True
, ignoreLinePragmas = True
, fixities = Nothing
}
I've also tried to replace the extensions field with knownExtensions from the parsing suite, without any luck.
This is a duplicate question of this answer - using the parseFile function fixed the issue. However, the reader should note that haskell-src-exts uses different parsing than GHC - I ran into another similar issue right after this, because haskell-src-exts can't handle multi-param contexts without -XMultiParamTypeClasses, yet GHC can, borking the parser if you're scraping Hackage. Hint may be a better option, can't say for sure though.
Related
I'd like to use Fable.JsonConverter.
My test code (almost copy this) FableJson.fs is below,
module FableJson
open Newtonsoft.Json
// Always use the same instance of the converter
// as it will create a cache to improve performance
let private jsonConverter = Fable.JsonConverter() :> JsonConverter
// Serialization
let toJson value =
JsonConvert.SerializeObject(value, [|jsonConverter|])
// Deserialization
let ofJson<'T> json =
JsonConvert.DeserializeObject<'T>(json, [|jsonConverter|])
and paket.dependencies file added nuget Fable.JsonConverter
source https://nuget.org/api/v2
storage:none
clitool dotnet-fable
nuget Fable.Core
nuget Fable.Import.Browser
nuget Fable.JsonConverter
and src/paket.references file added Fable.JsonConverter
dotnet-fable
Fable.Core
Fable.Import.Browser
Fable.JsonConverter
But cannnot compile.
~~~ snip ~~~
ERROR in ./src/FableJson.fs
d:/SRC/Repos/Fable/testJsonConverter/src/FableJson.fs(11,4): (11,57) error FABLE: Cannot find replacement for Newtonsoft.Json.JsonConvert::SerializeObject
# ./src/App.fs 6:0-48
# ./src/testJsonConverter.fsproj
# multi (webpack)-dev-server/client?http://localhost:8080 ./src/testJsonConverter.fsproj
ERROR in ./src/FableJson.fs
d:/SRC/Repos/Fable/testJsonConverter/src/FableJson.fs(15,4): (15,62) error FABLE: Cannot find replacement for Newtonsoft.Json.JsonConvert::DeserializeObject
# ./src/App.fs 6:0-48
# ./src/testJsonConverter.fsproj
# multi (webpack)-dev-server/client?http://localhost:8080 ./src/testJsonConverter.fsproj
ERROR in ./src/FableJson.fs
d:/SRC/Repos/Fable/testJsonConverter/src/FableJson.fs(7,28): (7,49) error FABLE: Cannot find replacement for Fable.JsonConverter::.ctor
# ./src/App.fs 6:0-48
# ./src/testJsonConverter.fsproj
# multi (webpack)-dev-server/client?http://localhost:8080 ./src/testJsonConverter.fsproj
What should I do?
#Maslow is right, with Fable 2 we removed Fable.JsonConverter in favour of the library created by the community.
Thoth.Json offers an Elm-like experience where you can decode the JSON manually or automatically depending on your preference. This library also offers a good error message
Fable.SimpleJson a library for parsing and transforming JSON in Fable projects
Thoth.Json is complemented with Thoth.Json.Net to allow you to use the same API on the backend.
I think Fable.SimpleJson also offer supports for the backend, but I am not sure.
You can use the JavaScript native API Fable.Core.JS.JSON.stringify and Fable.Core.JS.JSON.parse(x) but you will have to use unbox/cast to force the type of your Data which is not safe and can break easily.
See here: http://fable.io/docs/interacting.html#json-serialization
On the client side you should use the Fable.Core.JsInterop functions toJson and ofJson.
Fable.JsonConverter is for the server-side only. It uses Newtonsoft.Json, which is a .NET library that doesn't run in the browser. The compile error you're getting is because Fable doesn't know how to convert Newtonsoft.Json function calls into JavaScript.
It can be confusing when you're working with a language that works in one runtime (e.g. .NET) and also compiles into another one (e.g. JS), but you should try to keep a clear mental model where all of your code is running and therefore what it has access to.
The accepted answer is no longer valid. For newer Fable the only thing I've been able to find is Fable.Core.JS.JSON.stringify which calls the browser's built-in serializer.
Also Fable.Core.JS.JSON.parse(x) which returns obj.
I've noticed that calling hh_client is not always returning correct result. For example: I have following pieces of code:
backend\ConvertMessage.hh:
<?hh // strict
namespace ApiBackend\ConvertMessage {
enum Status: int {
success = 0;
// ... error codes
};
// ... some other classes
};
other place in project:
throw new \SoapFault(
'Server',
\ApiBackend\ConvertMessage\Status::getNames()[$result->status]
);
Sometimes, after doing some changes in project I get following error message: Could not find static method getNames in type ApiBackend\ConvertMessage\Status (Typing[4090])
When I remove a semicolon after one of closing curly brackets, hh_client stops displaying error. But when I insert semicolon back on its place, typechecker still gives me No errors! message.
This is not the only file that causes this problem - it happens to all enums.
It seems to me that it is problem with some cache of either hh_client or hh_server.
Thanks in advance for helping me with solving this problem (and sorry if my english is not too good).
You are probably using an outdated version of HHVM. This problem sounds an awful lot like this race condition, which was fixed in HHVM 3.5.0 and newer (and was backported into the 3.3.3 LTS release). Notably, 3.4.x still had the bug.
What version of HHVM are you using?
I'm having problems with a specific line of code - building.transmitter:[operation](player, unpack({...})) that causes an error in Corona, yet this loads fine when it's run in Lua separately. I suspect it has something to do with the : being placed before the [operation] variable but I'm clueless why.
Specifically the module is written as,
local activate = {}
local function activate.transmitter(player, operation, ...)
building = player:getTile()
building.transmitter:[operation](player, unpack({...}))
end
return activate
The runtime errror that is appearing gives me
"error loading module from file, '<name>' expected near '['"
Edit - WOW! I didn't notice that when troubleshooting this in Corona I changed some of the lines of code to identify the problem. I then mistakenly tested the edited code in Lua and it ran fine. I didn't realize the code wasn't the original until siffiejoe pointed out the interpreter getting an error as well. Sorry for the mistake.
maybe Corona uses older version of Lua which does not support this syntax. You can try workaround instead of
building.transmitter:[operation](player, unpack({...}));
you can call
building.transmitter[operation](building.transmitter, player, unpack({...}));
I am using analyzer_experimental to parse a Dart file into a CompilationUnit:
import 'package:analyzer_experimental/analyzer.dart';
var unit;
try {
unit = parseDartFile(path);
} on AnalyzerErrorGroup catch(e){
print(e);
}
The above code will catch any parsing errors encountered.
I am also interested in seeing any warnings associated with the file (e.g. 'Undefined name "foo"'). I know that the experimental_analyzer library has the capability to generate these warnings when running from the command line but it does not seem to be possible to get the warnings programmatically, without directly referencing classes in the src folder (which seems like a bad idea).
Is there any way to achieve this?
It's likely this package was very incomplete at the time.
There's now an analyzer package on pub and also a (work-in-progress) STDIN/STDOUT Analyzer Service aimed to help making tooling support easier for IDE extension authors.
I am using a REXML Ruby parser to parse an XML file. But on a 64 bit AIX box with 64 bit Ruby, I am getting the following error:
REXML::ParseException: #<REXML::ParseException: #<RegexpError: Stack overflow in
regexp matcher:
/^<((?>(?:[\w:][\-\w\d.]*:)?[\w:][\-\w\d.]*))\s*((?>\s+(?:[\w:][\-\w\d.]*:)?[\w:][\-\w\d.]*\s*=\s*(["']).*?\3)*)\s*(\/)?>/mu>
The call for the same is something like this:
REXML::Document.new(File.open(actual_file_name, "r"))
Does anyone have an idea regarding how to solve this issue?
I've had several issues for REXML, it doesn't seem to be the most mature library. Usually I use Nokogiri for Ruby XML parsing stuff, it should be faster and more stable than REXML. After installing it with sudo gem install nokogiri, you can use something like this to get a DOM instance:
doc = Nokogiri.XML(File.open(actual_file_name, 'rb'))
# => #<Nokogiri::XML::Document:0xf1de34 name="document" [...] >
The documentation on the official webpage is also much better than that of REXML, IMHO.
I almost immediately found the answer.
The first thing I did was to search in the ruby source code for the error being thrown.
I found that regex.h was responsible for this.
In regex.h, the code flow is something like this:
/* Maximum number of duplicates an interval can allow. */
#ifndef RE_DUP_MAX
#define RE_DUP_MAX ((1 << 15) - 1)
#endif
Now the problem here is RE_DUP_MAX. On AIX box, the same constant has been defined somewhere in /usr/include.
I searched for it and found in
/usr/include/NLregexp.h
/usr/include/sys/limits.h
/usr/include/unistd.h
I am not sure which of the three is being used(most probably NLregexp.h).
In these headers, the value of RE_DUP_MAX has been set to 255! So there is a cap placed on the number of repetitions of a regex!
In short, the reason is the compilation taking the system defined value than that we define in regex.h!
This also answers my question which i had asked recently:
Regex limit in ruby 64 bit aix compilation
I was not able to answer it immediately as i need to have min of 100 reputation :D :D
Cheers!