thrown: "Exceeded timeout of 120000 ms for a hook.

Description
When running the tests locally on my machine, the test work as expected. However on CircleCI I receive the described errors.
It seems like the app is being installed and uninstalled in a loop, very strange.

[x] I have tested this issue on the latest Detox release and it still reproduces

Reproduction
I'm not 100% sure how to reproduce this since this is only happening on CircleCI and Travis too.
I've tried to set the environment running on CircleCI to be as identical to my machine as possible. Both have the same Node, Xcode and Homebrew versions. The only difference is I'm running on M1 12.1 and CircleCI uses macOS 11.6.2
Expected behavior
The tests should initiate and run on both environments.
Environment

Detox: ^19.4.5
React Native: 0.67.2
Node: 14.19
Device: iPhone 12
Xcode: 12.5.1
iOS: Probably 12
macOS: 11.6.2
Test-runner (select one): jest-circus

Logs
If you are experiencing a timeout in your test

[x] I have followed the instructions under Identifying which synchronization mechanism causes us to wait too much, I have read synchronization debug documentation and am providing the relevant synchronization debug output below:

If you are seeing a Detox build problem (e.g. during npm install, not detox build)

[ ] I am providing the npm install log below:

Npm logs

 (paste logs here)

Device and verbose Detox logs

[ ] I have run my tests using the --loglevel trace argument and am providing the verbose log below:

Detox logs

GitHub doesn't allow me to upload such a large file (maximum body exceeded, 65536 chars). Full logs can be found here: https://drive.google.com/file/d/1ZSdd-nIGv1dWgua2lsu4tqhLcZvfNos6/view?usp=sharing

Device logs

I'm not sure how to get these from CircleCI. Can someone help me with that?

I am currently experiencing the same issue in Detox: ^19.4.5

I am currently experiencing the same issue in Detox: ^19.4.5

