WIP: New Cross-Targeting Type Provider SDK #88

baronfel · 2017-10-12T02:51:29Z

This so far does most of the grunt work for using the new context-required Type Provider SDK.

It's not functional yet, I was hoping to get some pointers though on what I may be doing wrong.

The biggest change is that the definition and operation compilers needed the context passed so that they could create the new context-aware members. This has the unfortunate side-effect of requiring a reference to the ProvidedTypesTesting module, which is sadly internal. I'm partly opening this to point Don at this and ask if that can be opened up some.

This will compile, but the Tests and Docs solution fails for the following reason:

  2) FS3033: D:\code\SwaggerProvider\tests\SwaggerProvider.ProviderTests\Swagger.PetStore.Tests.fs(7,17): The type provider 'SwaggerProvider.SwaggerTypeProvider' reported an error: The operation 'Namespace' on item 'Pet[]' should not be called on provided type, member or parameter

But I don't see easily what I'm doing wrong.

dsyme · 2017-10-12T19:59:13Z

I'm looking into these failures - thanks. Have found a few fixes. Swagger is a great stessssss case,,,,

baronfel · 2017-10-12T20:01:21Z

I'm hoping to pull down your latest round of changes after work today and see how much further I can get!

Heh, and @sergey-tihon is already on top of that

sergey-tihon · 2017-10-12T20:04:28Z

@baronfel I did push an update to latest SDK into this PR just a minute before @dsyme comment.

now we have different error

The operation 'GetProperties' on item 'Tuple`2' should not be called on provided type, member or parameter of type 'ProviderImplementation.ProvidedTypes.ContextTypeSymbol'. Stack trace:� at ProviderImplementation.ProvidedTypes.Misc.notRequired[a,b](a this, String opname, String item)� at ProviderImplementation.ProvidedTypes.ContextTypeSymbol.GetProperties(BindingFlags _bindingAttr)� at Microsoft.FSharp.Reflection.Impl.get@579-3(Type typ, Int32 index)� at Microsoft.FSharp.Reflection.Impl.getTupleReaderInfo(Type typ, Int32 index)� at Microsoft.FSharp.Reflection.FSharpValue.PreComputeTuplePropertyInfo(Type tupleType, Int32 index)� at <StartupCode$SwaggerProvider-DesignTime>.$ProvidedTypes.mkGet@353(Type ty, Int32 i, FSharpExpr e)� at ProviderImplementation.ProvidedTypes.QuotationSimplifier.transExpr(FSharpExpr q)

Update:

The type provider 'SwaggerProvider.SwaggerTypeProvider' reported an error: Specified method is not supported.�

dsyme · 2017-10-12T20:06:28Z

@sergey-tihon Yes. I'll take a look tomorrow. Don't bother trying anything for a bit

sergey-tihon · 2017-10-13T18:58:37Z

The error with the latest SDK is

error FS3033: The type provider 'SwaggerProvider.SwaggerTypeProvider' reported an error: Type mismatch when building 'value': the type of the field was incorrect. Expected 'Microsoft.FSharp.Core.FSharpOption1[System.Int32]', but received type 'Microsoft.FSharp.Core.FSharpOption1[System.Int32]'.Parameter name: receivedType

it looks like Fsharp.Core version mismatch somewhere...

We compile using FSharp.Core (4.0.0.1) and reference in test project with FSharp.Core (4.2.3)

dsyme · 2017-10-17T18:29:24Z

@sergey-tihon @baronfel I'm working on this, I'll push updates to this PR as I go

sergey-tihon · 2017-10-18T19:41:34Z

thank you @dsyme, it looks like we are one step closer but not done yet.
anything here we able to help with?

dsyme · 2017-10-19T11:04:27Z

Another step closer - many more tests now pass. I'm now seeing this final failure, will work on it later today

sergey-tihon · 2017-10-19T11:44:46Z

and we cannot compile test projects on Mono, Version 5.4.0.201
https://travis-ci.org/fsprojects/SwaggerProvider/builds/289918542#L2408

/home/travis/build/fsprojects/SwaggerProvider/tests/SwaggerProvider.ProviderTests/Swagger.PetStore.Tests.fs(7,17): error FS3033: The type provider 'SwaggerProvider.SwaggerTypeProvider' reported an error: Error in pass2 for type PetStore, error: One of your modules expects the type 'SwaggerProvider.Internal.ProvidedSwaggerBaseType' to be defined within the module being emitted. keys = [|TdKey� ([],� ProviderImplementation.ProvidedTypes.AssemblyReader.Utils+StructOption1[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]],� "<Module>");� TdKey� ([],� ProviderImplementation.ProvidedTypes.AssemblyReader.Utils+StructOption1[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]],� "PetStore");� TdKey� (["SwaggerProvider.PetStore"],� ProviderImplementation.ProvidedTypes.AssemblyReader.Utils+StructOption1[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]],� "ApiResponse");� TdKey� (["SwaggerProvider.PetStore"],� ProviderImplementation.ProvidedTypes.AssemblyReader.Utils+StructOption1[[System.String, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]],� "Category");� TdKey� (["SwaggerProvider.PetStore"],� ....

dsyme · 2017-10-20T17:06:44Z

@sergey-tihon I pushed another update, things feel one step closer.

However I'm concerned that there might have been a significant performance regression, where compiling a generative assembly is now slow. I'm noticing in particular that the APIs.Guru tests seem slow - 2-10seconds/test. Have they always been that slow? However that applies to master as well so maybe it's always been like this.

If there has been a further slowdown I'd like to know - it's not totally surprising if there has been - there are a number of places where code gen may be inefficient in the new implementation and Swagger might well reveal new places where we need to be more careful.

The latest commit has one use of UncheckedQuotations Expr.FieldSetUnchekced. This can happen when manually building quotations involving types built using MakeGenericType.

dsyme · 2017-10-20T17:16:17Z

Travis failure:

/home/travis/build/fsprojects/SwaggerProvider/tests/SwaggerProvider.ProviderTests/Swagger.i0027.Tests.fs(6,17): error FS3033: The type provider 'SwaggerProvider.SwaggerTypeProvider' reported an error: Error in pass2 for type PSwagger, error: One of your modules expects the type 'SwaggerProvider.Internal.ProvidedSwaggerBaseType' to be defined within the module being emitted. keys =

One of your modules expects the type 'SwaggerProvider.Internal.ProvidedSwaggerBaseType' to be defined within the module being emitted. keys =

I'm not seeing that behaviour on Windows

dsyme · 2017-10-20T17:20:34Z

One error so far on AppVeyor for test case https://api.apis.guru/v2/specs/azure.com/arm-iothub/2016-02-03/swagger.json

[10:13:34 ERR] Integration/Compile TP/Compile schema https://api.apis.guru/v2/specs/azure.com/arm-iothub/2016-02-03/swagger.json errored in 00:00:00.7250000 <Expecto>
System.Exception: Compilation error:
C:\Users\appveyor\AppData\Local\Temp\1\tmp6D92.fs (4,28)-(4,122) typecheck error The type provider 'SwaggerProvider.SwaggerTypeProvider' reported an error: Arithmetic operation resulted in an overflow.
C:\Users\appveyor\AppData\Local\Temp\1\tmp6D92.fs (5,20)-(5,35) typecheck error The value or constructor 'ProvidedSwagger' is not defined.
   at Microsoft.FSharp.Core.PrintfModule.PrintFormatToStringThenFail@1379.Invoke(String message)
   at [email protected](Unit _arg1) in C:\projects\swaggerprovider\tests\SwaggerProvider.ProviderTests\APIs.Guru.FSC.Tests.fs:line 61
   at [email protected](Unit unitVar)
   at [email protected](AsyncParams`1 args)
[10:13:35 DBG]

…eems that it works now.

sergey-tihon · 2017-10-20T21:38:42Z

I'm noticing in particular that the APIs.Guru tests seem slow - 2-10seconds/test. Have they always been that slow? However that applies to master as well so maybe it's always been like this.

Yes, it feels slower, but it never was fast.

We did the comparison before - fsharp/fsharp-compiler-docs#744 (comment)

I tool FCS 12.0.1 26 min 28 sec and run small parser script

here are the results

Count: 390
Avg time: 00:00:03.3979487
Max time: 00:00:44.4510000
Cnt [0(s)<t<=1(s)] = 90
Cnt [1(s)<t<=2(s)] = 125
Cnt [2(s)<t<=3(s)] = 59
Cnt [3(s)<t<=5(s)] = 60
Cnt [5(s)<t<=10(s)] = 37
Cnt [10(s)<t<=30(s)] = 14
Cnt [30(s)<t<=60(s)] = 5

and here are the results from the last run on Win (38min)

Count: 652
Avg time: 00:00:03.2058082
Max time: 00:00:44.8560000
Cnt [0(s)<t<=1(s)] = 176
Cnt [1(s)<t<=2(s)] = 170
Cnt [2(s)<t<=3(s)] = 111
Cnt [3(s)<t<=5(s)] = 85
Cnt [5(s)<t<=10(s)] = 82
Cnt [10(s)<t<=30(s)] = 23
Cnt [30(s)<t<=60(s)] = 5

We have more schemas from APIs.guru now, but avg and max time are almost equal.
So it does not looks like significant perf degradation

sergey-tihon · 2017-10-21T06:09:50Z

For history, or if we decide to verify the slowest compilation samples (slower than 30sec)

StarterPack

[13:28:43 DBG] Integration/Compile TP/Compile schema https://api.apis.guru/v2/specs/github.com/v3/swagger.json passed in 00:00:38.9560000.
[13:31:41 DBG] Integration/Compile TP/Compile schema https://api.apis.guru/v2/specs/googleapis.com/compute/alpha/swagger.json passed in 00:00:42.5940000.
[13:32:18 DBG] Integration/Compile TP/Compile schema https://api.apis.guru/v2/specs/googleapis.com/compute/beta/swagger.json passed in 00:00:36.8870000.
[13:41:03 DBG] Integration/Compile TP/Compile schema https://api.apis.guru/v2/specs/stackexchange.com/2.0/swagger.json passed in 00:00:44.4510000.

New SDK

[10:05:36 DBG] Integration/Compile TP/Compile schema https://api.apis.guru/v2/specs/amazonaws.com/ec2/2016-11-15/swagger.json passed in 00:00:35.1280000.
[10:17:13 DBG] Integration/Compile TP/Compile schema https://api.apis.guru/v2/specs/beezup.com/2.0/swagger.json passed in 00:00:34.8830000.
[10:21:59 DBG] Integration/Compile TP/Compile schema https://api.apis.guru/v2/specs/github.com/v3/swagger.json passed in 00:00:35.0010000.
[10:34:18 DBG] Integration/Compile TP/Compile schema https://api.apis.guru/v2/specs/stackexchange.com/2.0/swagger.json passed in 00:00:44.8560000.
[10:37:00 DBG] Integration/Compile TP/Compile schema https://api.apis.guru/v2/specs/zuora.com/2017-09-06/swagger.json passed in 00:00:36.6860000.

The winner is https://api.apis.guru/v2/specs/stackexchange.com/2.0/swagger.json =)

P.S. The is no guarantee that we could heavily rely on numbers from AppVeyour logs

sergey-tihon · 2017-10-21T06:58:06Z

Again, if we could compare time from AppVeyour logs ... Here is the diff - https://gist.github.com/sergey-tihon/ea37e6477408b44776fd7ba630ddfaa6

Compilation became slower (more than 2 seconds)

New-Old	Old	New	Url
00:05.352	00:02.387	00:07.739	https://api.apis.guru/v2/specs/squareup.com/2.0/swagger.json
00:05.020	00:01.519	00:06.539	https://api.apis.guru/v2/specs/azure.com/arm-apimanagement/2016-07-07/swagger.json
00:04.645	00:05.328	00:09.973	https://api.apis.guru/v2/specs/azure.com/arm-devtestlabs/2016-05-15/swagger.json
00:03.474	00:03.753	00:07.227	https://api.apis.guru/v2/specs/googleapis.com/sheets/v4/swagger.json
00:02.771	00:02.613	00:05.384	https://api.apis.guru/v2/specs/googleapis.com/slides/v1/swagger.json
00:02.733	00:09.653	00:12.386	https://api.apis.guru/v2/specs/apacta.com/0.0.1/swagger.json
00:02.334	00:07.656	00:09.990	https://api.apis.guru/v2/specs/epa.gov/dfr/0.0.0/swagger.json
00:02.051	00:05.068	00:07.119	https://api.apis.guru/v2/specs/googleapis.com/dataflow/v1b3/swagger.json

Compilation became faster (more than 3 seconds)

New-Old	Old	New	Url
00:03.368	00:10.193	00:06.825	https://api.apis.guru/v2/specs/googleapis.com/admin/directory_v1/swagger.json
00:03.465	00:09.637	00:06.172	https://api.apis.guru/v2/specs/reverb.com/3.0/swagger.json
00:03.955	00:38.956	00:35.001	https://api.apis.guru/v2/specs/github.com/v3/swagger.json
00:06.258	00:26.011	00:19.753	https://api.apis.guru/v2/specs/googleapis.com/dfareporting/v2.7/swagger.json
00:06.649	00:08.094	00:01.445	https://api.apis.guru/v2/specs/bbc.com/1.0.0/swagger.json
00:07.732	00:24.544	00:16.812	https://api.apis.guru/v2/specs/azure.com/arm-web/2015-08-01/swagger.json
00:07.865	00:13.757	00:05.892	https://api.apis.guru/v2/specs/bitbucket.org/2.0/swagger.json
00:09.974	00:23.012	00:13.038	https://api.apis.guru/v2/specs/trello.com/1.0/swagger.json
00:15.114	00:26.947	00:11.833	https://api.apis.guru/v2/specs/geodesystems.com/1.0.0/swagger.json

sergey-tihon · 2017-10-21T09:43:16Z

One of your modules expects the type 'T' to be defined within the module being emitted

I can reproduce it locally

/Users/sergey/github/SwaggerProvider/tests/SwaggerProvider.ProviderTests/Swagger.GitHub.Tests.fs(8,15): error FS3033: The type provider 'SwaggerProvider.SwaggerTypeProvider' reported anerror: Error in pass2 for type GitHub, error: One of your modules expects the type 'SwaggerProvider.Internal.ProvidedSwaggerBaseType' to be defined within the module being emitted. keys=

I am not sure, but it may be similar to fsprojects/FSharp.TypeProviders.SDK#150 (base type lookups)

We generate TP

// Create Swagger provider type
let baseTy = Some typeof<SwaggerProvider.Internal.ProvidedSwaggerBaseType>
let ty = ProvidedTypeDefinition(tempAsm, NameSpace, typeName, baseTy, isErased = false, hideObjectMethods = true)

and type SwaggerProvider.Internal.ProvidedSwaggerBaseType is not defined in emitted module - it is real type from different assembly SwaggerProvider.Runtime.dll

Arithmetic operation resulted in an overflow.

Also on Mono 5.4.0.201 I see Arithmetic operation resulted in an overflow. errors even on simple testes (without FCS)

/Users/sergey/github/SwaggerProvider/tests/SwaggerProvider.ProviderTests/Swagger.PetStore.Tests.fs(7,17): error FS3033: The type provider 'SwaggerProvider.SwaggerTypeProvider' reported an error: Arithmetic operation resulted in an overflow. [/Users/sergey/github/SwaggerProvider/tests/SwaggerProvider.ProviderTests/SwaggerProvider.ProviderTests.fsproj]

dsyme · 2017-10-23T13:48:48Z

@sergey-tihon I'm trying to repro the few remaining failures on AppVeyor/Windows first. In the log I see this:

[00:26:07] [12:14:53 ERR] Integration/Compile TP/Compile schema https://api.apis.guru/v2/specs/oxforddictionaries.com/1.8.0/swagger.json errored in 00:00:00.5650000 <Expecto>
[00:11:07] [11:59:54 ERR] Integration/Compile TP/Compile schema https://api.apis.guru/v2/specs/azure.com/arm-iothub/2016-02-03/swagger.json errored in 00:00:00.7200000 <Expecto>
[00:19:49] [12:08:36 ERR] Integration/Compile TP/Compile schema https://api.apis.guru/v2/specs/googleapis.com/compute/alpha/swagger.json errored in 00:00:00.7620000 <Expecto>
[00:19:51] [12:08:38 ERR] Integration/Compile TP/Compile schema https://api.apis.guru/v2/specs/googleapis.com/compute/beta/swagger.json errored in 00:00:01.9690000 <Expecto>
[00:19:52] [12:08:38 ERR] Integration/Compile TP/Compile schema https://api.apis.guru/v2/specs/googleapis.com/compute/v1/swagger.json errored in 00:00:00.6190000 <Expecto>

All with

[00:26:07] System.Exception: Compilation error:
[00:26:07] C:\Users\appveyor\AppData\Local\Temp\1\tmp9B84.fs (4,28)-(4,119) typecheck error The type provider 'SwaggerProvider.SwaggerTypeProvider' reported an error: Arithmetic operation resulted in an overflow.
[00:26:07] C:\Users\appveyor\AppData\Local\Temp\1\tmp9B84.fs (5,20)-(5,35) typecheck error The value or constructor 'ProvidedSwagger' is not defined.
[00:26:07]    at Microsoft.FSharp.Core.PrintfModule.PrintFormatToStringThenFail@1379.Invoke(String message)
[00:26:07]    at [email protected](Unit _arg1) in C:\projects\swaggerprovider\tests\SwaggerProvider.ProviderTests\APIs.Guru.FSC.Tests.fs:line 61
[00:26:07]    at [email protected](Unit unitVar)
[00:26:07]    at [email protected](AsyncParams`1 args)

However when I try to repro this using a source file

module TestModule
open SwaggerProvider
type ProvidedSwagger = SwaggerProvider<"https://api.apis.guru/v2/specs/oxforddictionaries.com/1.8.0/swagger.json">
let instance = ProvidedSwagger()

and a command-line compile

  fsc.exe --noframework -o b.dll -a b.fs -r:C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll -r:"C:\Program Files (x86)\Microsoft SDKs\F#\4.1\Framework\v4.0\FSharp.Core.dll" -r:"C:\GitHub\misc\SwaggerProvider\packages\test\FSharp.Data\lib\net45\FSharp.Data.dll" -r:"C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\System.dll" -r:"C:\GitHub\misc\SwaggerProvider\tests\SwaggerProvider.ProviderTests\..\..\bin\SwaggerProvider\SwaggerProvider.Runtime.dll" -r:"C:\GitHub\misc\SwaggerProvider\tests\SwaggerProvider.ProviderTests\..\..\bin\SwaggerProvider\SwaggerProvider.dll"

it doesn't repro....

dsyme · 2017-10-23T14:26:30Z

There are also some new errors appearing in CI for that list of APIs today,. e.g https://api.apis.guru/v2/specs/deutschebahn.com/stada/2.1.02/swagger.json gives

dsyme · 2017-10-23T15:15:03Z

@sergey-tihon Just to mention fsprojects/FSharp.TypeProviders.SDK#152 is a blocking issue before this should be integrated

Basically we should add testing to swagger that fsi.exe will also load some/all of the Guru API tests

sergey-tihon · 2017-10-23T17:47:34Z

There are also some new errors appearing in CI for that list of APIs today,. e.g https://api.apis.guru/v2/specs/deutschebahn.com/stada/2.1.02/swagger.json gives

This one is fixed already, I did rerun AppVeyor build. Only 5 schemas fails now with Arithmetic operation resulted in an overflow.

sergey-tihon · 2017-10-23T20:30:53Z

fsc.exe --noframework -o b.dll -a b.fs -r:C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll -r:"C:\Program Files (x86)\Microsoft SDKs\F#\4.1\Framework\v4.0\FSharp.Core.dll" -r:"C:\GitHub\misc\SwaggerProvider\packages\test\FSharp.Data\lib\net45\FSharp.Data.dll" -r:"C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\System.dll" -r:"C:\GitHub\misc\SwaggerProvider\tests\SwaggerProvider.ProviderTests....\bin\SwaggerProvider\SwaggerProvider.Runtime.dll" -r:"C:\GitHub\misc\SwaggerProvider\tests\SwaggerProvider.ProviderTests....\bin\SwaggerProvider\SwaggerProvider.dll"

This is interesting, it fails on my machine when I compile using FCS, but it works when I do it manually from Developer Command Prompt for Vs 2017 on Win10 Fall Creators Update.

just a note, when we call fsc from the test, we generate a slightly different list of referenced assemblies

["-r"; "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscorlib.dll"; "-r";
"y:\SwaggerProvider\tests\SwaggerProvider.ProviderTests\bin\Release\FSharp.Core.dll";
"-r";
"y:\SwaggerProvider\tests\SwaggerProvider.ProviderTests\bin\Release\SwaggerProvider.DesignTime.dll";
"-r";
"C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\System.dll";
"-r"; "y:\SwaggerProvider\bin\SwaggerProvider\SwaggerProvider.Runtime.dll";
"-r"; "y:\SwaggerProvider\bin\SwaggerProvider\SwaggerProvider.dll"]

Diff1

we use a later version of FSharp.Core.dll - y:\SwaggerProvider\tests\SwaggerProvider.ProviderTests\bin\Release\FSharp.Core.dll instead of C:\Program Files (x86)\Microsoft SDKs\F#\4.1\Framework\v4.0\FSharp.Core.dll

Diff2

SwaggerTP does not have reference to FSharp.Data.dll we include some source files in design-time assembly, so we reference y:\SwaggerProvider\tests\SwaggerProvider.ProviderTests\bin\Release\SwaggerProvider.DesignTime.dll instead of C:\GitHub\misc\SwaggerProvider\packages\test\FSharp.Data\lib\net45\FSharp.Data.dll

Works from command line

Fails using FCS

sergey-tihon · 2017-10-24T20:14:08Z

First green build on Windows! Yeah!

dsyme · 2017-10-26T19:23:10Z

One error on windows on last run - I don't think it is related to the PR though - looks like a network problem

https://api.apis.guru/v2/specs/amazonaws.com/elasticbeanstalk/2010-12-01/swagger.yaml errored in 00:09:53.2210000 <Expecto>
[00:45:53] YamlDotNet.Core.SyntaxErrorException: (Line: 788, Col: 15, Idx: 32336) - (Line: 788, Col: 18, Idx: 32339): While scanning a quoted scalar, find unexpected end of stream.
[00:45:53]    at YamlDotNet.Core.Scanner.ScanFlowScalar(Boolean isSingleQuoted)
[00:45:53]    at YamlDotNet.Core.Scanner.FetchFlowScalar(Boolean isSingleQuoted)
[00:45:53]    at YamlDotNet.Core.Scanner.FetchNextToken()
[00:45:53]    at YamlDotNet.Core.Scanner.FetchMoreTokens()
[00:45:53]    at YamlDotNet.Core.Scanner.MoveNextWithoutConsuming()
[00:45:53]    at YamlDotNet.Core.Parser.GetCurrentToken()
[00:45:53]    at YamlDotNet.Core.Parser.ParseBlockMappingValue()
[00:45:53]    at YamlDotNet.Core.Parser.MoveNext()
[00:45:53]    at YamlDotNet.Core.ParserExtensions.Allow[T](IParser parser)
[00:45:53]    at YamlDotNet.Serialization.NodeDeserializers.ScalarNodeDeserializer.YamlDotNet.Serialization.INodeDeserializer.Deserialize(IParser parser, Type expectedType, Func`3 nestedObjectDeserializer, Object& value)

dsyme · 2017-10-26T19:23:45Z

Close/reopen to re-run CI

dsyme · 2017-10-26T19:26:47Z

Still getting this on Linux:

/home/travis/build/fsprojects/SwaggerProvider/tests/SwaggerProvider.ProviderTests/Swagger.PetStore.Tests.fs(7,17): error FS3033: The type provider 'SwaggerProvider.SwaggerTypeProvider' reported an error: Error in pass2 for type PetStore, error: One of your modules expects the type 'SwaggerProvider.Internal.ProvidedSwaggerBaseType' to be defined within the module being emitted. keys = ...

sergey-tihon · 2017-10-26T20:01:21Z

One error on windows on last run - I don't think it is related to the PR though - looks like a network problem

Yes, this is not related.

error FS3033: The type provider 'SwaggerProvider.SwaggerTypeProvider' reported an error: Error in pass2 for type PetStore, error: One of your modules expects the type 'SwaggerProvider.Internal.ProvidedSwaggerBaseType' to be defined within the module being emitted. keys = [|TdKey ([],,""); TdKey ([],SwaggerProvider,"PetStore");� TdKey (["SwaggerProvider.PetStore"],,"ApiResponse");�

Any idea what it could be?

dsyme · 2017-10-26T21:29:52Z

@sergey-tihon There must be some difference in the implementation of reflection for Mono and .NET. I will need to debug it on a Linux VM I think. That might take a while before I get to that I'm afraid

dsyme · 2017-10-31T15:50:26Z

I can at least now repro this using Windows Subsystem for Linux :) So no need to switch to a Linux VM

baronfel · 2017-11-01T16:59:13Z

ok, now we're green everywhere :) Thanks for the hard work, @dsyme!

dsyme · 2017-11-01T17:01:15Z

Oh that's great

baronfel · 2017-11-03T15:57:18Z

Is this PR good as it stands, or should we go ahead and trial the proposed type-provider packaging conventions being discussed in dotnet/fsharp#3736? That issue seems to be in flux still.

dsyme · 2017-11-03T16:01:22Z

@baronfel You should treat this as separate.

This PR has value in and of itself, as it means that code will be correctly generated for the target .NET Framework, e.g. if targeting .NET 4.6.1, then code will be generated that references the correct .NET 4,6,1 assemblies, regardless of the .NET version being used by the host compiler.

sergey-tihon · 2017-11-04T12:06:23Z

I’ll merge it immediately when I back from vacation and will release new Nuget package based on new SDK. Net core support will be in separate pr. Thx.

sergey-tihon · 2017-11-17T06:55:23Z

Merged and released as v0.9.0

most of the grunt work for using the new Type Provider SDK

2f4860a

baronfel mentioned this pull request Oct 12, 2017

Question re: generative providers and testing fsprojects/FSharp.TypeProviders.SDK#140

Closed

Dependency update

97e9b00

sergey-tihon added 2 commits October 13, 2017 09:21

sdk update

9f12b25

sdk update

44afee8

updates for latest tpsdk

6f89bd7

update to latest TPSDK fixes

3bf2f31

update to latest SDK, add one use of Expr.FieldSetUnchecked

56892c4

This test failed previously with StackOverflowException in FCS, but s…

ac088ff

…eems that it works now.

update files

8a3502c

sergey-tihon added 2 commits October 23, 2017 21:23

sdk update

e674f3b

restore schema parse tests

30da540

sergey-tihon and others added 5 commits October 24, 2017 00:18

sdk update

040ae9a

Load in FSI generated TP

6363ffc

Load in FSI 30 random TP+schemas

2c0e17e

sdk updates

3a3b493

sdk updates

b1a2780

another TPSDK update

6a64d05

dsyme closed this Oct 26, 2017

dsyme reopened this Oct 26, 2017

dsyme mentioned this pull request Oct 30, 2017

"Base type not found in assembly" when using new TPSDK for Swagger on Linux/OSX fsprojects/FSharp.TypeProviders.SDK#166

Closed

SDK update

103f0d2

sdk update

1b39745

Dependencies update

cfb7a66

sergey-tihon merged commit cfb7a66 into fsprojects:master Nov 17, 2017

sergey-tihon mentioned this pull request Dec 2, 2017

[WIP] On the way to v1.0 #92

Merged

18 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WIP: New Cross-Targeting Type Provider SDK #88

WIP: New Cross-Targeting Type Provider SDK #88

baronfel commented Oct 12, 2017

dsyme commented Oct 12, 2017

baronfel commented Oct 12, 2017 •

edited

Loading

sergey-tihon commented Oct 12, 2017 •

edited

Loading

dsyme commented Oct 12, 2017

sergey-tihon commented Oct 13, 2017 •

edited

Loading

dsyme commented Oct 17, 2017

sergey-tihon commented Oct 18, 2017 •

edited

Loading

dsyme commented Oct 19, 2017

sergey-tihon commented Oct 19, 2017 •

edited

Loading

dsyme commented Oct 20, 2017

dsyme commented Oct 20, 2017 •

edited

Loading

dsyme commented Oct 20, 2017

sergey-tihon commented Oct 20, 2017 •

edited

Loading

sergey-tihon commented Oct 21, 2017 •

edited

Loading

sergey-tihon commented Oct 21, 2017 •

edited

Loading

sergey-tihon commented Oct 21, 2017

dsyme commented Oct 23, 2017

dsyme commented Oct 23, 2017

dsyme commented Oct 23, 2017

sergey-tihon commented Oct 23, 2017

sergey-tihon commented Oct 23, 2017

sergey-tihon commented Oct 24, 2017

dsyme commented Oct 26, 2017

dsyme commented Oct 26, 2017

dsyme commented Oct 26, 2017

sergey-tihon commented Oct 26, 2017

dsyme commented Oct 26, 2017

dsyme commented Oct 31, 2017

baronfel commented Nov 1, 2017

dsyme commented Nov 1, 2017

baronfel commented Nov 3, 2017 •

edited

Loading

dsyme commented Nov 3, 2017

sergey-tihon commented Nov 4, 2017

sergey-tihon commented Nov 17, 2017

WIP: New Cross-Targeting Type Provider SDK #88

WIP: New Cross-Targeting Type Provider SDK #88

Conversation

baronfel commented Oct 12, 2017

dsyme commented Oct 12, 2017

baronfel commented Oct 12, 2017 • edited Loading

sergey-tihon commented Oct 12, 2017 • edited Loading

dsyme commented Oct 12, 2017

sergey-tihon commented Oct 13, 2017 • edited Loading

dsyme commented Oct 17, 2017

sergey-tihon commented Oct 18, 2017 • edited Loading

dsyme commented Oct 19, 2017

sergey-tihon commented Oct 19, 2017 • edited Loading

dsyme commented Oct 20, 2017

dsyme commented Oct 20, 2017 • edited Loading

dsyme commented Oct 20, 2017

sergey-tihon commented Oct 20, 2017 • edited Loading

sergey-tihon commented Oct 21, 2017 • edited Loading

sergey-tihon commented Oct 21, 2017 • edited Loading

Compilation became slower (more than 2 seconds)

Compilation became faster (more than 3 seconds)

sergey-tihon commented Oct 21, 2017

One of your modules expects the type 'T' to be defined within the module being emitted

Arithmetic operation resulted in an overflow.

dsyme commented Oct 23, 2017

dsyme commented Oct 23, 2017

dsyme commented Oct 23, 2017

sergey-tihon commented Oct 23, 2017

sergey-tihon commented Oct 23, 2017

sergey-tihon commented Oct 24, 2017

dsyme commented Oct 26, 2017

dsyme commented Oct 26, 2017

dsyme commented Oct 26, 2017

sergey-tihon commented Oct 26, 2017

dsyme commented Oct 26, 2017

dsyme commented Oct 31, 2017

baronfel commented Nov 1, 2017

dsyme commented Nov 1, 2017

baronfel commented Nov 3, 2017 • edited Loading

dsyme commented Nov 3, 2017

sergey-tihon commented Nov 4, 2017

sergey-tihon commented Nov 17, 2017

baronfel commented Oct 12, 2017 •

edited

Loading

sergey-tihon commented Oct 12, 2017 •

edited

Loading

sergey-tihon commented Oct 13, 2017 •

edited

Loading

sergey-tihon commented Oct 18, 2017 •

edited

Loading

sergey-tihon commented Oct 19, 2017 •

edited

Loading

dsyme commented Oct 20, 2017 •

edited

Loading

sergey-tihon commented Oct 20, 2017 •

edited

Loading

sergey-tihon commented Oct 21, 2017 •

edited

Loading

sergey-tihon commented Oct 21, 2017 •

edited

Loading

baronfel commented Nov 3, 2017 •

edited

Loading