Create tests for vehicles - getVehicles()

Mission Control
The DAV project you are looking at is Mission Control. It is the brain in charge of orchestrating missions between DAV users and autonomous vehicles.
How you can help
Background
To help developers building on top of DAV technologies, Mission Control can start in a simulation environment. In a simulation environment, there are always a few simulated drones flying around the user, ready to take on missions. This makes it easy for developers to start building and testing without investing in hardware.
The Issue
As a project that relies on a large community of contributors, it is very important for us to have good test coverage to make sure changes don't break anything.
The file /server/simulation/vehicle.js isn't tested at all. Create a file /test/specs/simulation.vehicles.spec.js that will test the function generateRandomVehicles()
Test that generateRandomVehicles() fulfills these conditions:

receives an integer or undefined as the first argument (vehicleCount)
returns an array containing as many objects as the integer passed as the first argument (vehicleCount)
returns an array containing 4 objects if undefined is passed as the first argument (vehicleCount)
receives an object containing lat and lang entries as its second argument (coords)
receives an integer as its third argument (radius)
returned objects contain id, model, icon, coords, rating, missions_completed, missions_completed_7_days

You can see how this file should be structured based on the other files in the specs directory.
To run your tests, run npm test from the project's root directory. All tests should pass.

Contributing to Mission Control

[ ] Fork the repository from the Mission Control GitHub page.
[ ] Clone a copy to your local machine with $ git clone git@github.com:YOUR-GITHUB-USER-NAME/missioncontrol.git
[ ] Make sure you have node.js and npm installed on your machine. You can use this guide for help.
[ ] Install all of the project's dependencies with npm. $ cd missioncontrol; npm install
[ ] Run npm test to run linting checks and all the automated tests and see that they pass.
[ ] Code! code! code!
[ ] Before committing your code, run npm test one last time and make sure no errors (including linting errors) are thrown.
[ ] Once you've made sure all your changes work correctly and committed all your changes, push your local changes back to github with $ git push -u origin master
[ ] Visit your fork on GitHub.com (https://github.com/YOUR-USER-NAME/missioncontrol) and create a pull request for your changes.
[ ] Make sure your pull request describes exactly what you changed and references this issue (include the issue number in the title like this: #28)

@TalAter I see this one was claimed but it's been a while and no updates. Would I be able to take a shot at this?

I've asked @shpyzer who has already done most of the work on this. If he doesn't have the time to finish this one, we'd love the extra help 👍

@TalAter awesome, keep me posted.

@ZackTaylor
Looks like this one is still available, would you like to take this one on?


Ingress hosts are not getting DNS names created.

https://github.com/kubernetes-incubator/external-dns/blob/master/docs/tutorials/nginx-ingress.md
I followed the tutorial and I am not getting any DNS records created for ingress objects. It DOES work correctly when I annotate services with external-dns.alpha.kubernetes.io/hostname: hellofromkubernetes.k8s.me.me
time="2018-07-11T22:40:50Z" level=info msg="No matching hosted zones" is the only message reported.
I am using registry.opensource.zalan.do/teapot/external-dns:latest with the following arguments.
62         args:
63         - --source=service
64         - --source=ingress
65         - --domain-filter=k8s.me.me # will make ExternalDNS see only the hosted zones matching provided domain, omit to process all available hosted zones
66         - --provider=aws
67         - --policy=upsert-only # would prevent ExternalDNS from deleting any records, omit to enable full synchronization
68         - --aws-zone-type=public # only look at public hosted zones (valid values are public, private or no value for both)
69         - --registry=txt
70         - --txt-owner-id=my-identifier
Additionally. The A record for my service is being created with the private IPs of all of my nodes. How can I have the value of the A record be the public IP attached to a service, or ingress controller?
hellofromkubernetes2.k8s.me.me. | A | <IP_ADDRESS>  <IP_ADDRESS>  <IP_ADDRESS>  <IP_ADDRESS>  <IP_ADDRESS>  <IP_ADDRESS>  <IP_ADDRESS>  <IP_ADDRESS>  <IP_ADDRESS>  <IP_ADDRESS>  <IP_ADDRESS>  <IP_ADDRESS>  <IP_ADDRESS>  <IP_ADDRESS>  <IP_ADDRESS>  <IP_ADDRESS> |

Exactly the same problem here. Works fine on public and private hosted zones with service annotation.
But using Ingress I see nothing created in my public or privated hosted zone.

@cabrinoob Please run kubectl get ingress <your-ingress> and check whether the ADDRESS column is populated.

@bpinske what's the Type of your Service?

Hi,
I experienced the same and then I added --publish-service=$INGRESS_CONTROLLER_NAMESPACE/$INGRESS_CONTROLLER_CONTAINER_NAME
and it started working.
See https://github.com/kubernetes/ingress-nginx/blob/c0ed143fbd0909dcf2d75d74c84e6bbbca4b80fb/docs/user-guide/cli-arguments.md
Hope it helps,
Ohad

@linki : ADDRESS is correctly populated with the ELB of my nginx-ingress controller
@odavid : $INGRESS_CONTROLLER_CONTAINER_NAME is the name of the service or the pod of your ingress controller?

the service
sorry

@cabrinoob - If you are using the nginx-ingress helm chart, look at
      publishService:
        enabled: true

within the values.yaml

@odavid  : Now it works!

@odavid @cabrinoob Great!  🎉 For anyone stumbling here as well this is also documented at
https://github.com/kubernetes-incubator/external-dns/blob/v0.5.4/docs/tutorials/nginx-ingress.md#with-a-separate-tcp-load-balancer

@linki : Ok, I did not see this doc because it is related to GCE and I'am under AWS. But thank you!

@cptaffe Any chance you could share the YAML for your Traefik setup.  I can't for the life of me get this working for Ingresses.  It works fine for Services.
This is my current setup for just testing with the Traefik example Cheese sites:  https://gist.github.com/rosstimson/5d2d4eb1ef676a6744d8b3bfeab882cc
You can see I have added the Traefik config you mentioned:  https://gist.github.com/rosstimson/5d2d4eb1ef676a6744d8b3bfeab882cc#file-traefik-yml-L68-L71
Also the RBAC additions:  https://gist.github.com/rosstimson/5d2d4eb1ef676a6744d8b3bfeab882cc#file-traefik-yml-L28-L33
Back in the external-dns logs I just get:
time="2018-09-13T16:24:39Z" level=debug msg="No endpoints could be generated from ingress dev/cheese"

So it definitely is looking at the Ingresses but just not creating the Route 53 record.  If I manually add a record pointing to the ELB of the Traefik service the cheese sites work fine so all that side of things is wired up properly.
I'd love to see how you have set this up to compare with my config if you don't mind sharing.

Make sure the host in the ingress is one you control in Route53

@cptaffe  Oh, it definitely is one I control, I just replaced with example.com in the gist.  Like I say, this is working fine for services (type: LoadBalancer) that have the annotation, just not Ingresses.

@rosstimson here's my configs https://gist.github.com/cptaffe/0551478bdf628e167283e1d78a8f8219

Oh! Your Traefik config should be
publishedService = "kube-system/traefik-ingress-service"

since you've named your service traefik-ingress-service.

Exactly command to get it work with Helm:
helm install --namespace kube-system --name nginx-ingress \
  --set controller.publishService.enabled=true            \
  stable/nginx-ingress


Is there any plans to support Oracle Instant Client for macOS M1?

Is there any plans to support Oracle Instant Client for macOS M1?

Planned but no ETA.
Users have reported the Intel Instant Client works.  (Also we now have Instant Client Linux ARM)

@cjbj one of our users got the following:
/Users/xxx/Oracle/instantclient_19_8/libocijdbc19.dylib: mach-o, but wrong architecture.
when he tries to use Instant client on M1.
Do you need any extended logs?

@tjlee since this is a not a supported platform, and I have no access to M1, I am unable to comment.  Sorry!


test image signing using cosign

@developer-guy plz review it! thanks

plz consider this https://github.com/Cloud-Hacks/jaeger/blob/d6ba71ed8e6fb1e23b910dfe79bcbcdb3475a072/.github/workflows/ci-release.yml

@developer-guy as a friendly reminder, could u review that?

@developer-guy can you take a look again? Thanks.

Heyya @developer-guy it's been quite while now since you took up this. LMK how we can proceed further. Hope you can do this weekend.


[docs] Pigment migration docs doesn't mention spacing, breakpoints etc are no longer callable

Related page
https://mui.com/material-ui/migration/migrating-to-pigment-css/
Kind of issue
Missing information
Issue description
I just upgraded to MUI v6 and started migrating to pigment, followed all the steps in the docs and now there are errors when I'm trying to start dev server
import { Typography } from '@mui/material';
import { styled } from '@mui/material-pigment-css';

export const SectionHeader = styled(Typography)(({ theme }) => ({
  textTransform: 'uppercase',
  fontWeight: 800,
  display: 'inline-flex',
  width: '100%',
  justifyContent: 'center',
  [theme.breakpoints.down('md')]: { // <---- Cannot read properties of undefined (reading 'down')
    padding: 0,
  },
})) as typeof Typography;

import { styled } from '@mui/material-pigment-css';
import Box from '@mui/material-pigment-css/Box';

export const AllSpecialOffersBox = styled(Box)(({ theme }) => ({
  marginTop: theme.spacing(8), // <---- theme.spacing is not a function
  display: 'flex',
  justifyContent: 'center',
}));

Although on mui/pigment-css#creating-styles it does provide and example of how spacing should be used with pigment, i.e.
const title = css(({ theme }) => ({
  color: theme.colors.primary,
  fontSize: theme.spacing.unit * 4, // <---- spacing is now a property, not a function
  fontFamily: theme.typography.fontFamily,
}));

Should this be a part of migration docs and marked as breaking change? As for breakpoints, I couldn't find mentioning it anywhere except for https://github.com/mui/pigment-css/issues/203. Response suggests we need to set breakpoints explicitly now. Not sure if that's a bug or an undocumented breaking change, we were using default MUI breakpoints since day one.
Context
Migrating to pigment-css in NextJS + MUIv6
Search keywords: pigment

@abriginets Could you also share your next.config file ?

Sure, here it is
next.config.mjs
import bundleAnalyzerPlugin from '@next/bundle-analyzer';
import { extendTheme, withPigment } from '@pigment-css/nextjs-plugin';
import { withSentryConfig } from '@sentry/nextjs';
import createNextIntlPlugin from 'next-intl/plugin';
import pwaPlugin from 'next-pwa';

const { BACKEND_URL } = process.env;

/**
 * @type {import('next').NextConfig}
 */
const nextConfig = {
  compress: false,
  output: 'standalone',
  images: {
    domains: ['mpics.avs.io', 'pics.avs.io', 'yasen.aviasales.ru'],
  },
  experimental: {
    nextScriptWorkers: true,
    proxyTimeout: 60_000,
  },
  poweredByHeader: false,
  swcMinify: true,
  reactStrictMode: true,
  async rewrites() {
    return {
      beforeFiles: [
        {
          source: '/api/search/:path*',
          destination: `${BACKEND_URL}/api/search/:path*`,
        },
      ],
      fallback: [
        {
          source: '/api/:path*',
          destination: `${BACKEND_URL}/api/:path*`,
        },
      ],
    };
  },
};

const withPWA = pwaPlugin({
  dest: 'public',
  disable: process.env.NODE_ENV === 'development',
});
const withBundleAnalyzer = bundleAnalyzerPlugin({
  enabled: process.env.ANALYZE === 'true',
});

const withNextIntl = createNextIntlPlugin();

/**
 * @type {import('@pigment-css/nextjs-plugin').PigmentOptions}
 */
const pigmentConfig = {
  transformLibraries: ['@mui/material'],
  theme: extendTheme({
    colorSchemes: {
      dark: {
        palette: {
          error: {
            main: '#ff1744',
          },
          contrastThreshold: 3,
          tonalOffset: 0.2,
        },
      },
      light: {
        palette: {
          error: {
            main: '#ff1744',
          },
          contrastThreshold: 3,
          tonalOffset: 0.2,
        },
      },
    },
    components: {
      MuiInputLabel: {
        styleOverrides: {
          root: {
            fontWeight: 500,
          },
        },
      },
      MuiTooltip: {
        styleOverrides: {
          tooltip: {
            fontSize: '13px',
          },
        },
      },
    },
  }),
};

export default withPigment(
  withNextIntl(
    withPWA(
      withBundleAnalyzer(
        withSentryConfig(
          nextConfig,
          /** @type {import('@sentry/nextjs').SentryWebpackPluginOptions} */
          {
            authToken: process.env.SENTRY_AUTH_TOKEN,
            org: process.env.SENTRY_ORG,
            project: process.env.SENTRY_PROJECT,
            widenClientFileUpload: true,
            hideSourceMaps: true,
            disableLogger: process.env.NODE_ENV === 'production',
            finalize: false,
          },
          {
            hideSourceMaps: true,
          },
        ),
      ),
    ),
  ),
  pigmentConfig,
);

I think the issue here is related to extendTheme in next.config which is referenced in the migration docs
import { withPigment, extendTheme } from '@pigment-css/nextjs-plugin';
/** @type {import('next').NextConfig} */
const nextConfig = {};

const pigmentConfig = {
    transformLibraries: ['@mui/material'],
    theme: extendTheme({ // <---- issue
        cssVariables: true,
        colorSchemes: {
            light: {
                colors: {
                    background: "#fff",
                    foreground: "#000",
                },
            },
            dark: {
                colors: {
                    background: "#000",
                    foreground: "#fff",
                },
            },
        }
    }),
};

export default withPigment(nextConfig, pigmentConfig);

using createTheme() retains breakpoints and spacing:
import { withPigment } from '@pigment-css/nextjs-plugin';
import { createTheme } from "@mui/material";
/** @type {import('next').NextConfig} */
const nextConfig = {};

const pigmentConfig = {
    transformLibraries: ['@mui/material'],
    theme: createTheme({
        cssVariables: true,
        colorSchemes: {
            light: {
                colors: {
                    background: "#fff",
                    foreground: "#000",
                },
            },
            dark: {
                colors: {
                    background: "#000",
                    foreground: "#fff",
                },
            },
        }
    }),
};

export default withPigment(nextConfig, pigmentConfig);

However, there is still FOUC flickering when specifying dark mode, but that's another issue...

Thanks, @abriginets, for the report and @samuelgoldenbaum, for replying.
The guide has already been fixed to replace extendTheme with createTheme: https://mui.com/material-ui/migration/migrating-to-pigment-css/#removing-owner-state
@abriginets can you confirm if the following change on your config file solves your issue:
 import bundleAnalyzerPlugin from '@next/bundle-analyzer';
-import { extendTheme, withPigment } from '@pigment-css/nextjs-plugin';
+import {withPigment } from '@pigment-css/nextjs-plugin';
+import { createTheme } from '@mui/material/styles';
 import { withSentryConfig } from '@sentry/nextjs';
 // ...

 // ...
 const pigmentConfig = {
   transformLibraries: ['@mui/material'],
- theme: extendTheme({
+ theme: createTheme({
     colorSchemes: {
 // ...

@DiegoAndai yep, that does fix the issue with spacing and breakpoints, I can confirm there are no such errors now in the terminal.

Thanks @abriginets, I'm closing the issue as it has been fixed and the migration guide updated. If you have a similar issue, please open a new one with a repro.

I encountered the follwoing:
import { useTheme } from '@mui/material-pigment-css';

const theme = useTheme();
theme.spacing // undefined

import { useTheme } from '@mui/material/styles';

const theme = useTheme();
theme.spacing // function

Tried to set up a minimal Code Sandbox, but it's crashing when I import the useTheme. :/

Hey @bmakan, may I ask you to open a separate issue about this?


have shaded artifacts attached

#185: shaded jars are attached and published with classifier 'shaded' and no longer replace the original jars

ok lets try. Next release will be the 2.0 and if that one breaks it I will be angry.

that actually worked, thanks a lot. I have a question, how can i prevent "core" to be published?(the people need to use at least library instead...)

Was a pleasure. As "core" is your parent pom the other modules depend upon, you need to deploy it too, I guess. It's the same for other open source projects, if you take a look .


Unable to import h20 on spyder

Problem Description
Tried importing h2o package after installing latest release of h2o from h2o.ai
What steps will reproduce the problem?
Install in Python
Run the following commands in a Terminal window to install H2O for Python.
Install dependencies (prepending with sudo if needed):
pip install requests
pip install tabulate
pip install "colorama>=0.3.8"
pip install future
Note: These are the dependencies required to run H2O. A complete list of dependencies is maintained in the following file: https://github.com/h2oai/h2o-3/blob/master/h2o-py/conda/h2o/meta.yaml.
Run the following command to remove any existing H2O module for Python.
pip uninstall h2o
Use pip to install this version of the H2O Python module.
pip install -f http://h2o-release.s3.amazonaws.com/h2o/latest_stable_Py.html h2o
Note: When installing H2O from pip in OS X El Capitan, users must include the --user flag. For example:
pip install -f http://h2o-release.s3.amazonaws.com/h2o/latest_stable_Py.html h2o --user
Optionally initialize H2O in Python and run a demo to see H2O at work.
python
import h2o
h2o.init()
h2o.demo("glm")
Package Versions

Spyder version: 3.2.8
Python version: 3.6.5
Qt version: 5.9.4
PyQt5 version: 5.9.2
Operating system: Windows 10

Dependencies
pyflakes >=0.6.0 :  1.6.0 (OK)
pycodestyle >=2.3:  2.4.0 (OK)
pygments >=2.0   :  2.2.0 (OK)
pandas >=0.13.1  :  0.23.0 (OK)
numpy >=1.7      :  1.14.3 (OK)
sphinx >=0.6.6   :  1.7.4 (OK)
rope >=0.9.4     :  0.10.7 (OK)
jedi >=0.9.0     :  0.12.0 (OK)
nbconvert >=4.0  :  5.3.1 (OK)
sympy >=0.7.3    :  1.1.1 (OK)
cython >=0.21    :  0.28.2 (OK)
qtconsole >=4.2.0:  4.3.1 (OK)
IPython >=4.0    :  6.4.0 (OK)
pylint >=0.25    :  1.8.4 (OK)

Well, the problem is clear: you need to install six, with pip install six.
If you have more problems of this kind, please read our guide to solve them:
https://github.com/spyder-ide/spyder/wiki/Working-with-packages-and-environments-in-Spyder
but please don't open more issues about this because these are not really Spyder problems.


WIP: lazy loading dependencies

@kobik According to https://github.com/PayU/openapi-validator-middleware/issues/116#issuecomment-653123276, this provides 40% startup time reduction when not using OpenAPI 3.0, so this seems to be clearly helping. Shall we merge it then?


Document namespace prefix when scanning a hosted cluster

When using hypershift and scanning a hosted cluster, the namespace of the hosted cluster needs to be defined as well.
The namespace where clusters are installed can vary, and should be set accordingly for th scans to work.

I have fixed a small typo and rephrased one sentence.
Changed from define the name and namespace to  specifying the name and namespace

/px-approved
/doc-approved
/qe-approved
Applying necessary labels since this documenting existing behavior. Adding @sheriff-rh for downstream documentation awareness.


ResolvePackageDependencies failure

From @cesarbs on May 18, 2017 17:18
Got this in VS Code with the latest pre-release version of the C# extension (1.10.0-beta3):
[fail]: OmniSharp.MSBuild.ProjectFile.ProjectFileInfo
        The "ResolvePackageDependencies" task failed unexpectedly.
This is an unhandled exception from a task -- PLEASE OPEN A BUG AGAINST THE TASK OWNER.
System.TypeLoadException: Could not resolve type with token 01000040
  at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.GetPackageAndFileDependencies (NuGet.ProjectModel.LockFileTarget target) [0x0011f] in <9445a2665fcc4f009bbfa9fcd34c78f9>:0
  at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.RaiseLockFileTargets () [0x000a6] in <9445a2665fcc4f009bbfa9fcd34c78f9>:0
  at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.ExecuteCore () [0x00006] in <9445a2665fcc4f009bbfa9fcd34c78f9>:0
  at Microsoft.NET.Build.Tasks.TaskBase.Execute () [0x00000] in <9445a2665fcc4f009bbfa9fcd34c78f9>:0
  at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute () [0x0002a] in <6a1392588f4a45bdbe07807130f9b3d0>:0
  at Microsoft.Build.BackEnd.TaskBuilder+<ExecuteInstantiatedTask>d__26.MoveNext () [0x002bf] in <6a1392588f4a45bdbe07807130f9b3d0>:0
[warn]: OmniSharp.MSBuild.MSBuildProjectSystem
        Failed to load project file '/Users/Cesar/src/aspnet/KestrelHttpServer/src/Microsoft.AspNetCore.Server.Kestrel.Core/Microsoft.AspNetCore.Server.Kestrel.Core.csproj'.
/Users/Cesar/src/aspnet/KestrelHttpServer/src/Microsoft.AspNetCore.Server.Kestrel.Core/Microsoft.AspNetCore.Server.Kestrel.Core.csproj

Happens on every project in Kestrel.
dotnet info:
$ dotnet --info
.NET Command Line Tools (2.0.0-preview2-006082)

Product Information:
 Version:            2.0.0-preview2-006082
 Commit SHA-1 hash:  6453cb4e15

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.12
 OS Platform: Darwin
 RID:         osx.10.12-x64
 Base Path:   /Users/Cesar/.dotnet/sdk/2.0.0-preview2-006082/

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0-preview2-25309-07
  Build    : 41f5fc94eedc889f086800c23f35bf14a8c75a9f

Copied from original issue: dotnet/sdk#1229

From @cesarbs on May 18, 2017 20:1
I forgot to add, this happened on macOS.

@cesarbs Does it only fail in VS Code or also when doing dotnet restore && dotnet build on the command line?
cc @DustinCampbell

From @DustinCampbell on May 18, 2017 23:21
I believe the issue is that OmniSharp is using NuGet.ProjectModel 4.0.0, but the latest SDK is using 4.3. I'm updating OmniSharp now.
FWIW, this can be moved to the C# for VS Code repo (https://github.com/OmniSharp/omnisharp-vscode).

I hope to have a new beta of C# for VS Code tomorrow that will hopefully address this problem.

Hmmm... I'm running into some problems here. @nguerrera: I'm starting to see signs that there are breaking API changes in the NuGet packages that the SDK is using. I'm digging further and will let you know what I find.

@nguerrera: It looks like the there's a major NuGet breaking change in the more recent bits that the SDK is using. NuGet.Packaging.Core no longer includes a reference to NuGet.Packaging.Core.Types. Instead, it looks like all of the types that were in NuGet.Packaging.Core.Types have been moved to NuGet.Packaging.Core. Do you know anything about this, or could you loop in somebody who does?

@emgarten

We had a world of hurt upgrading things in the sdk due to these changes.

I bet. I'm feeling it now. :smile:

FWIW, this is very tricky to fix without breaking project.json support.

Hey @nguerrera, do you know how VS deals with this problem? Essentially, the problem boils down to using MSBuild in-proc. So, the assemblies referenced by a task get to use the ones already loaded in proc.

I think our tasks are always loaded out of proc by CPS, but P2P from non CPS can cause problems, which we've hit before. I think we're only ok if VS also loads a compatible nuget in that case.

I'm tempted to il-merge our build task dependencies.

Actually, if asm versions are different nuget should load sxs in devenv. I think the past issues were build to build breaks with same asm version.

but what's a compatible NuGet? Any members in other packages that exposed types from NuGet.Packaging.Core.Types will now cause MissingMethodExceptions. The first one I hit is NuGet.ProjectModel.LockFileTargetLibrary.get_Dependencies because it returns an IList<PackageDependency>, which has moved. At the moment, I can get this to work for .NET Core SDK 1.0.0->2.0.0-preview1, or I can get it to work for .NET Core SDK 2.0.0-preview2.

Our tasks don't exchange nuget types with anything else. So it should be possible to load 4.0 and 4.3 sxs and not break us. I don't know if that's doable in your runtime environment, though.

MSBuild is doing the loading and we use it in-proc. I'm not sure how I'd do it sxs.

What runtime is this?

Mono

Does the same problem happen on Windows?

It may be that there's a hole in my MSBuild knowledge. Maybe there's a way to tell MSBuild to use AppDomains for any task? @rainersigwald?

Does the same problem happen on Windows?

My Windows machine isn't quite clean enough to verify. We have code in OmniSharp that tells it to just use MSBuild from VS 2017 if it's there. Give me a few minutes to remove that and try.

I've been unsuccessful getting the issue to repro on Windows so far :smile:

other than in tests

Can you see in the debugger if both versions are successfully loaded SxS on Windows, but not on Mono?

honestly, I wouldn't even know how to debug that on Mono :smile:
I'm not confident I've got things right on Windows at the moment. Tests are failing.

I don't think there's a way to force MSBuild to use AppDomain isolation--it has to be opted in in code (task derives from AppDomainIsolatedTask or process isolation must be opted into with a UsingTask.
@radical might have thoughts about Mono behaviors here.

that's what I thought @rainersigwald, just wanted to be sure there wasn't something awesome I was missing. :smile:

Why do you think AppDomains are required? Assemblies can be SxS loaded in same domain and that is what I'd expect to happen if a Task has a newer version sitting next to it on full fx.

I don't think AppDomains are necessarily required. I was just curious if MSBuild had any special magic to isolate things.

Assemblies can be SxS loaded in same domain and that is what I'd expect to happen if a Task has a newer version sitting next to it on full fx

@nguerrera: I would expect that too, but I'm not seeing it happen on Mono. I wonder if that's a side-effect of using an embedded Mono runtime and setting MONO_PATH specifically. Perhaps when MSBuild does an Assembly.LoadFrom(...) on the task, it doesn't look next to the task for its dependencies because MONO_PATH is set?

NuGet merged several assemblies in 4.3.0 as mentioned earlier.
It sounds like this may be related to https://github.com/dotnet/cli/issues/4214
MSBuild favors the nuget assemblies in the msbuild folder.

If you run with MONO_LOG_LEVEL=debug MONO_LOG_MASK=asm then you should see messages about mono searching for assemblies, adding to domains or failing to do etc.

@emgarten: Isn't that a semver breaking change?

@DustinCampbell It is. And if it were v5, you'd still be in the same world of hurt, which is what I keep telling semver fanboys.

yeah, yeah. :smile:

😆 yes
I'm all for SemVer but it would be like @nguerrera said, plus every NuGet assembly would have a different major version and none of it would align with the CLI or VS.

Or your could, you know, stop making breaking changes every release.

Mono: Assembly Loader probing location: '/usr/local/share/dotnet/sdk/2.0.0-preview2-006080/Sdks/Microsoft.NET.Sdk/build/../tools/net46/Microsoft.NET.Build.Tasks.dll'.
Mono: Image addref Microsoft.NET.Build.Tasks[0x7e6bab30] -> /usr/local/share/dotnet/sdk/2.0.0-preview2-006080/Sdks/Microsoft.NET.Sdk/tools/net46/Microsoft.NET.Build.Tasks.dll[0x7f7f5c00]: 2
Mono: Prepared to set up assembly 'Microsoft.NET.Build.Tasks' (/usr/local/share/dotnet/sdk/2.0.0-preview2-006080/Sdks/Microsoft.NET.Sdk/tools/net46/Microsoft.NET.Build.Tasks.dll)
Mono: Assembly Microsoft.NET.Build.Tasks[0x7e6bab30] added to domain OmniSharp.exe, ref_count=1
Mono: Assembly Loader loaded assembly from location: '/usr/local/share/dotnet/sdk/2.0.0-preview2-006080/Sdks/Microsoft.NET.Sdk/build/../tools/net46/Microsoft.NET.Build.Tasks.dll'.
Mono: Assembly Ref addref Microsoft.NET.Build.Tasks[0x7e6bab30] -> Microsoft.Build.Utilities.Core[0x7e237ba0]: 2
Mono: Assembly Ref addref Microsoft.Build.Utilities.Core[0x7e237ba0] -> Microsoft.Build.Framework[0x7be6b360]: 4
Mono: Assembly Ref addref Microsoft.NET.Build.Tasks[0x7e6bab30] -> mscorlib[0x7a76f910]: 68
Mono: Assembly Ref addref Microsoft.NET.Build.Tasks[0x7e6bab30] -> System.Core[0x7b98d0b0]: 24
Mono: Assembly Loader probing location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.ProjectModel.dll'.
Mono: Image addref NuGet.ProjectModel[0x7e5bb490] -> /Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.ProjectModel.dll[0x7addd800]: 2
Mono: Prepared to set up assembly 'NuGet.ProjectModel' (/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.ProjectModel.dll)
Mono: Assembly NuGet.ProjectModel[0x7e5bb490] added to domain OmniSharp.exe, ref_count=1
Mono: Assembly Loader loaded assembly from location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.ProjectModel.dll'.
Mono: Assembly Ref addref Microsoft.NET.Build.Tasks[0x7e6bab30] -> NuGet.ProjectModel[0x7e5bb490]: 2
Mono: Assembly Ref addref NuGet.ProjectModel[0x7e5bb490] -> mscorlib[0x7a76f910]: 69
Mono: Assembly Ref addref Microsoft.NET.Build.Tasks[0x7e6bab30] -> Microsoft.Build.Framework[0x7be6b360]: 5
Mono: Assembly Ref addref NuGet.ProjectModel[0x7e5bb490] -> NuGet.Frameworks[0x7e254610]: 4
Mono: Assembly Loader probing location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Common.dll'.
Mono: Image addref NuGet.Common[0x7e5c12a0] -> /Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Common.dll[0x7adfc200]: 2
Mono: Prepared to set up assembly 'NuGet.Common' (/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Common.dll)
Mono: Assembly NuGet.Common[0x7e5c12a0] added to domain OmniSharp.exe, ref_count=1
Mono: Assembly Loader loaded assembly from location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Common.dll'.
Mono: Assembly Ref addref Microsoft.NET.Build.Tasks[0x7e6bab30] -> NuGet.Common[0x7e5c12a0]: 2
Mono: Assembly Ref addref NuGet.Common[0x7e5c12a0] -> mscorlib[0x7a76f910]: 70
Mono: Assembly Ref addref NuGet.ProjectModel[0x7e5bb490] -> NuGet.Common[0x7e5c12a0]: 3
Mono: Assembly Ref addref NuGet.Frameworks[0x7e254610] -> System[0x7b97e680]: 24
Mono: Assembly Ref addref NuGet.ProjectModel[0x7e5bb490] -> Newtonsoft.Json[0x7a727960]: 5
Mono: Assembly Ref addref NuGet.ProjectModel[0x7e5bb490] -> System[0x7b97e680]: 25
Mono: Assembly Ref addref NuGet.ProjectModel[0x7e5bb490] -> NuGet.Versioning[0x7e25b2a0]: 4
Mono: Assembly Loader probing location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Packaging.Core.Types.dll'.
Mono: Image addref NuGet.Packaging.Core.Types[0x7e2120e0] -> /Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Packaging.Core.Types.dll[0x7b660800]: 2
Mono: Prepared to set up assembly 'NuGet.Packaging.Core.Types' (/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Packaging.Core.Types.dll)
Mono: Assembly NuGet.Packaging.Core.Types[0x7e2120e0] added to domain OmniSharp.exe, ref_count=1
Mono: Assembly Loader loaded assembly from location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Packaging.Core.Types.dll'.
Mono: Assembly Ref addref NuGet.ProjectModel[0x7e5bb490] -> NuGet.Packaging.Core.Types[0x7e2120e0]: 2
Mono: Assembly Ref addref NuGet.Packaging.Core.Types[0x7e2120e0] -> mscorlib[0x7a76f910]: 71
Mono: Assembly Ref addref NuGet.ProjectModel[0x7e5bb490] -> System.Core[0x7b98d0b0]: 25
Mono: Assembly Ref addref NuGet.Frameworks[0x7e254610] -> System.Core[0x7b98d0b0]: 26
Mono: Assembly Ref addref NuGet.Packaging.Core.Types[0x7e2120e0] -> NuGet.Versioning[0x7e25b2a0]: 5
Mono: Assembly Loader probing location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.LibraryModel.dll'.
Mono: Image addref NuGet.LibraryModel[0x7e6c89a0] -> /Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.LibraryModel.dll[0x7f1f3a00]: 2
Mono: Prepared to set up assembly 'NuGet.LibraryModel' (/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.LibraryModel.dll)
Mono: Assembly NuGet.LibraryModel[0x7e6c89a0] added to domain OmniSharp.exe, ref_count=1
Mono: Assembly Loader loaded assembly from location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.LibraryModel.dll'.
Mono: Assembly Ref addref NuGet.ProjectModel[0x7e5bb490] -> NuGet.LibraryModel[0x7e6c89a0]: 2
Mono: Assembly Ref addref NuGet.LibraryModel[0x7e6c89a0] -> mscorlib[0x7a76f910]: 72
Mono: Assembly Loader probing location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.RuntimeModel.dll'.
Mono: Image addref NuGet.RuntimeModel[0x7e20b6d0] -> /Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.RuntimeModel.dll[0x7b669a00]: 2
Mono: Prepared to set up assembly 'NuGet.RuntimeModel' (/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.RuntimeModel.dll)
Mono: Assembly NuGet.RuntimeModel[0x7e20b6d0] added to domain OmniSharp.exe, ref_count=1
Mono: Assembly Loader loaded assembly from location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.RuntimeModel.dll'.
Mono: Assembly Ref addref NuGet.ProjectModel[0x7e5bb490] -> NuGet.RuntimeModel[0x7e20b6d0]: 2
Mono: Assembly Ref addref NuGet.RuntimeModel[0x7e20b6d0] -> mscorlib[0x7a76f910]: 73
Mono: Assembly Ref addref NuGet.RuntimeModel[0x7e20b6d0] -> Newtonsoft.Json[0x7a727960]: 6
Mono: Assembly Loader probing location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Configuration.dll'.
Mono: Image addref NuGet.Configuration[0x7e2094a0] -> /Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Configuration.dll[0x7b60b200]: 2
Mono: Prepared to set up assembly 'NuGet.Configuration' (/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Configuration.dll)
Mono: Assembly NuGet.Configuration[0x7e2094a0] added to domain OmniSharp.exe, ref_count=1
Mono: Assembly Loader loaded assembly from location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Configuration.dll'.
Mono: Assembly Ref addref NuGet.ProjectModel[0x7e5bb490] -> NuGet.Configuration[0x7e2094a0]: 2
Mono: Assembly Ref addref NuGet.Configuration[0x7e2094a0] -> mscorlib[0x7a76f910]: 74
Mono: Assembly Loader probing location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Packaging.Core.dll'.
Mono: Image addref NuGet.Packaging.Core[0x7e208980] -> /Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Packaging.Core.dll[0x7b685c00]: 2
Mono: Prepared to set up assembly 'NuGet.Packaging.Core' (/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Packaging.Core.dll)
Mono: Assembly NuGet.Packaging.Core[0x7e208980] added to domain OmniSharp.exe, ref_count=1
Mono: Assembly Loader loaded assembly from location: '/Users/dustincampbell/.vscode/extensions/ms-vscode.csharp-1.10.0-beta4/bin/omnisharp/NuGet.Packaging.Core.dll'.
Mono: Assembly Ref addref NuGet.ProjectModel[0x7e5bb490] -> NuGet.Packaging.Core[0x7e208980]: 2
Mono: Assembly Ref addref NuGet.Packaging.Core[0x7e208980] -> mscorlib[0x7a76f910]: 75
Mono: Assembly Ref addref NuGet.RuntimeModel[0x7e20b6d0] -> System.Core[0x7b98d0b0]: 27
Mono: Assembly Ref addref NuGet.RuntimeModel[0x7e20b6d0] -> NuGet.Frameworks[0x7e254610]: 5
Mono: Assembly Ref addref NuGet.LibraryModel[0x7e6c89a0] -> System.Core[0x7b98d0b0]: 28
Mono: Assembly Ref addref NuGet.LibraryModel[0x7e6c89a0] -> NuGet.Versioning[0x7e25b2a0]: 6
Mono: Assembly Ref addref Microsoft.NET.Build.Tasks[0x7e6bab30] -> NuGet.Frameworks[0x7e254610]: 6
Mono: Assembly Ref addref Microsoft.NET.Build.Tasks[0x7e6bab30] -> NuGet.Versioning[0x7e25b2a0]: 7
Mono: Assembly Ref addref Microsoft.NET.Build.Tasks[0x7e6bab30] -> NuGet.Packaging.Core[0x7e208980]: 3
[fail]: OmniSharp.MSBuild.ProjectFile.ProjectFileInfo
        The "ResolvePackageDependencies" task failed unexpectedly.
This is an unhandled exception from a task -- PLEASE OPEN A BUG AGAINST THE TASK OWNER.
System.TypeLoadException: Could not resolve type with token 01000040
  at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.GetPackageAndFileDependencies (NuGet.ProjectModel.LockFileTarget target) [0x0011f] in <9445a2665fcc4f009bbfa9fcd34c78f9>:0
  at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.RaiseLockFileTargets () [0x000a6] in <9445a2665fcc4f009bbfa9fcd34c78f9>:0
  at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.ExecuteCore () [0x00006] in <9445a2665fcc4f009bbfa9fcd34c78f9>:0
  at Microsoft.NET.Build.Tasks.TaskBase.Execute () [0x00000] in <9445a2665fcc4f009bbfa9fcd34c78f9>:0
  at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute () [0x0002a] in <bdf083ca20c84af487947992fd9a4a29>:0
  at Microsoft.Build.BackEnd.TaskBuilder+<ExecuteInstantiatedTask>d__26.MoveNext () [0x002bf] in <bdf083ca20c84af487947992fd9a4a29>:0

Mono's clearly preferring them in the application folder as I expected. My gut is that this is because MONO_PATH is specifically set. @radical, do you have any ideas?

FWIW, I see the same problem when I use a machine-wide mono rather than the embedded one. It does not seem like Mono wants to load different assemblies SxS. Note that these are technically the same versions. Both are 4.3.0 since the NuGet breaking change was made without changing assembly versions (shakes fist at @emgarten).

OK @nguerrera: I can verify that it does work on Windows. At least, I can see the libraries double-loaded correctly:

I'm surprised if it worked on Windows if both sets have same assembly version. LoadFrom doesn't work like that.

In the above case, it didn't. This is a build of OmniSharp where I've referenced the 4.3 NuGet versions. Note that the project I opened was using SDK 1.0.4.

(This isn't confusing at all)

right.

And I can prove that doesn't work by trying a project created with .NET Core SDK 2.0.0-preview1.

And of course, it fails:
[info]: OmniSharp.MSBuild.MSBuildProjectSystem
        Loading project: c:\Projects\test-2.0.0-preview1-005952\test-2.0.0-preview1-005952.csproj
[dbug]: OmniSharp.MSBuild.ProjectFile.ProjectFileInfo
        Using MSBuildSDKsPath: C:\Program Files\dotnet\sdk\2.0.0-preview1-005952\Sdks
[fail]: OmniSharp.MSBuild.ProjectFile.ProjectFileInfo
        The "ResolvePackageDependencies" task failed unexpectedly.
System.MissingMethodException: Method not found: 'System.Collections.Generic.IList`1<NuGet.Packaging.Core.PackageDependency> NuGet.ProjectModel.LockFileTargetLibrary.get_Dependencies()'.
   at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.GetPackageDependencies(LockFileTargetLibrary package, String targetName, Dictionary`2 resolvedPackageVersions, HashSet`1 transitiveProjectRefs)
   at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.GetPackageAndFileDependencies(LockFileTarget target)
   at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.RaiseLockFileTargets()
   at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.ExecuteCore()
   at Microsoft.NET.Build.Tasks.TaskBase.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()

Essentially, I can either support .NET Core 2.0.0-preview1 or .NET Core 2.0.0-preview2, but not both.

It seems like the cheapest thing I could do is just go back to shipping the SDKs with OmniSharp and not trying to resolve them at all.

@emgarten can you bump the nuget version? Then preview 2 can take that and preview 1 can keep 4.3. Then there'd only be interim preview 2 builds that are broken.

At one point nuget tried bumping every build, and that causes problems of its own. Moving forward, should only bump on breaking changes. But also, seriously, ease off the pace at which those happen.

@DustinCampbell that might be OK as an interim fix, but ultimately you should resolve as VS does

@nguerrera: I have no idea how that works. Remember that I'm not using MSBuild as VS does.

Incrementing the version number is good, but that'd only address Windows. It sounds like there's another issue in that Mono turns off SxS assembly loading if MONO_PATH is set (which makes sense). Since we want to have a VS Code experience where installing Mono isn't a prerequisite, that means I'd still want to ship the SDKs for running on OSX/Linux.

@nguerrera: Once there's a blessed SDK resolver that is packaged so that the community can use it, I'm on board. :smile:

Sounds fine. Let's get that on the books.

I'm not sure how it would solve the assembly resolution issue though.

It would not. So we need a versioning scheme for nuget that works. I don't want to punt on this issue because you're not resolving only to have it crop up when you do resolve again. It's important to me that we have a consistent SDK resolution story across VS, VS for Mac, and VS Code.

And we probably need to figure out the Mono SxS solution too. Basically fixing that would be a pre-req for moving to resolver.

Totally agree.
The Mono issue is likely because we're deploying our own Mono runtime to be self-contained. In order to make that work, MONO_PATH is set to the OmniSharp install folder and a folder of framework assemblies (also copied from Mono). It's definitely not a supported scenario.

@nguerrera: I just chatted with @marek-safar and he let me know about the upcoming mono --assembly-loader flag, which may be what I want to get the same assembly loading behavior on Mono as the .NET Framework. It's in Mono alpha channel builds now.

@emgarten, @nguerrera: I just tried VS 2017 with a .NET Core 2.0-preview2 drop and it looks like the same NuGet breaking change is breaking live unit testing as well. Here's the live unit testing output:
09:40:45.255 Verbose] - BuildManager - C:\Program Files\dotnet\sdk\2.0.0-preview2-006098\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(155,5): error MSB4018: The "ResolvePackageDependencies" task failed unexpectedly.
System.MissingMethodException: Method not found: 'System.Collections.Generic.IList`1<NuGet.Packaging.Core.PackageDependency> NuGet.ProjectModel.LockFileTargetLibrary.get_Dependencies()'.
   at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.GetPackageDependencies(LockFileTargetLibrary package, String targetName, Dictionary`2 resolvedPackageVersions, HashSet`1 transitiveProjectRefs)
   at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.GetPackageAndFileDependencies(LockFileTarget target)
   at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.RaiseLockFileTargets()
   at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.ExecuteCore()
   at Microsoft.NET.Build.Tasks.TaskBase.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
[09:40:45.286 Verbose] - BuildManager - C:\Program Files\dotnet\sdk\2.0.0-preview2-006098\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.targets(94,5): error MSB4018: The "GenerateDepsFile" task failed unexpectedly.
System.TypeLoadException: Could not load type 'NuGet.Packaging.Core.PackageIdentity' from assembly 'NuGet.Packaging.Core, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
   at Microsoft.NET.Build.Tasks.GenerateDepsFile.ExecuteCore()
   at Microsoft.NET.Build.Tasks.TaskBase.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
[09:40:45.286 Verbose] - BuildManager - Building project ifvm.core.tests.
[09:40:45.380 Info] - BuildManager - Build completed (failed).
[09:40:45.380 Verbose] - BuildManager - Interrupting build queue -> no new assemblies.
[09:40:45.380 Verbose] - BuildManager - Interrupting build queue -> no new assemblies.

Are we sure this change is a good idea? :smile: cc @tannergooding

And hopefully, this will go away if NuGet increments its assembly version.

Is LUT doing builds in proc in devenv?

No idea. I'm sending email on the issue now to make sure we get it fixed.

@nguerrera: Logically, I would expect to be doing magical builds in-proc since it needs to work on modified, unsaved files in VS.

And hopefully, this will go away if NuGet increments its assembly version.

Hoping this also, it would be the easiest fix for NuGet here.

Tried the beta 4, seems to work ok with .net core 2 preview 1.
thanks!

Guys, did this got fixed? I'm getting the same error...
Here is my dotnet --info:
.NET Command Line Tools (2.0.0-preview2-006127)

Product Information:
 Version:            2.0.0-preview2-006127
 Commit SHA-1 hash:  946ea7980a

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.12
 OS Platform: Darwin
 RID:         osx.10.12-x64
 Base Path:   /usr/local/share/dotnet/sdk/2.0.0-preview2-006127/

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0-preview2-25319-02
  Build    : 7983b575ebcbdc3a825eea4b141ff7fb69d25f9d

I tried VSCode insiders build but no lucky...

Preview 2 is NOT supported AFAIK
On Fri, May 26, 2017, 5:06 PM Gutemberg Ribeiro<EMAIL_ADDRESS>wrote:

Guys, did this got fixed? I'm getting the same error...
Here is my dotnet --info:
.NET Command Line Tools (2.0.0-preview2-006127)
Product Information:
Version:            2.0.0-preview2-006127
Commit SHA-1 hash:  946ea7980a
Runtime Environment:
OS Name:     Mac OS X
OS Version:  10.12
OS Platform: Darwin
RID:         osx.10.12-x64
Base Path:   /usr/local/share/dotnet/sdk/2.0.0-preview2-006127/
Microsoft .NET Core Shared Framework Host
Version  : 2.0.0-preview2-25319-02
Build    : 7983b575ebcbdc3a825eea4b141ff7fb69d25f9d
I tried VSCode insiders build but no lucky...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/OmniSharp/omnisharp-vscode/issues/1495#issuecomment-304397869,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADyryY37WOmRzEePER3TFbyzBrYxIh_6ks5r90z1gaJpZM4Nf6Hd
.

We need Preview 2 supportttt :(

Preview 2 builds are not yet supported. These are still bleeding edge nightly builds which need work to properly support. I plan on looking at this in the coming week.

A light in the end of the tunnel!
Thanks Dustin! :)

JFYI to those watching that I've gotten a super-hot Mono runtime that demonstrates .NET Core 2.0-preview2 builds working on OSX. A new Mono runtime is needed that adds an --assembly-loader=script flag to replicate desktop CLR SxS assembly loading behavior.

We need Preview 2 support on Windows ttt :(

We need Preview 2 support on Windows ttt :(

PowerShell needs Preview 2 support on Windows, OSX and Linux for our development need.

Support will come folks. 😀 When it's fixed, it'll be fixed for all OSs. I was just giving a bit of status since OSX and Linux require more effort.
@daxian-dbw: I'm not sure how getting C# for VS Code working with the latest nightly .NET Core SDK 2.0-preview2 builds help PoweShell. Could you clarify?

@DustinCampbell we want to move to the latest 2.0.0-preview2 .NET Core packages to get some fixes from CoreFx, but then we cannot use VS Code C# for the development because it will fail to load the projects with this error:
[fail]: OmniSharp.MSBuild.ProjectFile.ProjectFileInfo
        The version of Microsoft.NET.Sdk used by this project is insufficient to support this package.  Please ensure you are using the .NET Core SDK 2.0 or higher, which is included in Visual Studio 2017 Update 15.3.  This error may be suppressed by setting PackagingToolsInsufficientSDKVersion=false.

Therefore, we cannot move to latest .NET Core 2.0-preview2 packages until this issue is resolved.

@daxian-dbw: Note that the failure there is different than the failure reported in this thread.

Ah, yes, that error was what I got when using .NET Core SDK 2.0.0-preview1-005952 with 2.0.0-preview2-25402-02 netcoreapp2.0 runtime framework version. Then I switch to .NET Core SDK 2.0.0-preview2-006195 and got the following error when loading the projects in VS Code:
[fail]: OmniSharp.MSBuild.ProjectFile.ProjectFileInfo
        The "ResolvePackageDependencies" task failed unexpectedly.
System.MissingMethodException: Method not found: 'System.Collections.Generic.IList`1<NuGet.Packaging.Core.PackageDependency> NuGet.ProjectModel.LockFileTargetLibrary.get_Dependencies()'.
   at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.GetPackageDependencies(LockFileTargetLibrary package, String targetName, Dictionary`2 resolvedPackageVersions, HashSet`1 transitiveProjectRefs)
   at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.GetPackageAndFileDependencies(LockFileTarget target)
   at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.RaiseLockFileTargets()
   at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.ExecuteCore()
   at Microsoft.NET.Build.Tasks.TaskBase.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
[warn]: OmniSharp.MSBuild.MSBuildProjectSystem
        Failed to load project file 'd:\PowerShell\src\System.Management.Automation\System.Management.Automation.csproj'.
d:\PowerShell\src\System.Management.Automation\System.Management.Automation.csproj

Got it. I'm going to try to get a beta released today that at least fixes this for Windows. I'm still awaiting the latest Mono bits from Xamarin to address OSX/Linux.

OK. v1.11.0-beta2 is released. Follow the steps at Installing Beta Releases to get it.

Note that this only works for Windows until I get those Mono bits.

@DustinCampbell Any updates?

The latest beta fixes the problem on Windows. For OSX/Linux, the new Mono bits dropped on the alpha channel a little while ago and I'll be taking them soon. Once that happens, I'll push another beta that enables OSX/Linux.

I've just pushed the v1.11.0-beta3 release which includes updated Mono 5.2 bits from the alpha channel. This should fix .NET Core 2.0 support on OSX/Linux. Please try the beta out! You can download it from v1.11.0-beta3. Follow the instructions in Installing Beta Releases to install.

Thanks @DustinCampbell! Any idea when the v1.11.0 release will be made public?

Not for awhile yet. Note that we don't necessarily want to officially ship this until the bits it's using are more officially released. After all, the .NET Core 2.0-preview2 bits aren't official yet either.

Just checking that with this new beta extension running on macOS, is it expected that I would not get Intellisense or document formatting? If I should be seeing those ...any hints as to what I'm doing wrong? :)

Unfortunately, we discovered an issue just today that breaks .NET Core 2.0-preview2 support in C# for VS Code on OSX/Linux. The most recent .NET Core SDK has some changes that exasperate an issue in the Mono runtime. A PR is out for the Mono issue, so this will come soon. However, for now VS Code won't work for the very latest, super-hot builds on OSX/Linux.

okey doke. And for my purposes, it's sufficient. Though I keep surprising myself when things build. :) Thanks!

Sorry for the delay on this @julielerman!

no apology needed. I'm just exploring for now. Not stressing over production code.

p.s. I'll try it out in windows

Download leatest Mono 5.2 alpha, delete current C# plugin in vs code (reload vs), download leatest C# plugin (from this repo) which is in beta and install it manually in vs code with .vsix file that you downloaded

@harisbotic: you don't need to download Mono 5.2. C# for VS Code includes a local Mono 5.2. As I mentioned earlier, the very latest .NET Core 2.0-preview2 SDK doesn't work due to some recent changes in the SDK that collides with a but in Mono 5.2.

@julielerman: You can track https://github.com/OmniSharp/omnisharp-vscode/issues/1566 to track OSX/Linux support on the very latest .NET Core 2.0 Preview 2 builds. If you're curious, there are specific details about what is actually broken.

Thanks. In the meantime, things seem to be working well in windows VS Code. :)

Yup. The difference here is that we run on OmniSharp on the desktop CLR on Windows and a local Mono runtime on OSX/Linux. I'm tracking one last bug on the Mono runtime that should fix this problem.

FYI: I just put up a new beta release of C# for VS Code that actually fixes this issue on OSX/Linux. :smile:

Lets hope next build of CLR don't break it again, ehhehehe :P

Lets hope next build of CLR don't break it again, ehhehehe :P

I'm not sure what you mean. The CLR hasn't been an issue in this thread.

@DustinCampbell It happened with very last netcore 2.0 bits and that include the SDK, CLR, right? I meant that we are not sure if a new build of  netcore would not break again, just like in this issue. But in all cases, good work :) thanks for get it back working for us :)

thanks. The simple things I was missing like formatting an intellisense an help to do things like "hey you need a ref to this assembly" are all working again as expected! :)

@galvesribeiro: C# for VS Code doesn't run OmniSharp on .NET Core. On Windows, it runs on the desktop CLR that's already installed. On OSX/Linux, it runs on a local Mono that C# for VS Code installs.
There were three problems that sort of cascaded into a perfect storm of fail. :smile:

NuGet made API breaking changes without updating their assembly version numbers. When those changes were deployed with the .NET Core SDK, many things broke, such as C# for VS Code and Live Unit Testing in Visual Studio 2017. This has been fixed and included in newer .NET Core SDK builds.
On OSX/Linux, we needed to deploy a new Mono runtime with a new "strict assembly loader" feature to ensure that assemblies with different versions can be loaded side-by-side (just like they are on the CLR on Windows). This was necessary because of the NuGet changes above. OmniSharp itself deploys <IP_ADDRESS> versions of some NuGet assemblies and the latest .NET Core SDK deploys newer versions. Since these two versions have different API surface area, they collided badly.
There was a bug in the "strict assembly loader" feature on Mono that I discovered yesterday. There are more details on that issue in https://github.com/OmniSharp/omnisharp-vscode/issues/1566.

Now, we're in a much better place for not getting broken in the future.

thanks. The simple things I was missing like formatting an intellisense an help to do things like "hey you need a ref to this assembly" are all working again as expected! :)

Excellent! I'll expect a hug and a beer when I see you next. :grin:

Yay! Good news @DustinCampbell! Thanks for the clarification.


operator: generalize revision controller to be independent of static pods

/hold
until proven it fits into openshift-apiserver.

/hold cancel

/lgtm


Prepare Francisco-Gamino/dev-test5 branch for VNext: Clear notes, update version to 4.1037.100

Issue describing the changes in this PR
This PR contains the following changes:

Update version to 4.1037.100
Clear release notes

Pull request checklist
IMPORTANT: Currently, changes must be backported to the in-proc branch to be included in Core Tools and non-Flex deployments.

[x] Backporting to the in-proc branch is not required

Otherwise: Link to backporting PR

[x] My changes do not require documentation changes

[ ] Otherwise: Documentation issue linked to PR

[x] My changes should not be added to the release notes for the next release

[ ] Otherwise: I've added my notes to
elease_notes.md

[x] My changes do not need to be backported to a previous version

[ ] Otherwise: Backport tracked by issue/PR #issue_or_pr

[x] My changes do not require diagnostic events changes

Otherwise: I have added/updated all related diagnostic events and their documentation (Documentation issue linked to PR)

[ ] I have added all required tests (Unit tests, E2E tests)

Additional information
Additional PR information

Closing test PR for Host repo.


Add file icon next to the file title in the frame

Hi,
I was wondering if it's possible to add a file icon to the left of the file title in the frame? Here's an example to illustrate the request:

Something like this in .md or .mdx files:
```astro title="index.astro" icon="/icons/astro.svg"
---
import SomeAstroComponent from '../components/SomeAstroComponent.astro';

const { title } = Astro.props;
const data = await fetch('SOME_SECRET_API_URL/users').then(r => r.json());
---
<!-- Your template here! -->

Thanks in advance

I just found out about expressive-code so I really don't know how to even begin implementing it. I'm curious too.
But one workaround that comes to mind is that expressive-code seems to set the language into the pre elements data-language attribute so at least one could achieve something like that via CSS. But of course that would be a bit hacky, and a native or plugin based solution would be more robust.

Hello! I think this would be easy to do once we have a reliable source of SVG icons for all common file types.
Do you know any libraries that would fit this description? I know I looked earlier this year but couldn't find any.

@hippotastic There is Material Icon Theme for VSCode, which supports a wide range of icons and is very stable. Does that work for you?

So far I've used combinations of various icon sets from https://icon-sets.iconify.design/
Material Icon Theme for VS Code is probably the safest bet, but no matter what the choice, I think in the end it would be good to expose some configuration model for user-defined overrides.

Thank you for your replies and icon set links, much appreciated!
I'm always trying to keep the amount of meta information users need to add to their code blocks to a minimum by default, so my first thought when I read the feature request was that the plugin could try to automatically determine an icon based on the language and/or file extension (if provided). This would prevent users from having to repeat the same icon="..." for every code block.
To also allow adding icons to files that have no recognized language & extension, or when a manual override is desired, I could imagine using an icon meta prop as you outlined.
Would that solve your use case?


Is it compatible with 0.60.X?

I want to use this package for my app. Is it compatible with 0.60.x versions?

We are fixing the migration #361
If you can help us testing compatibility, we will thank you very much

Is the issue fixed??
I was unable to get this working on 0.60.4 version.

Not working yet?

Some way it worked for me. Versions:
"react": "16.8.6",
"react-native": "0.60.4",
"react-native-sqlite-storage": "^3.3.11"
Just install the package but I had to omit 4 part of the guide, in MainAplication.java:
"   new SQLitePluginPackage(),   // register SQLite Plugin here"
or how it is now:
packages.add(new SQLitePluginPackage());
Just dont add it  (it'll create a duplicate)  and it'll work

I did forked this repo and make changes to work with react-native 0.60.x (I've tested with 0.60.4)
This repo works with autolink, you don't need to do manual setup on Android.
https://github.com/carlosroberto555/react-native-sqlite-storage
I didn't tested with iOS yet, but if anybody can test it will be very helpfull.
You can install with:
yarn add carlosroberto555/react-native-sqlite-storage#enable_autolink

I tested this repo with iOS today, and seems work fine with none issue for me.
With this configuration 0.60.x autolink works like a charm for Android and iOS.
And for previous react-native versions isn't necessary Android manual configuration (only react-native link react-native-sqlite-storage)

4.0.0 wit RN 0.60 compatibility fix released.


enh(scraper): sort by project name

before:

after:

sure, I'll look into it!

sure, could you help me set this project in my repo? wanna make sure if the code successfully sorts the categories before sending a pull request

If you want to make the change you should modify the code on your repo and I will wait for your pull request.


fix(arm): use correct type casting for ints in azure scan

The wrong type was used when converting the value to int.
See https://github.com/aquasecurity/trivy/issues/4792
Example to reproduce the problem:
{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "<IP_ADDRESS>",
    "apiProfile": "2019-03-01-hybrid",
    "parameters": {},
    "variables": {},
    "functions": [],
    "resources": [
        {
            "name": "flowlogs/sample",
            "type": "Microsoft.Network/networkWatchers/flowLogs",
            "apiVersion": "2020-11-01",
            "location": "location",
            "tags": {},
            "properties": {
                "targetResourceId": "targetResourceId",
                "storageId": "storageId",
                "enabled": true,
                "retentionPolicy": {
                    "days": 2
                },
                "format": {
                    "type": "JSON"
                }
            }
        }
    ],
    "outputs": {}
}

nice, could you add a test for it?


Add event bus

Use an event bus instead of redux to communicate about events in the application.

Pull Request Test Coverage Report for Build 606290293

26 of 26 (100.0%)  changed or added relevant lines in 7 files are covered.
5 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.6%) to 83.075%

Files with Coverage Reduction
New Missed Lines
%

src/App/Statistics/StatisticsContext.tsx
1
95.74%

src/App/Statistics/index.tsx
2
74.0%

src/App/Transactions/TransactionsContext.tsx
2
83.87%

Totals

Change from base Build 605824745:
-0.6%

Covered Lines:
829

Relevant Lines:
939

💛  - Coveralls


CORE-5533 - minimum config value setting not being adhered to when config change is input

Description:
The issue here: CORE-5533 seemed like the minimum setting of 1000 milliseconds for maxRetryDelay was not being used as 999 milliseconds was accepted.
However, looking at the query that was tested actually the issue appeared to be that the maxRetryDelay was not queried within the processing object it was defined in. As a result of this the maxRetryDelay was actually being set and accepted as an additional property.
The fix here was to prevent additional properties from being accepted. This was done by adding additionalProperties: false to: properties object, event object, session object, processing object.
The issue raised was replicated and then the solution tested using manual testing. Curl command and response below.
Testing:
curl -X 'PUT' \
  -u "admin:admin" \
  -k 'https://localhost:8888/api/v1/config' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
  "request": {
    "config": "{ \"maxRetryDelay\": 999 }",
    "schemaVersion": {
      "major": 1,
      "minor": 0
    },
    "section": "corda.flow",
    "version": 0
    }
  }'

Response:
{
    "title": "Configuration \"{ \"maxRetryDelay\": 999 }\" could not be validated. Valid JSON or HOCON expected. Cause: Configuration failed to validate for key corda.flow at schema version null: $.maxRetryDelay: is not defined in the schema and the schema does not allow additional properties",
    "status": 400,
    "details": {}
}%

LGTM, pending 🟢 build

So I've looked into the failed gate here with Ronan. CorDapp-downstream-compatibility-checks  is a new non blocking PR gate added yesterday. Ronan is going to send comms on the new gate soon but in the meantime on this PR it seems here for some reason, a downstream job has not passed all the needed arguments to gradle when running. Ronan said either way it's build/infra related so fine to merge.


Curseforge Release

Hello, saw your mod on modrinth. can you add it to curseforge so I can add to my modpack? Thanks

The mod has been approved on curseforge! https://www.curseforge.com/minecraft/mc-mods/polaroid-camera


Updating Pop description with projects

Description
the pop up is not matching project titles
Steps to Reproduce
not updating projects.html concurrently
Expected Behavior
No response
Actual Behavior
No response
Screenshots
https://github.com/user-attachments/assets/988e0cb9-503b-4bfc-8c2c-47d4ee3495a0
Additional Information
No response
What browser are you seeing the problem on?

[X] Firefox
[X] Chrome
[X] Safari
[X] Microsoft Edge

Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I want to work on this issue. (optional)

@DarshAgrawal14 what's your solution on this
Please tell it.
So that I can check and assign you.

@DarshAgrawal14 assigning this issue to you.
Make sure to complete this.

already dine , submitting pr now

Resolve the conflicts in pull request.

@vivekvardhan2810  resolved


Use linter proposed by github

Related Github tickets

a list of github issues that are relevant for this PR

Background
A short paragraph on test what exactly this PR solves.
Testing completed

[ ] a list of actions that you've performed to ensure that this PR works as intended
[ ] 99% of the times you should have an item: "wrote tests"

Did you not want the [![GitHub Super-Linter](https://github.com/palomachain/paloma/workflows/Lint%20Code%20Base/badge.svg)](https://github.com/marketplace/actions/super-linter) badge in the readme? Also does it make sense to add this as an entirely separate workflow (and thus separate container execution) or can it be added to .github/workflows/ci-test.yml?

Reverting this as linter fails to properly load Go modules, thus reports that thing from other packages do not exist.


ASB-1202: HTML Validation Errors Observed

Task
https://pins-ds.atlassian.net/jira/software/c/projects/ASB/boards/166?modal=detail&selectedIssue=ASB-1207

:tada: This PR is included in version 2.8.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.11.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Support for unary minus in DaphneLib

The elementwise unary minus (additive inverse) operator has recently been added to DaphneDSL. This task is to add it to DaphneLib, DAPHNE's Python API as well.
Hints:

The operator needs to be added to src/api/python/daphne/operator/nodes/matrix.py and .../scalar.py.

Hello, please assign me to this issue and #774  .

Thanks for your interest. Sure, go ahead!


Enable nvidia-persistenced and increase nvidia-smi timeout to 40s (from 25s)

What type of PR is this?
/kind bug

What this PR does / why we need it:
To prevent timeout issues during CSE execution, for select GPU nodes
Which issue(s) this PR fixes:

Fixes #
Requirements:

[ ] uses conventional commit messages

[ ] includes documentation
[ ] adds unit tests
[ ] tested upgrade from previous version

Special notes for your reviewer:
Release note:
none

Moved select changes from henryli001's PR: https://github.com/Azure/AgentBaker/pull/2829

pulled into https://github.com/Azure/AgentBaker/pull/3209


Locality based routing not working for istio-proxy to istio-egressgateway traffic...

Bug Description
When our traffic routes out from an istio-proxy sidecar through an istio-egressgateway pod, we want the traffic to stay within-zone whenever possible so that we can avoid paying cross-AZ network costs. For setting up the EgressGateways, we followed the docs at https://istio.io/latest/docs/tasks/traffic-management/egress/egress-gateway/ (with a minor change, I'll describe it in the "Additional Information" section below).
We have other high volume services within the mesh that use locality-aware routing to great success, so we do understand that it works fundamentally within the mesh. I can confirm that it works when we route traffic from an istio-ingressgateway to a pod with an istio-proxy sidecar. It just doesn't seem to work in the reverse flow out of an egressgateway.
I've posted on Slack (https://istio.slack.com/archives/C37A4KAAD/p1657034565248319, https://istio.slack.com/archives/C37A4KAAD/p1656698370327109) and also dug through the discuss.istio.io page for help on this but I haven't found the answer yet.
My concern here is that this may simply not be a supported thing to do - or if it is, there must be something in the documentation we're missing or not understanding..
Version
$ istioctl version
client version: 1.13.3
control plane version: 1.14.0
data plane version: 1.14.0 (19 proxies)

$ kubectl version --short
Client Version: v1.23.5
Server Version: v1.22.9-eks-a64ea69

### Additional Information

Other than a fairly standard Istio installation, here are the resources we've configured to try to make the egress routing work. We followed the docs at https://istio.io/latest/docs/tasks/traffic-management/egress/egress-gateway/ pretty closely, however we made one change to reconfigure plaintext HTTP traffic (`http://httpbin.org`) to go out to the target destination via HTTPS:

## `Gateway: istio-egressgateway`
```yaml
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  generation: 3
  name: istio-egressgateway
  namespace: istio-system
spec:
  selector:
    istio: egressgateway
  servers:
  - hosts:
    - '*'
    port:
      name: http
      number: 80
      protocol: HTTP
  - hosts:
    - '*'
    port:
      name: tls
      number: 443
      protocol: TLS
    tls:
      mode: PASSTHROUGH

DestinationRule: istio-egressgateway
We created a DestinationRule for the egressgateway itself (traffic from the mesh -> gateway) to try to control the outlier detection:
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: istio-egressgateway
  namespace: istio-system
spec:
  host: istio-egressgateway.istio-system.svc.cluster.local
  trafficPolicy:
    connectionPool:
      http:
        maxRequestsPerConnection: 100
    outlierDetection:
      baseEjectionTime: 30s
      consecutiveGatewayErrors: 7
      interval: 10s

ServiceEntry: httpbin-org
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  generation: 1
  name: httpbin-org
  namespace: istio-system
spec:
  hosts:
  - httpbin.org
  ports:
  - name: http
    number: 80
    protocol: HTTP
    targetPort: 443
  - name: tls
    number: 443
    protocol: TLS
  resolution: DNS

DestinationRule: httpbin-org
This DestinationRule is used to reconfigure traffic targeting port 80 to re-route to port 443... it should only apply on the egressgateway where the final traffic out to the real destination is happening:
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: httpbin-org
  namespace: istio-system
spec:
  host: httpbin.org
  trafficPolicy:
    portLevelSettings:
    - port:
        number: 80
      tls:
        mode: SIMPLE

VirtualService: httpbin-org
Finally here's the VirtualService:
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-org
  namespace: istio-system
spec:
  gateways:
  - istio-egressgateway
  - mesh
  hosts:
  - httpbin.org
  http:
  - match:
    - gateways:
      - mesh
      port: 80
    route:
    - destination:
        host: istio-egressgateway.istio-system.svc.cluster.local
        port:
          number: 80
      weight: 100
  - match:
    - gateways:
      - istio-egressgateway
      port: 80
    route:
    - destination:
        host: httpbin.org
        port:
          number: 80
      weight: 100
  tls:
  - match:
    - gateways:
      - mesh
      port: 443
      sniHosts:
      - httpbin.org
    route:
    - destination:
        host: istio-egressgateway.istio-system.svc.cluster.local
        port:
          number: 443
  - match:
    - gateways:
      - istio-egressgateway
      port: 443
      sniHosts:
      - httpbin.org
    route:
    - destination:
        host: httpbin.org
        port:
          number: 443
      weight: 100

Logs from Requests
Ok, with this in mind, I launched a debug pod with an istio-proxy sidecar and I start curl'ling httpbin.org/ip and we can see that the upstream_host is fairly randomly selected:
$ k -n matt-test logs debug-diranged-8584a8da -c istio-proxy | grep httpbin | grep upstream | jq .upstream_host
"<IP_ADDRESS>:8080"
"<IP_ADDRESS>:8080"
"<IP_ADDRESS>:8080"
"<IP_ADDRESS>:8080"
"<IP_ADDRESS>:8080"
"<IP_ADDRESS>:8080"
"<IP_ADDRESS>:8080"
"<IP_ADDRESS>:8080"
"<IP_ADDRESS>:8080"
"<IP_ADDRESS>:8080"
"<IP_ADDRESS>:8080"
"<IP_ADDRESS>:8080"
"<IP_ADDRESS>:8080"
"<IP_ADDRESS>:8080"
"<IP_ADDRESS>:8080"

The logs on the istio-egressgateway containers are spread out between the containers too:
[pod/istio-egressgateway-57d76dddf9-948t2/istio-proxy] {"response_code_details":"via_upstream","request_id":"b4532f17-d23c-985e-a447-406204fe96a8","connection_termination_details":null,"upstream_transport_failure_reason":null,"requested_server_name":null,"bytes_sent":57,"upstream_local_address":"<IP_ADDRESS>:44082","upstream_host":"<IP_ADDRESS>:443","upstream_service_time":"66","user_agent":"curl/7.79.1","start_time":"2022-07-05T16:27:42.040Z","downstream_local_address":"<IP_ADDRESS>:8080","grpc_status":"Unknown","authorization":null,"response_code":200,"response_flags":"-","path":"/ip","method":"GET","protocol":"HTTP/2","downstream_remote_address":"<IP_ADDRESS>:0","duration":67,"authority":"httpbin.org","upstream_cluster":"outbound|80||httpbin.org","route_name":null,"x_forwarded_for":"<IP_ADDRESS>,<IP_ADDRESS>","bytes_received":0}
[pod/istio-egressgateway-57d76dddf9-948t2/istio-proxy] {"authority":"httpbin.org","connection_termination_details":null,"response_code":200,"request_id":"de431eca-4bde-9cba-bd0e-1c1540d49d0b","upstream_transport_failure_reason":null,"downstream_remote_address":"<IP_ADDRESS>:0","path":"/ip","bytes_received":0,"upstream_service_time":"69","downstream_local_address":"<IP_ADDRESS>:8080","route_name":null,"method":"GET","protocol":"HTTP/2","user_agent":"curl/7.79.1","x_forwarded_for":"<IP_ADDRESS>,<IP_ADDRESS>","duration":69,"upstream_local_address":"<IP_ADDRESS>:56574","upstream_host":"<IP_ADDRESS>:443","grpc_status":"Unknown","response_flags":"-","authorization":null,"response_code_details":"via_upstream","requested_server_name":null,"start_time":"2022-07-05T16:27:44.116Z","bytes_sent":57,"upstream_cluster":"outbound|80||httpbin.org"}
[pod/istio-egressgateway-57d76dddf9-h5lnl/istio-proxy] {"authority":"httpbin.org","connection_termination_details":null,"response_code_details":"via_upstream","route_name":null,"path":"/ip","upstream_local_address":"<IP_ADDRESS>:39180","request_id":"93d805d9-f3ea-9cd6-aecb-c01661751081","grpc_status":"Unknown","bytes_received":0,"upstream_host":"<IP_ADDRESS>:443","user_agent":"curl/7.79.1","x_forwarded_for":"<IP_ADDRESS>,<IP_ADDRESS>","authorization":null,"method":"GET","downstream_remote_address":"<IP_ADDRESS>:0","protocol":"HTTP/2","start_time":"2022-07-05T16:27:46.195Z","response_code":200,"duration":71,"bytes_sent":59,"downstream_local_address":"<IP_ADDRESS>:8080","response_flags":"-","upstream_service_time":"70","requested_server_name":null,"upstream_transport_failure_reason":null,"upstream_cluster":"outbound|80||httpbin.org"}
[pod/istio-egressgateway-57d76dddf9-96gk9/istio-proxy] {"authorization":null,"path":"/ip","response_code_details":"via_upstream","method":"GET","x_forwarded_for":"<IP_ADDRESS>,<IP_ADDRESS>","authority":"httpbin.org","bytes_received":0,"protocol":"HTTP/2","user_agent":"curl/7.79.1","response_code":200,"duration":69,"start_time":"2022-07-05T16:27:48.274Z","route_name":null,"upstream_transport_failure_reason":null,"upstream_local_address":"<IP_ADDRESS>:38612","requested_server_name":null,"downstream_remote_address":"<IP_ADDRESS>:0","request_id":"2b43161b-fe06-99cf-b228-cfa368e965f9","upstream_service_time":"69","upstream_cluster":"outbound|80||httpbin.org","bytes_sent":59,"upstream_host":"<IP_ADDRESS>:443","connection_termination_details":null,"grpc_status":"Unknown","response_flags":"-","downstream_local_address":"<IP_ADDRESS>:8080"}
[pod/istio-egressgateway-57d76dddf9-948t2/istio-proxy] {"bytes_sent":57,"downstream_remote_address":"<IP_ADDRESS>:0","upstream_local_address":"<IP_ADDRESS>:38886","protocol":"HTTP/2","request_id":"8f71f602-d2ac-93e5-b27e-78bdd557bbb4","response_code_details":"via_upstream","method":"GET","authorization":null,"upstream_transport_failure_reason":null,"upstream_cluster":"outbound|80||httpbin.org","response_flags":"-","grpc_status":"Unknown","duration":269,"response_code":200,"bytes_received":0,"connection_termination_details":null,"x_forwarded_for":"<IP_ADDRESS>,<IP_ADDRESS>","requested_server_name":null,"start_time":"2022-07-05T16:27:50.351Z","upstream_service_time":"269","route_name":null,"downstream_local_address":"<IP_ADDRESS>:8080","upstream_host":"<IP_ADDRESS>:443","path":"/ip","authority":"httpbin.org","user_agent":"curl/7.79.1"}

Jus checking in here. In thinking about this, is this failing to do what I expect because traffic from istio-proxy -> istio-egressgateway pods is not really considered mesh traffic?

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  generation: 1
  name: httpbin-org
  namespace: istio-system
spec:
  hosts:
  - httpbin.org
  ports:
  - name: http
    number: 80
    protocol: HTTP
    targetPort: 443
  - name: tls
    number: 443
    protocol: TLS
  resolution: DNS

This DestinationRule is used to reconfigure traffic targeting port 80 to re-route to port 443...

This can not work as expected, you may need to consider VirtualService HTTPRedirect

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  generation: 1
  name: httpbin-org
  namespace: istio-system
spec:
  hosts:
  - httpbin.org
  ports:
  - name: http
    number: 80
    protocol: HTTP
    targetPort: 443
  - name: tls
    number: 443
    protocol: TLS
  resolution: DNS

This DestinationRule is used to reconfigure traffic targeting port 80 to re-route to port 443...

This can not work as expected, you may need to consider VirtualService HTTPRedirect

Thank you - I have adjusted our config and have the HTTP->HTTPS working in a cleaner way now that is reliable. The fact that locality load balancing (with zone-priority) is not working is still here though.

Update: We've found the root cause and "fix"...
We spent a bunch of time debugging the eds.go / generateEndpoints() function, the loadbalancer.go / applyLocalityFailover() function and finally the the util.go | LbPriority functions. We discovered after introducing some debug log statements that when the priority := util.LbPriority(locality, localityEndpoint.Locality) statement is being executed, the locality object had no "locality information" in it:
2022-07-19T23:22:40.351623Z	warn	applyLocalityFailover[proxy=debug-slava2.default][outbound|5000||helloworld.default.svc.cluster.local][0][proxy locality: //][endpoint locality fake-az-1/fake-az-1a/]: priority 3

We then tried to trace where the locality object comes from, but got a bit lost as it starts to enter the envoy library world... however, it got us wondering: Why would this work for istio-ingressgateways, but fail for istio-proxy sidecars?
Answer: You need a Service pointing to your client workload!
We have a very simple and reproducible test case here. Let me take you through it here:
First, launch the hello-world service with outlier detection
$ kubectl apply -f helloworld.yaml
service/helloworld created
deployment.apps/helloworld created
destinationrule.networking.istio.io/helloworld created
$ kubectl apply -f client.yaml
deployment.apps/client created

Now we check our pods ... we should have 3 hello world pods, and a client pod:
$ kubectl get pods -o wide
NAME                          READY   STATUS    RESTARTS   AGE   IP               NODE                                           NOMINATED NODE   READINESS GATES
client-74d88ccb6f-c2kdh       2/2     Running   0          13m   <IP_ADDRESS>    ip-100-64-4-212.us-west-2.compute.internal     <none>           <none>
helloworld-7b8c654c59-2wkkc   2/2     Running   0          15m   <IP_ADDRESS>    ip-100-64-4-212.us-west-2.compute.internal     <none>           <none>
helloworld-7b8c654c59-lpvvw   2/2     Running   0          15m   <IP_ADDRESS>     ip-100-64-126-158.us-west-2.compute.internal   <none>           <none>
helloworld-7b8c654c59-x9dlj   2/2     Running   0          15m   <IP_ADDRESS>   ip-100-64-169-20.us-west-2.compute.internal    <none>           <none>

When we follow the client pod logs, we can see it bouncing around the helloworld pods:
$ kubectl logs -l app=client -f
Hello version: v1, instance: helloworld-7b8c654c59-2wkkc
Hello version: v1, instance: helloworld-7b8c654c59-2wkkc
Hello version: v1, instance: helloworld-7b8c654c59-lpvvw
Hello version: v1, instance: helloworld-7b8c654c59-lpvvw
Hello version: v1, instance: helloworld-7b8c654c59-x9dlj
Hello version: v1, instance: helloworld-7b8c654c59-x9dlj
Hello version: v1, instance: helloworld-7b8c654c59-2wkkc
Hello version: v1, instance: helloworld-7b8c654c59-2wkkc
Hello version: v1, instance: helloworld-7b8c654c59-lpvvw
Hello version: v1, instance: helloworld-7b8c654c59-lpvvw
Hello version: v1, instance: helloworld-7b8c654c59-x9dlj

So now let's apply the clientsvc.yaml file:
$ kubectl apply -f clientsvc.yaml
service/client created
$ kubectl logs -l app=client -f
Hello version: v1, instance: helloworld-7b8c654c59-2wkkc
Hello version: v1, instance: helloworld-7b8c654c59-2wkkc
Hello version: v1, instance: helloworld-7b8c654c59-lpvvw
Hello version: v1, instance: helloworld-7b8c654c59-lpvvw
Hello version: v1, instance: helloworld-7b8c654c59-x9dlj
Hello version: v1, instance: helloworld-7b8c654c59-x9dlj
Hello version: v1, instance: helloworld-7b8c654c59-2wkkc
Hello version: v1, instance: helloworld-7b8c654c59-2wkkc
Hello version: v1, instance: helloworld-7b8c654c59-lpvvw
Hello version: v1, instance: helloworld-7b8c654c59-lpvvw
...
Hello version: v1, instance: helloworld-7b8c654c59-2wkkc
Hello version: v1, instance: helloworld-7b8c654c59-2wkkc
Hello version: v1, instance: helloworld-7b8c654c59-2wkkc
Hello version: v1, instance: helloworld-7b8c654c59-2wkkc
Hello version: v1, instance: helloworld-7b8c654c59-2wkkc
Hello version: v1, instance: helloworld-7b8c654c59-2wkkc
Hello version: v1, instance: helloworld-7b8c654c59-2wkkc
Hello version: v1, instance: helloworld-7b8c654c59-2wkkc
Hello version: v1, instance: helloworld-7b8c654c59-2wkkc
Hello version: v1, instance: helloworld-7b8c654c59-2wkkc
Hello version: v1, instance: helloworld-7b8c654c59-2wkkc
Hello version: v1, instance: helloworld-7b8c654c59-2wkkc
Hello version: v1, instance: helloworld-7b8c654c59-2wkkc
Hello version: v1, instance: helloworld-7b8c654c59-2wkkc
Hello version: v1, instance: helloworld-7b8c654c59-2wkkc
Hello version: v1, instance: helloworld-7b8c654c59-2wkkc

Bug: You need a Service pointing to your client workload for the locality data to be available
I think this is a bug ... if you don't use a Service to point to your client workload, it seems that the locality data is not populated. When it isn't populated in the client, then the logic at https://github.com/istio/istio/blob/84133147b40b5a95b46d8246feed01ac65a1ff49/pilot/pkg/networking/util/util.go#L298 fails and immediately returns a 3 priority.
YAML Blobs
# helloworld.yaml
---
apiVersion: v1
kind: Service
metadata:
  name: helloworld
  labels:
    app: helloworld
    service: helloworld
spec:
  ports:
  - port: 5000
    name: http
  selector:
    app: helloworld
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloworld
  labels:
    app: helloworld
spec:
  replicas: 3
  selector:
    matchLabels:
      app: helloworld
  template:
    metadata:
      labels:
        app: helloworld
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchExpressions:
            - key: app
              operator: In
              values: [helloworld]
      containers:
      - name: helloworld
        env:
        - name: SERVICE_VERSION
          value: v1
        image: docker.io/istio/examples-helloworld-v1
        resources:
          requests:
            cpu: "100m"
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 5000
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: helloworld
spec:
  host: helloworld
  trafficPolicy:
    outlierDetection:
      baseEjectionTime: 3s
      consecutive5xxErrors: 10
      interval: 30s
      maxEjectionPercent: 30
      minHealthPercent: 50

# client.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: client
  labels:
    app: client
spec:
  replicas: 1
  selector:
    matchLabels:
      app: client
  template:
    metadata:
      labels:
        app: client
    spec:
      containers:
      - name: client
        env:
        - name: SERVICE_VERSION
          value: v1
        image: curlimages/curl:latest
        command:
          - /bin/sh
          - -c
          - 'while true; do curl --silent http://helloworld:5000/hello; sleep 0.5; done'
        imagePullPolicy: IfNotPresent

# clientsvc.yaml
---
apiVersion: v1
kind: Service
metadata:
  name: client
  labels:
    app: client
spec:
  ports:
  - port: 5000
    name: http
  selector:
    app: client

Update: Egress is still broken... but general mesh traffic works
My fix above is only partial. It works for fixing internal mesh-to-mesh locality routing.. it does not work for pod -> egress -> internet routing. Even though there is a service resource pointing to the istio-egressgateway pods, and one pointing to our client pods, we still see that the  traffic randomly routes through the istio egressgateways.

Yes, normally in istio we require the client has a service related.

@howardjohn
I think we can fix depend on service instance here, but not sure we should
	// Get the locality from the proxy's service instances.
	// We expect all instances to have the same IP and therefore the same locality.
	// So its enough to look at the first instance.
	if len(proxy.ServiceInstances) > 0 {
		proxy.Locality = util.ConvertLocality(proxy.ServiceInstances[0].Endpoint.Locality.Label)
	}

I think it's far from the only feature that depends on Service for clients,
we have a documented limitations for this
On Tue, Jul 19, 2022, 6:26 PM Zhonghu Xu @.***> wrote:

@howardjohn https://github.com/howardjohn
I think we can fix depend on service instance here, but not sure we should
// Get the locality from the proxy's service instances.
// We expect all instances to have the same IP and therefore the same locality.
// So its enough to look at the first instance.
if len(proxy.ServiceInstances) > 0 {
proxy.Locality = util.ConvertLocality(proxy.ServiceInstances[0].Endpoint.Locality.Label)
}
—
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/39792#issuecomment-1189704270, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXM2CXRM2ZYPOIQRKUTVU5IV7ANCNFSM52WZPKFA
.
You are receiving this because you were mentioned.Message ID:
@.***>

I'd be fine to fix it but we should try. to consider all features not just
locality
On Tue, Jul 19, 2022, 6:28 PM John Howard @.***> wrote:

I think it's far from the only feature that depends on Service for
clients, we have a documented limitations for this
On Tue, Jul 19, 2022, 6:26 PM Zhonghu Xu @.***> wrote:

@howardjohn https://github.com/howardjohn
I think we can fix depend on service instance here, but not sure we should
// Get the locality from the proxy's service instances.
// We expect all instances to have the same IP and therefore the same locality.
// So its enough to look at the first instance.
if len(proxy.ServiceInstances) > 0 {
proxy.Locality = util.ConvertLocality(proxy.ServiceInstances[0].Endpoint.Locality.Label)
}
—
Reply to this email directly, view it on GitHub
https://github.com/istio/istio/issues/39792#issuecomment-1189704270,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEYGXM2CXRM2ZYPOIQRKUTVU5IV7ANCNFSM52WZPKFA
.
You are receiving this because you were mentioned.Message ID:
@.***>

That may take some time to fully inverstigating that.

I think it's far from the only feature that depends on Service for clients,
we have a documented limitations for this

Yes, I am aware of it. Meant to fix this or not, irrespective others first

I have analyzed all the dependency place of proxy.ServiceInstances. And found out that the most are inbound listener, cluster, etc
Gateway is a little special, it needs service instances in mergeGateways(proxy *Proxy) , but fortunately for gateway we always has a service.
So the only dependent we need to resolve is proxy.Locality = util.ConvertLocality(proxy.ServiceInstances[0].Endpoint.Locality.Label)
This is simple and has no caveats.

/assign @hzxuzhonghu


Add a filter to the resource action endpoint to only select resource actions that have a change (#6837)

Pull request opened by the merge tool on behalf of #6837

Merged into branches iso6 in e825914947ecd91734baf5171aecce210956f7bb


Fix documentation to drop the '@liquid-labs' qualifier

Overview
The install and usage still referenced the org-qualified names.
Deliverables

[ ] remove the qualification

Work for this issue will begin begin on branch work-liquid-labs/find-plus/13.


Not able to move the window if the drager point is out of the right window edge.

Description
Not able to move the window if the pick-point in the Title bar is out of the right window edge. You have to resize the window until you found enough space to click and drag.
Also, it is not possible to resize from maximize by dragging the window from the top edge.
Steps To Reproduce

Open Window
Move it outside the right Border
Open new Tabs until the drag-point in title bar is missing.

Expected behavior
moving Window ishould be possible. Some pixel above the tab to drag the window is needed
Files Version
<IP_ADDRESS>
Windows Version
Windows 10 H2 19044
Relevant Assets/Logs

@Mannshoch this issue should be resolved with #9157.


corrupted com.google.firebase.firebase-messaging-unity-***.aar

[READ] For Firebase Unity SDK issues, please report to Firebase Unity open-source
Once you've read this section and determined that your issue is appropriate for this repository, please delete this section.
[REQUIRED] Please fill in the following fields:

Unity editor version: _____2022.3.7

Firebase Unity SDK version: _____11.3.0

Source you installed the SDK: _____ FirebaseMessaging.unitypackage

Problematic Firebase Component: _____ FirebaseMessaging

Platform you are using the Unity editor on: _____ Windows

Platform you are targeting: _____ Android

Scripting Runtime: _____ IL2CPP

[REQUIRED] Please describe the issue here:
As of FirebaseFirestore_10.7.0, the lib com.google.firebase.firebase-messaging-unity-.aar has a corrupted .jar of 1kb.
This makes it impossible for me to use the file in my custom activity.
With FirebaseMessaging_9.6.0.unitypackage the com.google.firebase.firebase-messaging-unity-.aar it's ok.
Steps to reproduce:
Download sdk and install FirebaseMessaging.unitypackage
Resolve dependencies
Open aar in android studio or unzip it.
The jar file will be corrupted.

This issue still exists in 11.8.1

Also having this issue on 11.8.1 and 11.8.0
Any indications on when this may be fixed?


fix: initialise selectedBuyAssetAccountId & selectedSellAssetAccountId

Description
Fixes the "no receive address" bug in production.
Issue is caused by the updateSelectedSellAssetAccountId and updateSelectedBuyAssetAccountId reducers not firing again after being cleared by changing assets.
Pull Request Type

[x] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[ ] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)
Closes https://github.com/shapeshift/web/issues/4850
Risk
Small surface area, but this impact of us getting anything related to accounts wrong is substantial.
Testing
Attempt to trade into ETH by switching assets on initial load. It should no longer say "no receive address".
Engineering
Check that the seleted account id values in the redux swapper store are always what we expect when changing assets, swappers etc.
Operations
☝
Screenshots (if applicable)
N/A

Current dependencies on/for this PR:

develop

PR #4870   👈

This comment was auto-generated by Graphite.


Date getting converted while reading from CSV file

Hello,
I am trying to read CSV file that has date value. It is observed that value read from date cell is including time zone value. I have observed 2 different weird behaviors:

In one of the CSV file, date value of 3/29/1981 returns Sun Mar 29 1981 00:00:00 GMT+0530 (India Standard Time).
In another CSV file, the date 2021-09-28 returns Tue Sep 28 2021 23:59:50 GMT +0530.

In first scenario, reading value from cell returns 3/29/1981 which is expected. In second scenario, reading value from cell returns 09/28/2021 which is a day before.
I am still not sure what caused second CSV file to have time value (23:59:50) which is causing the conversion, while the first one CSV has 00:00:00 for all cells.
Is there any workaround to get correct date value.
Thanks in advance.
Please note, the issue is not there when read from Excel file.

So that it can be reproduced, can you share the current timezone and the JS environment (web browser/version or nodejs version or other platform)?

Assuming timezone Asia/Kolkata, dates are anchored to the beginning of 1900.  A 10-second change in 1906 is not correctly reflected in Chrome
Combining with https://github.com/SheetJS/sheetjs/issues/2196


The argument "--vm-name" should not be required for "az vm nic show"

Description
The nic can exist even there's no VM, so azure-cli should allow to show its properties.

Environment summary
Install Method: How did you install the CLI? (e.g. pip, interactive script, apt-get, Docker, MSI, nightly)
Answer here: Docker
CLI Version: What version of the CLI and modules are installed? (Use az --version)
Answer here: 2.0.18
OS Version: What OS and version are you using?
Answer here: unknown
Shell Type: What shell are you using? (e.g. bash, cmd.exe, Bash on Windows)
Answer here: bash

Sorry. I figured it out. I should use az network nic show instead of az vm nic show.


feat: add client-side，faster and more accurate hmr

// vite.config.js
import { ClientSideLayout } from 'vite-plugin-vue-layouts'

export default {
  plugins: [
    ClientSideLayout({
      layoutsDir: 'src/mylayouts', // default to 'src/layout'
      defaultLayout: 'myDefault.vue', // default to 'default.vue'
      importMode: 'sync' // The default will automatically detect -> ssg is sync，other is async
    }),
  ],
};

The clientSideLayout uses a simpler virtual file + glob import scheme, This means that its hmr is faster and more accurate, but also more limited.
close issue: #71 #73 #82 #99 #104

Thanks for this; at some point, I'd like to see if we can consolidate the options, maybe deprecating the extension option on the original.

Hi @markthree is this plugin now compatible with unplugin-vue-router?
If yes, @JohnCampionJr Can you please make a PR so we can try it? It's been 3-4 months since no release is made!


Bucklescript 6 (OCaml 4.06.x) compatibility

Is genType compatible with OCaml 4.06? The current release is compiled against 4.02 which doesn't work with bucklescript beta. I am wondering if it can be compiled against 4.06 at all and if there's a workflow for doing that (I tried with esy but then I noticed that the opam file is empty)

@wokalski there's this version that compiles with dune on 4.06: https://github.com/cristianoc/genType/pull/100.
The dependencies are tiny:
(libraries unix str compiler-libs.common)

The only thing, I'm not sure how to set up CI with it, to create releases.

If we use cppo in the source the only concern would be what versioning scheme should be used for 4.06 compatible releases. Alternatively, if we assume that it’s only for people living on the bleeding edge, a complete opam file/esy.json would be sufficient (so that we could use it with opam/esy)

It would be great to have at least a bleeding edge going, to start with.

Sounds good. Is it okay if I use ppx_optcomp (cppo is not supported in re files)

Sounds great.

Until the 4_06_1 branch is merged, using this ppx with Bucklescript 6 involves a few additional steps.
For esy users:

Add gentype to your dependencies:

{
  "dependencies": { "ocaml": "4.6.x" },
  "devDependencies": {
    "@opam/genType": "cristianoc/genType:genType.opam#4_06_1"
  }
}

Run esy (installs and builds gentype)
Create a script (I called it gentype.ppx) with esy x gentype.exe "$@" as contents.
Make it executable (with chmod +x gentype.ppx)
Add the path of the script to your gentype config (inside bsconfig.json):

  "gentypeconfig": {
    "path": "./gentype.ppx",

PS: gentype has been autocorrected to genotype too many times while I was writing this comment!

Luckily, 4.06 support is a thing now.