Thank you @claudio that did the trick!
1 Like
We will need to fix motoko somehow - either by deeming type components not sharable/stable or supporting parsing of type components in object/actor types, but I’m not sure which yet.
My PR is just a workaround.
2 Likes
BTW I noticed that ‘dfx build’ takes a rather long time for this code. That’s my experience on a Windows Hyper-V VM running Ubutunu. Do you have the same experience?
@claudio first thank you, this fix worked for us as well. Out of curiosity, is this a difference in how private and public types are parsed? Is that why changing the type to private succeeds?
1 Like
The problem is that the type parser does not recognize type components in object/module/actor types. One fix is to extend the parser. The other is to forbid type components from appearing in shared/stable types, to ensure the parser won’t encounter them in ‘.most’ files.
Changing the types to private means they don’t appear in the actor type in the ‘.most’ file, avoiding the bug.
4 Likes
That’s expected, if you run just ‘dfx build’ alone then it will build all of our canister ( dev, qa, test ). Running just ‘dfx build modclub’ will result in 1-2 min build time which is manageable.
On a side note, we are seeing our wasm grow to more than 2mb now and we recently received this error:
status 413 Payload Too Large, content type "", content: Request 0x8dbf9ecf67edb9da4aae5cbb40978255d79aa034dda66161edef9c900ba671bf is too large. Message byte size 2117804 is larger than the max allowed 2097152
In the documentation it says the dfx deploy doesn’t support Gzip, is that still the case in later versions of dfx?
You can reduce the moc compile times considerably with flag ‘-no-check-ir’, if you are prepared to live a little more dangerously. Maybe use for debug builds but not release.( I saw the compile time of modclub go from 40s to 4s.)
Im not sure about the gzip question. Maybe ask separately or check the dfx release notes.
I’m not sure about the current version anymore (it’s gzip support is very spotty), but if you use the latest master, gzipped wasm is supported.
Support on old(er) versions (say 0.10.0 and before) is AFAIK non-existent.
1 Like
Wow, that is very fast, what risks do we take on using that flag?
The compiler does a number of transformations on the intermediate code. By default, as a sanity check to detect compiler bugs, it type checks the code after each transformation using a type system appropriate to the result of that transformation.
The flag suppresses the check so might fail to detect compiler bugs.
I would recommend to only turn it off during local development, but leave it on when producing the production deployed code (and final test run.)
1 Like
Can we keep the compiler reference up to date please? 
https://internetcomputer.org/docs/current/developer-docs/build/cdks/motoko-dfinity/compiler-ref/
And how do we pass moc flags to dfx? Is that possible?
You would have to use a canister of type “custom” for this AFAIK. Full schema for custom canisters is here: dfx.json Schema | Internet Computer
1 Like
We don’t document all the flags since some are for compiler development. This arguably is one of those.
You actually can specify flags to moc in the dfx.json file by adding an optional ‘arg’ (or maybe ‘args’) field in the motoko canister description.
1 Like
Would it be possible to get an example of a custom canister that compiles motoko with the -no-check-ir flag?
I’ve looked at the schema, but I honestly can’t figure out what I’m looking at and how to use it. 
1 Like
Here’s an example dfx.json that passes some command line args to moc for the “hello” canister.
{
"version": 1,
"dfx": "0.8.1",
"canisters": {
"hello": {
"type": "motoko",
"main": "src/hello/main.mo",
"args": "-v --compacting-gc -no-check-ir"
},
"hello_assets": {
"type": "assets",
"source": [
"src/hello_assets/assets"
],
"dependencies": [
"hello"
]
}
},
"defaults": {
"build": {
"packtool": "",
"args": ""
}
},
"networks": {
"local": {
"bind": "127.0.0.1:8000",
"type": "ephemeral"
}
}
}
3 Likes
So so so much faster! Thank you!