Your tests seems to hang trying to run this command:
14:36:54.747 detox[12679] DEBUG: [EXEC_CMD, #56] applesimutils --byId 1B18C8F5-57C4-47EE-B349-EA33FEFA9FDD --bundle is.timatorg.debug --restartSB --setPermissions calendar=YES,notifications=YES,location=inuse,camera=YES,photos=YES

Is it possible that AppleSimUtils isn't properly installed on the agent you get on circle CI? Note: it does not come preinstalled on their agents -- you have to set it up yourself by adding it to the beginning on the buildscript.

It looks like I'm already installing AppleSimUtils. Here is my CircleCI config:
version: 2.1

orbs:
  node<EMAIL_ADDRESS>
jobs:
  build:
    macos:
      xcode: '13.2.1'

    working_directory: ~/repo

    steps:
      - checkout

      - node/install:
          node-version: '14.19'
          install-yarn: true

      - run: brew update
      - run: brew reinstall cocoapods
      - run: brew tap wix/brew
      - run: brew install applesimutils
      - run: sudo gem install cocoapods
      - run: gem install CFPropertyList

      # Set up environment
      - run: npm install -g react-native-cli
      - run: npm install -g detox-cli

      # # run unit tests
      # - run: yarn install
      # - run: yarn test

      # Install dependencies
      - run: cd ~/repo
      - run: echo $NOONA_MOBILE_ENV > .env
      - run: yarn
      - run: cd ios && pod install && cd ..

      # run E2E tests
      - run: RN_SRC_EXT=e2e.ts detox build --configuration ios.sim.debug
      - run: RN_SRC_EXT=e2e.ts detox test --configuration ios.sim.debug --cleanup  --loglevel trace

workflows:
  deploy-dev:
    jobs:
      - build:
          context:
            - noona-dev
          filters:
            branches:
              only:
                - dev
                - detox2

I SSH'ed into the pipeline machine and ran:
applesimutils --byId 7B63FC91-8483-4E8E-A755-A8060449EC8D --bundle is.timatorg.debug --restartSB --setPermissions calendar=YES,notifications=YES,location=inuse,camera=YES,photos=YES
Got error:
An error was encountered processing the command (domain=NSPOSIXErrorDomain, code=2):
The operation couldn’t be completed. No such file or directory
No such file or directory

I got the ID from the output Detox printed:
"dataPath" : "\/Users\/distiller\/Library\/Developer\/CoreSimulator\/Devices\/7B63FC91-8483-4E8E-A755-A8060449EC8D\/data",
"dataPathSize" : 13312000,
"logPath" : "\/Users\/distiller\/Library\/Logs\/CoreSimulator\/7B63FC91-8483-4E8E-A755-A8060449EC8D",
"udid" : "7B63FC91-8483-4E8E-A755-A8060449EC8D",
"isAvailable" : true,
"deviceType" : {
  "minRuntimeVersion" : 917760,
  "bundlePath" : "\/Applications\/Xcode-13.2.1.app\/Contents\/Developer\/Platforms\/iPhoneOS.platform\/Library\/Developer\/CoreSimulator\/Profiles\/DeviceTypes\/iPhone 12.simdevicetype",
  "maxRuntimeVersion" :<PHONE_NUMBER>,
  "name" : "iPhone 12",
  "identifier" : "com.apple.CoreSimulator.SimDeviceType.iPhone-12",
  "productFamily" : "iPhone"
},
"deviceTypeIdentifier" : "com.apple.CoreSimulator.SimDeviceType.iPhone-12",
"state" : "Shutdown",
"name" : "iPhone 12-Detox"

I think the ID is correct (or the error would have been different). Is it possible that your applesimutils in not in your path? Could you try to run applesimutils -v and paste the result here?
@asafkorem anything else you can advise?

Thanks for the quick responses, really appreciate it.
Here's the output from the build machine:
static:repo distiller$ applesimutils -v
applesimutils -v
applesimutils version 0.9.5

Hi @gunnartorfis!

I SSH'ed into the pipeline machine and ran: ...

This error makes sense in case you are running this command without the app being installed.

Oh, of course. It was a bit hectic interacting with the build machine so I wasn't able to play around with it too much.
This is probably not something related to my OP then.

@gunnartorfis can you please execute:
cat ~/Library/Detox/device.registry.state.loc

in your machine?

@gunnartorfis can you please execute: cat ~/Library/Detox/device.registry.state.loc in your CI agent?
(and paste the output here)

static:repo distiller$ cat ~/Library/Detox/device.registry.state.lock
[{"id":"A8176C67-F1D0-4517-A6B5-A3495829BB1D"},{"id":"1B1C0426-C8CF-404A-B7B9-3619666F5900"},{"id":"6BB8402D-1A75-4E11-AD26-1ED496506DA0"},{"id":"6C49C4D3-AB91-4124-B147-1085ECCBFB28"}]
I had to run the build again to SSH into it, leaving me with different IDs than in the OP I assume.

It's still behaving a bit weird, like it's constantly restarting the simulator or something, eventually reaching an error thrown: "Exceeded timeout of 120000 ms for a hook.     Use jest.setTimeout(newTimeout) to increase the timeout value, if this is a long-running test.".
It also might be worth mentioning that when running the tests locally, Detox spins up a new simulator. For example, if I declare "iPhone 12" in my `.detoxrc.json', that one will fire up but tests will run on "iPhone 12-Detox". Not sure if that's normal but wanted to mention that.
Here's a link to the output logs: https://drive.google.com/file/d/1Fcfyy_wGZfsrAF5vHBCqRFOOhQSwec7s/view?usp=sharing
Here's my Detox config.json:
{
    "maxWorkers": 1,
    "testEnvironment": "./environment",
    "testRunner": "jest-circus/runner",
    "testTimeout": 120000,
    "testRegex": "\\.e2e\\.js$",
    "reporters": [
        "detox/runners/jest/streamlineReporter"
    ],
    "verbose": true,
    "setupFilesAfterEnv": [
        "<rootDir>/init.js"
    ]
}

environment.js:
const {
  DetoxCircusEnvironment,
  SpecReporter,
  WorkerAssignReporter,
} = require('detox/runners/jest-circus');

class CustomDetoxEnvironment extends DetoxCircusEnvironment {
  constructor(config, context) {
    super(config, context);

    // Can be safely removed, if you are content with the default value (=300000ms)
    this.initTimeout = 300000;

    // This takes care of generating status logs on a per-spec basis. By default, Jest only reports at file-level.
    // This is strictly optional.
    this.registerListeners({
      SpecReporter,
      WorkerAssignReporter,
    });
  }
}

module.exports = CustomDetoxEnvironment;

init.js:
const detox = require('detox');
const config = './config.json';

beforeAll(async () => {
  await detox.init(config);
  await device.launchApp();
});

afterAll(async () => {
  await detox.cleanup();
});

.detoxrc.json
{
  "testRunner": "jest",
  "runnerConfig": "e2e/config.json",
  "skipLegacyWorkersInjection": true,
  "apps": {
    "ios.debug": {
      "type": "ios.app",
      "binaryPath": "ios/build/Build/Products/Debug-iphonesimulator/NoonaDEV.app",
      "build": "xcodebuild -workspace ios/timatorgmobile.xcworkspace -scheme 'Noona Develop' -sdk iphonesimulator -derivedDataPath ios/build"
    },
    "ios.release": {
      "name": "Noona",
      "type": "ios.app",
      "binaryPath": "ios/build/Build/Products/Release-iphonesimulator/Noona.app",
      "build": "xcodebuild -workspace ios/timatorgmobile.xcworkspace -scheme 'Noona Release' -sdk iphonesimulator -derivedDataPath ios/build"
    },
    "android.DEV": {
      "type": "android.apk",
      "binaryPath": "android/app/build/outputs/apk/debug/app-debug.apk",
      "build": "cd android && ./gradlew assembleDebug assembleAndroidTest -DtestBuildType=DEV && cd .."
    },
    "android.release": {
      "type": "android.apk",
      "binaryPath": "android/app/build/outputs/apk/release/app-release.apk",
      "build": "cd android && ./gradlew assembleRelease assembleAndroidTest -DtestBuildType=release && cd .."
    }
  },
  "devices": {
    "simulator": {
      "type": "ios.simulator",
      "device": {
        "type": "iPhone 12"
      }
    },
    "emulator": {
      "type": "android.emulator",
      "device": {
        "avdName": "Pixel_3a_API_30_x86"
      }
    }
  },
  "configurations": {
    "ios.sim.debug": {
      "device": "simulator",
      "app": "ios.debug"
    },
    "ios.sim.release": {
      "device": "simulator",
      "app": "ios.release"
    },
    "android.emu.DEV": {
      "device": "emulator",
      "app": "android.DEV"
    },
    "android.emu.release": {
      "device": "emulator",
      "app": "android.release"
    }
  }
}

@gunnartorfis I'm not sure why your init.js is required. Detox init and cleanup is done automatically in a jest-circus environment, such as yourself. That alone might be a source of some of the issues 🤔

any solution?


Spm

Support Swift Package Manager
Add support to SPM
Changed

Add Package.swift
Project folders organization for compatibility to structure Swift Package Manager
Samples Apps grouped folders
Add Demo for SPM
Fix Headers Objc
Fix Build.sh

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Bruno Fernandes seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Reference issue #91

+1 ! Awesome work!

@reidmain Any chance we can have a review in this PR, please? Thanks

Hey @bfernandesbfs, thank you for the contribution!
Unfortunately, this change is just way too large to take in its current form. It is unreviewable, at over 600 files changed.
Secondly, we want to make sure that changes like these are made after a discussion about the pros and cons of the approach, which didn't happen. You can imagine that as a project maintainer, to get a huge PR without an understanding of why it might be worth merging, can be a big investment of time to review. For example, I don't know which changes in this PR are 100% necessary and which are 'nice to have'.
So my suggestion is, let's come up with a plan of how we can make these PRs reviewable. We can split the changes into one commit per PR. Changes should be backwards compatible, i.e., none of them should break the master branch which we are working on adding spm support.

thank you for feedback
I closed this PR and going reopen without folder change for better code review


[generator/linting] Generated app should not have any linting issue

When generating an application with the generator, the initial code contains one Eslint error:
/home/USER/dev/tests/lint-issue/src/lint-issue.js
  4:8  error  Expected 'this' to be used by class method 'render'  class-methods-use-this

I generated the project with the following options:
✔ What would you like to do today? › Scaffold a new project
✔ What would you like to scaffold? › Application
✔ What would you like to add? › Linting, Testing, Building
✔ What would you like to use for Building? › Rollup (recommended)
✔ Would you like to scaffold examples files for? › Testing, Building
✔ What is the tag name of your application/web component? … lint-issue

I see two ways to solve this:

Change the eslint configuration to remove the error.
Move the render function outside.

probably best to just use this inside of the render... as this will be the case for most components?


Unexpected token < in JSON at position 0 npm ERR!

I am trying to install babel core and this is my debug log.
Rambabus-Mac-mini:beoStore 2 NCPLInc$ npm install --save-dev babel-core
npm ERR! registry error parsing json
npm ERR! registry error parsing json
npm ERR! registry error parsing json
npm ERR! Darwin 15.6.0
npm ERR! argv "/Users/NCPLInc/.nvm/versions/node/v6.3.1/bin/node" "/Users/NCPLInc/.nvm/versions/node/v6.3.1/bin/npm" "install" "--save-dev" "babel-core"
npm ERR! node v6.3.1
npm ERR! npm  v3.10.3
npm ERR! Unexpected token < in JSON at position 0
npm ERR!
npm ERR!
npm ERR!
npm ERR! ERROR: The requested URL could not be retrieved
npm ERR!
npm ERR!
npm ERR!
npm ERR!
npm ERR!
npm ERR!
npm ERR!    ERROR
npm ERR! The requested URL could not be retrieved
npm ERR!
npm ERR!
npm ERR!
npm ERR!
npm ERR! The following error was encountered while trying to retrieve the URL: http://ec2-46-137-149-160.eu-west-1.compute.amazonaws.com/babel-core
npm ERR!
npm ERR!
npm ERR! Connection to <IP_ADDRESS> failed.
npm ERR!
npm ERR!
npm ERR! The system returned: (110) Connection timed out
npm ERR!
npm ERR! The remote host or network may be down. Please try the request again.
npm ERR!
npm ERR!
npm ERR!
npm ERR!
npm ERR!
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR!     https://github.com/npm/npm/issues
npm ERR! Please include the following file with any support request:
npm ERR!     /Users/NCPLInc/Downloads/beoStore 2/npm-debug.log

This looks like an issue caused by configuring your npm client to use a registry that doesn't exist.
Nothing to do with this module, if you need more assistance you'll have to look into npm's support channels


Change Tinkerbell default nodeStartupTimeout to 20m

Closes https://github.com/aws/eks-anywhere/issues/5755
Bare metal startup times can be impacted by various factors. 10m has proven too short in some common contexts so this PR increases the nodeStartupTimeout for Tinkerbell clusters to 20m.

/retest

/approve
/lgtm

/test eks-anywhere-presubmit

/retest-required


Add functional raw device events test

Hello @mmkayPL! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file tests/functional/trace_io_events.py:

Line 24:21: E131 continuation line unaligned for hanging indent
Line 34:80: E501 line too long (89 > 79 characters)
Line 35:80: E501 line too long (95 > 79 characters)
Line 50:80: E501 line too long (86 > 79 characters)
Line 51:80: E501 line too long (82 > 79 characters)
Line 61:80: E501 line too long (85 > 79 characters)
Line 62:80: E501 line too long (81 > 79 characters)
Line 70:80: E501 line too long (88 > 79 characters)
Line 71:80: E501 line too long (84 > 79 characters)

retest this please

add to whitelist


update Princeton catalog to sync collection names with traject

@aaron-collier I don't understand the error message here. It looks like the name change broke one of the tests? Can you confirm if this needs any additional changes?

I rebased this on mail so I could run the tests. I adjusted the test to reflect the new data-path for princeton that is being changed in this PR.


Sync changes from Kyma NATS chart to nats-manager NATS chart.

Description
Make sure that possible new changes on the Kyma side are synced to nats-manager.
When we enable a module using kyma alpha enable module nats -c fast -n kyma-system, the lifecycle manager by default creates a NAT CR in the cluster. The default CR is configured here.
Note
Small upgrade hickups like helm chart issues should be fixed within this ticket. Big changes should be a follow up ticket.
Tasks:

[ ] Synchronise changes from Kyma NATS chart to nats-manager NATS chart.
[ ] Bump all the NATS images tag to same as in kyma NATS chart:

[ ] Config Reloader
[ ] Metrics Exporter
[ ] NATS Server

[ ]  Make sure that the default CR is correct for upgrade from kyma to nats-manager.
[ ] Test the upgrade from kyma to nats-manager on a working Kyma cluster by following the steps from: link.

[ ] Fast-integration test
[ ] Stream and consumers are not recreated by the upgrade
[ ] Check that the pvcs are not recreated by the upgrade

Here is a PR https://github.com/kyma-project/nats-manager/pull/127


Create Test.md

added a short description of application in the readme file.

Only a documentation change


DOC: Update 'Go Reference' badge in README.md to v2 documentation

This PR points the 'Go reference' badge in the README to the v2 documentation on pkg.go.dev.
Description

[ ] Bug fix
[ ] Feature addition
[ ] Code refactoring
[x] Documentation update
[ ] Other (please explain):

How Has This Been Tested?

[ ] Unit tests
[ ] Integration tests
[x] Manual testing

Checklist

[x] My code follows the style guidelines of this project.
[x] I have performed a self-review of my code.
[x] I have made corresponding changes to the documentation.
[ ] I have added tests that ensure my fix is effective or that my feature works.
[ ] New and existing unit tests pass locally with my changes.
[ ] Any dependent changes have been merged and published in downstream modules.

Welcome to Codecov :tada:
Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.
:information_source: You can also turn on project coverage checks and project coverage reporting on Pull Request comment
Thanks for integrating Codecov - We've got you covered :open_umbrella:


Use tree walking and polling for Github buttons

This pull request is to address the following issues:
#15
#14
What does this change do?

Uses tree walking to find text-area's

First we find all the buttons we want to create 'Prettier' buttons next to and create them. Once we have done that we then do a tree walk from that button upwards until we find the first text area.

Added buttons to Issues

I've tested this in most cases I think of with no issues found.

New PR's
New Issues
Issue comments
PR comments (as well as comments on diffs)

The only thing that might want tweaking is the Polling timer I've setup, I've set it to a second as realistically the check that I'm doing to see if the path name has changed is extremely light-weight but we could change it to something like five seconds if you don't mind the buttons appearing slightly later.

The code looks good and it seems to work pretty well.
I'm not sure we need the timeout though, could we wait for some DOM event like load or DOMContentLoaded instead? It should be more reliable when the page takes a longer time than expected to load.

Thanks for doing this! I agree with @nickmccurdy. Is there some kind of event we could listen for? Or could we just bind a listener to clicking on any buttons that trigger an editable comment to appear?
I'm not seeing it work for a few cases:
Adding a comment in the PR diff:

Editing an existing comment in the PR conversation view:

Finally, from a UX perspective, I personally don't think we should move any of the existing GitHub buttons around. I know I click Cancel enough that I might accidentally click Prettier without thinking:

Maybe we could use MutationObserver? I think that like as long as we wait until after the first render, we should be able to create an observer on each HTMLElement that the comment renders into?

Yeah they seem like fair observations, I'll see if I can switch over to MutationObserver (I also think the buttons not showing is probably caused by the timeouts)

I've changed over to using mutationObserver which seems to make things more consistent and got rid of the polling behaviour, let me know if you have any other suggestions.
Also the button will always now appear as the furthest left button (so that it does not get confused with the Cancel button or close pull request buttons from a UX point of view as mentioned)

The Prettier button doesn't appear when I'm trying to edit a comment (for example in this PR)

The Prettier button doesn't appear when I'm trying to edit a comment (for example in this PR)
This should be fixed with the latest commit, I have to add additional observers for the comment area's (that have to be setup again on page-change) but this seems to work well and is reasonably fast as the comment subtrees are fairly small.

Apologies for not checking it I forgot to check github comments.

test

Also needed an extra observer to deal with new comments (otherwise the listener won't be there for when they click edit) -> again this is only checking immediate sub-tree so it should be fine.

Functionality-wise, this looks like it's working great for me! It looks like some of the styling could be further refined, but I would advocate for landing this and fixing those cases up afterwards. This is a much better solution than the one I came up with in the initial implementation ❤

Example of some of the styles referenced above:

It looks like sometimes the button gets grouped with the button next to it inside a div because the DOM structure of the buttons can differ depending on the location. Again, would advocate for landing this and refining that further in the future!

Would be great to land this! This is a huge improvement over the current version!

@lipis Any chance we can merge this? I think we can probably do something similar to fix https://github.com/prettier/prettier-chrome-extension/issues/12.
Unrelated, but I'm happy to help maintain this project. This is something I've been wanting to implement anyway and I have some bandwidth to both contribute and help move PRs along :)

Unrelated, but I'm happy to help maintain this project. This is something I've been wanting to implement anyway and I have some bandwidth to both contribute and help move PRs along :)

You are more than welcome! I sent you an invite.. :)

Thanks!


Upgrade to null safety

Creating pull request asked by https://github.com/FooStudio/tinycolor/pull/13#issuecomment-867907762

@lslv1243 please also resolve conflicts.

@calvintam236 resolved conflicts


Increase ccache size and exclude ext/ from coverage reports

increase cache to 5000Mb
Exclude ext/ from coverage reports.

Codecov Report

Merging #8047 into master will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #8047      +/-   ##
==========================================
- Coverage   55.03%   55.03%   -0.01%
==========================================
  Files         481      481
  Lines       53934    53934
  Branches    10474    10474
==========================================
- Hits        29684    29683       -1
  Misses      19981    19981
- Partials     4269     4270       +1

Impacted Files
Coverage Δ

boards/posix/native_posix/timer_model.c
98.21% <0%> (-1.79%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ec7d483...1144808. Read the comment docs.

recheck

recheck


Storing secrets for API authentication

Hi,
In the custom request example you use a variable $token.  I suppose this is a dashboard variable?  If so, how do I store this in a safe way?
custom requests
const resp = fetch(url, {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "PRIVATE-TOKEN": "$token",
  },

@vdwpsmt You can retrieve it from the data source or dashboard variable using the data source.
The most secure way is to use the custom data source in a proxy mode, as we described in blog post https://volkovlabs.io/blog/how-to-connect-the-data-manipulation-plugin-for-grafana-to-api-server-1abe5f60c904/

Using Data Sources for Initial and Update requests introduced in v3.1.0.


Files missing from version control

attempting to clone and build the project results in many errors, most importantly issues with missing files.
Severity	Code	Description	Project	File	Line	Suppression State
UseHexGridUtilities\HexUtilities\Common\BlockedBoardStorage32x32.cs' could not be found.
UseHexGridUtilities\HexUtilities\Common\FlatBoardStorage.cs' could not be found.
UseHexGridUtilities\HexUtilities\IHex.cs' could not be found.
UseHexGridUtilities\HexUtilities\Common\BoardStorage.cs' could not be found.
UseHexGridUtilities\HexUtilities\IHexBoard.cs' could not be found.
UseHexGridUtilities\HexUtilities\IHexgrid.cs' could not be found.
UseHexGridUtilities\HexUtilities\Pathfinding\IDirectedPathCollection.cs' could not be found.
UseHexGridUtilities\HexUtilities\Pathfinding\ILandmark.cs' could not be found.
UseHexGridUtilities\HexUtilities\Pathfinding\INavigableBoard.cs' could not be found.
UseHexGridUtilities\HexUtilities\Pathfinding\IPathfinder.cs' could not be found.
UseHexGridUtilities\HexUtilities\Hexsides.cs' could not be found.
UseHexGridUtilities\HexUtilities\Common\EnumHelper.cs' could not be found.
UseHexGridUtilities\HexUtilities\Common\IBoardStorage.cs' could not be found.
UseHexGridUtilities\HexUtilities\FieldOfView\IFieldOfView.cs' could not be found.
UseHexGridUtilities\HexgridPanel\BufferedHexgridScrollable.cs' could not be found.
UseHexGridUtilities\HexgridPanel\BufferedHexgridScrollable.Designer.cs' could not be found.
UseHexGridUtilities\HexgridPanel\bin\Debug\HexgridPanel.dll' could not be found
UseHexGridUtilities\HexUtilities\bin\Debug\PGNapoleonics.HexUtilities.dll' could not be found
UseHexGridUtilities\HexUtilities\bin\Debug\PGNapoleonics.HexUtilities.dll' could not be found
UseHexGridUtilities\HexGridExampleCommon\bin\Debug\HexgridExampleCommon.dll' could not be found
UseHexGridUtilities\HexgridPanel\bin\Debug\HexgridPanel.dll' could not be found
UseHexGridUtilities\HexUtilities\bin\Debug\PGNapoleonics.HexUtilities.dll' could not be found
These files don't seem to exist in the repo structure

These files aren't missing from version control, they have just been moved and the solution file isn't up-to-date.

My apologies for the very long delay getting to this. The branch master is no repaired, and I am working on restoring the documentation through Doxygen.


Connect* needs stories

Feature: What is your use case for such a feature?
using connect as a feature isn’t very easy, because the only example is a connectSearchBox.
Feature: What is your proposed API entry? The new option to add? What is the behavior?
adding stories or other examples about each of the connectors would be very useful in understanding how they work, and how you “should” use them.
What project are you opening an issue for?

react-instantsearch

React InstantSearch has been moved here: https://github.com/algolia/react-instantsearch
This issue has either been rewritten or placed inside our backlog.


Compact Thredded initializer and some additional ground work surrounding user avatars

Move avatar URL logic the User and Pic model so we can use it directly in the Thredded configuration.

Adds URL methods and predicate methods to test for existence to User and Pic.
Adds a way to serve mocked uploaded files during request specs.
Adds view helpers to generate a user avatar URL (will be used in upcoming PR).
Adds ImageVariant to slowly move to a single truth for all image variant information (will be used more in upcoming PR).
Compact Thredded initializer so it's a little more readable.

I tested this branch locally. It's probably a good idea to check the pics table in production to see if all of them have an image/* content-type before merging this change.


Unable to load plugins (1392545)

When trying to load any plugin Bluesky is unable always returning a message e.g. BlueSky plugin system failed to load DATAFEED : No module named 'plugins\\adsbfeed'. Currently running Python 3.6

Found what was causing the error for me. In the most recent push the importlib lib class doesn't work as before meaning that the modules cannot be found in the plugin folder.
Reverting back to the previous code has resolved the issue for me (using imp)

Hi @Ellislee1!
Thanks for mentioning this, again it shows that cross-platform compatibility is always difficult :) The bug should be fixed in 786738d.


Certificate renewal fails during DNS challenge with Route53

Describe the bug:
In a kubernetes cluster on AWS we're using cert-manager with Route53 and Let's Encrypt. While obtaining a new certificate always seems to work flawlessly, we had an issue with the renewal.
Expected behaviour:
If the certificate can be issued then renewal should also work.
Detailed description:
The key error message from the cert-manager log seems to be (hostnames edited):
RRSet with DNS name xxxxxxxxxxxxxxxx-xxxxxxxxxx.us-east-2.elb.amazonaws.com. is not permitted in zone my.public.zone.

I've tried to find a similarly formatted message here but none were exactly the same. It's not clear to me what the root cause is, but in my mind it could be one of the following:

cert-manager has enough IAM permissions for the creation phase but not for the renewal phase
during renewal a bug causes cert-manager to send an invalid request to Route53

The issuer CR is as follows:
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: public-issuer
spec:
  acme:
    email: XXXXXXXXXX
    preferredChain: ""
    privateKeySecretRef:
      name: letsencrypt-account-key
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
    - dns01:
        cnameStrategy: Follow
        route53:
          accessKeyID: XXXXXXXXXXXXXXXXXX
          hostedZoneID: XXXXXXXXXXXXXXXXXX
          region: us-east-2
          secretAccessKeySecretRef:
            key: AWS_SECRET_ACCESS_KEY
            name: aws-pca-access-key
      selector:
        dnsZones:
        - my.public.zone

The IAM policy document, created with terraform is:
data "aws_iam_policy_document" "dns_challenge" {
  statement {
    effect = "Allow"

    resources = [
      "arn:aws:route53:::change/*"
    ]

    actions = [
      "route53:GetChange"
    ]
  }
  statement {
    effect = "Allow"

    resources = [
      "arn:aws:route53:::hostedzone/*"
    ]

    actions = [
      "route53:ChangeResourceRecordSets",
      "route53:ListResourceRecordSets"
    ]
  }
  statement {
    effect = "Allow"

    resources = [
      "*"
    ]

    actions = [
      "route53:ListHostedZonesByName"
    ]
  }
}

Here's the output of kubectl describe certificate:
$ oc describe certificate my.public.zone
Name:         my.public.zone
Namespace:    openshift-ingress
Spec:
  Common Name:  *.apps.my.public.zone
  Dns Names:
    *.apps.my.public.zone
  Duration:  2160h0m0s
  Issuer Ref:
    Group:  cert-manager.io
    Kind:   ClusterIssuer
    Name:   public-issuer
  Private Key:
    Algorithm:   RSA
    Encoding:    PKCS1
    Size:        2048
  Renew Before:  360h0m0s
  Secret Name:   my.public.zone-tls
  Subject:
    Organizations:
      IBM
  Usages:
    server auth
    client auth
Status:
  Conditions:
    Last Transition Time:        2022-10-12T21:51:56Z
    Message:                     Certificate is up to date and has not expired
    Observed Generation:         1
    Reason:                      Ready
    Status:                      True
    Type:                        Ready
    Last Transition Time:        2022-12-26T20:51:54Z
    Message:                     Renewing certificate as renewal was scheduled at 2022-12-26 20:51:54 +0000 UTC
    Observed Generation:         1
    Reason:                      Renewing
    Status:                      True
    Type:                        Issuing
  Next Private Key Secret Name:  my.public.zone-rl9l6
  Not After:                     2023-01-10T20:51:54Z
  Not Before:                    2022-10-12T20:51:55Z
  Renewal Time:                  2022-12-26T20:51:54Z
  Revision:                      1
Events:                          <none>

And finally here's the relevant log section :
I1226 20:51:54.000636       1 conditions.go:201] Setting lastTransitionTime for Certificate "my.public.zone" condition "Issuing" to 2022-12-26 20:51:54.000632427 +0000 UTC m=+6557108.873962103
I1226 20:51:54.118306       1 controller.go:161] cert-manager/certificates-key-manager "msg"="re-queuing item due to optimistic locking on resource" "key"="openshift-ingress/my.public.zone" "error"="Operation cannot be fulfilled on certificates.cert-manager.io \"my.public.zone\": the object has been modified; please apply your changes to the latest version and try again"
I1226 20:51:54.126034       1 conditions.go:261] Setting lastTransitionTime for CertificateRequest "my.public.zone-ftf8d" condition "Approved" to 2022-12-26 20:51:54.126029011 +0000 UTC m=+6557108.999358690
I1226 20:51:54.160129       1 conditions.go:261] Setting lastTransitionTime for CertificateRequest "my.public.zone-ftf8d" condition "Ready" to 2022-12-26 20:51:54.160120854 +0000 UTC m=+6557109.033450524
I1226 20:51:54.177214       1 conditions.go:261] Setting lastTransitionTime for CertificateRequest "my.public.zone-ftf8d" condition "Ready" to 2022-12-26 20:51:54.177207129 +0000 UTC m=+6557109.050536800
I1226 20:51:54.187238       1 controller.go:161] cert-manager/certificaterequests-issuer-acme "msg"="re-queuing item due to optimistic locking on resource" "key"="openshift-ingress/my.public.zone-ftf8d" "error"="Operation cannot be fulfilled on certificaterequests.cert-manager.io \"my.public.zone-ftf8d\": the object has been modified; please apply your changes to the latest version and try again"
E1226 20:51:54.831186       1 controller.go:210] cert-manager/challenges/scheduler "msg"="error scheduling challenge for processing" "error"="Operation cannot be fulfilled on challenges.acme.cert-manager.io \"my.public.zone-ftf8d-1306855964-4198664360\": the object has been modified; please apply your changes to the latest version and try again" "resource_kind"="Challenge" "resource_name"="my.public.zone-ftf8d-1306855964-4198664360" "resource_namespace"="openshift-ingress" "resource_version"="v1"
E1226 20:51:56.290126       1 controller.go:166] cert-manager/challenges "msg"="re-queuing item due to error processing" "error"="failed to change Route 53 record set: InvalidChangeBatch: [RRSet with DNS name xxxxxxxxxxxxxxxx-xxxxxxxxxx.us-east-2.elb.amazonaws.com. is not permitted in zone my.public.zone.]" "key"="openshift-ingress/my.public.zone-ftf8d-1306855964-4198664360"

Any ideas or pointers are much appreciated.
/kind bug

I have some new data points. At first I thought it was the renewal that failed, but when I tried to delete only the Certificate resource and create it again, it the creation failed in exactly the same way.
After our terraform creates the Certificate resource it proceeds to create a CNAME wildcard record pointing *.apps.my.public.zone to xxxxxxxxxxxxxxxx-xxxxxxxxxx.us-east-2.elb.amazonaws.com . If I delete that record prior to re-creating the Certificate, the creation process works. Perhaps there is some kind of conflict between the wildcard entry and the challenge _acme-challenge.apps.my.public.zone.

I have the exact same issue and similar setup, DNS01 challenge for use of wildcard certificate.  If I have an DNS entry in Route53 hosted zone the challenge never is successful and I get the same error Warning  PresentError  20m (x974 over 20d)  cert-manager-challenges  Error presenting challenge: failed to change Route 53 record set: InvalidChangeBatch: [RRSet with DNS name my-lb.us-east-1.elb.amazonaws.com. is not permitted in zone mydomain.com .]

This is still an issue

/reopen


Fix Nim 2.0.0 compile error caused by _ variables

Hello, Thank you so much for maintaining tool :) I created a fix PR for the issue below.

Fix #105

In Nim 2.0.0 released on August 1st, it seems that _ can no longer be used as a variable due to the following changes.

https://github.com/nim-lang/Nim/pull/21584
https://github.com/nim-lang/Nim/issues/20687
https://github.com/nim-lang/Nim/issues/21435

Currently, only the macOS code had _ usage, so I replaced it with x.
For this pull request, I have confirmed following:

Successful compilation with Nim 2.0.0 and 1.6.14
README some sample code works

I would appreciate it if you could review.
Regards,

Thanks this is great! Got to get 2.0 ready!

Thank you so much for quick review :)


How to enable type providers with new-style .NET SDK project files (and in some cases .NET Core programming too)

This issue documents how to enable the use of type providers when using a .NET SDK 2.0 "new style" project file.
This also allows the use of  cross-targeting type providers as part of  .NET Core 2.0 app programming or .NET Standard 2.0 library programming. At the time of writing, the only widely used cross-targeting type provider is the popular FSharp.Data library.
If you don't follow one of the workarounds below you may get a silent failure from the F# compiler when executing dotnet build or "StackOverflowException", if your project references a type provider.
This technique has been tested with .NET SDK 2.0 preview 2 and Visual Studio 2017 preview 3 (though should also work with Mono 5.0 and/or earlier installs of the .NET SDK)
Examples where the problem occurs
Example 1 (building a .NET 4.6.1 application that uses FSharp.Data)
dotnet new console -o -lang F# --target-framework-override net461 app3
cd app3
dotnet add package FSharp.Data
dotnet restore
dotnet build

Example 2 (building a .NET Core 2.0 application that uses FSharp.Data)
dotnet new console -o -lang F# app4
cd app4
dotnet add package FSharp.Data
dotnet restore
dotnet build

Expected behaviour is compilation success, or at least nice error point to workaround. Actual behavior is a silent compilation failure, and dotnet build /v:d shows l Process is terminating due to StackOverflowException.    Done executing task "Fsc" -- FAILED.
What you need to do
Explanation:
As explained in this issue, type providers are not yet supported when the F# compiler runs using .NET Core. By default, the .NET SDK tooling runs the F# compiler using .NET Core.
The workaround is to have the .NET SDK tooling use an F# Compiler running on the .NET Framework or Mono, regardless of which version of .NET you're targeting. By doing this, the type provider is hosted and executed using the .NET Framework. This technique applies even if you are doing .NET Core programming (for cross-targeting type providers), or building a .NET Standard 2.0 library.  The F# Compiler cross-generates code for the correct target regardless of how it executes.
Although this workaround may seem "wrong" if targeting .NET Core, it has advantages:

the use of .NET Framework/Mono is only at compile-time
the technique stress-tests the cross-targeting capabilities of the type provider
the technique unblocks TP authors to test and adjust TPs to be cross-targeting

In the future, the plan of record is to allow .NET Standard 2.0 type providers to be used when the F# compiler is running on .NET Core.  This is an interim workaround for those who wish to unblock the testing and use of type providers for .NET SDK project files and .NET Core/.NET Standard 2.0 programming.
Steps:

Install an F# Compiler that runs on .NET Framework or Mono, see Linux,  Windows,  OSX.  It is likely you already have one installed.

Add FscToolPath and ```FscToolExe`` settings to your project file:

     ...
     C:\Program Files (x86)\Microsoft SDKs\F#\4.1\Framework\v4.0
fsc.exe

(On Mono/Linux/OSX you will need a different path e.g. /usr/lib/mono/fsharp/fsc.exe, we will document that properly as a conditional setting soon)
You can then use "dotnet build", "dotnet restore" etc.
Alternative Workaround
On Windows:

Install Visual Studio 2017 Update 3 or later
Use "msbuild.exe" from a Visual Studio 2017 command line prompt to build the project instead of "dotnet build"

On Linux/OSX/Xamarin/Mono:

Install Mono 5.0 or later
Use "msbuild"  to build the project instead of "dotnet build"

Explanation: when you compile your project using msbuild.exe the F# support in the .NET SDK will assume .NET Framework execution is required.

Note that the same error happens when building a .NET Framework 4.61 component, seen by changing to
    <TargetFramework>net461</TargetFramework>

when the warnings above go away but the stack overflow still happens
This blocks people using F# type providers from moving to .NET SDK 2.0 preview 2. We knew that supporting type provides for .NET Core was WIP, but I hadn't realised that those compiling .NET Framework components would hit this limitation.

This is the stack: https://gist.github.com/dsyme/44e7ecd8c6187f7de78abe386c375670
 	System.Private.CoreLib.dll!System.Reflection.Assembly.Load(System.Reflection.AssemblyName assemblyRef, System.IntPtr ptrLoadContextBinder)	Unknown
 	System.Private.CoreLib.dll!System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyName(System.Reflection.AssemblyName assemblyName)	Unknown
 	FSharp.Compiler.Private.dll!Microsoft.FSharp.Core.ReflectionAdapters.CustomAssemblyResolver.Load(System.Reflection.AssemblyName assemblyName)	Unknown
 	System.Private.CoreLib.dll!System.Runtime.Loader.AssemblyLoadContext.ResolveUsingLoad(System.Reflection.AssemblyName assemblyName)	Unknown
 	System.Private.CoreLib.dll!System.Runtime.Loader.AssemblyLoadContext.Resolve(System.IntPtr gchManagedAssemblyLoadContext, System.Reflection.AssemblyName assemblyName)	Unknown
 	[Native to Managed Transition]
 	[Managed to Native Transition]
 	System.Private.CoreLib.dll!System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(System.Reflection.AssemblyName assemblyRef, System.Security.Policy.Evidence assemblySecurity, System.Reflection.RuntimeAssembly reqAssembly, ref System.Threading.StackCrawlMark stackMark, System.IntPtr pPrivHostBinder, bool throwOnFileNotFound, bool forIntrospection, System.IntPtr ptrLoadContextBinder)	Unknown
 	System.Private.CoreLib.dll!System.Reflection.Assembly.Load(System.Reflection.AssemblyName assemblyRef, System.IntPtr ptrLoadContextBinder)	Unknown
 	System.Private.CoreLib.dll!System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyName(System.Reflection.AssemblyName assemblyName)	Unknown
 	FSharp.Compiler.Private.dll!Microsoft.FSharp.Core.ReflectionAdapters.CustomAssemblyResolver.Load(System.Reflection.AssemblyName assemblyName)	Unknown
 	System.Private.CoreLib.dll!System.Runtime.Loader.AssemblyLoadContext.ResolveUsingLoad(System.Reflection.AssemblyName assemblyName)	Unknown
 	System.Private.CoreLib.dll!System.Runtime.Loader.AssemblyLoadContext.Resolve(System.IntPtr gchManagedAssemblyLoadContext, System.Reflection.AssemblyName assemblyName)	Unknown
 	[Native to Managed Transition]
 	[Managed to Native Transition]
 	System.Private.CoreLib.dll!System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(System.Reflection.AssemblyName assemblyRef, System.Security.Policy.Evidence assemblySecurity, System.Reflection.RuntimeAssembly reqAssembly, ref System.Threading.StackCrawlMark stackMark, System.IntPtr pPrivHostBinder, bool throwOnFileNotFound, bool forIntrospection, System.IntPtr ptrLoadContextBinder)	Unknown
 	System.Private.CoreLib.dll!System.Reflection.Assembly.Load(System.Reflection.AssemblyName assemblyRef, System.IntPtr ptrLoadContextBinder)	Unknown
 	System.Private.CoreLib.dll!System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyName(System.Reflection.AssemblyName assemblyName)	Unknown
 	FSharp.Compiler.Private.dll!Microsoft.FSharp.Core.ReflectionAdapters.CustomAssemblyResolver.Load(System.Reflection.AssemblyName assemblyName)	Unknown
 	System.Private.CoreLib.dll!System.Runtime.Loader.AssemblyLoadContext.ResolveUsingLoad(System.Reflection.AssemblyName assemblyName)	Unknown
 	System.Private.CoreLib.dll!System.Runtime.Loader.AssemblyLoadContext.Resolve(System.IntPtr gchManagedAssemblyLoadContext, System.Reflection.AssemblyName assemblyName)	Unknown
 	[Native to Managed Transition]
 	[Managed to Native Transition]

[Native to Managed Transition]
[Managed to Native Transition]
System.Private.CoreLib.dll!System.Reflection.RuntimeAssembly.GetExportedTypes()	Unknown
FSharp.Compiler.Private.dll!Microsoft.FSharp.Compiler.ExtensionTyping.GetTypeProviderImplementationTypes(string runTimeAssemblyFileName, string designTimeAssemblyNameString, Microsoft.FSharp.Compiler.Range.range m)	Unknown
FSharp.Compiler.Private.dll!Microsoft.FSharp.Compiler.ExtensionTyping.GetTypeProvidersOfAssembly@160.GenerateNext(ref System.Collections.Generic.IEnumerable<System.Tuple<Microsoft.FSharp.Core.CompilerServices.ITypeProvider, Microsoft.FSharp.Compiler.AbstractIL.IL.ILScopeRef>> next)	Unknown
FSharp.Core.dll!Microsoft.FSharp.Core.CompilerServices.GeneratedSequenceBase<System.Tuple<Microsoft.FSharp.Core.CompilerServices.ITypeProvider, Microsoft.FSharp.Compiler.AbstractIL.IL.ILScopeRef>>.MoveNextImpl()	Unknown
FSharp.Core.dll!Microsoft.FSharp.Core.CompilerServices.GeneratedSequenceBase<System.__Canon>.System.Collections.IEnumerator.System-Collections-IEnumerator-MoveNext()	Unknown
FSharp.Core.dll!Microsoft.FSharp.Collections.SeqModule.ToList<System.Tuple<Microsoft.FSharp.Core.CompilerServices.ITypeProvider, Microsoft.FSharp.Compiler.AbstractIL.IL.ILScopeRef>>(System.Collections.Generic.IEnumerable<System.Tuple<Microsoft.FSharp.Core.CompilerServices.ITypeProvider, Microsoft.FSharp.Compiler.AbstractIL.IL.ILScopeRef>> source)	Unknown
FSharp.Compiler.Private.dll!Microsoft.FSharp.Compiler.ExtensionTyping.GetTypeProvidersOfAssembly(string runtimeAssemblyFilename, Microsoft.FSharp.Compiler.AbstractIL.IL.ILScopeRef ilScopeRefOfRuntimeAssembly, string designerAssemblyName, Microsoft.FSharp.Compiler.ExtensionTyping.ResolutionEnvironment resolutionEnvironment, bool isInvalidationSupported, bool isInteractive, Microsoft.FSharp.Core.FSharpFunc<string, bool> systemRuntimeContainsType, System.Version systemRuntimeAssemblyVersion, Microsoft.FSharp.Compiler.Range.range m)	Unknown
FSharp.Compiler.Private.dll!Microsoft.FSharp.Compiler.CompileOps.providers@4153.GenerateNext(ref System.Collections.Generic.IEnumerable<Microsoft.FSharp.Collections.FSharpList<Microsoft.FSharp.Compiler.Tainted<Microsoft.FSharp.Core.CompilerServices.ITypeProvider>>> next)	Unknown
FSharp.Core.dll!Microsoft.FSharp.Core.CompilerServices.GeneratedSequenceBase<Microsoft.FSharp.Collections.FSharpList<Microsoft.FSharp.Compiler.Tainted<Microsoft.FSharp.Core.CompilerServices.ITypeProvider>>>.MoveNextImpl()	Unknown
FSharp.Core.dll!Microsoft.FSharp.Core.CompilerServices.GeneratedSequenceBase<System.__Canon>.System.Collections.IEnumerator.System-Collections-IEnumerator-MoveNext()	Unknown
FSharp.Core.dll!Microsoft.FSharp.Collections.SeqModule.ToList<Microsoft.FSharp.Collections.FSharpList<Microsoft.FSharp.Compiler.Tainted<Microsoft.FSharp.Core.CompilerServices.ITypeProvider>>>(System.Collections.Generic.IEnumerable<Microsoft.FSharp.Collections.FSharpList<Microsoft.FSharp.Compiler.Tainted<Microsoft.FSharp.Core.CompilerServices.ITypeProvider>>> source)	Unknown
FSharp.Compiler.Private.dll!Microsoft.FSharp.Compiler.CompileOps.TcImports.ImportTypeProviderExtensions(Microsoft.FSharp.Compiler.AbstractIL.Internal.Library.CompilationThreadToken ctok, Microsoft.FSharp.Compiler.CompileOps.TcConfig tcConfig, string fileNameOfRuntimeAssembly, Microsoft.FSharp.Compiler.AbstractIL.IL.ILScopeRef ilScopeRefOfRuntimeAssembly, Microsoft.FSharp.Collections.FSharpList<Microsoft.FSharp.Compiler.AbstractIL.IL.ILAttribute> runtimeAssemblyAttributes, Microsoft.FSharp.Compiler.Tast.Entity entityToInjectInto, Microsoft.FSharp.Control.FSharpEvent<string> invalidateCcu, Microsoft.FSharp.Compiler.Range.range m)	Unknown
FSharp.Compiler.Private.dll!Microsoft.FSharp.Compiler.CompileOps.ccuRawDataAndInfos@4340-1.Invoke(Microsoft.FSharp.Core.Unit unitVar0)	Unknown
FSharp.Core.dll!Microsoft.FSharp.Primitives.Basics.List.iter<System.Tuple<Microsoft.FSharp.Compiler.TastPickle.PickledDataWithReferences<Microsoft.FSharp.Compiler.Tast.PickledCcuInfo>, Microsoft.FSharp.Compiler.CompileOps.ImportedAssembly, Microsoft.FSharp.Core.FSharpFunc<Microsoft.FSharp.Core.Unit, Microsoft.FSharp.Core.Unit>>>(Microsoft.FSharp.Core.FSharpFunc<System.Tuple<Microsoft.FSharp.Compiler.TastPickle.PickledDataWithReferences<Microsoft.FSharp.Compiler.Tast.PickledCcuInfo>, Microsoft.FSharp.Compiler.CompileOps.ImportedAssembly, Microsoft.FSharp.Core.FSharpFunc<Microsoft.FSharp.Core.Unit, Microsoft.FSharp.Core.Unit>>, Microsoft.FSharp.Core.Unit> f, Microsoft.FSharp.Collections.FSharpList<System.Tuple<Microsoft.FSharp.Compiler.TastPickle.PickledDataWithReferences<Microsoft.FSharp.Compiler.Tast.PickledCcuInfo>, Microsoft.FSharp.Compiler.CompileOps.ImportedAssembly, Microsoft.FSharp.Core.FSharpFunc<Microsoft.FSharp.Core.Unit, Microsoft.FSharp.Core.Unit>>> x)	Unknown
FSharp.Compiler.Private.dll!Microsoft.FSharp.Compiler.CompileOps.PrepareToImportReferencedFSharpAssembly@4354-1.Invoke(Microsoft.FSharp.Core.Unit unitVar0)	Unknown
FSharp.Core.dll!Microsoft.FSharp.Primitives.Basics.List.collectToFreshConsTail<Microsoft.FSharp.Core.FSharpFunc<Microsoft.FSharp.Core.Unit, Microsoft.FSharp.Collections.FSharpList<Microsoft.FSharp.Compiler.CompileOps.AvailableImportedAssembly>>, Microsoft.FSharp.Compiler.CompileOps.AvailableImportedAssembly>(Microsoft.FSharp.Core.FSharpFunc<Microsoft.FSharp.Core.FSharpFunc<Microsoft.FSharp.Core.Unit, Microsoft.FSharp.Collections.FSharpList<Microsoft.FSharp.Compiler.CompileOps.AvailableImportedAssembly>>, Microsoft.FSharp.Collections.FSharpList<Microsoft.FSharp.Compiler.CompileOps.AvailableImportedAssembly>> f, Microsoft.FSharp.Collections.FSharpList<Microsoft.FSharp.Core.FSharpFunc<Microsoft.FSharp.Core.Unit, Microsoft.FSharp.Collections.FSharpList<Microsoft.FSharp.Compiler.CompileOps.AvailableImportedAssembly>>> list, Microsoft.FSharp.Collections.FSharpList<Microsoft.FSharp.Compiler.CompileOps.AvailableImportedAssembly> cons)	Unknown
FSharp.Core.dll!Microsoft.FSharp.Primitives.Basics.List.collect<Microsoft.FSharp.Core.FSharpFunc<Microsoft.FSharp.Core.Unit, Microsoft.FSharp.Collections.FSharpList<Microsoft.FSharp.Compiler.CompileOps.AvailableImportedAssembly>>, Microsoft.FSharp.Compiler.CompileOps.AvailableImportedAssembly>(Microsoft.FSharp.Core.FSharpFunc<Microsoft.FSharp.Core.FSharpFunc<Microsoft.FSharp.Core.Unit, Microsoft.FSharp.Collections.FSharpList<Microsoft.FSharp.Compiler.CompileOps.AvailableImportedAssembly>>, Microsoft.FSharp.Collections.FSharpList<Microsoft.FSharp.Compiler.CompileOps.AvailableImportedAssembly>> f, Microsoft.FSharp.Collections.FSharpList<Microsoft.FSharp.Core.FSharpFunc<Microsoft.FSharp.Core.Unit, Microsoft.FSharp.Collections.FSharpList<Microsoft.FSharp.Compiler.CompileOps.AvailableImportedAssembly>>> list)	Unknown
FSharp.Compiler.Private.dll!Microsoft.FSharp.Compiler.CompileOps.RegisterAndImportReferencedAssemblies@4432-1.Invoke(Microsoft.FSharp.Collections.FSharpList<Microsoft.FSharp.Core.FSharpOption<System.Tuple<Microsoft.FSharp.Compiler.CompileOps.ImportedBinary, Microsoft.FSharp.Core.FSharpFunc<Microsoft.FSharp.Core.Unit, Microsoft.FSharp.Collections.FSharpList<Microsoft.FSharp.Compiler.CompileOps.AvailableImportedAssembly>>>>> _arg5)	Unknown
<EMAIL_ADDRESS>Microsoft.FSharp.Collections.FSharpList<Microsoft.FSharp.Compiler.CompileOps.AvailableImportedAssembly>>, Microsoft.FSharp.Collections.FSharpList<Microsoft.FSharp.Core.FSharpOption<System.Tuple<Microsoft.FSharp.Compiler.CompileOps.ImportedBinary, Microsoft.FSharp.Core.FSharpFunc<Microsoft.FSharp.Core.Unit, Microsoft.FSharp.Collections.FSharpList<Microsoft.FSharp.Compiler.CompileOps.AvailableImportedAssembly>>>>>>.Invoke(System.Threading.CancellationToken ct)	Unknown
<EMAIL_ADDRESS>System.Tuple<Microsoft.FSharp.Collections.FSharpList<Microsoft.FSharp.Compiler.CompileOps.ImportedBinary>, Microsoft.FSharp.Collections.FSharpList<Microsoft.FSharp.Compiler.CompileOps.AvailableImportedAssembly>>>.Invoke(System.Threading.CancellationToken ct)	Unknown
FSharp.Compiler.Private.dll!Microsoft.FSharp.Compiler.AbstractIL.Internal.Library.CancellableModule.runWithoutCancellation<Microsoft.FSharp.Compiler.CompileOps.TcImports>(Microsoft.FSharp.Compiler.AbstractIL.Internal.Library.Cancellable<Microsoft.FSharp.Compiler.CompileOps.TcImports> comp)	Unknown
FSharp.Compiler.Private.dll!Microsoft.FSharp.Compiler.Driver.main0<Microsoft.FSharp.Compiler.AbstractIL.Internal.Library.CompilationThreadToken>(Microsoft.FSharp.Compiler.AbstractIL.Internal.Library.CompilationThreadToken ctok, string[] argv, Microsoft.FSharp.Compiler.ReferenceResolver.Resolver legacyReferenceResolver, bool bannerAlreadyPrinted, bool openBinariesInMemory, bool defaultCopyFSharpCore, Microsoft.FSharp.Compiler.ErrorLogger.Exiter exiter, Microsoft.FSharp.Compiler.Driver.ErrorLoggerProvider errorLoggerProvider, Microsoft.FSharp.Compiler.Driver.DisposablesTracker disposables)	Unknown
FSharp.Compiler.Private.dll!Microsoft.FSharp.Compiler.Driver.typecheckAndCompile(Microsoft.FSharp.Compiler.AbstractIL.Internal.Library.CompilationThreadToken ctok, string[] argv, Microsoft.FSharp.Compiler.ReferenceResolver.Resolver legacyReferenceResolver, bool bannerAlreadyPrinted, bool openBinariesInMemory, bool defaultCopyFSharpCore, Microsoft.FSharp.Compiler.ErrorLogger.Exiter exiter, Microsoft.FSharp.Compiler.Driver.ErrorLoggerProvider loggerProvider, Microsoft.FSharp.Core.FSharpOption<Microsoft.FSharp.Core.FSharpFunc<Microsoft.FSharp.Compiler.CompileOps.TcImports, Microsoft.FSharp.Core.Unit>> tcImportsCapture, Microsoft.FSharp.Core.FSharpOption<Microsoft.FSharp.Core.FSharpFunc<System.Tuple<Microsoft.FSharp.Compiler.TcGlobals.TcGlobals, string, Microsoft.FSharp.Compiler.AbstractIL.IL.ILModuleDef>, Microsoft.FSharp.Core.Unit>> dynamicAssemblyCreator)	Unknown
FSharp.Compiler.Private.dll!Microsoft.FSharp.Compiler.Driver.mainCompile(Microsoft.FSharp.Compiler.AbstractIL.Internal.Library.CompilationThreadToken ctok, string[] argv, Microsoft.FSharp.Compiler.ReferenceResolver.Resolver legacyReferenceResolver, bool bannerAlreadyPrinted, bool openBinariesInMemory, bool defaultCopyFSharpCore, Microsoft.FSharp.Compiler.ErrorLogger.Exiter exiter, Microsoft.FSharp.Compiler.Driver.ErrorLoggerProvider loggerProvider, Microsoft.FSharp.Core.FSharpOption<Microsoft.FSharp.Core.FSharpFunc<Microsoft.FSharp.Compiler.CompileOps.TcImports, Microsoft.FSharp.Core.Unit>> tcImportsCapture, Microsoft.FSharp.Core.FSharpOption<Microsoft.FSharp.Core.FSharpFunc<System.Tuple<Microsoft.FSharp.Compiler.TcGlobals.TcGlobals, string, Microsoft.FSharp.Compiler.AbstractIL.IL.ILModuleDef>, Microsoft.FSharp.Core.Unit>> dynamicAssemblyCreator)	Unknown
fsc.exe!Microsoft.FSharp.Compiler.CommandLineMain.Driver.main(string[] argv)	Unknown
fsc.exe!Microsoft.FSharp.Compiler.CommandLineMain.main(string[] argv)	Unknown

I looked at this problem with @enricosada and documented known workarounds above
Workaround 1 (Currently WIndows only)

Install Visual Studio 2017 Update 3 (currently in preview)

Add this to your project file:
$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\FSharp\Microsoft.FSharp.NetSdk.targets

On Windows,

Install Visual Studio 2017 Update 3 (currently in preview)
Use "msbuild.exe" from a Visual Studio 2017 command line prompt to build the project instead of "dotnet build"

On Linux/OSX/Xamarin/Mono:

Use "msbuild" or "xbuild" to build the project instead of "dotnet build"

If you use "dotnet build" then the F# targets file for .NET Core is used, that configuration doesn't currently support type providers in any form

(Note, I think we can have a better second workaround which works on both Windows and Mono, though it needs a conditional to determine the right location for FscToolPath)

Thanks @dsyme!
The FscToolPath/FscToolExe workaround seems to work just fine even with SDK 1.0.4.

@cartermp @KevinRansom Well well well.... My initial experiments indicate that it is possible to use the above workarounds to enable type providers for .NET Core programming, as long as the type providers have been written as a cross targeting type provider, as all god type providers are these days (that's not true, it's just a wish - FSharp.Data is the really the only widely used type provider that is cross-targeting today, to my knowledge).
Here are the steps I used to verify this:

dotnet --version
dotnet new console -o -lang F# tpapp2
cd tpapp2
dotnet add package FSharp.Data
dotnet restore
edit the .fs to contain

open System
open FSharp.Data

type NugetStats = HtmlProvider<"https://www.nuget.org/packages/FSharp.Data">

let rawStats = NugetStats().Tables.``Version History``

rawStats.Rows |> Seq.iter (printfn "row = %A")

edit the tpapp2.fsproj to contain

    <FscToolPath>C:\Program Files (x86)\Microsoft SDKs\F#\4.1\Framework\v4.0</FscToolPath>
    <FscToolExe>fsc.exe</FscToolExe>

dotnet build
dotnet run

output:
row = ("F# Data 2.3.3 (this version)", 22954M, 10/04/2017 00:00:00)
...
row = ("FSharp.Data 1.0.2", 234M, 14/12/2012 00:00:00)
row = ("FSharp.Data 1.0.1", 187M, 14/12/2012 00:00:00)
row = ("FSharp.Data 1.0.0", 469M, 13/12/2012 00:00:00)

When using VSCode/Ionide you also get full intellisense:

(Over time we will have to move to the expectation that type providers are .NET Standard 2.0 components that can be loaded into the F# compiler when running on either .NET Framework/Mono or .NET Core.  But for now it appears you can still enable type providers which depend on being loaded into a compiler running .NET Framework through the above.  Also the editor tooling will be running .NET Framework for the forseeable future, and the type providers are hosted there too).

@dsyme you are the freaking man! If I'm ever at a conference you're speaking at dinner one night is on me...
So I journeyed into the matrix to get my application running inside a Docker container on Linux despite it's heavy JSON Type Provider usage due to your workaround and I'm happy to report it works like a champion!
Pros:
This workaround is elegant, nice, and awesome
Runs in Docker on Linux!!!!!
Only developer IDEs and build servers need Windows which is perfectly livable until type providers compile on Core
I can still write all my build scripts for the build servers to be dotnet cli compliant
Cons:
There were 3 things that came up and I've attached a screenshot for all of them to see if I'm doing something wrong..

FSC was complaining about netstandard2.0 but it works when I put in netcoreapp2.0

NuGet shows no packages installed for F#

My Intellisense is broken but I'm pretty certain this probably has something to do with item 2

The only other con was dotnet build, run, restore, publish all throw errors when I include the docker-compose.dcproj file in the .sln file.  I have read that is because the SDK hasn't been open sourced which is a requirement to be included in the tool chain.  This is not a concern as I can simply script the commands to all run against the top level project file rather than the solution.
I have a feeling my cons are entirely a PEBCAK and I've thought up workarounds in the event they are not. I'm still way happier about actually being able to build out my services against dockerswarm on Linux and still being able to use the Type Providers.
Regards,
Brian

The PEBCAK is that I couldn't read.... vscode/ionide I will leave the items up here just in case we want the VS team to see they are very close.

Not sure about (2), but (3) is due to an issue in the language service.  #3260 is tracking that issue, and @KevinRansom is currently working on it.  This is wonderful to hear, though, @buvinghausen!  Happy to hear that it's working for you in Docker/Linux.

Only developer IDEs and build servers need Windows which is perfectly livable until type providers compile on Core

Atm will work also on non windows, using mono. two big ways:

use mono on dev on non win. same workaround

use docker multi stage setup

build a mono docker image for build, build there => get output
run run the build output in another container with just .net core

maybe i should gist the dockerfile i use for that. is a good setup, also for ci who are docker based (we use jenkins).

@dsyme as a note, dotnet new lib -lang F#  works the same of classlib, and is less wierd 😄

@cartermp thanks for the clarification I'm actually working on getting VS Code launch & debug into the Docker container like I can from VS 2017 then I may just cut the cord on VS full I've been looking for an excuse to do that as I have been using VS Code exclusively for TypeScript development.
@enricosada Those are some excellent points but for now I'm totally happy with simply making my CI server run on Windows and letting the FE developers run everything in Node but talking to our integration services on the back end.  That should give me enough runway to let all the frameworks and tooling catch up such that I can then tell them they have to install .NET Core & OmniSharp and learn the dotnet cli.  As an aside I think today is the day that I'm going to see how feasible it is to run the React Redux template in Docker. I know when you create the project they have the docker option disabled.
I really appreciate all the work you guys are putting into this platform I cannot stress that enough it really is amazing to think what the future holds.

Thx for the workaround but I encountered another issue:

error FS3033: The type provider 'FSharp.Data.TypeProviders.DesignTime.DataProviders' reported an error: The .NET SDK 4.0 or 4.5 tools could not be found

Source code tells the truth: SDK paths are fixed. On my relatively new machine (or on VSTS agent) there're no such registry keys. I added new ones (which existed on my machine):

@"Software\Microsoft\Microsoft SDKs\NETFXSDK\4.6.1\WinSDK-NetFx40Tools"
@"Software\Microsoft\Microsoft SDKs\NETFXSDK\4.6.2\WinSDK-NetFx40Tools"

and now it works. Are you interested in pull request for that change?

My solution currently to finding the proper fsc.exe on macOS/Linux is to use a small helper script under my ./tools dir called fsharpc.exe
#!/bin/sh
fsharpc "$@"

Then my project file
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net462</TargetFramework>
    <FscToolPath>../../tools</FscToolPath>
    <FscToolExe>fsharpc.exe</FscToolExe>
  </PropertyGroup>

All it does it delegate to fsharpc, another shell script usually installed my mono and put on the path.  For some reason the tooling is looking for an .exe at the end and won't execute the script without it.  I saw it once somewhere but I can't remember where it was doing the check.
This seems to work with:
$ mono -V
Mono JIT compiler version 4.8.1 (mono-4.8.0-branch/22a39d7 Fri Apr  7 12:00:08 EDT 2017)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
	TLS:           normal
	SIGSEGV:       altstack
	Notification:  kqueue
	Architecture:  x86
	Disabled:      none
	Misc:          softdebug
	LLVM:          yes(3.6.0svn-mono-master/8b1520c)
	GC:            sgen

$ dotnet --info
.NET Command Line Tools (1.0.1)

Product Information:
 Version:            1.0.1
 Commit SHA-1 hash:  005db40cd1

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.11
 OS Platform: Darwin
 RID:         osx.10.11-x64
 Base Path:   /usr/local/share/dotnet/sdk/1.0.1

Libs I've tested so far:
FSharp.Data
FSharp.Configuration
FSharp.Management
Additional note: mdb doesn't seem to get copied over so I have to add this target to copy mdbs
  <Target Name="Copy MDBs"
          Condition="$(OS)=='Unix'"
          AfterTargets="Build">
         <Copy SourceFiles="$(IntermediateOutputPath)/$(AssemblyName).exe.mdb" DestinationFolder="$(OutputPath)" ContinueOnError="true" />
  </Target>

@TheAngryByrd Thanks for that info

Additional note: mdb doesn't seem to get copied over so I have to add this target to copy mdbs...

@KevinRansom It seems this should be part of standard F# targets?

Repo with instructions to enable the workaround : https://github.com/rfrerebe/TypeProviderDotNetCorePreview2

One thing I've also noticed is I don't get incremental build support using that macos/linux workaround. Is there something else I need to set or is it just not supported?

Seems like the fsc.exe shipped with mono 4.8 is still <IP_ADDRESS>
monodis --assembly  /Library/Frameworks/Mono.framework/Versions/4.8.1/lib/mono/fsharp/fsc.exe
Assembly Table
Name:          fsc
Hash Algoritm: 0x00008004
Version:       <IP_ADDRESS>
Flags:         0x00008001
PublicKey:     BlobPtr (0x000000ea)

Even though it reports it's the compiler for 4.1
mono /Library/Frameworks/Mono.framework/Versions/4.8.1/lib/mono/fsharp/fsc.exe
F# Compiler for F# 4.1

Either using mono 5.0.1's version or downloading the latest FSharp.Compiler.Tools from nuget doesn't have the project rebuild every single time.

I need to do something specific to running on SDK 1.0.4 and targetting netcoreapp1.1? Trying target to net462 give me a issue on dotnet run:
❯ dotnet run
/opt/dotnet/sdk/1.0.4/Microsoft.Common.CurrentVersion.targets(1111,5): error MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.6.2" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend. [/home/lerax/Desktop/dchart/backend/backend.fsproj]

The build failed. Please fix the build errors and run again.

I should able to compile and running with mono, but is not working when I try running with .NET Core. My setup is .NE Core SDK 1.0.4 and .NET Core runtime 1.1.2 on Linux.

Alternatively, fsc can be obtained from FSharp.Compiler.Tools nuget. With Paket:
paket.dependencies:
nuget FSharp.Compiler.Tools
.fsproj:
  <PropertyGroup>
    <FscToolPath>../packages/FSharp.Compiler.Tools/tools</FscToolPath>
    <FscToolExe>fsc.exe</FscToolExe>
  </PropertyGroup>```

Tested on Windows 7, but it should work cross-platform (?)

@jindraivanek you are targetting to which framework? (I just want know)

@ryukinix net46

@dsyme Does  cross-targeting type providers now work with generative providers?
I was also wondering if an elaborate bait and swich could be used, like targeting 4.6.1 in consuming a type provider then using a net core facade assembly to redirect to the consumer dll?

Does anyone know how to make this workaround work on Linux (or microsoft/dotnet:sdk Docker image)? We successfully use workaround @jindraivanek mentioned (using fsc.exe from FSharp.Compiler.Tools) on Windows, but anytime we want to build our project on Linux, Travis CI (based on Linux) or Docker, we got:
/usr/share/dotnet/sdk/2.0.0/FSharp/Microsoft.FSharp.Targets(224,9): error MSB6006: "fsc.exe" exited with code 8.

FAKE script build.sh Publish neither dotnet publish, none of them work. Do we need to use different fsc.exe? Any help would be great!

We resolve it now, so here is the description, maybe someone finds it useful:
On windows, everything is the same as @jindraivanek proposed - we use fsc.exe directly from FSharp.Compiler.Tools. To have it working on Linux, we did this:

Created file tools/fsc.exe with content:

#!/bin/sh
chmod +x ../../packages/FSharp.Compiler.Tools/tools/fsc.exe
mono ../../packages/FSharp.Compiler.Tools/tools/fsc.exe "$@"

Changed fsproj to have property groups like this:

 <PropertyGroup Condition="$(OS)=='Unix'">
    <FscToolPath>../../tools</FscToolPath>
    <FscToolExe>fsc.exe</FscToolExe>
  </PropertyGroup>
  <PropertyGroup Condition="$(OS)=='Windows_NT'">
    <FscToolPath>../../packages/FSharp.Compiler.Tools/tools</FscToolPath>
    <FscToolExe>fsc.exe</FscToolExe>
  </PropertyGroup>

Set env variable OS to have Unix value in build.sh script file.
Profit! 😄

Please note: We use [root]/src/AppName folder structure, so if you do it differently, change paths in script file and fsproj.

... to have it working on Linux, we did this:... Created file tools/fsc.exe with content...

We should include the fsharpc and fsharpi scripts in packages/FSharp.Compiler.Tools/tools as part of the FSharp.Compiler.Tools package

I'm trying to build an erasing type provider on .Net core and my problem is:
FSC : error FS3031: The type provider 'myProvider.dll' reported an error: Assembly
attribute 'TypeProviderAssemblyAttribute' refers to a designer assembly 'myProvider' which cannot
be loaded or doesn't exist. Could not load file or assembly 'System.Runtime, Version=<IP_ADDRESS>,
 Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find
the file specified. [C:\tests\myTests.fsproj]

If I target to netstandard2.0 I fail compiling the typeprovider, and if I target to netcoreapp2.0 everything goes ok, until I try to build my test project: when compilation of the test project is done, the compiler executes some code related to TypeProviderAssemblyAttribute which somehow refers a non-core-version of System.Runtime.

I'm trying to build an erasing type provider on .Net core and my problem is:

@Thorium This is not yet supported

Yet another solution to get fsc.exe working on any platform combining the ones above and https://github.com/Microsoft/msbuild/issues/539#issuecomment-289930591 (no need of $(OS) environment variable).
Please, note that YMMV for <FscToolPath>.
Maybe we can get the ultimate solution combining @Dzoukr solution using tools from FSharp.Compiler.Tools with scripts add-ons proposed by @dsyme.
  <PropertyGroup>
    <IsWindows Condition="'$(OS)' == 'Windows_NT'">true</IsWindows>
  </PropertyGroup>
  <PropertyGroup Condition="'$(MSBuildRuntimeType)' == 'Core'">
    <IsOSX Condition="'$([System.Runtime.InteropServices.RuntimeInformation]::IsOSPlatform($([System.Runtime.InteropServices.OSPlatform]::OSX)))' == 'true'">true</IsOSX>
    <IsLinux Condition="'$([System.Runtime.InteropServices.RuntimeInformation]::IsOSPlatform($([System.Runtime.InteropServices.OSPlatform]::Linux)))' == 'true'">true</IsLinux>
  </PropertyGroup>
  <PropertyGroup Condition="'$(IsWindows)' == 'true'">
    <FscToolPath>C:\Program Files (x86)\Microsoft SDKs\F#\4.1\Framework\v4.0</FscToolPath>
    <FscToolExe>fsc.exe</FscToolExe>
  </PropertyGroup>
  <PropertyGroup Condition="'$(IsOSX)' == 'true'">
    <FscToolPath>/Library/Frameworks/Mono.framework/Versions/Current/Commands</FscToolPath>
    <FscToolExe>fsharpc</FscToolExe>
  </PropertyGroup>
  <PropertyGroup Condition="'$(IsLinux)' == 'true'">
    <FscToolPath>/usr/bin</FscToolPath>
    <FscToolExe>fsharpc</FscToolExe>
  </PropertyGroup>

@manchoz Thanks for that workaround - I've added it above.  I removed the Condition="'$(MSBuildRuntimeType)' == 'Core'" - I don't think it's needed or correct when using Mono?  Could you check please?  Thanks

@dsyme yes, it works. Thanks!

I included netstandard.dll, System.Console.dll, System.IO.dll, System.Reflection.dll, System.Runtime.dll from the .NET Standard SDK to the type provider NuGet package and now it seems to work... I don't know if there will be problems but I'll probably find out soon...

Would this trick working on FSharp.Compiler.Service like fable? I'm trying using FSharp.Data.GraphQL client TP in fable, I update TP in FSharp.Data.GraphQL follow the cross target tutorial, and build successfully in dotnet build, but keeps throwing error for cannot find the provided type in Fable.

Has anyone been able to get this to work with FSharp.Data.TypeProviders to connect to a SQL Server database yet?

I've updated the description of what to do to be clearer, specifically adding this text:

Add the file  fsc.props to the root of your project and import it into each of your project files that reference a type provider

@Disco-Dave FSharp.Data.TypeProviders is not a cross-targeting type provider at this stage.  If doing .NET Framework programming you should be able to use it with a .NET SDK 2.0 style project file targeting net45 or net461 though I haven't checked
If you would like a SQL type provider to use with .NET Standard 2.0 programming, see https://github.com/fsprojects/SQLProvider, also @Thorium may have latest details on that.

@zaaack Re your question above - I'm not quite sure what you're asking?  If it involves Fable it may be better to ask via a Fable issue

@manchoz If you could check the fsc.props file mentioned above, and if possible use it, that would be great

Hi, @dsyme. Sorry for the bother, I want to know does FSharp.Compiler.Service work  on .netcoreapp2.0 with non-generative type providers with this configuration? Because I tried this in fable and cannot get the tp working, if FCS works, then must be fable's issue. I find this issue https://github.com/fsharp/FSharp.Compiler.Service/issues/568 and wondering whether this still work when targeting .netcoreapp2.0..

SQLProvider status:

Works on .Net Framework and .Net Coreapp 2.0 on runtime
You will need some configuration to your project files. There are some example projects to show those.

you need a path to fsc as described above.
you need your database driver and dependency dlls to dependency path. (Because I haven't found a reliable way to TypeProvider to load NuGet-package-hierarchies via reflection on compilation.)

The old support for both .NET 4.5.1 and Mono is there still for all the databases there have been.
Besides that the new .Net Coreapp 2.0 example projects are tested to build and run on:

                     | Win10 | Mac  | Ubuntu
Microsoft SQL Server | [x]   | [x]  | [x]
Postgres             | [x]   | [x]  | [x]
MySQL                | [x]   | [x]  | [x]
SQLite               | [x]   |      |

I know you probably have your favourite database type provider, and I'm looking forward to see the others to support .Net Core also. Having multiple options for tools is a good thing.

@zaaack Thanks, I see.  It is not yet under test to load type providers into FCS running in .netcoreapp 2.0.  It might work after recent fixes by @KevinRansom in this repo, but it's possible FCS needs to be republished.  But as I said, it's not yet under test even if it works

@dsyme, thanks a lot!

Just a "heads up"...
The second link in

Add the file fsc.props to the root of your project and import it into each of your project files that reference a type provider

points to an incorrect example.
The correct syntax for importing the fsc.props file is something along the lines of: <Import Project="fsc.props" />.
Took me quite a while (and help from @enricosada) to figure this out.

@pblasucci Thanks for pointing that out, I fixed it

@dsyme I have a type provider which is built as Combo NET Standard TPDTC. Works fine with NET Core on Windows with any tooling VS/Rider/VSCode. Deployed on Linux works at run-time too.
On Mac and Linux at design/build time throws
"Could not resolve field token 0x0400055b"
Any suggestions?
I use the latest Provided Types SDK.
Tooling redirection applied as suggested
https://github.com/Microsoft/visualfsharp/issues/3303#issuecomment-331426983
Thanks

@dsyme I got it. It's same as
https://github.com/npgsql/npgsql/issues/1603#issuecomment-338495817
https://github.com/npgsql/npgsql/issues/1633#issuecomment-338495347
What's the best way to solve it?
Because the way it's done in SQLProvider is not really acceptable.

@dmitry-a-morozov we accept PRs to SQLProvider if you find any better solution.

@Thorium Unfortunately I don't have better solution.
I was surprised to see you guys ship mix of NetStandard and NET461 components in netstandard2.0 folder.

I'm pretty sure that I followed the workaround from above: https://github.com/Microsoft/visualfsharp/issues/3303#issuecomment-312966306.
I get 'FS2024: Static linking may not be used on an assembly referencing mscorlib' when building the netcoreapp that uses WsdlService.
I have a repo demonstrating my attempt and screenshots in the README.
https://github.com/gfritz/tp-apps
Can anyone identify how the WsdlService type provider needs to change to fix that, or if that is the problem? I can't figure out what in WsdlService makes that happen, but I'd be happy to try fixing it.

@zaaack @dsyme FYI, I just tried a project with a "Hello World" erased type provider and F# compiler on netcore seems to recognize it (typing dotnet run yields the correct result), but when parsing it with latest FCS (20.0.1) the provided type is not recognized :/

@zaaack @dsyme FYI, I just tried a project with a "Hello World" erased type provider and F# compiler on netcore seems to recognize it (typing dotnet run yields the correct result), but when parsing it with latest FCS (20.0.1) the provided type is not recognized :/

Could you create a repro ZIP please?  AFAIK this should work, but we need more details on the TP package layout, and whether FCS is running on .NET Core or .NET Framework.

@dsyme I've created a test repo and listed the steps to reproduce in the README. FCS 20.0.1 didn't recognize the erased member when parsing the project, but the good news is... FCS 21.0.1 does! :tada:

@alfonsogarciacaro That's great, thanks

Are FscToolPath and FscToolExe properties still needed?
<FscToolPath>C:\Program Files (x86)\Microsoft SDKs\F#\4.1\Framework\v4.0</FscToolPath>
seems to have changed. There would be this:
<FscToolPath>C:\Program Files (x86)\Microsoft SDKs\F#\10.1\Framework\v4.0</FscToolPath>
Is it compatible?
Do I have to update all the project files and all the documentations?

@dsyme I'm happy to report that @tpetricek released the 3.0 beta two days ago which supports .netstandard2 out of the box.  We have already upgraded our applications to use the 3.0 beta and removed the fsc.props and everything is still going green.  I think you can safely close this topic and say go get it here NuGet FSharp.Data

I don't deserve any credit here :-) all the fantastic work on F# Data has been done by @ovatsus and @dsyme !

Actually it was @dsyme and @baronfel, I just basically clicked the merge button :)

Well cheers to all! Fantastic work

I have the Fsharp.Data 3.0 beta and I still have this issue: :-\
Here is my travis log for the failed build: https://travis-ci.org/NullVoxPopuli/CryptoExchangeClient/builds/365901067  (just trying to get linux support working, the master branch works on windows)
I searched the paket.lock, and all occurrences of FSharp.Data are the latest beta.

Thank you very much! Get it to work in my stuff. Great job :)

Is the Fsc.prop fix still required when using dotnet SDK 2.1.300 but using netcoreapp2.0 packages?

No, it shouldn't be needed

We've been using FSharp.Data 3.0 beta with every SDK 2.1.300 release from preview1, preview2, rc1, and rtm all without issue it's been awesome.  That's with devs using both OSX and WIndows along with our build server & deployment servers all running in Docker on Linux.  We're using it for both XML & JSON provider scenarios extensively.

Closing this, as Type Providers are now supported as .NET Standard components

@cartermp I think you claimed victory too early
https://github.com/fsprojects/FSharp.TypeProviders.SDK/issues/244
Hopefully it will get fixed soon.

@dmitry-a-morozov
Here is an example of using the dotnet sdk to create and consume a Type Provider nuget package.
https://github.com/Microsoft/visualfsharp/tree/master/tests/EndToEndBuildTests/BasicProvider
Let me know if this helps.
Kevin

@KevinRansom This is no helpful because it's essentially same as https://github.com/fsprojects/FSharp.TypeProviders.SDK/tree/master/examples and doesn't have any external dependencies.
I need an example with TPDTC dependency on external assembly (ideally a nuget package).

@KevinRansom Not exactly. My design time component has dependencies like Npgsql
https://github.com/demetrixbio/FSharp.Data.Npgsql/blob/master/src/DesignTime/DesignTime.fsproj#L36
But by using <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> in build file I copy all required binaries to the same folder as TPDTC.
Current version of F# compiler has breaking change. It doesn't know to load assemblies co-located with TPDTC. I applied workaround suggested by @dsyme
https://twitter.com/dsyme/status/1024420744250515456
But I'm stuck with
error FS1108: The type 'Void' is required here and is unavailable. You must add a reference to assembly 'System.Private.CoreLib, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'.

I described it all in
https://github.com/fsprojects/FSharp.TypeProviders.SDK/issues/244

I guess we should take a look then.
Do you have a branch of your repro, without the workaround?  I will see what needs to be done in the compiler to make it work.
From: Dmitry Morozov<EMAIL_ADDRESS>Sent: Wednesday, August 1, 2018 1:19 PM
To: Microsoft/visualfsharp<EMAIL_ADDRESS>Cc: Kevin Ransom<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [Microsoft/visualfsharp] How to enable type providers with new-style .NET SDK project files, dotnet build, .NET Standard and .NET Core programming (#3303)
@KevinRansomhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKevinRansom&data=02|01|Kevin.Ransom%40microsoft.com|6f6143039a3440a4b9f508d5f7ec0dd5|72f988bf86f141af91ab2d7cd011db47|1|0|636687515569580454&sdata=diHOMT3stS%2F3s%2BF0NV5z%2BDOqvl9BMEWweGNxpyTiNp8%3D&reserved=0 Not exactly. My design time component has dependencies like Npgsql
https://github.com/demetrixbio/FSharp.Data.Npgsql/blob/master/src/DesignTime/DesignTime.fsproj#L36https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdemetrixbio%2FFSharp.Data.Npgsql%2Fblob%2Fmaster%2Fsrc%2FDesignTime%2FDesignTime.fsproj%23L36&data=02|01|Kevin.Ransom%40microsoft.com|6f6143039a3440a4b9f508d5f7ec0dd5|72f988bf86f141af91ab2d7cd011db47|1|0|636687515569590462&sdata=CXX2oWmp3ACesKT4S4xoqnWqCTgYtkcG39QyhfxdPfQ%3D&reserved=0
But by using true in build file I copy all required binaries to the same folder as TPDTC.
Current version of F# compiler has breaking change. It doesn't know to load assemblies co-located with TPDTC. I applied workaround suggested by @dsymehttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdsyme&data=02|01|Kevin.Ransom%40microsoft.com|6f6143039a3440a4b9f508d5f7ec0dd5|72f988bf86f141af91ab2d7cd011db47|1|0|636687515569600475&sdata=57N6I6RHvDY0%2F8K%2B%2BXy7firJrGNNvHTkd4NhPVSlbLY%3D&reserved=0
https://twitter.com/dsyme/status/1024420744250515456https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fdsyme%2Fstatus%2F1024420744250515456&data=02|01|Kevin.Ransom%40microsoft.com|6f6143039a3440a4b9f508d5f7ec0dd5|72f988bf86f141af91ab2d7cd011db47|1|0|636687515569600475&sdata=BQzoh5MZ%2BZxZGH1%2F9IpKbYAfUR3Tk5hEi013xonZ4fQ%3D&reserved=0
But I'm stuck with
error FS1108: The type 'Void' is required here and is unavailable. You must add a reference to assembly 'System.Private.CoreLib, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'.
I described it all in
fsprojects/FSharp.TypeProviders.SDK#244https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ffsprojects%2FFSharp.TypeProviders.SDK%2Fissues%2F244&data=02|01|Kevin.Ransom%40microsoft.com|6f6143039a3440a4b9f508d5f7ec0dd5|72f988bf86f141af91ab2d7cd011db47|1|0|636687515569610479&sdata=FdwnMIb4YLpIKeaPii7t%2FIt0KS9N5P1pELnVjw%2FSuWQ%3D&reserved=0
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoft%2Fvisualfsharp%2Fissues%2F3303%23issuecomment-409708328&data=02|01|Kevin.Ransom%40microsoft.com|6f6143039a3440a4b9f508d5f7ec0dd5|72f988bf86f141af91ab2d7cd011db47|1|0|636687515569610479&sdata=ZWmUD3X3ovF%2Fpg%2BKMSNYvHS4fHT6jAo9n4JIgpruFR0%3D&reserved=0, or mute the threadhttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAE76FuDnwGZseIGuuOBlvoJ76G69BrpRks5uMg1DgaJpZM4ONPFJ&data=02|01|Kevin.Ransom%40microsoft.com|6f6143039a3440a4b9f508d5f7ec0dd5|72f988bf86f141af91ab2d7cd011db47|1|0|636687515569620487&sdata=KXJh5YrPhpyDTWKcFAe4h%2FswFMIwdHCz3vSA%2Fuim%2BP0%3D&reserved=0.

Latest commit de10d57 has workaround commented out
https://github.com/demetrixbio/FSharp.Data.Npgsql/blob/de10d5749dbdf3d8dfb9292bcaaa245f8da9629b/tests/Tests.fsproj#L10
So it compiles from VS but fails from command line.
I actually wanted to take it step father and place TPDTC in
...\typeproviders\fsharp41\netstandard2.0\FSharp.Data.Npgsql.DesignTime.dll relative to runtime component but legacy location (design time co-located to run-time) doesn't work either.
Follow instructions to run tests.
Honestly I think it's better to extend BasicProvider example to have dependency because it will useful for community as example of managing dependencies. But I'll leave it to your judgement.

@KevinRansom I made some changes to unit test suite so it should run on your machine.
Use this commit
https://github.com/demetrixbio/FSharp.Data.Npgsql/commit/b44df12e87eb66b374814208245e82ce65e69d35
Thanks

@buvinghausen Thanks for the tip on FSharp.Data beta, it also fixed my issue.
Still a brave new world this Dotnet core. :)

@KevinRansom
Congrats on 15.8 VS release ! Great work.
Do you have any updates on discussion above and  https://github.com/fsprojects/FSharp.TypeProviders.SDK/issues/244?
Thanks
//cc @dsyme @cartermp

@dmitry-a-morozov It's on my list of things to resolve.  I'm afraid I have no details about when :-(

@KevinRansom I understand. Keep me posted.

I so confused on what I need to do to get the OpenAPITypeProvider to work. It is build for netstandard2.0. https://github.com/fsprojects/OpenAPITypeProvider/issues/6

Recording a link to my reply here: https://github.com/fsprojects/OpenAPITypeProvider/issues/6#issuecomment-428900442

I'm trying to use FSharp.Configuration in my project. On my TeamCity build environment (Linux), I have installed the fsharp compiler and imported fsc.props, but the build breaks with the error message
"fsharpc" exited with code 1.
For now, I'm not sure where to go, as it's not clear how to get a detailed error description from fsharpc.

The fsc.props workaround stopped working in version 2.2.203 of the SDK.
I posted a workaround in fsprojects/FSharp.TypeProviders.SDK/issues/244

Why would you still be using the fsc.props workaround?  The 3.0 beta (and all subsequent 3.x releases) has been working without the workaround for over a year now...

After the latest caching improvements I started to get this error FS3033(0,0): The design-time type 'System.String' utilized by a type provider was not found in the target reference assembly set '[ ...(list of assemblies)... ]'. You may be referencing a profile which contains fewer types than those needed by the type provider you are using. also in the .NET Framework full.
Commit 8cc9f9f8ca9b934e1f9d37743bc792dccc91675c did work, but after commit b08fe13625b2ffc08529cb9350db8f86c6b3c537 there are problems.

It's fixed in 3.0? With dotnet-sdk-3.0.100-preview5-011568-linux-x64.tar.gz I still get the same error, after invoking "dotnet build" on a F# project:
error FS3053 : The type provider 'FSharp.Configuration.ConfigTypeProvider+FSharpConfigurationProvider' reported an error : The type provider constructor has thrown an exception: Exception has been thrown by the target of an invocation.
Will it be fixed properly? Can a out-of-the-box solution that does not demand manual workardounds with paths and hacks, be expected in the future? In the Java world things are much easier.

@patham9 it’s highly unlikely that this issue is the right place to report that error, as the mechanism to allow type providers to work on .NET Core has been shipped and stable for quite some time.

I agree with @cartermp. My initial porting of the FSharp.Configuration TP was incomplete and it hasn't been fully updated with a .netstandard version, which would be required for seamless usage. There's an issue on the repo for this I believe, but someone needs to do/finish the work.  It's on my list to do, but like many others I have many competing priorities.

@Thorium Did you ever figure out a workaround or fix? Having this same problem...

After the latest caching improvements I started to get this error FS3033(0,0): The design-time type 'System.String' utilized by a type provider was not found in the target reference assembly set '[ ...(list of assemblies)... ]'. You may be referencing a profile which contains fewer types than those needed by the type provider you are using. also in the .NET Framework full.

Yes, I figured out what happened.
FSharp.TypeProviders.SDK has the file ProvidedTypes.fs which is loading types from netstandard.dll which contains the base types of .NET Standard.
If you follow the tutorial, LemonadeProvider, and open the file
src\LemonadeProvider.DesignTime\LemonadeProvider.DesignTime.fsproj you will notice the dependency:
    <None Include="..\..\packages\NETStandard.Library.NETFramework\build\net461\lib\netstandard.dll" Condition="'$(TargetFramework)' == 'net45'">
        <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>

So the typeprovider loads the netstandard.dll from this NuGet package:
https://www.nuget.org/packages/NETStandard.Library.NETFramework/2.0.0-preview2-25405-01
But the netstandard.dll there is an old version, and if you a later use netstandard.dll in your machine (you have the latest .NET Core installed) there will be version conflict between the loaded netstandard.dll and the used netstandard.dll. That might also lead the type-provider to reflection-loading-loop between the two dlls, causing stackoverflow.
I went the simplest fix which was uninstall VS2019 and take VS2017 back, and everything worked correctly. :-P


Logs no longer include call stack

#51 changed how we setup the loggers in order to write to two different sinks.
As a side effect I think we stopped logging the caller.

Previously we were doing
c := zap.NewDevelopmentConfig()
log, err := c.Build()
if err != nil {
    t.Fatalf("Failed to create logger: %v", err)
}

It looks like that calls cfg.buildOptions on the writeSyncer
https://github.com/uber-go/zap/blob/3ffa0c00594205c2c623aa9493847217982b558d/config.go#L264
Here we can add the option to AddCaller
https://github.com/uber-go/zap/blob/3ffa0c00594205c2c623aa9493847217982b558d/config.go#L272

This turns out to be a one line fix
newLogger = newLogger.WithOptions(zap.AddCaller())
zap.ReplaceGlobals(newLogger)

Fix is in #54


Any way to confirm if a PV/PVC exists before create

Output of helm version:
Client: &version.Version{SemVer:"v2.16.3", GitCommit:"1ee0254c86d4ed6887327dabed7aa7da29d7eb0d", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.16.3", GitCommit:"1ee0254c86d4ed6887327dabed7aa7da29d7eb0d", GitTreeState:"clean"}
Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"06ad960bfd03b39c8310aaf92d1e7c12ce618213", GitTreeState:"clean", BuildDate:"2020-02-11T18:14:22Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"06ad960bfd03b39c8310aaf92d1e7c12ce618213", GitTreeState:"clean", BuildDate:"2020-02-11T18:07:13Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"}
Cloud Provider/Platform (AKS, GKE, Minikube etc.):
Minikube
We need some support during pre-install hook:
Any way to create a PVC during pre-install hook phase by helm3 install command automatically since the hook image will need to use the PVC?
Any way to give a check before PVC creation if this PVC exist or  not?
Really thanks for your time!

There is not a way in Helm v2. In Helm v3 there is the lookup function. This function enables you to lookup resources in a cluster.
Note, if you use helm template or perform a dry run Helm will not interact with the cluster and will return no results for a lookup. It will only perform the lookup when installing or upgrading.

Hi, thanks for your reply.
But how to create PVC before pre-install during helm install command since pre-install hook is executed before any resources are created in Kubernetes?

I don’t think a pre-pre-install hook exists if that’s what you’re looking for.

Okay, thanks for your help.


Permalinks for queries

I was wondering whether it'd be possible to add permanent links for query pages. It's useful for bookmarking or fast sharing of links without having to re-enter again the specific query. I'd expect something along the lines:

http://localhost/my_table/query/.WHERE?cond1=AAA&cond2=TRUE.ORDERBY?column1

I guess that at least simple keywords such WHERE, LIMIT, ORDER BY and GROUP BY would be sufficient. Covering all cases isn't necessary for a simple lightweight tool.
Thanks for this sweet tool by the way.

Ah, interesting idea. I can look into this for sure.

To implement the clause-specific stuff, I'd have to parse the actual SQL which I'm not thinking I will end up implementing, but maybe there's an easy way to encode the whole query.


Separate UIs for message editing and moving messages

In #22537 / #22652 we changed the three-dot message menu to always show "Edit message" and "Move message" as separate options when the user has the relevant permissions, as well as splitting up "Move message" and "View message source".
We should complete this change by splitting up the UIs for moving and editing messages.
UI for Edit message or View message source

[x] Don't show stream / topic in the UI. We should just show the source of the message (editable or not, based on permissions).
[ ] The e shortcut key should open this UI. We should update the description of this shortcut to:

? menu: Edit selected message or view message source
/help/keyboard-shortcuts: Edit message or view message source

UI for Move message
Selecting this option should open the "Move topic" modal we have in the three-dot topic menu, with the following changes:

[x] Rename the modal to "Move messages"
[x] Add the dropdown for which messages to move just below the stream > topic selector.
[x] Disable (but do not remove) the stream and/or topic selector when the user doesn't have the permissions to change the stream and/or topic.

Completing this issue should also resolve:

#22565
#22566
#21712

We will need to audit help center documentation after these changes, but this can be done as a follow-up.
CZO discussion

Reviewing the issue description, I think we should make a couple of small tweaks:

Add the (e) shortcut to the "View message source" option in the message menu.
Looks like "Edit selected message or view message source" is too long to fit on one line in the ? menu, so let's change it to  "Edit selected message or view source", so that it at least fits in English.

@sahil839 would you be up for putting up a PR?

PR that resolved most of this issue: #23139


Add support for code actions

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_codeAction


Test enhancement

Changed log

Add php-7.2 and php-7.3 tests during Travis CI build.
To be compatible with future PHPUnit versions, using the PHPUnit\Framework\TestCase class namesapce instead.
satooshi/php-coveralls package is deprecated and using the php-coveralls/php-coveralls instead.
Removing the hhvm version test because it will not be different from future PHP versions.

Coverage decreased (-14.2%) to 83.019% when pulling dc4f91167def3d47f78cf0e65c763b6b0a2d924c on open-source-contributions:test_enhancement into e0544181aeb5d0d3334a51a1189eaaad5fa3c33b on gpslab:master.

Coverage decreased (-14.2%) to 83.019% when pulling dc4f91167def3d47f78cf0e65c763b6b0a2d924c on open-source-contributions:test_enhancement into e0544181aeb5d0d3334a51a1189eaaad5fa3c33b on gpslab:master.

Coverage decreased (-14.2%) to 83.019% when pulling dc4f91167def3d47f78cf0e65c763b6b0a2d924c on open-source-contributions:test_enhancement into e0544181aeb5d0d3334a51a1189eaaad5fa3c33b on gpslab:master.

Coverage decreased (-14.2%) to 83.019% when pulling dc4f91167def3d47f78cf0e65c763b6b0a2d924c on open-source-contributions:test_enhancement into e0544181aeb5d0d3334a51a1189eaaad5fa3c33b on gpslab:master.

Coverage decreased (-14.2%) to 83.019% when pulling dc4f91167def3d47f78cf0e65c763b6b0a2d924c on open-source-contributions:test_enhancement into e0544181aeb5d0d3334a51a1189eaaad5fa3c33b on gpslab:master.

Coverage decreased (-14.2%) to 83.019% when pulling dc4f91167def3d47f78cf0e65c763b6b0a2d924c on open-source-contributions:test_enhancement into e0544181aeb5d0d3334a51a1189eaaad5fa3c33b on gpslab:master.

@peter-gribanov, please look at this PR.
Thanks :).

Good job. Thanks.


TensorFlow Lite Micro fully connected int8 test passes illegal filter offset

An external developer pointed out that the test for the quantized fully connected operation passes in a non-zero weight offset to the kernel for int8 tests:
https://github.com/tensorflow/tensorflow/blob/master/tensorflow/lite/micro/kernels/fully_connected_test.cc#L118-L119
The quantization specification promises that int8 kernels will always receive zero weight offsets:
https://www.tensorflow.org/lite/performance/quantization_spec
This failing test is preventing an optimized kernel for a hardware platform from being accepted.

ARM with CMSIS-NN optimization seems to be also affected by this issue. At least the int8 tests fail and once the same workaround as above is added here, all tests pass.

This issue has been fixed by PR #38040

@petewarden  Can I close this issue?


Vercel-Deploymeent Solution

IF you directly select your app on vercel then it will not gonna deploy.
Because your root directory is inside SoppingOffice file so select it then deploy it.

@HarshwardhanPatil07 kindly add these labels


Update Issue - 11369307

default description
URL tested: http://ci.bsstag.com/welcome
Open URL on Browserstack

Property
Value

Browser
Chrome 38.0

Operating System
Windows XP

Resolution
1024x612

Screenshot Attached
Screenshot URL

Click here to reproduce the issue on Browserstack

Updated Screenshot Attached