Skip to content
This repository has been archived by the owner on Jan 3, 2019. It is now read-only.

Type providers not compiling on MonoDevelop #67

Closed
7sharp9 opened this issue Dec 8, 2012 · 7 comments
Closed

Type providers not compiling on MonoDevelop #67

7sharp9 opened this issue Dec 8, 2012 · 7 comments

Comments

@7sharp9
Copy link
Member

7sharp9 commented Dec 8, 2012

Type providers appear to work initially but on compilation non defined member errors are shown.

This effects MonoDevelop 3.05 stable and 3.06 beta. This is with the 3.2.10 binding from the gallery.

Screen Shot 2012-12-08 at 10.46.19.png

Could this be related to compilation order as intellisense works ok. Its as if the compilation phase is not getting the generated output from the type provider.

Its possible that this may be a fault in the fsharpx type providers as the Regex, Maths, and freebase providers seem to compile ok. This could simply be a cross platform issue for fsharpx. If so I can move this issue over there...

@knocte
Copy link
Contributor

knocte commented Dec 8, 2012

Look carefully in the references list: it's not finding FSharp.Core, which may be related to the issue.

@7sharp9
Copy link
Member Author

7sharp9 commented Dec 8, 2012

Dont worry about that, its always shown like that due to an issue with the pkgconfig, thats issue #30

@7sharp9
Copy link
Member Author

7sharp9 commented Dec 8, 2012

To be honest I dont think this is an issue with the binding anymore, Ill leave it here until I get to the bottom of the issue though...

@ghost
Copy link

ghost commented Dec 9, 2012

A while back someone helped us make a couple of type providers "cross platform" on Mono/MonoDevelop.

Here are the notes:

First, a type provider on Mono can expose some small differences in Mono and .NET, especially in the System.Type implementation. The ProvidedTypes API can normally be adjusted to account for these.

To help isolate the problem, try the following:

  • Start with a simple file that uses the type provider and compile it using "fsc.exe" on Windows. This should succeed.
  • Now compile the file on windows using the open source "fsc.exe" (this will run using .NET). This should succeed (if not, there is a bug in the open source compiler)
  • Now compile the file on windows using the open source "mono fsc.exe" (this will run using Mono). . If this fails, then there are differences in Mono v. .NET exposed by the type provider. The type provider can probably be adjusted.
  • If that succeeded, then try the same command-line compilation on, say, OSX. If this fails then the type provider may not be cross-platform, e.g. may rely on Windows-only functionality. Diagnostics from the type provider may need improving.
  • If that succeeded, then check if the type provider works from MonoDevelop. If not then the problem is with the MonoDevelop binding (but that is very unlikely because it doesn't know anything specific about type providers)

In any case, switching to command-line compilations will help localize the problem.

@7sharp9
Copy link
Member Author

7sharp9 commented Dec 9, 2012

Thanks @dsyme

One of the main problems is debugging the issues. I found the main issue was the errors reported didn't reflect the problem. It looked like the problem was with with the compiler not being passed the types, but the real issue was with path differences between osx and windows. Whats Ill do is transfer this issue to the fsharpx repo.

One thing I have noticed is that intellisense seems to be extremely limited around the nested functions in the type providers, Ill see if I can localise this too and raise an issue in the binding.

@7sharp9
Copy link
Member Author

7sharp9 commented Jun 26, 2013

@dsyme Maybe we should extend the advice above and include it in the new documentation we are planning (we being fsharp.org)

@ghost
Copy link

ghost commented Jun 26, 2013

Good point. I've copied them into some working notes for a x-plat development guide and will send you a copy of the collected notes I have.

Therzok pushed a commit to Therzok/fsharpbinding that referenced this issue Oct 16, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants