Embed MSBUILD dependencies in the package

This is work-in-progress PR for #337.
This correctly copies the binaries to the bin/net45 folder, but for some reason, it does not do the same for the build in bin/net40.
@dsyme @7sharp9 Do you have any idea why the change would not affect the net40 build? Am I missing another fsproj file somewhere :-)?

Looks like you'd need to do these ones too: https://github.com/fsharp/FSharp.Compiler.Service/pull/338/files#diff-d81cb596fee05d911235bc8c0730075bR599

OK, now it should all work!

This is now ready to merge and release - @dsyme - could you please do that?
This is coming up in another context - when you have just VS 2015, you do not have the versions of MSBUILD libraries required by the F# Compiler Service (see https://github.com/tpetricek/Dojo-Suave-FsHome/issues/3), so it would be good to have a new release of F.C.S that fixes this :-)

It would be nice to decouple msbuild entirely and replicate the project options manually, especially as the msbuild reference resolution can take several seconds.

On 24 May 2015, at 12:32, Tomas Petricek<EMAIL_ADDRESS>wrote:
This is now ready to merge and release - @dsyme - could you please do that?
This is coming up in another context - when you have just VS 2015, you do not have the versions of MSBUILD libraries required by the F# Compiler Service (see tpetricek/Dojo-Suave-FsHome#3), so it would be good to have a new release of F.C.S that fixes this :-)
—
Reply to this email directly or view it on GitHub.

Sorry I missed this PR before, but I wonder what effect bundling the
windows msbuild assemblies will have on mono? Perhaps we could use a single
unified code path (new api) in that case?
Dave, what exactly do you propose? I'm not sure how we can guarantee to
give the same behaviour as the build except by using msbuild here. I do
accept that the msbuild dependency is rather heavyweight for what it gives,
but I also think that capability is very useful.
On 24 May 2015 13:36, "Dave Thomas"<EMAIL_ADDRESS>wrote:

It would be nice to decouple msbuild entirely and replicate the project
options manually, especially as the msbuild reference resolution can take
several seconds.

On 24 May 2015, at 12:32, Tomas Petricek<EMAIL_ADDRESS>wrote:
This is now ready to merge and release - @dsyme - could you please do
that?
This is coming up in another context - when you have just VS 2015, you
do not have the versions of MSBUILD libraries required by the F# Compiler
Service (see tpetricek/Dojo-Suave-FsHome#3), so it would be good to have a
new release of F.C.S that fixes this :-)
—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
https://github.com/fsharp/FSharp.Compiler.Service/pull/338#issuecomment-105010515
.

Yes, I'm nervous about the impact of deploying all these DLLs too in various scenarios. It's risky.  Tomas, how much validation have you done of the solution? For example, is it still possible to crack project files when things like Microsoft.Common.targets is not on the machine?  I'd imagine not.  But equally we don't really want to include that as part of the FCS package.  So it seems there is still some loss of functionality on target machines.
If we're trying to avoid outright crashes, then the alternative technique is to make sure that the MSBuild dependencies are only exercised on very specific pathways, e.g. when non-explicit references are used like #r "System.Runtime".  Many uses of FCS use only fully explicit references (where no use of MSBuild should logically speaking be required, though the DLLs are still actually required today)
I'm not sure what the best and safest solution is. At least, I think we should do a bit more work to quantify what will work and what won't.  In the meantime I suppose we can give advice to people to manually deploy the MSBuild binaries in situations where the target machine is not a dev machine.

In the case of the build machines at xamarin we had to get msbuild12 deployed to the build server because of the FCS dependency.  I think it just needs to be noted quite clearly.  I would advise against packaging like this for what is just a single feature of FCS.

On 26 May 2015, at 22:14, Don Syme<EMAIL_ADDRESS>wrote:
Yes, I'm nervous about the impact of deploying all these DLLs too in various scenarios. It's risky. Tomas, how much validation have you done of the solution? For example, is it still possible to crack project files when things like Microsoft.Common.targets is not on the machine? I'd imagine not. But equally we don't really want to include that as part of the FCS package. So it seems there is still some loss of functionality on target machines.
If we're trying to avoid outright crashes, then the alternative technique is to make sure that the MSBuild dependencies are only exercised on very specific pathways, e.g. when non-explicit references are used like #r "System.Runtime". Many uses of FCS use only fully explicit references (where no use of MSBuild should logically speaking be required, though the DLLs are still actually required today)
I'm not sure what the best and safest solution is. At least, I think we should do a bit more work to quantify what will work and what won't. In the meantime I suppose we can give advice to people to manually deploy the MSBuild binaries in situations where the target machine is not a dev machine.
—
Reply to this email directly or view it on GitHub.

I love this quote: "So far, the only thing I really do not like [about F#] is msbuild. How did that barf sandwich ever make it out of alpha?"
http://www.reddit.com/r/fsharp/comments/377ih0/what_i_dislike_about_f/
:)

@7sharp9 - there are two features that depend on MSBuild

MSBuild-style reference resolution used by scripts and "non-simpleresolution" command line compilation/processing.

FSharpChecker project file cracking via GetProjectOptionsFromCommandLineArgs/GetProjectOptionsFromProjectFile/GetProjectOptionsFromScript.

Feature 1 is the one that Tomas (and transitive users of FSharp.Formatting) are hitting.  Further I think this feature causes a hard dependency on the MSBuild binaries even if it is not actually used (i.e. if "simpleresolution" is used)
To explain in further detail.... Feature 1 lets #r in scripts and command line -r references use text like "System.Runtime" or "System.Xml" (without ".dll"), or versioned full assembly names like "System.Xml, Version=...." using a full assembly name.  It also searches some "standard" installation locations like ReferenceAssemblies also the GAC in addition to #I paths.
Feature 1 is used by F# Interactive and FsiInteractiveSession when processing scripts.  In practice very many scripts rely on it, though mostly because people drop off the ".dll" from a reference name. It's also used by invocations to the F# compiler that do not pass "--simpleresolution", though those are much rarer and less important since any compilation coming from Xamarin Studio or Visual Studio does full resolution in the IDE based on project file settings and passes "--simpleresolution".
In the implementation Feature 1 relies on MSBuild's capabilities to do reference resolution (in contrast --simpleresolution does resolution "manually" by looking through search paths).   Feature 1 is not even enabled on Mono systems where "simple resolution" is used all the time. However this is regarded as an important discrepancy that needs to be resolved), see also this
One path would be to just disable Feature 1 completely for the nuget-shipped FSharp.Compiler.Service - i.e. require that simple resolution be used.  However this would give discrepancies in script reference resolution on Windows, and wouldn't place us on a path to good convergence.   Alternatively we could seek to completely re-implement the relevant part of the reference resolution code (perhaps with an option to use MSBuild reference, inducing a runtime dependency on the DLLs, just in case there are discrepancies - I can see that being attractive to the Visual F# Tools, for example, when they move to use FCS).
Feature 2 uses MSBuild's ability to crack and process project files.  My understanding is that feature 2 is just not going to work easily without an appropriate install of MSBuild - processing project files naturally requires all the relevant .targets to be installed.  I think it's reasonable to expect MSBuild to be installed in those scenarios (though we should document exactly which version needs to be installed and why in a design note similar to the one on FSharp.Core)
As a first step, it would be good to remove the hard dependency on MSBuild for reference resolution in the case where --simpleresolution is passed.
Finally, I should add that I find the way FSharp.Formatting is driving FSharp.Compiler.Service a bit hard to unpick - the various "generate.fsx" files I've seen seem to be doing some reference resolution themselves, and in a somewhat adhoc way, and may be relying on the "non-simple" reference resolution feature (Feature 1 above) much more than any other client.  For "generate.fsx" documentation generation I think I'd prefer the reference resolution to be done using the more standard "crack a project file" or "crack a script" rather than the adhoc "throw some text for some references at FCS and cross your fingers" approach that seems to be commonplace right now. I'm not sure about other clients of FCS besides these "generate.fsx" scripts though, it would be good to get a grip on how widespread the use of Feature 1 is.

On 27 May 2015, at 00:26, Don Syme<EMAIL_ADDRESS>wrote:
@7sharp9 https://github.com/7sharp9 - there are two features that depend on MSBuild
MSBuild-style reference resolution used by scripts and "non-simpleresolution" command line compilation/processing.
FSharpChecker project file cracking via GetProjectOptionsFromCommandLineArgs/GetProjectOptionsFromProjectFile/GetProjectOptionsFromScript.
Feature 1 is the one that Tomas (and transitive users of FSharp.Formatting) are hitting. Further I think this feature causes a hard dependency on the MSBuild binaries even if it is not actually used (i.e. if "simpleresolution" is used)
To explain in further detail.... Feature 1 lets #r in scripts and command line -r references use text like "System.Runtime" or "System.Xml" (without ".dll"), or versioned full assembly names like "System.Xml, Version=...." using a full assembly name. It also searches some "standard" installation locations like ReferenceAssemblies also the GAC in addition to #I paths.
Feature 1 is used by F# Interactive and FsiInteractiveSession when processing scripts. In practice very many scripts rely on it, though mostly because people drop off the ".dll" from a reference name. It's also used by invocations to the F# compiler that do not pass "--simpleresolution", though those are much rarer and less important since any compilation coming from Xamarin Studio or Visual Studio does full resolution in the IDE based on project file settings and passes "--simpleresolution".
In the implementation Feature 1 relies on MSBuild's capabilities to do reference resolution (in contrast --simpleresolution does resolution "manually" by looking through search paths). Feature 1 is not even enabled on Mono systems where "simple resolution" is used all the time. However this is regarded as an important discrepancy that needs to be resolved https://github.com/fsharp/fsharp/issues/113), see also this https://github.com/fsharp/fsharp/issues/251
One path would be to just disable Feature 1 completely for the nuget-shipped FSharp.Compiler.Service - i.e. require that simple resolution be used. However this would give discrepancies in script reference resolution on Windows, and wouldn't place us on a path to good convergence. Alternatively we could seek to completely re-implement the relevant part of the reference resolution code (perhaps with an option to use MSBuild reference, inducing a runtime dependency on the DLLs, just in case there are discrepancies - I can see that being attractive to the Visual F# Tools, for example, when they move to use FCS).
Feature 2 uses MSBuild's ability to crack and process project files. My understanding is that feature 2 is just not going to work easily without an appropriate install of MSBuild - processing project files naturally requires all the relevant .targets to be installed. I think it's reasonable to expect MSBuild to be installed in those scenarios (though we should document exactly which version needs to be installed and why in a design note similar to the one on FSharp.Core)
As a first step, it would be good to remove the hard dependency on MSBuild for reference resolution in the case where --simpleresolution is passed.
Finally, I should add that I find the way FSharp.Formatting is driving FSharp.Compiler.Service a bit hard to unpick - the various "generate.fsx" files I've seen seem to be doing some reference resolution themselves, and in a somewhat adhoc way, and may be relying on the "non-simple" reference resolution feature (Feature 1 above) much more than any other client. For "generate.fsx" documentation generation I think I'd prefer the reference resolution to be done using the more standard "crack a project file" or "crack a script" rather than the adhoc "throw some text for some references at FCS and cross your fingers" approach that seems to be commonplace right now. I'm not sure about other clients of FCS besides these "generate.fsx" scripts though, it would be good to get a grip on how widespread the use of Feature 1 is.
—
Reply to this email directly or view it on GitHub https://github.com/fsharp/FSharp.Compiler.Service/pull/338#issuecomment-105696655.

Feature 1 needs the older version of msbuild, feature 2 needs the newer one, version 12 I believe which results in the new references which are now needed.

@7sharp9 - can you adjust your comment above to give the exact version numbers (DLL version numbers) you mean when you say "older" and "newer" versions of MSBuild.  Also, I think this thread is about allowing basic compilation, checking and script processing functionality of FCS to be used without any version of MSBuild installed (i.e. if Feature 1 and Feature 2 are not used at all)

Ill find out when I get a minute about the versions.  The point I was making was feature 2 added new dependencies on a newer msbuild, which required installing a seperate package on the build server.

I do not understand all the implications here.
It might not be such a big issue, but I got back to this because of the issue raised here: https://github.com/tpetricek/Dojo-Suave-FsHome/issues/3. Is there another solution to that issue? (If no, it means that F# Compiler Service only works when you have VS 2013 installed, which sounds wrong.)

@tpetricek msbuild is installed separately from the .Net framework, so if you were referencing one more recent than whatever was shipped with vs2013 then you might expect to have to install it.

If FCS does not work without a newer msbuild then that might mean that Xamarin Studio now has a dependency on a later msbuild being installed too.

@dsyme thanks for the thorough explanation. I was only vaguely aware of "Feature 1" as I'm focused on "Feature 2" which is an important facility for FSharp.AutoComplete. I think this issue might well be traced back to the inclusion of Feature 2 (8249ee675c9d1cfe9635bbc4ead9c93a079e12d8)
though, specifically when we changed to depend on new MSBuild in order that the cracking worked on Mono (96a5f329244b8866f7a0231a6cd1efb4058754e2):
--- a/src/fsharp/FSharp.Compiler.Service/FSharp.Compiler.Service.fsproj
+++ b/src/fsharp/FSharp.Compiler.Service/FSharp.Compiler.Service.fsproj
@@ -596,11 +596,17 @@
     <Reference Include="System" />
     <Reference Include="System.Core" />
     <Reference Include="System.Xml" />
-    <Reference Include="Microsoft.Build.Framework" />
-    <Reference Include="Microsoft.Build.Engine" />
-    <Reference Include="Microsoft.Build" />
-    <Reference Include="Microsoft.Build.Utilities.v4.0" />
-    <Reference Include="Microsoft.Build.Tasks.v4.0" />
+    <Reference Include="Microsoft.Build.Framework" Condition=" '$(TargetFrameworkVersion)' == 'v4.0'" />
+    <Reference Include="Microsoft.Build.Engine" Condition=" '$(TargetFrameworkVersion)' == 'v4.0'" />
+    <Reference Include="Microsoft.Build" Condition=" '$(TargetFrameworkVersion)' == 'v4.0'" />
+    <Reference Include="Microsoft.Build.Utilities.v4.0" Condition=" '$(TargetFrameworkVersion)' == 'v4.0'" />
+    <Reference Include="Microsoft.Build.Tasks.v4.0" Condition=" '$(TargetFrameworkVersion)' == 'v4.0'" />
+
+    <Reference Include="Microsoft.Build.Framework, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Condition=" '$(TargetFrameworkVersion)' == 'v4.5'" />
+    <Reference Include="Microsoft.Build.Engine, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Condition=" '$(TargetFrameworkVersion)' == 'v4.5'" />
+    <Reference Include="Microsoft.Build, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Condition=" '$(TargetFrameworkVersion)' == 'v4.5'" />
+    <Reference Include="Microsoft.Build.Utilities.v12.0" Condition=" '$(TargetFrameworkVersion)' == 'v4.5'" />
+    <Reference Include="Microsoft.Build.Tasks.v12.0" Condition=" '$(TargetFrameworkVersion)' == 'v4.5'" />
     <Reference Include="FSharp.Core, Version=$(TargetFSharpCoreVersion), Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
       <Private>False</Private>
     </Reference>

Before VS2012, I think MSBuild was bundled with .NET, so most machines can be expected to have the <IP_ADDRESS> version of MSBuild. Before the diff above therefore the MSBuild assemblies in the GAC would have been used.
A later change (306e478e06e989f0385e58f3ba24d674c1b668b4) added SpecificVersion:
-    <Reference Include="Microsoft.Build.Framework, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Condition=" '$(TargetFrameworkVersion)' == 'v4.5'" />
-    <Reference Include="Microsoft.Build.Engine, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Condition=" '$(TargetFrameworkVersion)' == 'v4.5'" />
-    <Reference Include="Microsoft.Build, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Condition=" '$(TargetFrameworkVersion)' == 'v4.5'" />
+    <Reference Include="Microsoft.Build.Framework, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Condition=" '$(TargetFrameworkVersion)' == 'v4.5'" >
+        <SpecificVersion>True</SpecificVersion>
+    </Reference>
+    <Reference Include="Microsoft.Build.Engine, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Condition=" '$(TargetFrameworkVersion)' == 'v4.5'" >
+        <SpecificVersion>True</SpecificVersion>
+    </Reference>
+    <Reference Include="Microsoft.Build, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Condition=" '$(TargetFrameworkVersion)' == 'v4.5'" >
+        <SpecificVersion>True</SpecificVersion>
+    </Reference>

I am a bit unsure of the semantics of this tag. Does it mean no later version, whereas that is normally allowed? In the issue linked by Tomas, the user had VS2015 installed, which surely comes with some more advanced version of MSBuild, so perhaps this tag prevented use of the VS2015 MSBuild assemblies?
If we want to bundle, which might be a good idea, I'm not sure yet, then I can test that bundling .NET MSBuild works on Linux/OSX.
I do think that MSBuild should be provided as a NuGet package. There actually is a recently created package at https://www.nuget.org/packages/MSBuild/, but I'm not sure if the maintainer is connected with the project.
@rojepp I agree, but I guess we are where we are.

No one likes msbuild but unfortunately until someone re-writes what it provides for us we have to use it.  Luckily its open source so we can see the source.  ARAIK the latest mono has msbuild14
Interestingly Roslyn has a hard dependency on msbuild14 too.

@tpetricek Probably the simplest interim solution is for you to push a nuget package ("FSharp.Compiler.Service.Dependencies"?) containing the MSBuild binaries (and an .fsx script to load/reference them). Then add that as a dependency to those projects/samples using FSharp.Compiler.Service delivered to non dev machines.

@rneatherway Yes, I think you're right.
We need a list of what versions of the MSBuild SDK binaries are made available by which versions of Mono/VS/WindowsSDK. It seems:
MSBuild <IP_ADDRESS> - Widely available as bundled with .NET 4.x
MSBuild <IP_ADDRESS> - Installed with Visual Studio 2013 (actually the Windows SDK?)
MSBuild <IP_ADDRESS> - Installed with Visual Studio 2015 (actually the Windows SDK?)
But what about Mono?
cheers
don

This is the current situation:
Mono JIT compiler version 4.0.1 (tarball Tue Apr 28 11:47:58 UTC 2015)
$ gacutil -l Microsoft.Build
Microsoft.Build, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Microsoft.Build, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Microsoft.Build, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Number of items = 3

I'm not sure if MSBuild 14 is the MS open-source release. It would be great if so.
Another possibility is to add a binding redirect to FCS from MSBuild 12 up to 14. Is it possible to do that for a library, if not we could recommend it for applications that use FCS, as with your note on FSharp.Core. That note is incredibly useful btw.

@rneatherway Thanks for the info.  (Do you know which Linux package has the MSBuild DLLs?  I presume it's not in the "minimal" mono runtime installation, but is in "mono-devel"?)
The binding redirects (or a runtime assembly binding using Assembly Load Event?) are an interesting possibility

@rneatherway Could you also show the gacutil -l for Microsoft.Build.Framework please? (I assume is that on Linux?)
I notice MSBuild.exe.config on Windows has the following binding redirects (and so does devenv.exe.config), so it certainly is valid to use binding redirects for these assemblies.
        <dependentAssembly>
            <assemblyIdentity name="Microsoft.Build.Framework" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
            <bindingRedirect oldVersion="<IP_ADDRESS>-<IP_ADDRESS>" newVersion="<IP_ADDRESS>"/>
        </dependentAssembly>
        <dependentAssembly>
            <assemblyIdentity name="Microsoft.Build.Engine" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
            <bindingRedirect oldVersion="<IP_ADDRESS>-<IP_ADDRESS>" newVersion="<IP_ADDRESS>"/>
        </dependentAssembly>
        <dependentAssembly>
            <assemblyIdentity name="Microsoft.Build" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
            <bindingRedirect oldVersion="<IP_ADDRESS>-<IP_ADDRESS>" newVersion="<IP_ADDRESS>"/>
        </dependentAssembly>
        <dependentAssembly>
            <assemblyIdentity name="Microsoft.Build.Conversion.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
            <bindingRedirect oldVersion="<IP_ADDRESS>-<IP_ADDRESS>" newVersion="<IP_ADDRESS>"/>
        </dependentAssembly>
        <dependentAssembly>
            <assemblyIdentity name="Microsoft.Build.Tasks.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
            <bindingRedirect oldVersion="<IP_ADDRESS>-<IP_ADDRESS>" newVersion="<IP_ADDRESS>"/>
        </dependentAssembly>
        <dependentAssembly>
            <assemblyIdentity name="Microsoft.Build.Utilities.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
            <bindingRedirect oldVersion="<IP_ADDRESS>-<IP_ADDRESS>" newVersion="<IP_ADDRESS>"/>
        </dependentAssembly>

@dsyme it is really split up amongst a bunch of packages.
$ dpkg -S Microsoft.Build | cut -d':' -f1 | sort -u
libmono-microsoft-build4.0-cil
libmono-microsoft-build-engine4.0-cil
libmono-microsoft-build-engine4.0-cil, mono-xbuild
libmono-microsoft-build-framework4.0-cil
libmono-microsoft-build-tasks-v4.0-4.0-cil
libmono-microsoft-build-utilities-v4.0-4.0-cil
mono-devel
mono-xbuild

It's pretty strange, the full breakdown is:
$ dpkg -S Microsoft.Build*dll | sort
libmono-microsoft-build4.0-cil: /usr/lib/mono/4.5/Microsoft.Build.dll
libmono-microsoft-build4.0-cil: /usr/lib/mono/gac/Microsoft.Build/<IP_ADDRESS>__b03f5f7f11d50a3a/Microsoft.Build.dll
libmono-microsoft-build-engine4.0-cil: /usr/lib/mono/4.5/Microsoft.Build.Engine.dll
libmono-microsoft-build-engine4.0-cil: /usr/lib/mono/gac/Microsoft.Build.Engine/<IP_ADDRESS>__b03f5f7f11d50a3a/Microsoft.Build.Engine.dll
libmono-microsoft-build-framework4.0-cil: /usr/lib/mono/4.5/Microsoft.Build.Framework.dll
libmono-microsoft-build-framework4.0-cil: /usr/lib/mono/gac/Microsoft.Build.Framework/<IP_ADDRESS>__b03f5f7f11d50a3a/Microsoft.Build.Framework.dll
libmono-microsoft-build-tasks-v4.0-4.0-cil: /usr/lib/mono/4.5/Microsoft.Build.Tasks.v4.0.dll
libmono-microsoft-build-tasks-v4.0-4.0-cil: /usr/lib/mono/gac/Microsoft.Build.Tasks.v4.0/<IP_ADDRESS>__b03f5f7f11d50a3a/Microsoft.Build.Tasks.v4.0.dll
libmono-microsoft-build-utilities-v4.0-4.0-cil: /usr/lib/mono/4.5/Microsoft.Build.Utilities.v4.0.dll
libmono-microsoft-build-utilities-v4.0-4.0-cil: /usr/lib/mono/gac/Microsoft.Build.Utilities.v4.0/<IP_ADDRESS>__b03f5f7f11d50a3a/Microsoft.Build.Utilities.v4.0.dll
mono-devel: /usr/lib/mono/2.0/Microsoft.Build.Engine.dll
mono-devel: /usr/lib/mono/2.0/Microsoft.Build.Framework.dll
mono-devel: /usr/lib/mono/2.0/Microsoft.Build.Tasks.dll
mono-devel: /usr/lib/mono/2.0/Microsoft.Build.Utilities.dll
mono-devel: /usr/lib/mono/3.5/Microsoft.Build.Engine.dll
mono-devel: /usr/lib/mono/3.5/Microsoft.Build.Framework.dll
mono-devel: /usr/lib/mono/3.5/Microsoft.Build.Tasks.v3.5.dll
mono-devel: /usr/lib/mono/3.5/Microsoft.Build.Utilities.v3.5.dll
mono-devel: /usr/lib/mono/4.0/Microsoft.Build.dll
mono-devel: /usr/lib/mono/4.0/Microsoft.Build.Engine.dll
mono-devel: /usr/lib/mono/4.0/Microsoft.Build.Framework.dll
mono-devel: /usr/lib/mono/4.0/Microsoft.Build.Tasks.v4.0.dll
mono-devel: /usr/lib/mono/4.0/Microsoft.Build.Utilities.v4.0.dll
mono-xbuild: /usr/lib/mono/gac/Microsoft.Build/<IP_ADDRESS>__b03f5f7f11d50a3a/Microsoft.Build.dll
mono-xbuild: /usr/lib/mono/gac/Microsoft.Build/<IP_ADDRESS>__b03f5f7f11d50a3a/Microsoft.Build.dll
mono-xbuild: /usr/lib/mono/gac/Microsoft.Build.Engine/<IP_ADDRESS>__b03f5f7f11d50a3a/Microsoft.Build.Engine.dll
mono-xbuild: /usr/lib/mono/gac/Microsoft.Build.Engine/<IP_ADDRESS>__b03f5f7f11d50a3a/Microsoft.Build.Engine.dll
mono-xbuild: /usr/lib/mono/gac/Microsoft.Build.Framework/<IP_ADDRESS>__b03f5f7f11d50a3a/Microsoft.Build.Framework.dll
mono-xbuild: /usr/lib/mono/gac/Microsoft.Build.Framework/<IP_ADDRESS>__b03f5f7f11d50a3a/Microsoft.Build.Framework.dll
mono-xbuild: /usr/lib/mono/gac/Microsoft.Build.Tasks.Core/<IP_ADDRESS>__b03f5f7f11d50a3a/Microsoft.Build.Tasks.Core.dll
mono-xbuild: /usr/lib/mono/gac/Microsoft.Build.Tasks.v12.0/<IP_ADDRESS>__b03f5f7f11d50a3a/Microsoft.Build.Tasks.v12.0.dll
mono-xbuild: /usr/lib/mono/gac/Microsoft.Build.Utilities.Core/<IP_ADDRESS>__b03f5f7f11d50a3a/Microsoft.Build.Utilities.Core.dll
mono-xbuild: /usr/lib/mono/gac/Microsoft.Build.Utilities.v12.0/<IP_ADDRESS>__b03f5f7f11d50a3a/Microsoft.Build.Utilities.v12.0.dll
mono-xbuild: /usr/lib/mono/xbuild/12.0/bin/Microsoft.Build.dll
mono-xbuild: /usr/lib/mono/xbuild/12.0/bin/Microsoft.Build.Engine.dll
mono-xbuild: /usr/lib/mono/xbuild/12.0/bin/Microsoft.Build.Framework.dll
mono-xbuild: /usr/lib/mono/xbuild/12.0/bin/Microsoft.Build.Tasks.v12.0.dll
mono-xbuild: /usr/lib/mono/xbuild/12.0/bin/Microsoft.Build.Utilities.v12.0.dll
mono-xbuild: /usr/lib/mono/xbuild/14.0/bin/Microsoft.Build.dll
mono-xbuild: /usr/lib/mono/xbuild/14.0/bin/Microsoft.Build.Engine.dll
mono-xbuild: /usr/lib/mono/xbuild/14.0/bin/Microsoft.Build.Framework.dll
mono-xbuild: /usr/lib/mono/xbuild/14.0/bin/Microsoft.Build.Tasks.Core.dll
mono-xbuild: /usr/lib/mono/xbuild/14.0/bin/Microsoft.Build.Utilities.Core.dll

So MSBuild versions:

.NET < 4.5: Provided by mono-devel, placed under /usr/lib/mono/$FRAMEWORK, not symlinked to GAC
.NET = 4.5: Provided by libmono-microsoft-build*. Placed in /usr/lib/mono/4.5, symlinked to the GAC versions <IP_ADDRESS>
(VS) 12 and 14: Provided by mono-xbuild, placed in /usr/lib/mono/xbuild/$VSVERSION/bin, symlinked to corresponding GAC versions.

Also:
$ gacutil -l Microsoft.Build.Framework
The following assemblies are installed into the GAC:
Microsoft.Build.Framework, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Microsoft.Build.Framework, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Microsoft.Build.Framework, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Number of items = 3

The xbuild.exe that gets called by /usr/bin/xbuild has a similar redirect:
$ cat /usr/lib/mono/xbuild/12.0/bin/xbuild.exe.config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
	<runtime>
		<generatePublisherEvidence enabled="false" />
		<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
			<dependentAssembly>
				<assemblyIdentity name="Microsoft.Build.Framework" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
				<bindingRedirect oldVersion="<IP_ADDRESS>-<IP_ADDRESS>" newVersion="<IP_ADDRESS>" />
			</dependentAssembly>
			<dependentAssembly>
				<assemblyIdentity name="Microsoft.Build.Engine" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
				<bindingRedirect oldVersion="<IP_ADDRESS>-<IP_ADDRESS>" newVersion="<IP_ADDRESS>" />
			</dependentAssembly>
		</assemblyBinding>
	</runtime>
</configuration>

The one under 14.0 redirects to the 14.0 assemblies, but it isn't the default yet.
I think that understanding and addressing this issue may allow us to resolve #342 as well.

I changed the PR so that it builds a separate package (FSharp.Compiler.Service.Standalone) rather than changing the existing one to include the MSBUILD assemblies. Let me know if this sounds like a good option for now.
Doing this is still not optimal, because I'm not sure what you'd do if you wanted to use, say F# Formatting (which has FCS dependency) but with FCS.Standalone. But it at least gives us a starting point that we can use for the web scenarios.
Having FCS.Lightweight without MSBUILD dependencies would be even cooler though. We could certainly change F# Formatting to use that instead.

I think we should probably go ahead and merge this. As it adds a new package it seems fairly harmless, and it has cropped up elsewhere as well. The more people have VS2015 installed and not VS2013 the worse it will get.

Wouldn't that just lead to errors with missing *.targets files?

Hmm, do you think the VisualStudioVersion will cause it to look in a non-existent place? Troubling. This is a nightmare. I can't easily create a machine with just VS2015 either.

I'd prefer not to merge as is, at least not yet. Adding another nuget package to FCS which includes MSBuild binaries makes the FCS project responsible for distributing a bunch of MSBuild binaries in a non-standard configuration. This seems like the wrong direction without really extensive testing of the functionality this does/doesn't enable (see these two features - as I understand it the PR doesn't really enable either feature) . From past experience, if we add an extra nuget package it will be years before we remove it.
That said, we certainly have a real problem here and we need to document it and enable a workaround.
@tpetricek - do you think you can do as I suggested here and create a separate package (in a separate repo) that provides the MSBuild binaries? Then submit a guide like this one which explains what the MSBuild dependencies are and how to use the interim package to avoid having a specific version of MSBuild on the target machine?
@rneatherway - another option is that we reflection-bind to MSBuild - either V4.0 or v12.0, so we have no static dependencies to MSBuild at all.  If no MSBuild is bindable then feature 1 "reference resolution" falls back to simple resolution, and feature 2 "Project Cracking" fails with an informative exception.  We could test both scenarios via fault injection.
Thanks,
Don

Theres still underlying issues with project cracking too, the whole operation needs to be done via a separate process to support redirecting msbuild tasks to the right version.

Closing as we now have https://github.com/fsharp/FSharp.Compiler.Service/isues/470


Upgrade to Terraform v0.12.16

Upgrade to Terraform v0.12.16 so that terraform fmt works on Terraform upgraded code.

Closing this um-merged. I am addressing these updates elsewhere.


[v4] Mega PR (part 2)

About this pull request
This is a dupe of #357 except:

This does not recursively set Optionals to None if not given via the initial approach.

Likewise, slotting in *.py has been reverted back to *.pyi.

Currently, a draft PR until scheduled events are integrated :) (and possibly other minor things Discord added)

Changes

(self explanatory above)

Checklist

[X] I've run the pre_push.py script to format and lint code.
[X] I've checked this pull request runs on Python 3.6.X.
[ ] This fixes something in Issues.

Issue:

[X] This adds something new.
[X] There is/are breaking change(s).
[X] (If required) Relevant documentation has been updated/added.
[ ] This is not a code change. (README, docs, etc.)

motherfucking jesus AWOO AWOO 😭


Families smart select use family instead label

Context:
Light task opened in Maya. Access to creator (Openpype -> Create)
Problem:
In the creator panel, the family ins't set automatically on Render.

Cause & Solution:
The Family Smart object is wrong.

Switch "Render" to "rendering".

PR => https://github.com/ynput/OpenPype/pull/5128


Reenable logs (e.g. when server error occurred)

Follow up of #256

In theory we can utilize JSON logging in k8s Loki. In practice we don't yet. I don't have strong opinion on either formatting, I got used to JSON output by now.


zh-trans: fix wrong links for doc-zh

检查了所有能够匹配到相应中文页面的相对链接，将链接指向对应的中文页面

/assign @chenrui333

[trans-bot:N/A]
Thank you @SataQiu, there are more than 1 files in your PR, will not be reported to the task issues.

/hold
This makes no sense. Could it be some HUGO configuration problem?

嗯，看上去需要了解 hugo 的 config setup 😆


Single cpu build doesn't work

Describe the bug
Library build fails in case of using REQCPU="avx2" option for build.
To Reproduce
Steps to reproduce the behavior:

Checkout sources
Call make with make daal -j4 PLAT=lnx32e COMPILER=gnu REQCPU="avx2"
Build fails

Expected behavior
Library should be successfully build with optimization for selected and base CPUs
Output/Screenshots
Public CI run - https://github.com/intel/daal/runs/219127300
In file included from ./algorithms/kernel/adaboost/adaboost_predict_kernel.h:29:0,
                 from ./algorithms/kernel/adaboost/adaboost_predict_batch_container.h:29,
                 from ./algorithms/kernel/adaboost/adaboost_predict_dense_default_batch_fpt_dispatcher.cpp:26:
./algorithms/kernel/kernel.h:58:83: error: expected identifier before ‘;’ token
 extern template class DAAL_KERNEL_SSSE3_CONTAINER1(ContainerTemplate, __VA_ARGS__);              \

Environment:

OS: Any
Compiler: Any
Version: DAAL 2020

Hello @napetrov !
We have some period of time when "one cpu" build was broken. But it should be fixed by first commit of @orazve . Could you verify it?
Andrey


Use the Google Play "In-App-Review" API

Instead of opening Google Play to rate the app, we should use the embedded API "In-App-Review":
https://developer.android.com/guide/playcore/in-app-review

Note: Only Google Play variants should implement this

could I tackle this? Thanks!

My initial idea was to let my students implement it tomorrow.
it does not bother you @lailajs ?

You can take it @lailajs (my students won't have the time to work on it today)

Is-it ok for you @lailajs?

Any news @lailajs?

Yes! I’ll be working on it this week as part of a school project. Thank you
On Fri, Apr 8, 2022 at 4:51 PM Edouard Marquez @.***>
wrote:

Any news @lailajs https://github.com/lailajs?
—
Reply to this email directly, view it on GitHub
https://github.com/openfoodfacts/openfoodfacts-androidapp/issues/4600#issuecomment-1093353805,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANIXDCWPOQ2G72SRL27N44DVECL5PANCNFSM5RO2BLMA
.
You are receiving this because you were mentioned.Message ID:
@.***>

hey @g123k, im looking through the repo code, and was wondering if you have any ideas of where the best  place to implement this feature is. Thank you so much!

It's already implemented in the app.
In the MainActivity, you have the showFeedbackDialog method, which is called on a user is logged in

ohh okay I see! So what exactly is my task then? the current code makes the user leave the app right?

The current code doesn’t use the Rating API from the Google Play.
That’s the change required in this issue

Yes, I see. Just to make sure, the current code redirects the user to the google play store, right? Im a beginner in Kotlin and just want to make sure!

Yes.
You should test the app, you will how the workflow works

Do you know if its possible to run the android version on my iphone? i dont have any android devices, and I'm not sure how to run the app without one

There is an emulator on Android, directly available on Android Studio

its so weird, when i run the app it only runs open beauty facts.. not open food facts, does that happen for you?

I don't want to offense you, but regarding your questions I suggest you to take some time to learn the basics of the Android programming


ARROW-18184: [C++] Improve JSON parser benchmarks

See: ARROW-18184.
For context, this is based on pull/14100.
This enhances the capabilities of the existing random JSON generators and adds benchmark coverage for ordered/unordered fields, missing fields, and inferred schemas over a range of field counts.

Since the null_probability "fix" is now gone, I got rid of the related helper functions and moved the vector allocation + extra loop out of the non-shuffling path.

CI passed on submitter's fork, will merge.


Missing S3PostUploadSignedPolicy when using in .NET Core class library

Expected Behavior
Amazon.S3.Util.S3PostUploadSignedPolicy class should exist.
Current Behavior
Amazon.S3.Util.S3PostUploadSignedPolicy class not found when using in .NET Core class library.
Note: Works fine if using in .NET Framework class library.
Steps to Reproduce (for bugs)

Create a .NET Core 2.1 class library.
Add AWSSDK.S3 package.
Add using Amazon.S3.Util;
S3PostUploadSignedPolicy class not found.

Your Environment

AWSSDK.Core version used: <IP_ADDRESS>
AWSSDK.S3 version used: <IP_ADDRESS>
Service assembly and version used:

#region Assembly AWSSDK.S3, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=885c28607f98e604
// .nuget\packages\awssdk.s3\<IP_ADDRESS>\lib\netstandard1.3\AWSSDK.S3.dll
#endregion

Visual Studio version: VS 2017 15.8.6
Targeted .NET platform: .NET Core 2.1

.NET Core Info

.NET Core version used for development: 2.1
.NET Core version installed in the environment where application runs: 2.1
Output of dotnet --info:

.NET Core SDK (reflecting any global.json):
 Version:   2.1.402
 Commit:    3599f217f4

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.402\

Host (useful for support):
  Version: 2.1.4
  Commit:  85255dde3e

.NET Core SDKs installed:
  1.0.4 [C:\Program Files\dotnet\sdk]
  1.1.0 [C:\Program Files\dotnet\sdk]
  2.0.2 [C:\Program Files\dotnet\sdk]
  2.0.3 [C:\Program Files\dotnet\sdk]
  2.1.2 [C:\Program Files\dotnet\sdk]
  2.1.4 [C:\Program Files\dotnet\sdk]
  2.1.101 [C:\Program Files\dotnet\sdk]
  2.1.103 [C:\Program Files\dotnet\sdk]
  2.1.104 [C:\Program Files\dotnet\sdk]
  2.1.200 [C:\Program Files\dotnet\sdk]
  2.1.201 [C:\Program Files\dotnet\sdk]
  2.1.202 [C:\Program Files\dotnet\sdk]
  2.1.400 [C:\Program Files\dotnet\sdk]
  2.1.401 [C:\Program Files\dotnet\sdk]
  2.1.402 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.3-servicing-26724-03 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

Contents of project.json/project.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.1</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="AWSSDK.S3" Version="<IP_ADDRESS>" />
    <PackageReference Include="MailChimp.Net.V3" Version="3.4.0" />
    <PackageReference Include="Newtonsoft.Json" Version="11.0.2" />
    <PackageReference Include="Sendgrid" Version="9.10.0" />
    <PackageReference Include="System.Drawing.Common" Version="4.5.1" />
  </ItemGroup>
</Project>

Hello @mattrichnz, thank you for bringing this to our attention.  Due to the differences in .NET Framework and Core, not everything will be compatible.  However, upon first review, I did not notice anything that seemed like this would be the case.   I'll work on raising the team's attention to this and see if we can get it supported for .NET Core.

@klaytaybai Thanks so much. I’m currenly migrating a .NET Framework API to ASP.NET Core 2.1 API hosted in Lambda, so very keen on getting this going as soon as possible!

@klaytaybai Investigation shows that S3PostUploadSignedPolicy.cs exists in _bcl+unity but not for _bcl+coreclr - I believe this is the issue.

Changed to use a presigned URL which is available in the .NET Core NuGet package.

Why was this closed?
S3PostUploadSignedPolicy  is still missing from .NET Core SDK!

@mbergal I’ve reopened this issue.

Hey @normj,  we have team that has use case for this functionality. They are planning to allow their client (a browser) to upload files to S3. They want this functionality to apply a size restriction on the file.
Because this isn't supported they are going to need to instead implement this in nodejs, which isn't a problem, but does mean that a lot of the internal standardisation tooling we have  to support .NET core Lambdas will need to be rebuilt in Javascript.
Is there anyway to prioritise this? We're happy to work on a PR with you if that will help?

Hey folks, has there been any progress on this? We need specific functionality that is only available using a Post Policy and not a presigned URL (specifically: allowing the client to specify content type of the uploaded file).
We're using .Net Core 3.1 and S3PostUploadSignedPolicy is not available, I can see no way to create a signed policy otherwise—unfortunately rebuilding in JS is not an option for us. Thanks!

Hey folks, has there been any progress on this? We need specific functionality that is only available using a Post Policy and not a presigned URL (specifically: allowing the client to specify content type of the uploaded file).
We're using .Net Core 3.1 and S3PostUploadSignedPolicy is not available, I can see no way to create a signed policy otherwise—unfortunately rebuilding in JS is not an option for us. Thanks!

(for anyone reading this in the same position, we were forced to use NodeServices, which is an obsolete feature of dotnet core, in this PR to interface with the JS SDK and create a presigned Post Policy that way, which works but is not ideal 😅)

(for anyone reading this in the same position, we were forced to use NodeServices, which is an obsolete feature of dotnet core, in this PR to interface with the JS SDK and create a presigned Post Policy that way, which works but is not ideal 😅)

BCL version: https://github.com/aws/aws-sdk-net/blob/master/sdk/src/Services/S3/Custom/Util/_bcl/S3PostUploadSignedPolicy.cs

Please prioritize this. This is an important feature for .NET based web developers. Not sure how we can contribute, but please let us know if we can.

Still waiting for this to be added


Unable to assume ec2 IAM role through local kubernetes

Describe the bug
I'm working on kubernetes components that interact with AWS services through ec2 instances that have assumed IAM roles.
I am unable to get aws-sdk-rust calls to resolve correctly due to missing credential errors.
Similar issues:
#606
#425

Proof of concept rust code:
// [dependencies]
// aws-config = "0.48.0"
// aws-sdk-sts = "0.18.0"
// tokio = { version = "1.20.1", features = ["full"] }

#[tokio::main]
async fn main() {
    let conf = aws_config::from_env().region("us-west-2").load().await;

    let client = aws_sdk_sts::Client::new(&conf);
    let res = client.get_caller_identity().send().await;
    println!("caller_identity = {:#?}", res)
}

When the above program is run on my local hosts, I get the expected results. All seems good here!
$ cargo run
   Compiling sts-poc v0.1.0 (/home/fedora/workspace/ssm-poc/ssm-poc)
    Finished dev [unoptimized + debuginfo] target(s) in 4.91s
     Running `target/debug/sts-poc`
caller_identity = Ok(
    GetCallerIdentityOutput {
        user_id: Some(
            <redacted>,
        ),
        account: Some(
            <redacted>,
        ),
        arn: Some(
            "arn:aws:sts::<redacted>:assumed-role/<redacted>",
        ),
    },
)

Expected Behavior
When my host with the assumed role runs a container, I'd expect aws-sdk-rust to be able to also assume that host's role.
Current Behavior
However, when run through a local kubernetes cluster (kind), I hit the ConstructionFailure(MissingCredentials) error:
Reproduction Steps
Along with the above rust proof of concept program, use the following dockerfile and pod yaml:

Dockerfile:
FROM rust
WORKDIR sts-poc
COPY ./ /sts-poc
RUN cargo build --release
CMD ["./target/release/sts-poc"]

Kubernetes pod yaml named run-aws-sdk.yaml
apiVersion: v1
kind: Pod
metadata:
  name: sts-poc
  namespace: default
spec:
  containers:
  - image: sts-poc:demo
    name: sts-proof-of-concept

Create a kind cluster

$ kind create cluster --name demo

Create the container image using docker. Tag it as sts-poc:demo

$ docker build . -t sts-poc:demo

Load the image into the kind cluster:

$ kind load docker-image --name demo sts-poc:demo

Apply the pod yaml:

$ kubectl apply -f run-aws-poc.yaml

Check the logs from the pod. Notice the error.

$ kubectl logs sts-poc
caller_identity = Err(
    ConstructionFailure(
        MissingCredentials,
    ),
)

Possible Solution
Are there things in my environment I'm missing? Other issues on this topic made it seem like this should "just work" ™
Version
$ cargo tree | rg aws
├── aws-config v0.48.0
│   ├── aws-http v0.48.0
│   │   ├── aws-smithy-http v0.48.0
│   │   │   ├── aws-smithy-types v0.48.0
│   │   ├── aws-smithy-types v0.48.0 (*)
│   │   ├── aws-types v0.48.0
│   │   │   ├── aws-smithy-async v0.48.0
│   │   │   ├── aws-smithy-client v0.48.0
│   │   │   │   ├── aws-smithy-async v0.48.0 (*)
│   │   │   │   ├── aws-smithy-http v0.48.0 (*)
│   │   │   │   ├── aws-smithy-http-tower v0.48.0
│   │   │   │   │   ├── aws-smithy-http v0.48.0 (*)
│   │   │   │   ├── aws-smithy-types v0.48.0 (*)
│   │   │   ├── aws-smithy-http v0.48.0 (*)
│   │   │   ├── aws-smithy-types v0.48.0 (*)
│   ├── aws-sdk-sso v0.18.0
│   │   ├── aws-endpoint v0.48.0
│   │   │   ├── aws-smithy-http v0.48.0 (*)
│   │   │   ├── aws-smithy-types v0.48.0 (*)
│   │   │   ├── aws-types v0.48.0 (*)
│   │   ├── aws-http v0.48.0 (*)
│   │   ├── aws-sig-auth v0.48.0
│   │   │   ├── aws-sigv4 v0.48.0
│   │   │   │   ├── aws-smithy-http v0.48.0 (*)
│   │   │   ├── aws-smithy-http v0.48.0 (*)
│   │   │   ├── aws-types v0.48.0 (*)
│   │   ├── aws-smithy-async v0.48.0 (*)
│   │   ├── aws-smithy-client v0.48.0 (*)
│   │   ├── aws-smithy-http v0.48.0 (*)
│   │   ├── aws-smithy-http-tower v0.48.0 (*)
│   │   ├── aws-smithy-json v0.48.0
│   │   │   └── aws-smithy-types v0.48.0 (*)
│   │   ├── aws-smithy-types v0.48.0 (*)
│   │   ├── aws-types v0.48.0 (*)
│   ├── aws-sdk-sts v0.18.0
│   │   ├── aws-endpoint v0.48.0 (*)
│   │   ├── aws-http v0.48.0 (*)
│   │   ├── aws-sig-auth v0.48.0 (*)
│   │   ├── aws-smithy-async v0.48.0 (*)
│   │   ├── aws-smithy-client v0.48.0 (*)
│   │   ├── aws-smithy-http v0.48.0 (*)
│   │   ├── aws-smithy-http-tower v0.48.0 (*)
│   │   ├── aws-smithy-query v0.48.0
│   │   │   ├── aws-smithy-types v0.48.0 (*)
│   │   ├── aws-smithy-types v0.48.0 (*)
│   │   ├── aws-smithy-xml v0.48.0
│   │   ├── aws-types v0.48.0 (*)
│   ├── aws-smithy-async v0.48.0 (*)
│   ├── aws-smithy-client v0.48.0 (*)
│   ├── aws-smithy-http v0.48.0 (*)
│   ├── aws-smithy-http-tower v0.48.0 (*)
│   ├── aws-smithy-json v0.48.0 (*)
│   ├── aws-smithy-types v0.48.0 (*)
│   ├── aws-types v0.48.0 (*)
├── aws-sdk-sts v0.18.0 (*)

Environment details (OS name and version, etc.)
Fedora 34, kernel 5.11.12, aarch64

Docker build logs
$ docker build . -t sts-poc:demo
Sending build context to Docker daemon  1.329GB
Step 1/5 : FROM rust
---> ab88ceb21a7d
Step 2/5 : WORKDIR sts-poc
---> Using cache
---> ca4a7ec4d0dc
Step 3/5 : COPY ./ /sts-poc
---> d6b97d1263e8
Step 4/5 : RUN cargo build --release
---> Running in c8f64db3cb91
Updating crates.io index
Downloading crates ...

Can you include detailed logs from when you hit the ConstructionFailure(MissingCredentials) error?

The only logs that are returned by the pod are:
caller_identity = Err(
    ConstructionFailure(
        MissingCredentials,
    ),
)

I've updated the text of the top level post to be more clear as well as added docker build logs

This doesn't appear to be related to IMDSv2 or the hop limit. This is what my instance looks like:
{
    "InstanceId": "i-<redacted>",
    "InstanceMetadataOptions": {
        "State": "pending",
        "HttpTokens": "required",
        "HttpPutResponseHopLimit": 2,
        "HttpEndpoint": "enabled",
        "HttpProtocolIpv6": "disabled",
        "InstanceMetadataTags": "disabled"
    }
}

I get the same results:
❯ k logs pods/sts-poc
caller_identity = Err(
    ConstructionFailure(
        MissingCredentials,
    ),
)

I've observed this same issue with plain Docker containers on an EC2 instance using the same proof-of-concept Rust code and Dockerfile as @jpmcb:
$ docker run --rm -it sts-poc:demo
caller_identity = Err(
    DispatchFailure(
        DispatchFailure {
            source: ConnectorError {
                kind: Other(
                    None,
                ),
                source: CredentialsNotLoaded(
                    CredentialsNotLoaded {
                        source: "no providers in chain provided credentials",
                    },
                ),
                connection: Unknown,
            },
        },
    ),
)

However I've found a simple workaround by setting the Docker network mode to host:
$ docker run --rm -it --network=host sts-poc:demo
caller_identity = Ok(
    GetCallerIdentityOutput {
        user_id: Some(
            <redacted>,
        ),
        account: Some(
            <redacted>,
        ),
        arn: Some(
            "arn:aws:sts::<redacted>:assumed-role/<redacted>",
        ),
        _request_id: Some(
            <redacted>,
        ),
    },
)

The AWS CLI appears to retrieve the credentials correctly when run from within the container even without host networking enabled. My hunch is some faulty fetching of the EC2 instance metadata for nonstandard network interfaces on the SDK side.

if you did this by setting the docker network mode to host, then this sounds like the hop-limit issue—you've removed a hop by setting the docker network mode to host.


Board Review: Management Plane Namespace Review Elastic

Thank you for submitting this review request. Thorough review of your management library namespaces ensures that your library names are consistent with the guidelines and the consumers of your management library have a consistently good experience when using Azure.
To ensure consistency, all language library names will generally be reviewed together.
Before submitting, ensure you adjust the title of the issue appropriately.
Note that the required material must be included before a meeting can be scheduled.
Contacts and Timeline

Responsible service team: Liftr-Elastic
Main contacts: @jkore1911
Expected release date: 15-09-2024

About the Service (required)

Link to documentation introducing/describing the service: https://devdividc.azurewebsites.net/liftr/ElasticDocV2/Home.html
Link to the service REST APIs Specs: [azure-rest-api-specs/specification/elastic/resource-manager/Microsoft.Elastic/stable/2024-03-01 at main · Azure/azure-rest-api-specs (github.com)]

Namespace Proposals (required per language)
In the examples below please replace every occurrence of [ResourceProviderName] with your the service resource provider name. Be sure to keep the casing shown with [ResourceProviderName] when replacing it with the service resource provider name.

.NET: Azure.ResourceManager.elastic
Java: azure-resourcemanager-elastic (com.azure.resourcemanager.elastic)
Go/Golang: sdk/resourcemanager/elastic/armelastic
JavaScript: @azure/arm-elastic
Python: azure-mgmt-elastic

Thank you!

@jkore1911, please update the proposed namespaces for Java, Go, JavaScript and Python to only use lowercase letters.
Thank you.

@ronniegeraghty, updated.

@ronniegeraghty, updated.

.NET should have been left as it. .NET uses capital letters in it's package names.

@ronniegeraghty , ok

Elastic feels like its a bit generic, when I click the link above to learn more about the service it goes to an empty page?
@jkore1911 can you help provide context around what the service does?

@m-nash, can u check this link.
https://devdividc.azurewebsites.net/liftr/ElasticDocV2/Home.html

@m-nash , You can access it here
https://github.com/Azure/azure-sdk/issues/url

Hey @jkore1911 , is this the ElasticSearch?

Yes, it is ElasticSearch
Made the required changes in the namespace.

Now we'll move on to the second phase of the MGMT Plane Namespace approval process, where the names will be shown to our architect team. The architects will have 1 week to make any objections to the namespaces. If there are no objections by end of business on 9/6 the names will be considered approved, and I will leave a comment on this issue state so.

Hi @ronniegeraghty, any update on this ?

Hi @jkore1911,
The week is up and there have been no objections from our architects. The namespaces in the description of this issue are considered approved.


pixel_type more explicit and extended

I have extended pixel_type to include more types and to be more
explicit.  The handling of floats is not yet done.  It is also not
yet clear to me why an assert wasn't working for me.  I think the values
were equivalent, just not represented the same.
This isn't ready to be merged yet, I've just pushed it for review: @wtolson
I am still trying to figure out how to express IEEE_REAL and PC_REAL in numpy.
refs #16

Actually, if I take the resulting img.data from the HiRISE PC_REAL example and do img.data.newbyteorder('<') it looks right.
Also, it would probably be more succinct if I used the <f4 or >i2 notation for creating these.  I don't understand that notation yet, so I will have to look into it.

:( broken, shame felt, looks like I need to ensure sample_bytes is an int.

I like how this has worked out.
This notebook kind of indicates the status
http://nbviewer.ipython.org/urls/gist.githubusercontent.com/godber/2530f95e2986655ecaac/raw/Test_All.ipynb
Here are the data products in a json file:
https://gist.githubusercontent.com/godber/34a7639cfc457150f22c/raw/4d1e3745f8e68a0d7b6106cf5cd2fba4102fb074/mission_data.json
I think I understand most of the failures here:

Mastcam PDS products fail because of JPEG compression
ESP_030168_1755_BG12_0.IMG fails because RECORD_BYTES isn't present.  The parse_pointer method should be called differently to support this type.
W1782844276_1.LBL will be handled by #18
RA_090929123307_PIX3_LIN.LBL no idea what this should look like

Not sure whats up with M1166071628ME.IMG.


CAMEL-18126: improved split support for the file component

Note: I am also running external tests for this one, so I'll merge it when/if those tests pass.

Note: I am also running external tests for this one, so I'll merge it when/if those tests pass.

My local tests ran without problems. The actions were failing due to an outage on Github.


[WIP] fix travis-ci

I've restored the gcc and clang builds and have the python test closer to working again, but marked it as allowed to fail (for now).


Head yaw/pitch sync

attach_to should synchronize a head bone automatically separately based on the head of the entity, separate from the body, when appropriate.

There should ideally be a generic API toolset for any bone to have a custom position/rotation separate from its normal value


position flickers when accessing bounds onEnterFrame (html5)

This is how to reproduce it with NyanCat, positioning it on 50,50, and then tracing height on ENTER_FRAME:
public function new () {

            super ();

            var cat = Assets.getMovieClip ("library:NyanCatAnimation");
            cat.x = 50;
            cat.y = 50;
            addChild (cat);

            addEventListener(Event.ENTER_FRAME, function(event:Event) { trace(cat.height); });

}

Then:
openfl test html5
And the cat movie clip will flicker, between 0,0 and 50,50.

This is since 5.0.0

Thank you for the simple test case. Previously, we did an update of all the matrix transforms immediately before rendering, but adding cacheAsBitmap has led to (surprise!) more caching. Please let me know if you experience anything else like this!


[SVG output] options for selecting fonts

As a designer, I want to customize fonts.

Oddly enough, mjpage did not, so technically a new feature.

This applies only to the CLI tool.


cmake: dts: Use temporary file for dts.cmake with sysbuild

Uses a temporary file when sysbuild is being used for images then uses CMake to copy to the correct file if it has changed. This prevents a ping-pong of configuring and building cycle when nothing has changed and there is sysbuild code which loads in the devicetree data from an image
Upstream PR #: 81340

@trantanen when a PR in sdk-zephyr is a fromlist, then please give review comments in the linked upstream PR: zephyr:81340
and not in the downstream fromlist.

@trantanen when a PR in sdk-zephyr is a fromlist, then please give review comments in the linked upstream PR: zephyr:81340 and not in the downstream fromlist.

Sorry about that. I noticed there was upstream PR only after reviewing. I didn't pay attention this was fromlist as I don't tend to look at commits but just the changes of the PR as a whole. And there was no link to upstream but later realized the PR number is there but you don't link them anymore to avoid spamming in upstream.


getNamedReference doesn`t return EntityReference type

When I call getNamedReference, I expect to see an etn value.
Instead I have _etn or logicalName
My package.json

{
"name": "pcf-project",
"version": "1.0.1",
"description": "Project containing your PowerApps Component Framework (PCF) control.",
"scripts": {
"build": "pcf-scripts build",
"clean": "pcf-scripts clean",
"rebuild": "pcf-scripts rebuild",
"start": "pcf-scripts start"
},
"dependencies": {
"@ant-design/colors": "^4.0.5",
"@types/node": "^10.12.18",
"@types/powerapps-component-framework": "^1.2.3",
"@types/react": "^16.9.46",
"@types/react-dom": "^16.9.8",
"gantt-task-react": "^0.1.5",
"react": "^16.13.1",
"react-dom": "^16.13.1"
},
"devDependencies": {
"pcf-scripts": "^1",
"pcf-start": "^1"
}
}

https://docs.microsoft.com/en-us/powerapps/developer/component-framework/reference/entityrecord/getnamedreference

@MaTeMaTuK Thanks for the feedback. This is a known issue and we are fixing it. Will update it when we finish fixing the issue.

Duplicate of #https://github.com/MicrosoftDocs/powerapps-docs/issues/1465. Closing the issue here. Please follow the other issue for updates on this.


Clang format

Format the codebase with the defaults from the LLVM style, but with 4 columns indentation.
Style option are in the .clang-format
Build on top of PR #14

LGTM, thanks!


Support live migrate a vm to a specified node

Is your feature request related to a problem? Please describe:
I've looked live migration related docs and APIs, but seems there's no way to make a vm live migrate to a specified node.
Describe the solution you'd like:
Maybe add a target object to vmim spec , like below :
type VirtualMachineInstanceMigrationSpec struct {
    // The name of the VMI to perform the migration on. VMI must exist in the migration objects namespace
    VMIName string `json:"vmiName,omitempty" valid:"required"`
    // The name of the target node where the VMI want
    TargetNodeName string `json:"targetNodeName,omitempty"`
}

Describe alternatives you've considered:
n/a
Additional context:
n/a

Hi @chenxinlong, note that the idea is to let the scheduler figure out where the VM should be migrated to.
Have you tried adding some affinity rules?

I haven't try it.
How should I do ?  Firstly update the spec of vmi(modify schedule related properties) and then create a vmim ?

How should I do ? Firstly update the spec of vmi(modify schedule related properties) and then create a vmim ?

Create the VM, apply node affinity rule and start the migration.
See the following node-affinity rule example, it should make the VM schedule at "node02.example.com" node:
apiVersion: kubevirt.io/v1
kind: VirtualMachine
  name: vm-cirros
spec:
  running: true
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/hostname
                operator: In
                values:
                - node02.example.com
...

How should I do ? Firstly update the spec of vmi(modify schedule related properties) and then create a vmim ?

Create the VM, apply node affinity rule and start the migration. See the following node-affinity rule example, it should make the VM schedule at "node02.example.com" node:
apiVersion: kubevirt.io/v1
kind: VirtualMachine
  name: vm-cirros
spec:
  running: true
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/hostname
                operator: In
                values:
                - node02.example.com
...

it doesn't work. because if vm has started, the patch don't work on the pod of vm.

it doesn't work. because if vm has started, the patch don't work on the pod of vm.

You right, changes in  VM spec.template manifest after the VM gets restated (e.g.: virtctl restart),
but in that case, there is no point in migration because the VM is re-created.
Sorry for the confusion, I didn't understand the scenario well.
@enp0s3 do you know if and when it will be possible to migrate VM to a specific node?


0.17.0

Implements https://github.com/jupyterlab/jupyterlab_geojson/issues/27.
Depends on jupyterlab 0.17.0.
This allows users to specify a tileset and tile layer options via the display class:
from jupyterlab_geojson import GeoJSON
GeoJSON(data={
    "type": "Feature",
    "geometry": {
        "type": "Point",
        "coordinates": [11.8, -45.04]
    }
}, url_template="http://s3-eu-west-1.amazonaws.com/whereonmars.cartodb.net/{basemap_id}/{z}/{x}/{y}.png",
layer_options={
    "basemap_id": "mola-color",
    "attribution" : "NASA/MOLA",
    "tms": True,
    "minZoom" : 0,
    "maxZoom" : 6
})

Other improvements:

Add support .geo.json file extension
Re-center map on jupyterlab resize events: Closes https://github.com/jupyterlab/jupyterlab_geojson/issues/20 and https://github.com/jupyterlab/jupyterlab_geojson/issues/22

Can you remind me, does this work with all kinds of protocols? I’m also confused, GeoJSON isn’t a protocol for transporting data across the web, right? It’s just a container for accessing things either local or remote?

If there’s a good intro I should read into all this net-mapping, I’d be happy to get a recommendation! I want to get that new super CTX working in Jupyter: https://twitter.com/erroneoustholus/status/1112786087858966528?s=21

The supported geojson-extension uses leaflet to render GeoJSON data (JSON representation of geography, see https://github.com/jupyterlab/jupyter-renderers/tree/master/packages/geojson-extension#usage for examples). ipyleaflet is a ipywidget that also uses leaflet but allow you to create maps using leaflet primitives vs. just GeoJSON.


Support pydantic v2

Hi Pierce.
Do you have any plans to support Pydantic v2?
From running the unit tests with pyproject.toml edited for Pydantic v2, the main point where errors occur is at value.type_ here::
gpt_json/prompts.py
32:            elif issubclass(value.type_, BaseModel):
33:                payload.append(f'"{key}": {generate_payload(value.type_)}')
35:                payload.append(f'"{key}": {value.type_.__name__.lower()}')

Hey @stevesimmons, yes Pydantic 2 is certainly on my list. Let me investigate over the weekend to see if the fix is an easy one and I'll get back to you.

Put up an initial PR to support both V1 and V2. It's passing the current test cases, but give it a try in your deployment and give a shout if anything seems amiss:
https://github.com/piercefreeman/gpt-json/pull/37


As a user I want a good typographic scale in an established font  to make it easy to read and perceive content on the pages

Acceptance criteria

Typographic scales that suit multiple devices are implemented
Base font size/s is/are established
The web pages use the Equinor font

In order to ensure good quality we should

Extra focus on usability
Test for accessibility
Perform performance and load test when the font loads
Perform user testing

Sub-tasks

[x] #165 Design and implement a typographic scale
[x] #166 Add Equinor font

Started refactoring the news article. Also made a Power App for calculating values for the CSS clamp function. It’s in the Heap Purple teams channel in Teams.


irregular error with comma operator

In my project within the following code, the last line errors out.
  var args = Array.prototype.slice.call( arguments );
  args[0] = error( args[0] );

  callback && callback.apply( commit, (args.push( commit ), args) );

Line 46 callback && callback.apply( commit, (args.push( commit ), args) );
Expected ')' to match '(' from line 46 and instead saw ','.
This is, however, completely valid use of the , operator.

CoffeeScript lexer also has an error with the following:
var _ref, count, starts, compact, last;
_ref = test, count = _ref.count, starts = _ref.starts, compact = _ref.compact, last = _ref.last;

getting an error with comma operator as well, see this issue for details:
https://github.com/jshint/node-jshint/issues/78


VS Code does not call resolveDebugConfigurationWithSubstitutedVariables

VS Code Version: 1.80.0
OS Version: Windows_NT x64 10.0.19045

Steps to Reproduce:

Install C# dev kit
Clone C# extension and start debugging the extension
Create a .NET console app (I tried .NET 6 or .NET 7)
Open Program.cs and click F5. Select C#:

Expected
The debugger gets queried for its configuration variables and start debugging.
Actual
C# extension registers two debug providers, but the second provider, BaseVsDbgConfigurationProvider.resolveDebugConfigurationWithSubstitutedVariables (which implements vscode.DebugConfigurationProvider) is never called.
Remarks

If you have a launch.json with a profile type specified (only one provider is used), step 5 is called.
If you start debugging from the project in Solution Explorer window (from C# dev kit extension, so only one provider is used), step 5 is called.

This is the launch request for the repro scenario:
-> (C) {"command":"launch","arguments":{"name":"C#: ConsoleApp47","request":"launch","type":"coreclr","launchConfigurationId":"TargetFramework=;ConsoleApp47"}

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.80.1. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

Updated to 1.80.1 and verified that the issue also reproduces there. Thanks!

I believe the issue is resolveDebugConfigurationWithSubstitutedVariables is being called on type and not resolvedConfig.type
https://github.com/microsoft/vscode/blob/8451eb531c801f345a3f1c94e0effdafee089867/src/vs/workbench/contrib/debug/browser/debugService.ts#L496

This bug has been fixed in the latest release of VS Code Insiders!
@isadorasophia, you can help us out by commenting /verified if things are now working as expected.
If things still don't seem right, please ensure you're on version 1091f68d834974d78cd4f9769034b4ae4581ff2a of Insiders (today's or later - you can use Help: About in the command palette to check), and leave a comment letting us know what isn't working as expected.
Happy Coding!

@isadorasophia bump on if this fix has been verified?

The original repro steps don't work for me with dotnet SDK 7:
F5 fails to launch for step 4

Some Debug Console output
stack trace: Error: Cannot find language server in path 'c:\Users\raymondzhao\work\vscode-csharp\.roslyn\Microsoft.CodeAnalysis.LanguageServer.dll'
	at getServerPath (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:116329:15)
	at RoslynLanguageServer.<anonymous> (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115939:32)
	at Generator.next (<anonymous>)
	at c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115572:71
	at new Promise (<anonymous>)
	at __webpack_modules__../src/lsptoolshost/roslynLanguageServer.ts.__awaiter (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115568:12)
	at RoslynLanguageServer.startServer (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115938:16)
	at RoslynLanguageServer.<anonymous> (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115684:35)
	at Generator.next (<anonymous>)
	at c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115572:71
	at new Promise (<anonymous>)
	at __webpack_modules__../src/lsptoolshost/roslynLanguageServer.ts.__awaiter (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115568:12)
	at serverOptions (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115683:41)
	at RoslynLanguageClient.createMessageTransports (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:165521:20)
	at RoslynLanguageClient.createConnection (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:156482:39)
	at RoslynLanguageClient.start (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:156022:43)
	at RoslynLanguageServer.<anonymous> (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115716:26)
	at Generator.next (<anonymous>)
	at c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115572:71
	at new Promise (<anonymous>)
	at __webpack_modules__../src/lsptoolshost/roslynLanguageServer.ts.__awaiter (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115568:12)
	at RoslynLanguageServer.initializeAsync (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115682:16)
	at c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:116280:59
	at Generator.next (<anonymous>)
	at c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115572:71
	at new Promise (<anonymous>)
	at __webpack_modules__../src/lsptoolshost/roslynLanguageServer.ts.__awaiter (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115568:12)
	at activateRoslynLanguageServer (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:116273:12)
	at c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:117304:106
	at Generator.next (<anonymous>)
	at fulfilled (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:117173:58)

The original repro steps don't work for me with dotnet SDK 7:
F5 fails to launch for step 4

Some Debug Console output
stack trace: Error: Cannot find language server in path 'c:\Users\raymondzhao\work\vscode-csharp\.roslyn\Microsoft.CodeAnalysis.LanguageServer.dll'
	at getServerPath (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:116329:15)
	at RoslynLanguageServer.<anonymous> (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115939:32)
	at Generator.next (<anonymous>)
	at c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115572:71
	at new Promise (<anonymous>)
	at __webpack_modules__../src/lsptoolshost/roslynLanguageServer.ts.__awaiter (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115568:12)
	at RoslynLanguageServer.startServer (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115938:16)
	at RoslynLanguageServer.<anonymous> (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115684:35)
	at Generator.next (<anonymous>)
	at c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115572:71
	at new Promise (<anonymous>)
	at __webpack_modules__../src/lsptoolshost/roslynLanguageServer.ts.__awaiter (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115568:12)
	at serverOptions (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115683:41)
	at RoslynLanguageClient.createMessageTransports (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:165521:20)
	at RoslynLanguageClient.createConnection (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:156482:39)
	at RoslynLanguageClient.start (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:156022:43)
	at RoslynLanguageServer.<anonymous> (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115716:26)
	at Generator.next (<anonymous>)
	at c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115572:71
	at new Promise (<anonymous>)
	at __webpack_modules__../src/lsptoolshost/roslynLanguageServer.ts.__awaiter (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115568:12)
	at RoslynLanguageServer.initializeAsync (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115682:16)
	at c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:116280:59
	at Generator.next (<anonymous>)
	at c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115572:71
	at new Promise (<anonymous>)
	at __webpack_modules__../src/lsptoolshost/roslynLanguageServer.ts.__awaiter (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:115568:12)
	at activateRoslynLanguageServer (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:116273:12)
	at c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:117304:106
	at Generator.next (<anonymous>)
	at fulfilled (c:\Users\raymondzhao\work\vscode-csharp\dist\extension.js:117173:58)

Thanks, I verified that this problem was addressed in VS Code 1.86.0-insider.
/verified


Crate readme and rustdoc description of ockam_vault_sync_core

Crate readme and rustdoc description of ockam_vault_sync_core does not match
https://github.com/ockam-network/ockam/blob/23b3c5d4d1c7501858fd34293bcd0f18a1174bfd/implementations/rust/ockam/ockam_vault_sync_core/src/lib.rs#L1-L5
https://github.com/ockam-network/ockam/blob/b5cb97aa858de1ba547951db66346ab8d68c50ad/implementations/rust/ockam/ockam_vault_sync_core/README.md#L11-L12

@mrinalwadhwa this crate does not exist anymore, can we close this issue?

up ☝  @mrinalwadhwa


[SceneViewer] AR not working on new installations/after new update.

Description
Hi,
after update of Google App from 14th May 2021 (v. <IP_ADDRESS>.arm) SceneViewer stopped working in "ar_only" mode which is used in model-viewer.
To reproduce

Uninstall updates of Google App
Install them again
Go to https://modelviewer.dev/examples/augmentedreality/#sceneViewer and try to place model in AR.
It results in error such as "File could not be loaded". It seems it happens because SceneViewer doesn't have permissions to camera etc. and app fails and exits before user can grant those permissions. If I run SceneViewer app in "3d_preferred" mode which is used in Google AR examples (like duck or other animals) and then switch to ar mode, I can grant those permissions and model loads in AR. After I grant those permissions opening any model in "ar_only" mode (via model-viewer) also works correctly.

It is really a major bug that just breaks usage of SceneViewer.
OS

[x] Android
[ ] iOS
[ ] Linux
[ ] MacOS
[ ] Windows

AR

[ ] WebXR
[x] SceneViewer
[ ] QuickLook

Entering AR-Mode from none "ar_only" has the same problem.

Not just new installations. All devices which have the update installed have this problem. Even if permissions were previously granted and appear in app settings. Uninstalling the update aka switching to preinstalled Google App version is working.

We have the same problem, scene viewer doesn't open any of the objects on android 10, but seems to work fine on Android 11.

After whining for weeks about the previous bug, I am now in the funny situation that it works on my phone. I am on Samsung Note10+ with Android 11, the Google version is the one from May 14th

I am also experiencing the issue on android 11

All our android devices at the office are experiening the same issue.
"It is really a major bug that just breaks usage of SceneViewer."
Yes it is!
Any ideia how to escalate this issue to the google UI team?

All our android devices at the office are experiening the same issue.
"It is really a major bug that just breaks usage of SceneViewer."
Yes it is!
Any ideia how to escalate this issue to the google UI team?

by adding @AdrianAtGoogle and @tpsiaki - I think

While the Scene Viewer issue is being worked on, this seems like a good time to ask about your thoughts on WebXR. What are the reasons you prefer Scene Viewer to WebXR mode? We just improved the object placement flow in WebXR and added two-finger rotation. I'm curious what our next priorities should be, since WebXR mode is the only way to enable hotspots and variants and such.

While the Scene Viewer issue is being worked on, this seems like a good time to ask about your thoughts on WebXR. What are the reasons you prefer Scene Viewer to WebXR mode? We just improved the object placement flow in WebXR and added two-finger rotation. I'm curious what our next priorities should be, since WebXR mode is the only way to enable hotspots and variants and such.

My biggest issue is cross-platform compatibility. We run https://cldxr.com - the goal is that our clients upload one file once - and then it works no matter if the end users are on iOS or Android. And it needs to be possible to standardize things.
Scene viewer is easy to handle, the USDZ for iOS we auto-generate.
If you can offer better solutions we can integrate and works on Android and iOS out of the box - perfect.

We put WebXR as our default AR mode precisely because it's available on all the devices Scene Viewer is, and doesn't require an extra download of either file or app (Scene Viewer is part of the Google App, which not everyone has). It also stays in the browser, which gives you much more control of the experience and analytics. Give it a try and let us know if you find anything lacking. The console will now report errors in our latest version and explain why a particular AR mode was chosen.

Well - was excited to see a Google update, thought you guys are quick, but it was the update that now also killed it on my phone...

While the Scene Viewer issue is being worked on, this seems like a good time to ask about your thoughts on WebXR. What are the reasons you prefer Scene Viewer to WebXR mode? We just improved the object placement flow in WebXR and added two-finger rotation. I'm curious what our next priorities should be, since WebXR mode is the only way to enable hotspots and variants and such.

@elalish, last time we tested WebXR (2020Q3) the experience seemed very slower than Scene-Viewer. Meaning that in the same device the FPS was higher in Scene-Viewer AR Mode. I really prefer the ability to make interactive models and UIs on WebXR, but the overall flow of the experience is what made me choose not to change. Since the new updates involves a lot of WebXR features, I'm about to test the new version and see if we can suggest anything. Maybe there should be a space for feedback? 🤔

About the issue, I recorded the current problem:
https://user-images.githubusercontent.com/49691924/118556832-ba81ff80-b73a-11eb-8c46-ba61d600e172.mp4

@FelipeR2U Feel free to open a discussion about WebXR! Feedback would be much appreciated.

Submitted a SceneViewer fix for this issue - should be out in the next release

For people experiencing this issue who have control over their intent URLs, switching to 'mode=ar_preferred' allows the camera permission popup to be accepted and the AR session started without the "couldn't load object" popover, although the user has a flash of the non-AR 3D UI.
We're lucky enough to generate all our intent URLs on-the-fly (even for QRs, which was a worry!) so we're switching to this until the update resolves the issue.

While the Scene Viewer issue is being worked on, this seems like a good time to ask about your thoughts on WebXR. What are the reasons you prefer Scene Viewer to WebXR mode? We just improved the object placement flow in WebXR and added two-finger rotation. I'm curious what our next priorities should be, since WebXR mode is the only way to enable hotspots and variants and such.

WebXR mode is very cool, gives a lot of extra features and possibilities. Generally it would be my "go to" technology regarding AR, but it is currently supported only on chrome and samsung browsers and doesn't work on IOS devices at all. Having extra features that are only available on specific devices/browsers is not a good idea and limiting a solution only to Android and Chrome is also not a good idea. Until Safari and other browsers implement WebXR I don't think I will use it in my cross-platform projects.
Regarding WebXR implementation:

there is no user guidance, model just shows up in front of user and places on the floor when it finds it. But there is no prompt or anything saying that user should point the camera on the ground and move a phone from side to side to find a floor.
no scale information when scaling model

While the Scene Viewer issue is being worked on, this seems like a good time to ask about your thoughts on WebXR. What are the reasons you prefer Scene Viewer to WebXR mode? We just improved the object placement flow in WebXR and added two-finger rotation. I'm curious what our next priorities should be, since WebXR mode is the only way to enable hotspots and variants and such.

WebXR is great, the only missing feature stopping me from using it is the possibility for the user to capture photos and videos as this is highly requested (and expected, unfortunately) by clients.

While the Scene Viewer issue is being worked on, this seems like a good time to ask about your thoughts on WebXR. What are the reasons you prefer Scene Viewer to WebXR mode? We just improved the object placement flow in WebXR and added two-finger rotation. I'm curious what our next priorities should be, since WebXR mode is the only way to enable hotspots and variants and such.

I use WebXR as a default, BUT if a user opens link in an app (which is a lot of cases) than it uses Android WebView instead of Chrome - and then SceneViewer is the only option and a nice fallback. Otherwise my page would be broken.

While the Scene Viewer issue is being worked on, this seems like a good time to ask about your thoughts on WebXR. What are the reasons you prefer Scene Viewer to WebXR mode? We just improved the object placement flow in WebXR and added two-finger rotation. I'm curious what our next priorities should be, since WebXR mode is the only way to enable hotspots and variants and such.

WebXR mode is very cool, gives a lot of extra features and possibilities. Generally it would be my "go to" technology regarding AR, but it is currently supported only on chrome and samsung browsers and doesn't work on IOS devices at all. Having extra features that are only available on specific devices/browsers is not a good idea and limiting a solution only to Android and Chrome is also not a good idea. Until Safari and other browsers implement WebXR I don't think I will use it in my cross-platform projects.

I honestly don't mind too much telling a mobile user to use Chrome if they are on Android and as far as the iOS issue is concerned, I understand that this is covered (mostly) with the latest 1.7 model viewer update?

Regarding WebXR implementation:
* there is no user guidance, model just shows up in front of user and places on the floor when it finds it. But there is no prompt or anything saying that user should point the camera on the ground and move a phone from side to side to find a floor.

* no scale information when scaling model

Those are very good points - plus the fact that scene viewer easily allows to capture photos and videos.

Same error is happening to me when using scene-viewer. WIth webxr works fine. Hoping you can fix it.

For people experiencing this issue who have control over their intent URLs, switching to 'mode=ar_preferred' allows the camera permission popup to be accepted and the AR session started without the "couldn't load object" popover, although the user has a flash of the non-AR 3D UI.
We're lucky enough to generate all our intent URLs on-the-fly (even for QRs, which was a worry!) so we're switching to this until the update resolves the issue.

that was a good tip, thanks!

Could you perhaps elaborate on the intent URL modification? Should I intercept model-viewer event to modify it?

There is also something strange going on with the iOS side. After viewing the USDz file in AR for about a minute its lists the file name and size with a 'done' prompt...? It's never done this before.

@MicDesign1 That sounds worthy of it's own issue, given it's unrelated to this Scene Viewer thread (we can't launch Scene Viewer on iOS, only Quick Look). Can you fill out the issue template so we can repro? A screen recording would be great too.


No module named 'zipline.api'; 'zipline' is not a package when debugging in VS, VS Code, Pycharm

Dear Zipline Maintainers,
Before I tell you about my issue, let me describe my environment:

Operating System: (Windows Version 10)
Python Version: $ python --version 3.5
How did you install Zipline: (conda)
Python packages:  All required as zipline conda environment works excellent with ipython/jupyter notebook, but don't work with debuggers

Now that you know a little about me, let me tell you about the issue I am
having:
Zipline conda environment works fine with VS Code interactive interpretter / Jupyter notebook / VS Interactive interpretter(Ipython or command line works well)
When I run debugger in VS Code / VS  / Pycharm , import zipline works,
When I run debugger in VS Code / VS  / Pycharm , from zimpline.api import symbol or from zipline import run_algorithm I'm receiving error message No module named 'zipline.api'; 'zipline' is not a package
Description of Issue

What did you expect to happen?
When run in editor from zipline.api import symbol, order, record no error during debugging
What happened instead?
When run in editor debugger error message No module named 'zipline.api'; 'zipline' is not a package

Here is how you can reproduce this issue on your machine:
Reproduction Steps

Write to editor from zipline.api import symbol, order, record
in VS or VS code, pycharm press debug
Error message: No module named 'zipline.api'; 'zipline' is not a package
...

What steps have you taken to resolve this already?
I have checked in VS Code terminal that debugger use correct environment, below is terminal output:
(env_zipline) g:\Google Drive\FI\02_Research\zipline>cd "g:\Google Drive\FI\02_Research\zipline" && cmd /C "set "PYTHONIOENCODING=UTF-8" && set "PYTHONUNBUFFERED=1" && C:\Users\sutyke\Anaconda3\envs\env_zipline\python.exe c:\Users\sutyke\.vscode\extensions\ms-python.python-2019.10.44104\pythonFiles\ptvsd_launcher.py --default --client --host localhost --port 59017 "g:\Google Drive\FI\02_Research\zipline\zipline.py" "...
What else:
From command line in env_zipline python -c "import zipline;print(zipline.__version__)" i get v1.3.0
From command line in env_zipline python -c "from zipline.api import symbol, order, record" no error msg all works fine
Below is error message from pycharm, when I press Run>file.py or Shift+F10: I get error message below:
C:\Users\sutyke\Anaconda3\envs\env_zipline\python.exe "G:/Google Drive/FI/02_Research/zipline/zipline.py"
Traceback (most recent call last):
  File "G:/Google Drive/FI/02_Research/zipline/zipline.py", line 3, in <module>
    import zipline
  File "G:\Google Drive\FI\02_Research\zipline\zipline.py", line 5, in <module>
    from zipline.api import symbol, order, record
ImportError: No module named 'zipline.api'; 'zipline' is not a package

Process finished with exit code 1

Or if I write in pycharm editor from zipline import run_algorithm and run Shift+F10
C:\Users\sutyke\Anaconda3\envs\env_zipline\python.exe "G:/Google Drive/FI/02_Research/zipline/zipline.py"
Traceback (most recent call last):
  File "G:/Google Drive/FI/02_Research/zipline/zipline.py", line 3, in <module>
    from zipline import run_algorithm
  File "G:\Google Drive\FI\02_Research\zipline\zipline.py", line 3, in <module>
    from zipline import run_algorithm
ImportError: cannot import name 'run_algorithm'

Process finished with exit code 1

Sincerely,
$ whoami

I just replicated those steps and worked fine for me.
I'm using the latest version of conda and Pycharm.

Curiously, I experience the same issue in Atom with the Hydrogen plugin but not in the command line

https://stackoverflow.com/questions/43207427/using-anaconda-environment-in-atom https://stackoverflow.com/questions/43207427/using-anaconda-environment-in-atom

El 14 dic 2019, a las 5:23, Beng<EMAIL_ADDRESS>escribió:
Curiously, I experience the same issue in Atom with the Hydrogen plugin but not in the command line
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/quantopian/zipline/issues/2575?email_source=notifications&email_token=AAQOLRNOX6R5DFOCFLYTQE3QYRNUFA5CNFSM4JLJWFU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG3ZZFY#issuecomment-565681303, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQOLROIBRRGUS5IZ6JCJ2DQYRNUFANCNFSM4JLJWFUQ.


feat(biome_css_analyzer): noShorthandPropertyOverrides

Summary

close #2807
Implement declaration-block-no-shorthand-property-overrides
Test Plan

added tests and snapshots

I believe we can accept the regressions for now

@neokidev can you send a PR to update the changelog?

@neokidev can you send a PR to update the changelog?

@ematipico I created the PR(#3163).


Looking for Drivers for Lenovo ThinkBook

Hi,
we are using Version 7.2.0 and try to implement Drivers for Lenovo ThinkBook.
I have no Model available.
When searching for drivers it looks at
https://download.lenovo.com/cdrt/td/catalogv2.xml
Is this an issue with the Driver Automation Tool or does Lenovo not provide Drivers for these kind of models?

Lenovo does not provide drivers for this model in catalog,


Nape physics debug draw; ignoring shape.localCOM; all shapes center middle

Tried to fix it by adding offset without success at https://github.com/underscorediscovery/luxe/blob/master/luxe/physics/nape/DebugDraw.hx#L243

Could you provide some example code of what exactly you're doing? I tried creating some shapes, changing their COMs and adding them to bodies, and they seem to draw fine.

The body has a bottom displacement of 8: https://github.com/alesegdia/evoswonie/blob/master/project/src/entity/Player.hx#L112
Adding the body to the physics debug drawer: https://github.com/alesegdia/evoswonie/blob/master/project/src/entity/GameWorld.hx#L16
You can see the debug circle is drawn in the center, but it collides a little lower as expected.
http://alesegdia.github.io/vswn/

Should be fixed in f39e5f01e848412102be33e80e8010304a7178a7.
Small tip on the side: For nape vectors, you'd generally use Vec2.get() / Vec2.weak() instead of new Vec2(). Just noticed it while looking at the code.


Paypal Express Checkout - JMS

I am trying to test Paypal Express Checkout - JMS on http://sandbox.payum.org/other/prepare_paypal_via_jms_plugin
This error is displayed:
"Cannot find right api supported by Payum\Bridge\JMSPayment\Action\CaptureAction"
Could you take a look please?

@thiphamyp It worked a long time ago but I haven't tested it for months. Could be broken.
I'll try to fix it on weekends.

Fixed in 1.2.1 version. Make sure you have payum bundle >=2.0
Changes: https://github.com/Payum/JMSPaymentBridge/commit/ed9ec56a8fb1d17bb8e1a28037dc20842db4a36b


Mining Devices Killed

I have run the grin and then I run the miner, it connect but disconnect soon.
the miner status is : Waiting for the server
Last Message Sent : Get new job
Last Message Received : None

Old issue, closing. Feel free to reopen if this is still relevant.


Discovery: add component for featured channels

This feature will add a new component at the top of the Discovery page that contains featured channels. Those are specific channels we want to highlight. For example when we want to highlight specific channels. These could be a new additions. This list of channels should be synced when the user is online, so that we have control of it and can update it accordingly.

Initially we wanted to have the featured channels as part of each content collection, and we decided to use the external tags for that: T34311
@erikos what would be the advantage of having this information online? So far we don't have any "sync when online" logic, we rely on Kolibri Studio for everything online related to content.

Blocking this until we have some clarification on the question above.
The question can be reduced to: Do we want the featured channels to be fetched from somewhere online (like github releases)? Or do we waht them to be shipped within the app (like current content packs)?

@manuq The channels are coming from the user's library.
When the content is refreshed (when they are online at school, for example). They might get content from a channel they didn't have previously. For example:

We have secured a new Coding Education Partner's content.
The content goes to the top of the recommendations list, because we want to promote it.
The channel card gets featured.

I've added more information here: https://github.com/endlessm/endless-key-content-private/issues/12

I will start simple:

Reuse the tags mechanism by tagging the root node of channels with "featured"
Display featured channels in the Discovery page as a card row
Don't touch the content update for now. It will continue happening as software updates. It can be changed to "fetch online" in the future.

I will assume that the collection manifest files will have that tag at one point. I will try with a custom JSON. I will open a feature request later for the packs editor.
This should be easy as it's no longer a special case like (T34311)[https://phabricator.endlessm.com/T34311] was. In that one the content of each featured channel was displayed and rotated weekly.

Ready for review: #538
I used a modified artist pack that adds the featured-channel tag to 4 channels: https://github.com/endlessm/endless-key-collections/compare/wip-featured-channels?expand=1#diff-d74e40460fa3ad73684a58e1cffc558a2ff9139591994839148e1a6eb6ba6de1
This is how it looks:

If there aren't any featured channel the UI would be the same as before so we shouldn't block merging this prior to tweaks inb content or packs editor.
I also made sure that only channels (root nodes) are added to this row. So if a content node is tagged featured-channel by accident, the UI will not misbehave.

Steps for testing in a dev environment:

Put the modified artist JSON file in kolibri_explore_plugin/static/collections/artist-0001.json
Reset your KOLIBRI_HOME, example:

rm -rf $KOLIBRI_HOME
kolibri plugin enable kolibri_explore_plugin
kolibri manage migrate
kolibri manage provisiondevice --facility $FACILITY --superusername $USERNAME --superuserpassword $USERPASSWORD --language_id en --preset nonformal

Then run Kolibri with: KOLIBRI_INITIAL_CONTENT_PACK=artist yarn run devserver-hot

After the rebase, the "Your channels" row appears empty to me (and I followed the instructions on https://github.com/endlessm/kolibri-explore-plugin/issues/529#issuecomment-1555106897 an extra time to double check).
I'm also seeing the following warnings, which I did not remember seeing before the rebase, when running yarn serve from packages/template-ui:
 WARNING  Compiled with 2 warnings                                                                                4:22:30 PM

 warning  in ./src/dynamicRequireAsset.js

Module not found: Error: Can't resolve '@/overrides/assets' in '/sysroot/home/jprvita/src/kolibri-explore-plugin/packages/template-ui/src'

 warning  in ./src/dynamicLoadComponents.js

Module not found: Error: Can't resolve '@/overrides/components' in '/sysroot/home/jprvita/src/kolibri-explore-plugin/packages/template-ui/src'

@jprvita ready for review again. As you found out, the rebase was wrong. You won't need to go through the download again to re-test this because the rebase issue was for frontend only.
Please don't pay attention to those warnings when serving the template-ui. They have been there forever. I think we can get rid of them if we add assets/ and components/ directories in git revision (with dummy files inside for that to work).

It's verified passed in Ladybird 6.9-339

@heather has been using this feature: https://github.com/endlessm/endless-key-collections/commit/e58c955cf271b4534e32a900d493770ddf4ad4bb Looks like it is working.


PostUsage event returns status as null

Hello,
My Azure managed application is in preview mode . So does it mean PostUsageEventAsync event will be successful but response will be null ??
{
"status": null,
"effectiveStartTime": null,
"usageEventId": "00000000-0000-0000-0000-000000000000",
"messageTime": "0001-01-01T00:00:00",
"resourceId": "00000000-0000-0000-0000-000000000000",
"quantity": 0,
"dimension": null,
"planId": null,
"RequestID": null
}
Thanks
Hemant

This looks to be a bug in the code.
I will provide a PR for the fix in a bit!
Thank you for reporting the issue