Dependencies not found

It looks like that PackageReferences (dependencies) are not found if they are included with Microsoft.Build.CentralPackageVersions. Our project uses a Packages.props file that locks the version for all projects. This will prevent us from using BlackDuck.
Project configuration:
<!-- Foo.csproj -->
<ItemGroup>
  <PackageReference Include="DotNet.Testcontainers" Version="1.4.0" />
  <PackageReference Include="System.Composition" /> <!-- Missing in analysis -->
  <PackageReference Include="Bar.UI" /> <!-- Missing in analysis -->
</ItemGroup>

<!-- Packages.props -->
<Project>
  <ItemGroup>
    <GlobalPackageReference Include="StyleCop.Analyzers" Version="1.2.0-beta.321" /> <!-- Missing in analysis -->
    <PackageReference Update="System.Composition" Version="1.4.1" />
    <PackageReference Update="Bar.UI" Version="1.0.0" />
  </ItemGroup>
</Project>

BlackDuck output:
2021-03-23 09:24:43 DEBUG [main-Executable_Stream_Thread] --- Processing Project: Foo
2021-03-23 09:24:43 DEBUG [main-Executable_Stream_Thread] --- Using Project Directory: C:/.../src/.../Foo
2021-03-23 09:24:43 DEBUG [main-Executable_Stream_Thread] --- Attempting to parse configuration output paths.
2021-03-23 09:24:43 DEBUG [main-Executable_Stream_Thread] --- Project File: C:/.../src/.../Foo/Foo.csproj
2021-03-23 09:24:43 DEBUG [main-Executable_Stream_Thread] --- Skipping configuration output paths.
2021-03-23 09:24:43 DEBUG [main-Executable_Stream_Thread] --- Attempting reference resolver: C:/.../src/.../Foo
2021-03-23 09:24:43 DEBUG [main-Executable_Stream_Thread] --- Using backup XML resolver.
2021-03-23 09:24:43 DEBUG [main-Executable_Stream_Thread] --- Have not looked up package 'DotNet.Testcontainers', using metadata resources.
2021-03-23 09:24:43 DEBUG [main-Executable_Stream_Thread] --- No packages were found for DotNet.Testcontainers in any meta data resources.
2021-03-23 09:24:43 DEBUG [main-Executable_Stream_Thread] --- Nuget was unable to find the package 'DotNet.Testcontainers' with version range '[1.4.0, )', assuming it is using versio
2021-03-23 09:24:43 DEBUG [main-Executable_Stream_Thread] --- Found 1 dependencies among 1 packages.
2021-03-23 09:24:43 DEBUG [main-Executable_Stream_Thread] --- Finished processing project Foo which took 30 ms.

Are you running detect post-build? Typically you only see "Using backup XML resolver." (which means we parsed the project XML) when we don't find any build artifacts.

If that is not the issue, the next culprit would be that DotNet.Testcontainers is not published to the nuget repo the inspector is using. Are you using an internal nuget repository or is this an internal nuget package? Have you provided detect your nuget.config or otherwise properly configured the internal nuget repo?

We currently require the "project.assets.json" file be in an "obj" folder next to the project file. So "project/file.csproj" would expect "project/obj/project.assets.json". It's possible your project is putting that in a non-standard location, and if that is the case we would like to understand why and how we could support it across all project files.

Yes we override the default path to built all files into a global output directory. That's pretty common for large projects and Mircosoft supports to override the properties. See BaseIntermediateOutputPath in Common MSBuild project properties.
This resolves only to project/obj/project.assets.json:
https://github.com/blackducksoftware/nuget-dotnet3-inspector/blob/b7287a972ea5872045454c462fba2046995b33b7/NugetDotnet3Inspector/Inspection/Project/ProjectInspector.cs#L325
That's not correct for every build configuration.

Any updates?

I have not found a viable path forward yet.
The current inspector is unable to even reliably open project files, and that is only half the battle - most of these are stored in variables would have to be fully evaluated (expanded). It also appears that BaseIntermediateOutputPath is tied to the configuration you built.
And even if we do take in a folder ie --detect.nuget.artifact.directory=, its not a one to one with the project, for example with the monolinker project the redirect happens in the root folder so you get /obj//project.assets.json so it's not just taking in a location of a project.assets.json but matching generated artifacts to projects. And all of this has to be done in all three inspectors.
The best I can find, is that you can run "dotnet build /v:diag" and it prints the intermediate output path:
00:04:35.052 1>Project "/opt/project/src/dwCheckApi.sln" (1) is building "/opt/project/src/dwCheckApi/dwCheckApi.csproj" (2:5) on node 1 (_GenerateRestoreGraphProjectEntry target(s)).
00:04:38.250 2:5>Initial Properties:
BaseIntermediateOutputPath = /opt/project/src/dwCheckApi/obj/
IntermediateOutputPath = obj\Debug/netcoreapp2.1/
But this does not look like an easy to parse output file. And this means we have to start building the project for you (which we do for something like gradle) but this may mean we can deprecate the inspectors.
We are still looking into it, but as of now I am unsure what we will do.

it's not just taking in a location of a project.assets.json but matching generated artifacts to projects.

Can you explain that? I do not understand it. What else do you need? Maybe you can gather the missing information with Microsoft.Build. To accept more than just one project we can pass a list with project.assets.jsons or a wildcard to the detector.

We are unable to open the project using MSBuild - that's the only reason it falls back the parsing the XML in the first place. We do that here. And being unable to open the project means we can't use that to resolve the intermediate output path, at least as present.
As for finding the artifacts, it seems like for most cases the Project Name alone is used to indicate where the artifacts are placed. So if I have a project file at "parent/child/myproject.csproj" the artifacts are generated in "obj/myproject/project.assets.json". While in some cases this might be fine and cause no issues, I feel this has too many edge cases. Perhaps it doesn't but that still needs to be researched. However I think calling dotnet build with the additional arguments is the most viable at present.

We do that here.

I see. I should have take a look into the source code again 😀.

we can't use that to resolve the intermediate output path

If you just need the intermediate output path for each project, I can pass them as a list to the detector. Notice that the project.assets.json contains some project properties such as projectName, outputPath, etc. too.

With some small changes it seams to work. At least I'm able to load the *.csproj file and query all evaluated properties. It's not difficult. If you take a look at this article you should not deploy Microsoft.Build. It's also important to not:

reference any MSBuild types (from the Microsoft.Build namespace) in the method that calls MSBuildLocator.

This is the diff:
diff --git a/NugetDotnet3Inspector/NugetDotnet3Inspector.csproj b/NugetDotnet3Inspector/NugetDotnet3Inspector.csproj
index 1ff6099..78429b3 100644
--- a/NugetDotnet3Inspector/NugetDotnet3Inspector.csproj
+++ b/NugetDotnet3Inspector/NugetDotnet3Inspector.csproj
@@ -31,8 +31,10 @@
   </ItemGroup>

   <ItemGroup>
-    <PackageReference Include="Microsoft.Build" Version="15.9.20" />
-    <PackageReference Include="Microsoft.Build.Locator" Version="1.2.2" />
+
+    <PackageReference Include="Microsoft.Build" Version="15.9.20" ExcludeAssets="runtime" />
+    <PackageReference Include="Microsoft.Build.Utilities.Core" Version="15.9.20" ExcludeAssets="runtime" />
+    <PackageReference Include="Microsoft.Build.Locator" Version="1.4.1" />
     <PackageReference Include="Mono.Options" Version="<IP_ADDRESS>" />
     <PackageReference Include="NuGet.Client" Version="4.2.0" />
     <PackageReference Include="NuGet.ProjectModel" Version="4.8.0" />
diff --git a/NugetDotnet3Inspector/Program.cs b/NugetDotnet3Inspector/Program.cs
index 175c545..c050878 100644
--- a/NugetDotnet3Inspector/Program.cs
+++ b/NugetDotnet3Inspector/Program.cs
@@ -12,7 +12,7 @@ namespace IntegrationNugetInspectorPortable
 {
     class Program
     {
-        static void Main(string[] args)
+        static void Disabled(string[] args)
         {
             RegisterMSBuild();

namespace Com.Synopsys.Integration.Nuget.Dotnet3
{
    public static class Program1
    {
        private const string CSharpProjectPath = "xyz.csproj";

        static Program1()
        {
            MSBuildLocator.RegisterDefaults();
        }

        public static void Main(string[] args)
        {
            MethodThatCallsMsBuild();
        }

        private static void MethodThatCallsMsBuild()
        {
            var csproj = new Project(CSharpProjectPath);
            var properties = csproj.Properties.Select(property => $"{property.Name}: {property.EvaluatedValue}").ToArray();
            File.WriteAllLines("properties.log", properties);
        }
    }
}

Of course, MSBuild properties such as Configuration, Platform, etc. are not resolved. Although you can pass the configurations to the Project constructor but I don't know how to get the right values. Maybe you already have a solution for this.
Anyway, you can access the package references incl. their versions:
csproj.Items
  .Where(item => "PackageReference".Equals(item.ItemType, StringComparison.OrdinalIgnoreCase))
  .Select(item => $"{item.EvaluatedInclude} {item.Metadata.First(metaData => "Version".Equals(metaData.Name, StringComparison.OrdinalIgnoreCase)).EvaluatedValue}")
  .ToArray();

It may not be difficult with a trivial example project but I don't think it's that straight forward with real world projects. Even with your proposed changes I had projects already downloaded that were unable to be opened. If this does improve those numbers though I do think these changes should be made.
Projects I had that didn't work:

https://github.com/mono/linker
https://github.com/nkovacic/Sample-ASP.NET-project

I also had varied results across the dotnet3 and the dotnet5 inspector and I'm guessing the results would also not carry over to the dotnet2 and earlier inspector. I don't think this necessarily 'fixes' the problem but if it increases the number of projects we support I will put it on our radar.

Do you have the Microsoft.Build.dll in your output directory? Which MSBuild version gets registred? I think it's important not to register the Microsoft.Build package. Instead it should register the local version of Visual Studio / .NET SDK.

It may not be difficult with a trivial example project but I don't think it's that straight forward with real world projects. Even with your proposed changes I had projects already downloaded that were unable to be opened.

Well, I used exactly the solution / projects (more than 50) where BlackDuck (the detector) fails incl. various project sdks with CentralPackageVersions.

At least the first issue is related to missing a build sdk, specifically Arcade SDK. The second I believe is similar that there is an additional web sdk I need to have installed to open the project file. I don't think these are things we will be able to solve in the inspector code - I could be wrong. I did not have an MSBuild.dll in the output directory.
Like I said if it increases our support we should do it, but I would still like to find a solution that works for all projects.


How to register a property of type material?

I tried many ways, but none is working for me. Is there an example repository, or a tutorial, or docs?
There are virtually no examples beyond extremely basic ones (in GDNative-demos I didn't found any property which isn't of primitive type) and "docs" are redirecting to compilation of the engine, why?
My last attempt with Variant ended with editor crash:
[1] /lib/x86_64-linux-gnu/libc.so.6(+0x354b0) [0x7fd8e8ef44b0] (??:0)
[2] /xxx/Godot_v3.1-beta4_x11_64/Godot_v3.1-beta4_x11.64() [0x214619c] (??:?)
[3] /xxx/Godot_v3.1-beta4_x11_64/Godot_v3.1-beta4_x11.64() [0xca5881] (??:?)
[4] godot::Object* godot::get_wrapper<godot::Object>(void*) (??:0)
[5] void godot::register_property<godot::CPP, godot::Variant>(char const*, godot::Variant godot::CPP::*, godot::Variant, godot_method_rpc_mode, godot_property_usage_flags, godot_property_hint, godot::String) (??:0)
[6] godot::CPP::_register_methods() (??:0)
[7] void godot::register_class<godot::CPP>() (??:0)
[8] /mnt/veracrypt/old_ssd_data/workspace/godot/ugb-godot-3.1.beta3-cpp-2/demo/bin/x11/libgdexample.so(godot_nativescript_init+0x13) [0x7fd8c75a495b] (??:0)
[9] /xxx/Godot_v3.1-beta4_x11_64/Godot_v3.1-beta4_x11.64() [0xf49b6c] (??:?)
[10] /xxx/Godot_v3.1-beta4_x11_64/Godot_v3.1-beta4_x11.64() [0xa71a0f] (<artificial>:?)
[11] /xxx/Godot_v3.1-beta4_x11_64/Godot_v3.1-beta4_x11.64() [0xad649c] (<artificial>:?)
[12] /xxx/Godot_v3.1-beta4_x11_64/Godot_v3.1-beta4_x11.64() [0x20f3bdf] (??:?)
[13] /xxx/Godot_v3.1-beta4_x11_64/Godot_v3.1-beta4_x11.64() [0x219e151] (??:?)
[14] /xxx/Godot_v3.1-beta4_x11_64/Godot_v3.1-beta4_x11.64() [0x1d5cbf6] (<artificial>:?)
[15] /xxx/Godot_v3.1-beta4_x11_64/Godot_v3.1-beta4_x11.64() [0x2367bd7] (??:?)
[16] /xxx/Godot_v3.1-beta4_x11_64/Godot_v3.1-beta4_x11.64() [0xe15eb4] (??:?)
[17] /xxx/Godot_v3.1-beta4_x11_64/Godot_v3.1-beta4_x11.64() [0x2583a0e] (??:?)
[18] /xxx/Godot_v3.1-beta4_x11_64/Godot_v3.1-beta4_x11.64() [0x23463f2] (??:?)
[19] /xxx/Godot_v3.1-beta4_x11_64/Godot_v3.1-beta4_x11.64() [0x1513ea0] (<artificial>:?)
[20] /xxx/Godot_v3.1-beta4_x11_64/Godot_v3.1-beta4_x11.64() [0x1514558] (<artificial>:?)
[21] /xxx/Godot_v3.1-beta4_x11_64/Godot_v3.1-beta4_x11.64() [0xd11250] (??:?)
[22] /xxx/Godot_v3.1-beta4_x11_64/Godot_v3.1-beta4_x11.64() [0x1039c12] (<artificial>:?)
[23] /xxx/Godot_v3.1-beta4_x11_64/Godot_v3.1-beta4_x11.64() [0x20dd3c4] (??:?)
[24] /xxx/Godot_v3.1-beta4_x11_64/Godot_v3.1-beta4_x11.64() [0x160e67c] (<artificial>:?)
[25] /xxx/Godot_v3.1-beta4_x11_64/Godot_v3.1-beta4_x11.64() [0x160e5d3] (<artificial>:?)
[26] /xxx/Godot_v3.1-beta4_x11_64/Godot_v3.1-beta4_x11.64() [0x1693b17] (<artificial>:?)
[27] /xxx/Godot_v3.1-beta4_x11_64/Godot_v3.1-beta4_x11.64() [0x1693c26] (??:?)
[28] /xxx/Godot_v3.1-beta4_x11_64/Godot_v3.1-beta4_x11.64() [0x7ac20b] (??:?)
[29] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7fd8e8edf830] (??:0)
[30] /xxx/Godot_v3.1-beta4_x11_64/Godot_v3.1-beta4_x11.64() [0x7b9c8e] (??:?)

Probably utterly wrong, but I am starting to lose hope (is anyone even using GDNative with c++? several days without any comment on a very basic common beginner topic).
  register_property<CPP, Variant>("material", &CPP::material, Variant(new Material()));
...
    Variant material;

Linux 64b, 3.1.beta3 and 4 behaves same.

Variant(new Material()) - this will crash, there are no new/delete operators defined for gdnative types, use x = T::_new() and x->free() instead.
I'm pretty sure properties should be references, try something like:

Ref<Material> material;
...
register_property<CPP, Ref<Material> >("material", &CPP::material, Ref<Material>(), GODOT_METHOD_RPC_MODE_DISABLED, GODOT_PROPERTY_USAGE_DEFAULT, GODOT_PROPERTY_HINT_RESOURCE_TYPE, String("Material"));

Or try defining _get_property_list/_get/_set, here's working example: https://github.com/BastiaanOlij/gdprocmesh/blob/master/src/gdprocmesh.cpp#L8

Yeah, I was pretty sure using Variant this way is wrong, I tried directly Material, Ref, combinations of what is pointer and what's not, nullptr in Ref and so on.
Your register_property way is behaving exactly same as majority of my other attempts (locked Material prop with text "[null]" and nothing can be changed).
Hopefully tomorrow I'll look at the _get_property_list/_get/_set (looks a bit complex for what I wanted to do).
Thank you for your response.

You can look at property list/get/set which is what I do in procmesh but for entirely different reasons:
https://github.com/BastiaanOlij/gdprocmesh/blob/master/src/gdprocmesh.cpp#L8
The same should work with register_property as well. Everything is communicated as variants but you have to set the types correctly, I know I've done it before but can't find an example.
Anyways, procmesh atleast gives you an example of how to do it with property_list, get and set :)

Tried the _get_property_list way and it doesn't seem to be doing anything:
  register_method("_get_property_list", &CPP::_get_property_list);
  register_method("_get", &CPP::_get);
  register_method("_set", &CPP::_set);

Array CPP::_get_property_list() {
  std::cout << "_get_property_list ";
  Array arr;

  {
    Dictionary prop;
    prop["name"] = "material";
    prop["type"] = GlobalConstants::TYPE_OBJECT;
    prop["hint"] = GlobalConstants::PROPERTY_HINT_RESOURCE_TYPE;
    prop["hint_string"] = GlobalConstants::PROPERTY_USAGE_SCRIPT_VARIABLE;
    arr.push_back(prop);
  }

  std::cout << arr.size() << std::endl;
  return arr;
}

Variant CPP::_get(String name) {
  return Variant();
}

bool CPP::_set(String name, Variant value) {
  return false;
}

_get_property_list doesn't seem to be ever called (no console output) and that one property is not visible in the editor. I have no clue what things in GlobalConstants are for (or format of items expected from _get_property_list), because there are no comments, no documentation in code...
Any idea why this (or anything related to property objects) is not working for me, but apparently it works fine for others? I don't see any warning or error in editor output tab nor console. I am starting to question if this immature C++ interop is worth it. Even alpha C# support seemed to be much better, at least basics like "export" for editor worked flawlessly in minutes...

Done some test, register_property doesn't work since it can't infer type of object from null reference (it's set to GlobalConstants::TYPE_NIL instead of GlobalConstants::TYPE_OBJECT).
_get_property_list/_get/_set works fine for me.

doesn't seem to be ever called (no console output)

You have to register classes as tool class using godot::register_tool_class instead of godot::register_class, otherwise scripts (including _get_property_list) won't be executed in editor!
Here's my code:
class Test2 : public Node2D {
	GODOT_CLASS(Test2, Node2D);

private:

	Ref<Material> material;

public:
	static void _register_methods();

	Array _get_property_list();
	Variant _get(String p_name);
	bool _set(String p_name, Variant p_value);

	void _init() { /*NOP*/ };

	Test2() { /*NOP*/ };
	~Test2() { /*NOP*/ };
};

/*************************************************************************/

void Test2::_register_methods() {

	register_method("_get_property_list", &Test2::_get_property_list);
	register_method("_get", &Test2::_get);
	register_method("_set", &Test2::_set);
}

Array Test2::_get_property_list() {

	Array arr;

	Dictionary prop;
	prop["name"] = String("test_material");
	prop["type"] = GlobalConstants::TYPE_OBJECT;
	prop["hint"] = GlobalConstants::PROPERTY_HINT_RESOURCE_TYPE;
	prop["hint_string"] = "ShaderMaterial,CanvasItemMaterial";
	prop["usage"] = GlobalConstants::PROPERTY_USAGE_DEFAULT;
	arr.push_back(prop);

	return arr;
}

Variant Test2::_get(String p_name) {

	if (p_name == "test_material") {
		return material;
	} else {
		return Variant();
	}
}

bool Test2::_set(String p_name, Variant p_value) {

	if (p_name == "test_material") {
		material = p_value;
		return true;
	} else {
		return false;
	}
}

@bruvzg Well, your code works (material can be selected), but if I understand it correctly - it must run as an editor plugin (class? node?), so _process is called in editor, instead of during game run (so benchmark code started to run inside editor, freezing it) - I am not sure I can use this approach...
I also tried passing new material to the initial property value, but that didn't really work in editor - new material cannot be easily created from dropdown of property.
  register_property<CPP, Ref<Material>>("material", &CPP::set_material, &CPP::get_material,
                                        Ref<Material>(Material::_new()),
                                        GODOT_METHOD_RPC_MODE_DISABLED, GODOT_PROPERTY_USAGE_DEFAULT,
                                        GODOT_PROPERTY_HINT_RESOURCE_TYPE,
                                        "ShaderMaterial,CanvasItemMaterial");

I guess my next attempt will be just calling method on C++ node from GDScript with exported material (so working in editor) and passing the material from GDScript to C++ part via a method argument. Seems really hacky, but I don't see other options.
Maybe by the time (months) I get to the feature I will need properties properly working without hacks/workarounds, register_property might be fixed.

I also tried passing new material to the initial property value, but that didn't really work in editor - new material cannot be easily created from dropdown of property.

That's another bug, register_property version with getter/getter doesn't set the hint string.
Here's quick fix for register_property (patch can be applied to the header without need to rebuild godot-cpp library), it just assumes null is object, probably there is a better method, but Variant::NIL property doesn't make much sense and shouldn't cause any problems.
diff --git a/include/core/Godot.hpp b/include/core/Godot.hpp
index 4ed48ed..8b1c2aa 100644
--- a/include/core/Godot.hpp
+++ b/include/core/Godot.hpp
@@ -326,8 +326,13 @@ void register_property(const char *name, P(T::*var), P default_value, godot_meth
 	godot_string *_hint_string = (godot_string *)&hint_string;

 	godot_property_attributes attr = {};
-	attr.type = def_val.get_type();
-	attr.default_value = *(godot_variant *)&def_val;
+	if (def_val.get_type() == Variant::NIL) {
+		attr.type = Variant::OBJECT;
+	} else {
+		attr.type = def_val.get_type();
+		attr.default_value = *(godot_variant *)&def_val;
+	}
+
 	attr.hint = hint;
 	attr.rset_type = rpc_mode;
 	attr.usage = usage;
@@ -356,12 +361,19 @@ template <class T, class P>
 void register_property(const char *name, void (T::*setter)(P), P (T::*getter)(), P default_value, godot_method_rpc_mode rpc_mode = GODOT_METHOD_RPC_MODE_DISABLED, godot_property_usage_flags usage = GODOT_PROPERTY_USAGE_DEFAULT, godot_property_hint hint = GODOT_PROPERTY_HINT_NONE, String hint_string = "") {
 	Variant def_val = default_value;

+	godot_string *_hint_string = (godot_string *)&hint_string;
+
 	godot_property_attributes attr = {};
-	attr.type = def_val.get_type();
-	attr.default_value = *(godot_variant *)&def_val;
+	if (def_val.get_type() == Variant::NIL) {
+		attr.type = Variant::OBJECT;
+	} else {
+		attr.type = def_val.get_type();
+		attr.default_value = *(godot_variant *)&def_val;
+	}
 	attr.hint = hint;
 	attr.rset_type = rpc_mode;
 	attr.usage = usage;
+	attr.hint_string = *_hint_string;

 	_PropertySetFunc<T, P> *wrapped_set = (_PropertySetFunc<T, P> *)godot::api->godot_alloc(sizeof(_PropertySetFunc<T, P>));
 	wrapped_set->f = setter;

With this patch following code works:
register_property<Test1, Ref<Material> >("test_material", &Test1::set_test_material, &Test1::get_test_material, Ref<Material>(), GODOT_METHOD_RPC_MODE_DISABLED, GODOT_PROPERTY_USAGE_DEFAULT, GODOT_PROPERTY_HINT_RESOURCE_TYPE, String("ShaderMaterial,CanvasItemMaterial"));

@bruvzg Thank you, the patch seems to work well :smiley:.

hi @bruvzg, thank you for this patch. It works great!
After some research, I found that the root cause seems to be c2b59773af525161d4dd3f1dd9baac179f1afda9, where you added the if-else in Variant's constructor as below:
https://github.com/GodotNativeTools/godot-cpp/blob/c2b59773af525161d4dd3f1dd9baac179f1afda9/src/core/Variant.cpp#L143-L149
That way, the Variant's type obviously becomes NIL when passing an empty Ref<...>() as default value.
Would it be a better idea to call godot_variant_new_object(..., nullptr) instead of godot_variant_new_nil at this place?
I'd love to see this issue fixed in upstream, btw :)


Missing LICENSE file in release tarball 0.12.1

The tarball for 0.12.1 on pypi is missing the LICENSE file. The LICENSE file is present in the 0.12.0 tarball.
https://files.pythonhosted.org/packages/c1/0f/c34c727d3184c7430e547a8c6b1b60099b347c6356ff4962ecfc66313850/asyncio_mqtt-0.12.1.tar.gz
When I ran 'python setup.py sdist' with v0.12.1 branch checked out locally the tarball includes the LICENSE file. Is the tarball built in some other way?
Thanks

Hi Stewart, thanks for opening this issue. Let me have a look. :)

python setup.py sdist

That's the exact command that I run when I make a release.
I can't find the LICENSE file in the 0.12.0 or 0.11.1 tarballs:
https://files.pythonhosted.org/packages/cd/0a/d8ab9a6b069c26426fef4e7802863d6439cf684a238c4d3b16a8f62ea31f/asyncio_mqtt-0.12.0.tar.gz
https://files.pythonhosted.org/packages/0d/16/5c7ba8321f67114eab14b12d59c8cae7d6fdde7f7b994a9f321ab7b77c8e/asyncio_mqtt-0.11.1.tar.gz
I don't think that the LICENSE file was ever in the tarballs from PyPI to begin with. Note that the tarballs from GitHub includes the LICENSE file (GitHub auto-generates the tarballs from the repo). Maybe that caused the confusion?
That being said, I'd gladly accept a PR that changes setup.py so that it includes the LICENSE file. :+1:
~Frederik

Hi Frederik,
You are correct that I was confused about where I'd pulled the tarball from to find the LICENSE file. The issue is totally about getting the LICENSE file into the pypi tarball.
From what I have understood (and checked with test.pypi.org) the added setup.cfg in #107 should provide the LICENSE file in the tarball that our CI wants to check for.
Thanks!

Closed by #107.


Markup class does not seem to work as per documentation

Hi, I have a cloned copy of highlight.js which I use to edit the VHDL syntax file. I managed to build and deploy the highlight.pack.js successfully.
I hit one problem though. When I changed the class for some VHDL code snippets, the highlighting was not VHDL. I was following this documentation.

To disable highlighting altogether use the nohighlight class:

...

An example snippet was this test:

file file_handle: text;

I expect file to be highlighted as it is a VHDL keyword. In this case, file_handle was highlighted instead.
However, when I changed to the following, the snippet was highlighted correctly:

file file_handle: text;

Perhaps this is an oversight on the part of the documentation (is this intended behaviour?), or perhaps the codebase needs to be updated to match with the documentation? Or maybe I'm missing something?
Best regards, Daniel

It shouldn't matter where you put class="vhdl", we're looking both at the  element and at its parent. What could have happened is your highlight.pack.js built without vhdl.js, for example. Could you reproduce the bug and see what classes get assigned to the  element after incorrect highlighting (using the DOM inspector, to see dynamically applied changes).

The DOM inspector for Chrome showed this:

file file_handle: text;

Looks like the code element's class is correct.
Anyway, after editing the vhdl.js to add more markups, looks like this problem disappears. I'm not sure why.
I guess I'll just commit the new vhdl.js anyway.

Closing this as new pull request no longer has this problem.


Support for basic HTML tags

Is your feature request related to a problem? Please describe.
We're planning to render emails to the user and a major issue is that emails may contain lots of markup that is difficult to parse through. Also, customers may be sending businesses images in the emails for customer support issues, etc. In order to provide the most value to the stripe user, we want to be able to include as much valuable information from their emails as possible.
Describe the solution you'd like
We want to be able to use basic HTML tags so that we can closely reflect the rich emails that a user receives. Support for basic tags such as p, a, img, ul, ol, li, h1, h2, h3, h4 will make the emails more useful to the user.
Describe alternatives you've considered
An alternative is to link out to our own app where we can display the full richness of their email.

Adding some screenshots for the folks to review why this is crucial for us to deliver a great experience through our app. Please reach out in case of any questions.


Fix handling of white space in channel names.

Handle white space inside channel names #10
Fix level meters #12
Disallow curly braces in channel name regex.
Fix query of input gates on connect
Fix heart beat query
Better layout of input & output meter feedbacks.

A few more button layouts still to touch up.

Revised button layouts.
They did not look healthy in the 3.2 betas.

Actually... there is one issue I'm aware of as a possibility but we haven't encountered it in use...
The channel name field can be up to 31char according to the protocol doc. At anything close to that length it one fit on one line and the channel status advanced layout is likely to become garbled. We could force a truncation to something that would definitely fit on 1 line; unless you have another suggestion?
(Who makes channel names 31char long though!?)

Great, then I believe there is nothing left to do.

Cool.  Thanks!  Yeah, I originally implemented this to spec but never really got feedback from people that it was working properly.  Appreciate the effort to spruce it up.

Thanks for putting in the work. It's a nice little module, I believe my team will find it quite useful.


Pass transcriptome fasta through to samtools stats

We supply a reference FASTA to samtools stats to enable accurate mismatch, insertion, and deletion reporting by comparing aligned reads against the reference sequence, thereby enhancing the analysis of alignment quality and genomic variation. This facilitates a comprehensive assessment of the sequencing data, including coverage and variant analysis, by providing the precise genetic context for the reads.
So we must supply a reference compatible with the alignments. In the case of the transcriptome alignments, this should be the transcriptome.
PR checklist

[ ] This comment contains a description of changes (with reason).
[ ] If you've fixed a bug or added code that should be tested, add tests!
[ ] If you've added a new tool - have you followed the pipeline conventions in the contribution docs
[ ] If necessary, also make a PR on the nf-core/rnaseq branch on the nf-core/test-datasets repository.
[ ] Make sure your code lints (nf-core lint).
[ ] Ensure the test suite passes (nextflow run . -profile test,docker --outdir <OUTDIR>).
[ ] Check for unexpected warnings in debug mode (nextflow run . -profile debug,test,docker --outdir <OUTDIR>).
[ ] Usage Documentation in docs/usage.md is updated.
[ ] Output Documentation in docs/output.md is updated.
[ ] CHANGELOG.md is updated.
[ ] README.md is updated (including new tool citations and authors/contributors).

Thanks @maxulysse !


DELETE operation implemented in the Heap class does not work for min-max heaps

This means that I've to override that method in the MinMaxHeap class. So currently, the MinMaxHeap class is buggy.

(Probably) fixed. Now tests are passing.


Usage when writing an npm package

We ran into a challenge last week that we couldn't solve with CSS Modules + webpack-flush-chunks. Maybe you have a recommendation here.
We have a core-ui repository with components we use in all of our apps like Button, TextInput, Logo etc.
We consume this repo in other apps as an npm module. Our goal is to be able to import Button from 'core-ui/Button' without any extra import 'core-ui/Button/styles.css' or a global import 'core-ui/styles.css'.
Haven't been able to get it working and had to resolve to using styled-components. We're not too unhappy because we'll most likely also consume the core components in a future react-native app where styled-components might offer some benefits over CSS Modules but I was still wondering if there is a way to achieve the above with your setup?

Try Emotion. They have an extract mode that uses a babel plugin to generate CSS from CSS-in-js components. And I think they have a React Native components as well.

https://github.com/emotion-js/emotion/blob/master/docs/extract-static.md
Emotion is meant for this precise use case. I haven't tried it though, but I planned to and then to write an article about it. It's perfect for RUC. If it works, you should share your findings in an article.

thanks man, i'll check it out this weekend

@chapati23 Where did you end up with this?

at using styled-components :)
works for us and didn't wanna prematurely refactor the whole styling to yet another stack before we actually run into performance problems.

@chapati23 so SC and this library worked well for you together? If yes, what changes did you have to make, or how did you set it up?


[improve][broker] Make some methods in NamespacesBase async.

Motivation
See PIP #14365  and change tracker #15043.
Make NamespacesBase getTenantNamespaces / createNamespace / getTopics / getPolicies / getPermissions methods to pure async.
Documentation

[x] no-need-doc
(Please explain why)

there seem to be a new type of failure in tests causing flakiness and it could be related to this PR. Please check #15652


switch from fluxcd/go-git to go-git/go-git

Switch from fluxcd/go-git to go-git/go-git, as all changes made to our fork have been contributed back upstream.
Use the HEAD of the master branch for now, switch to v5.7.0 when it gets released.

Please rebase this with https://github.com/go-git/go-git/releases/tag/v5.7.0


Infinite completion loop

Given this test.js script:
#!/usr/bin/env node
var argv = require('./index')
  .completion('completion')
  .argv;

console.log('argv: %j', argv);

Enabling completion:
$ eval "$( ./test.js completion )"

And typing ./test.js [TAB][TAB], it looks like you get stuck in an endless completion loop with this shown:
./test.js completion

You need to send SIGINTto get back to sanity (or just watch the endless -bash: fork: Resource temporarily unavailable).

@tschaub could you please give this branch a shot and let me know if it solves the problem:
https://github.com/bcoe/yargs/pull/181

Yup @bcoe - the changes in #181 look like a good fix for this as well.

awesome :+1:


Not working

Installed via comfy manager
tried to install.bat, get this error below have nodes red in the workflow tried install missing nodes all points to custom node pack.
Installing ComfyUI Frame Interpolation..
Installing with ComfyUI Portable
Installing torch...
Requirement already satisfied: torch in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (2.0.1+cu118)
Requirement already satisfied: filelock in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torch) (3.10.0)
Requirement already satisfied: typing-extensions in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torch) (4.5.0)
Requirement already satisfied: sympy in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torch) (1.11.1)
Requirement already satisfied: networkx in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torch) (3.0)
Requirement already satisfied: jinja2 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torch) (3.1.2)
Requirement already satisfied: MarkupSafe>=2.0 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from jinja2->torch) (2.1.2)
Requirement already satisfied: mpmath>=0.19 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from sympy->torch) (1.3.0)
[notice] A new release of pip is available: 23.1.2 -> 23.2.1
[notice] To update, run: D:\ComfyUI_windows_portable_nvidia_cu118_or_cpu\ComfyUI_windows_portable\python_embeded\python.exe -m pip install --upgrade pip
Installing numpy...
Requirement already satisfied: numpy in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (1.23.5)
[notice] A new release of pip is available: 23.1.2 -> 23.2.1
[notice] To update, run: D:\ComfyUI_windows_portable_nvidia_cu118_or_cpu\ComfyUI_windows_portable\python_embeded\python.exe -m pip install --upgrade pip
Installing einops...
Requirement already satisfied: einops in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (0.6.1)
[notice] A new release of pip is available: 23.1.2 -> 23.2.1
[notice] To update, run: D:\ComfyUI_windows_portable_nvidia_cu118_or_cpu\ComfyUI_windows_portable\python_embeded\python.exe -m pip install --upgrade pip
Installing opencv-contrib-python...
Requirement already satisfied: opencv-contrib-python in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (<IP_ADDRESS>)
Requirement already satisfied: numpy>=1.21.2 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from opencv-contrib-python) (1.23.5)
[notice] A new release of pip is available: 23.1.2 -> 23.2.1
[notice] To update, run: D:\ComfyUI_windows_portable_nvidia_cu118_or_cpu\ComfyUI_windows_portable\python_embeded\python.exe -m pip install --upgrade pip
Installing kornia...
Requirement already satisfied: kornia in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (0.7.0)
Requirement already satisfied: packaging in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from kornia) (23.0)
Requirement already satisfied: torch>=1.9.1 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from kornia) (2.0.1+cu118)
Requirement already satisfied: filelock in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torch>=1.9.1->kornia) (3.10.0)
Requirement already satisfied: typing-extensions in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torch>=1.9.1->kornia) (4.5.0)
Requirement already satisfied: sympy in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torch>=1.9.1->kornia) (1.11.1)
Requirement already satisfied: networkx in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torch>=1.9.1->kornia) (3.0)
Requirement already satisfied: jinja2 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torch>=1.9.1->kornia) (3.1.2)
Requirement already satisfied: MarkupSafe>=2.0 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from jinja2->torch>=1.9.1->kornia) (2.1.2)
Requirement already satisfied: mpmath>=0.19 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from sympy->torch>=1.9.1->kornia) (1.3.0)
[notice] A new release of pip is available: 23.1.2 -> 23.2.1
[notice] To update, run: D:\ComfyUI_windows_portable_nvidia_cu118_or_cpu\ComfyUI_windows_portable\python_embeded\python.exe -m pip install --upgrade pip
Installing scipy...
Requirement already satisfied: scipy in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (1.10.1)
Requirement already satisfied: numpy<1.27.0,>=1.19.5 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from scipy) (1.23.5)
[notice] A new release of pip is available: 23.1.2 -> 23.2.1
[notice] To update, run: D:\ComfyUI_windows_portable_nvidia_cu118_or_cpu\ComfyUI_windows_portable\python_embeded\python.exe -m pip install --upgrade pip
Installing Pillow...
Requirement already satisfied: Pillow in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (9.4.0)
[notice] A new release of pip is available: 23.1.2 -> 23.2.1
[notice] To update, run: D:\ComfyUI_windows_portable_nvidia_cu118_or_cpu\ComfyUI_windows_portable\python_embeded\python.exe -m pip install --upgrade pip
Installing torchvision...
Requirement already satisfied: torchvision in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (0.15.2+cu118)
Requirement already satisfied: numpy in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torchvision) (1.23.5)
Requirement already satisfied: requests in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torchvision) (2.31.0)
Requirement already satisfied: torch==2.0.1 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torchvision) (2.0.1+cu118)
Requirement already satisfied: pillow!=8.3.*,>=5.3.0 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torchvision) (9.4.0)
Requirement already satisfied: filelock in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torch==2.0.1->torchvision) (3.10.0)
Requirement already satisfied: typing-extensions in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torch==2.0.1->torchvision) (4.5.0)
Requirement already satisfied: sympy in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torch==2.0.1->torchvision) (1.11.1)
Requirement already satisfied: networkx in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torch==2.0.1->torchvision) (3.0)
Requirement already satisfied: jinja2 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torch==2.0.1->torchvision) (3.1.2)
Requirement already satisfied: charset-normalizer<4,>=2 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from requests->torchvision) (3.1.0)
Requirement already satisfied: idna<4,>=2.5 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from requests->torchvision) (3.4)
Requirement already satisfied: urllib3<3,>=1.21.1 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from requests->torchvision) (2.0.5)
Requirement already satisfied: certifi>=2017.4.17 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from requests->torchvision) (2022.12.7)
Requirement already satisfied: MarkupSafe>=2.0 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from jinja2->torch==2.0.1->torchvision) (2.1.2)
Requirement already satisfied: mpmath>=0.19 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from sympy->torch==2.0.1->torchvision) (1.3.0)
[notice] A new release of pip is available: 23.1.2 -> 23.2.1
[notice] To update, run: D:\ComfyUI_windows_portable_nvidia_cu118_or_cpu\ComfyUI_windows_portable\python_embeded\python.exe -m pip install --upgrade pip
Installing tqdm...
Requirement already satisfied: tqdm in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (4.65.0)
Requirement already satisfied: colorama in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from tqdm) (0.4.6)
[notice] A new release of pip is available: 23.1.2 -> 23.2.1
[notice] To update, run: D:\ComfyUI_windows_portable_nvidia_cu118_or_cpu\ComfyUI_windows_portable\python_embeded\python.exe -m pip install --upgrade pip
Installing timm==0.6.13...
Requirement already satisfied: timm==0.6.13 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (0.6.13)
Requirement already satisfied: torch>=1.7 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from timm==0.6.13) (2.0.1+cu118)
Requirement already satisfied: torchvision in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from timm==0.6.13) (0.15.2+cu118)
Requirement already satisfied: pyyaml in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from timm==0.6.13) (6.0)
Requirement already satisfied: huggingface-hub in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from timm==0.6.13) (0.17.3)
Requirement already satisfied: filelock in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torch>=1.7->timm==0.6.13) (3.10.0)
Requirement already satisfied: typing-extensions in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torch>=1.7->timm==0.6.13) (4.5.0)
Requirement already satisfied: sympy in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torch>=1.7->timm==0.6.13) (1.11.1)
Requirement already satisfied: networkx in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torch>=1.7->timm==0.6.13) (3.0)
Requirement already satisfied: jinja2 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torch>=1.7->timm==0.6.13) (3.1.2)
Requirement already satisfied: fsspec in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from huggingface-hub->timm==0.6.13) (2023.3.0)
Requirement already satisfied: requests in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from huggingface-hub->timm==0.6.13) (2.31.0)
Requirement already satisfied: tqdm>=4.42.1 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from huggingface-hub->timm==0.6.13) (4.65.0)
Requirement already satisfied: packaging>=20.9 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from huggingface-hub->timm==0.6.13) (23.0)
Requirement already satisfied: numpy in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torchvision->timm==0.6.13) (1.23.5)
Requirement already satisfied: pillow!=8.3.*,>=5.3.0 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from torchvision->timm==0.6.13) (9.4.0)
Requirement already satisfied: colorama in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from tqdm>=4.42.1->huggingface-hub->timm==0.6.13) (0.4.6)
Requirement already satisfied: MarkupSafe>=2.0 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from jinja2->torch>=1.7->timm==0.6.13) (2.1.2)
Requirement already satisfied: charset-normalizer<4,>=2 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from requests->huggingface-hub->timm==0.6.13) (3.1.0)
Requirement already satisfied: idna<4,>=2.5 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from requests->huggingface-hub->timm==0.6.13) (3.4)
Requirement already satisfied: urllib3<3,>=1.21.1 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from requests->huggingface-hub->timm==0.6.13) (2.0.5)
Requirement already satisfied: certifi>=2017.4.17 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from requests->huggingface-hub->timm==0.6.13) (2022.12.7)
Requirement already satisfied: mpmath>=0.19 in d:\comfyui_windows_portable_nvidia_cu118_or_cpu\comfyui_windows_portable\python_embeded\lib\site-packages (from sympy->torch>=1.7->timm==0.6.13) (1.3.0)
[notice] A new release of pip is available: 23.1.2 -> 23.2.1
[notice] To update, run: D:\ComfyUI_windows_portable_nvidia_cu118_or_cpu\ComfyUI_windows_portable\python_embeded\python.exe -m pip install --upgrade pip
Checking cupy...
Uninstall cupy if existed...
WARNING: Skipping cupy-wheel as it is not installed.
WARNING: Skipping cupy-cuda102 as it is not installed.
WARNING: Skipping cupy-cuda110 as it is not installed.
WARNING: Skipping cupy-cuda111 as it is not installed.
WARNING: Skipping cupy-cuda11x as it is not installed.
WARNING: Skipping cupy-cuda12x as it is not installed.
Installing cupy...
Collecting cupy-wheel
Using cached cupy-wheel-12.2.0.tar.gz (2.9 kB)
Preparing metadata (setup.py) ... error
error: subprocess-exited-with-error
× python setup.py egg_info did not run successfully.
│ exit code: 1
╰─> [28 lines of output]
[cupy-wheel] CUDA_PATH is not set.cupy-wheel may not be able to discover NVRTC to probe version
[cupy-wheel] Trying to detect CUDA version from libraries: ['nvrtc64_120_0.dll', 'nvrtc64_112_0.dll', 'nvrtc64_111_0.dll', 'nvrtc64_110_0.dll', 'nvrtc64_102_0.dll']
[cupy-wheel] Looking for library: nvrtc64_120_0.dll
[cupy-wheel] Failed to open nvrtc64_120_0.dll: Could not find module 'nvrtc64_120_0.dll' (or one of its dependencies). Try using the full path with constructor syntax.
[cupy-wheel] Looking for library: nvrtc64_112_0.dll
[cupy-wheel] Failed to open nvrtc64_112_0.dll: Could not find module 'nvrtc64_112_0.dll' (or one of its dependencies). Try using the full path with constructor syntax.
[cupy-wheel] Looking for library: nvrtc64_111_0.dll
[cupy-wheel] Failed to open nvrtc64_111_0.dll: Could not find module 'nvrtc64_111_0.dll' (or one of its dependencies). Try using the full path with constructor syntax.
[cupy-wheel] Looking for library: nvrtc64_110_0.dll
[cupy-wheel] Failed to open nvrtc64_110_0.dll: Could not find module 'nvrtc64_110_0.dll' (or one of its dependencies). Try using the full path with constructor syntax.
[cupy-wheel] Looking for library: nvrtc64_102_0.dll
[cupy-wheel] Failed to open nvrtc64_102_0.dll: Could not find module 'nvrtc64_102_0.dll' (or one of its dependencies). Try using the full path with constructor syntax.
[cupy-wheel] No more candidate library to find
[cupy-wheel] ROCm detection unsupported on platform: win32
Traceback (most recent call last):
File "", line 2, in
File "", line 34, in
File "C:\Users\USER\AppData\Local\Temp\pip-install-_x17ekon\cupy-wheel_59c969eaba2840e7a3f1283ab365374e\setup.py", line 285, in
main()
File "C:\Users\USER\AppData\Local\Temp\pip-install-_x17ekon\cupy-wheel_59c969eaba2840e7a3f1283ab365374e\setup.py", line 269, in main
package = infer_best_package()
File "C:\Users\USER\AppData\Local\Temp\pip-install-_x17ekon\cupy-wheel_59c969eaba2840e7a3f1283ab365374e\setup.py", line 259, in infer_best_package
raise AutoDetectionFailed(
main.AutoDetectionFailed:
============================================================
Unable to detect NVIDIA CUDA or AMD ROCm installation.
============================================================
  [end of output]

note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed
× Encountered error while generating package metadata.
╰─> See above for output.
note: This is an issue with the package mentioned above, not pip.
hint: See above for details.
[notice] A new release of pip is available: 23.1.2 -> 23.2.1
[notice] To update, run: D:\ComfyUI_windows_portable_nvidia_cu118_or_cpu\ComfyUI_windows_portable\python_embeded\python.exe -m pip install --upgrade pip
Press any key to continue . . .

+1

The exact same error for me as well

+1

@Fannovel16 , the last update seems to have fixed the probem. Thanks a lot man!!

Works here as well, thank you for your time!


Dvictor1/hosts dns zookeeper fix

@dvictor1 I merged #18 but I see that the merged commit is also in this PR. Can you do a quick rebase?


hparams missing in the longformer_large_science checkpoint?

Hi David!
Thanks a lot for sharing your great work!
I am currently struggling to use the longformer_large_science checkpoint for making predictions on the scifact dataset.
It seems the model checkpoint doesn't have 'hparams' needed to instantiate the model. I am getting following error:
model = cls._load_model_state(checkpoint, strict=strict, **kwargs)

 File "/pytorch_lightning/core/saving.py", line 198, in _load_model_state
    model = cls(**_cls_kwargs)

TypeError: __init__() missing 1 required positional argument: 'hparams'

I wonder if there is an issue with saving the checkpoint or if additional modifications to the MultiVerSModel class can help run the checkpoint.
Thank you

Hi, thanks for your interest!
I'm traveling for the next two weeks, but will take a look when I get back at the end of March. In the meantime, my only advice is to make sure that your setup matches the specification in the README.
Dave

I'm taking a look at this now. I think it probably doesn't make sense to use longformer_large_science for prediction, since it wasn't trained on any fact-checking datasets. I think that's what's going on with the hparams. If you want to make predictions on scifact, you're probably better off using the dedicated scifact model, as done here.
Let me know if you have more questions.

Thanks for the response. I wanted to try out a model that hasn't been specifically trained on fact-checking datasets but has science knowledge. Is there any way to use the longformer_large_science model to make predictions?

Thank you so much for the response. :) I wanted to try out a model that hasn't been specifically trained on fact-checking datasets but has science knowledge. Is there any way to use the longformer_large_science model to make predictions?

The way that I made supports / refutes / nei decisions for MultiVerS was to train a three-way classification head on top of the <s> token from LongFormer. The base longformer_large_science model doesn't have this classification head, so you can't make fact-checking predictions in the same fashion. I think if you're interested in looking at zero-shot fact-checking abilities of scientific LLM's, your best bet is to try a prompting-based approach with an autoregressive language model like PubMedGPT.

That makes sense, thanks alot for the pointer! :)

No problem! I'm going to close this issue; feel free to reopen if you've got more questions.


bugfix: kubelet cgroup driver not match containerd

Signed-off-by: 晓杰<EMAIL_ADDRESS>fix #2459 #2447
i also test sealos add node/master, del node/master, is ok

"change func order" is not the bug.

wrong order will lead to bugs


feat(material/form-field): Allow mat-hint to persist alongside errors

Uses CSS to hide hints when errors are displayed, rather than removing them from the DOM altogether.
Fixes #24319

Sorry, having some trouble running tests locally. Fixing.

Time-boxing this one, since I don't want to have to go through and update all the other components' specs without more familiarity.


conda/scans.py heterogenous behavior on Harvard cluster (Odyssey)

I'm running XPEHH calculations for a bunch of different population pairs. Using the same script, a bunch of these have gotten started running, while the latter half fails with an unexpected error:

2017-01-28 09:48:28,476 - cmd:112:main_argparse - INFO - software version: 2.0.0-beta-181-ge43cb00-dirty, python version: 3.5.2 |Continuum Analytics, Inc.| (default, Jul  2 2016, 17:53:06)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)]
2017-01-28 09:48:28,477 - cmd:115:main_argparse - INFO - command: /n/home08/jvitti/cms/cms/scans.py selscan_xpehh tmpDirKeep=False inputRefTped=/n/regal/sabeti_lab/jvitti/clear-synth/1kg_tpeds/chr1_strictMask_PJL_clear-synth-20161227.tped.gz maf=0.05 threads=8 inputTped=/n/regal/sabeti_lab/jvitti/clear-synth/1kg_tpeds/chr1_strictMask_FIN_clear-synth-20161227.tped.gz outFile=/n/regal/sabeti_lab/jvitti/clear-synth/1kg_scores/xpehh/chr1_strictMask_FIN_clear-synth-20161227_vs_PJL tmpDir=/tmp gapScale=20000 loglevel=DEBUG truncOk=False
2017-01-28 09:48:28,478 - cmd:127:main_argparse - DEBUG - using tempDir: /tmp/tmp-scans-selscan_xpehh-semx0iw6
Traceback (most recent call last):
File "/n/home08/jvitti/cms/cms/scans.py", line 580, in
util.cmd.main_argparse(commands, doc)
File "/n/home08/jvitti/cms/cms/util/cmd.py", line 130, in main_argparse
ret = args.func_main(args)
File "/n/home08/jvitti/cms/cms/scans.py", line 365, in main_selscan_xpehh
gap_scale       = args.gapScale
File "/n/home08/jvitti/cms/cms/tools/selscan.py", line 530, in execute_xpehh
toolCmd = [self.install_and_get_path()]
File "/n/home08/jvitti/cms/cms/tools/init.py", line 124, in install_and_get_path
self.install()
File "/n/home08/jvitti/cms/cms/tools/init.py", line 101, in install
m.attempt_install()
File "/n/home08/jvitti/cms/cms/tools/init.py", line 145, in attempt_install
self._attempt_install()
File "/n/home08/jvitti/cms/cms/tools/init.py", line 441, in _attempt_install
pkg_version = self.verify_install()
File "/n/home08/jvitti/cms/cms/tools/init.py", line 386, in verify_install
installed_version = self.get_installed_version()
File "/n/home08/jvitti/cms/cms/tools/init.py", line 480, in get_installed_version
matches = package_info_re.match(installed_package_string)
TypeError: expected string or bytes-like object
srun: error: holy2a18202: task 0: Exited with exit code 1

And I now appear to get the same error when I run scans.py from the command line. I don't have this issue on the Broad cluster. I tried rolling back to conda 4.0.10 (which is what's installed on the Broad) but ran into another unexpected error:

(cms-env3) [jvitti@holy2a18308 /]$ conda install -q -y conda==4.0.10
Fetching package metadata ...........
InstallError: Install error: Error: 'conda' can only be installed into the root environment

I can always rsync the data to the Broad server and run the calculations there, but it'd be great to understand why this (apparently) stopped working -- spooky.

Yeep, it seems like this is also making problems for Travis...

For the first error, replacing tools/__init__.py with the one available here should hopefully resolve it. The error, 'conda' can only be installed into the root environment is accurate; conda cannot be installed when an environment is active—it has to be installed when miniconda is included in the system PATH (but not when an environment is active). A sticking point is that conda v4.0.10 is (at last check) now unavailable. Fortunately, I submitted a fix for the activation race condition that has been accepted into conda as v4.2.16 and later (not sure if it is in the 4.3.x tree yet).

That does the trick -- thanks @tomkinsc !


No autoimports after upgrading to TS 2.6.2

TypeScript Version:  2.6.2
Code
Before (2.6.1):

After (2.6.2, typescript@next):

(Only global completions shown, no external libraries import, no local project files imports)
The import codefix still works with 2.6.2. I've pretty large monorepo with multiple tsconfig and tsconfig paths. I'll try to get the repro, but any suggestions where should i start?

Additional information:
vscode 1.18.1
macOS 10.13.1
If i build local TS version from tags/v2.6.2 and point tssdk in vscode to it - it works as expected.
If i point vscode to installed TS 2.6.2 in local node_modules - it doesn't work

This may have to do with whether you've visited those files yet -- try adding one import manually and see if other imports come up as fixes.

@andy-ms Nope, it doesn't work even for additional imports in already imported file.

Found the problem:
        "plugins": [
            {
                "name": "typescript-styled-plugin",
                "tags": [
                    "styled",
                    "css",
                    "extend",
                    "keyframes",
                    "injectGlobal",
                    "breakpoints"
                ]
            }
        ],

ping @mjbvz

Sorry for noise

If you file an issue on vscode could you link to this one for reference?


PVInverter1Phase increasing AC amplitude

Hi everyone,
I am currently using the basic layout of example PVInverter1Phase along with mppt tracker .
How can I achieve AC output at 230 V instead of the same amplitude on DC side?
Thank you in advance.

@AggelikiGk, sorry,  I haven't been keeping track of this repo's issues. Did you manage to solve your problem?


The active resolution cannot be retrieved for the lowest resolution on the G500s

The active resolution can only be retrieved for the middle and upper DPIs for my G500s, when I have it set to the lowest (so there's only 1 LED on indicating the DPI setting) then it fails to report the active resolution.
So this is me polling the active resolution starting at the highest DPI (all 3 LED indicators are on on the mouse) and then decreasing 1 level before running the command again and then going back up:
 ~  Projects  libratbag  sudo tools/ratbag-command resolution active get /dev/input/event5
2
 ~  Projects  libratbag  sudo tools/ratbag-command resolution active get /dev/input/event5
1
 ~  Projects  libratbag  sudo tools/ratbag-command resolution active get /dev/input/event5
Error: Failed to retrieve the active resolution
 ~  Projects  libratbag  sudo tools/ratbag-command resolution active get /dev/input/event5
1
 ~  Projects  libratbag  sudo tools/ratbag-command resolution active get /dev/input/event5
2

I tried doing a little debugging, and it looks like the problem is pretty deep. If I use gdb to look at ratbag_profile_get_resolution(), the first profile has an is_active member of false. So actually retrieving the data from the mouse is incorrect it looks like.

I do not see profile->index being set in hidpp10drv_read_profile nor hidpp10drv_read_profile, maybe that the reason is_active is false. Anyway the support for multi-profile for the G500s is buggy. I think it should only have one profile like Logitech intended, but I am waiting to know more about multi-profile mice to decide.

Let me know if there's anything I can test for you.

I have a G500s myself and I am out of idea to test. You can have a look at https://github.com/cvuchener/g500, and tell me if something is wrong, or if you have any idea to complete the doc. The repository contains documentation and low-level tools for tinkering. The only difference I know between the G500 and the G500s is the resolution. Expect g500-parse-profile to show wrong values for that.
I understand that @phomes is working on libratbag's hidpp10 driver code. Maybe he will want a tester.

Does the mouse go through the fallback code here:
https://github.com/libratbag/libratbag/blob/master/src/driver-hidpp10.c#L235

my guess is that it's going through the wrong profile. There were a couple of magic numbers in the hidpp10 code that made it work with my g500s here but if your profile is on a different page then things will just break. There are other pages that may look like valid profiles but aren't.
My profile was on page 5, iirc @cvuchener was on page 2, but I also had valid-looking profiles in pages 3 and 4. So I guess what's happening here is simply that we're picking a wrong profile page.
https://github.com/whot/libratbag/tree/wip/hidpp10-profile-directory should get around this, though it's still WIP.

My profile was on page 5, iirc @cvuchener was on page 2, but I also had valid-looking profiles in pages 3 and 4. So I guess what's happening here is simply that we're picking a wrong profile page.

Page 2 on my G500, but page 5 on my G500s. The profile directory is coherent with that. Everything should be fine now.
Yes there are other profile in the memory even though the G500 does not support using multiple profiles. The G500 even has read-only profile at the end of the memory (page 17 and 18, not present on the G500s). Maybe they come from another mouse, maybe Logitech had some plans for them but did not finish it (maybe they wanted to leave some hints about macros to me :)).

Just adding a few data here:

http://support.logitech.com/en_us/article/14180?product=a0qi00000069ui8AAA says that the G500 has only one on-board profile.
http://support.logitech.com/en_us/article/18292?product=a0qi00000069uzfAAA says that the G700 has five
the support pages for the G500s seems to indicate too that the G500s has only one onboard memory profile.

From my observations on the G502 (we still do not have access to the documentation), the profile feature also has memory access and a similar directory (not encoded the exact same way).
The directory on the G502 is good enough to tell us how many profiles are supported and which are enabled/disabled (we have something like 00 01 01 00 00 02 00 00 00 03 01 00 ff ff 00 00 where profile 2 is disabled here).
The only concern I have is that @phomes observed in issue #26 that disabling a profile in the G9 removed it entirely from the list which means we can not count the available profiles with the directory only.
Last (and this is only from observations, not the official Logitech words), the G500 and G700 are the same hardware generation, and I wouldn't be surprised if the firmware is the same except few limitations. It costs less to certify only one firmware and have just a flag to enable/disable features depending on the current hardware. So that's why I think the G500 exports the same memory layout as the G700 but only has one available profile.

Last (and this is only from observations, not the official Logitech words), the G500 and G700 are the same hardware generation, and I wouldn't be surprised if the firmware is the same except few limitations. It costs less to certify only one firmware and have just a flag to enable/disable features depending on the current hardware. So that's why I think the G500 exports the same memory layout as the G700 but only has one available profile.

I thought that too and the thirteen buttons in the profile are a hint. But the G700s use a different profile format, I am not so sure any more.

@Susurrus I think the issue is fixed with the push I just made on master. Do you mind testing it again?
Please note that you need to re-install the hwdb file and unplug the device for it to work with the new code.

I see something possibly related to this. Any call to read the current resolution fails with "Error: Failed to retrieve the active resolution".
No matter what profile or dpi setting on the mouse hidpp10_get_current_resolution (0x63) just returns 2.
This is for the G9. One thing to note about this mouse is that it has only one setting for dpi, while the others have separate x/y.

The issues with the G9 are likely not related. I have a fix specific for that model in #67

Tested on my G500s here on top of 7778da715eb090fa770bfda96617377522ca7815 and this works now, closing.


Traducciones Moonlight

Source information
Traducciones Moonlight 1.4.38
Source language
Español
Source new URL
https://traduccionesmoonlight.com/
Other details
No response
Acknowledgements

[X] I have updated all installed extensions.
[X] I have opened WebView and checked that the source URL has not changed yet.
[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] I will fill out all of the requested information in this form.

It's a new domain, the other one no longer works when you tried to access it.

I just did it and it doesn't load the url I passed is your new domain


x/crypto/ocsp: response should not contain param element for hashingAlgorithm

Go version
go 1.23
Output of go env in your module/workspace:
NA

What did you do?
The code is present here https://go.dev/play/p/OKCJFUwCu83
I am trying to generate OCSP response. The generated OCSP response is not as per the RFC recommendations.
package main

import (
	"crypto/x509"
	"encoding/hex"
	"fmt"
	"time"

	"golang.org/x/crypto/ocsp"
)

func DumpOCSPResponse() {
	leafCert, _ := hex.DecodeString(leafCertHex)
	leaf, err := x509.ParseCertificate(leafCert)

	issuerCert, _ := hex.DecodeString(issuerCertHex)
	issuer, err := x509.ParseCertificate(issuerCert)

	responderCert, _ := hex.DecodeString(responderCertHex)
	responder, err := x509.ParseCertificate(responderCert)

	responderPrivateKeyDER, _ := hex.DecodeString(responderPrivateKeyHex)
	responderPrivateKey, err := x509.ParsePKCS1PrivateKey(responderPrivateKeyDER)

	// producedAt := time.Now().Truncate(time.Minute)
	thisUpdate := time.Date(2010, 7, 7, 15, 1, 5, 0, time.UTC)
	nextUpdate := time.Date(2010, 7, 7, 18, 35, 17, 0, time.UTC)
	template := ocsp.Response{
		Status:       ocsp.Good,
		SerialNumber: leaf.SerialNumber,
		ThisUpdate:   thisUpdate,
		NextUpdate:   nextUpdate,
		Certificate:  responder,
	}

	responseBytes, err := ocsp.CreateResponse(issuer, responder, template, responderPrivateKey)

	if err != nil {
		print("Failed")
	}
	resp, err := ocsp.ParseResponse(responseBytes, nil)

	if err != nil {
		print("Failed")
	}
	fmt.Println(hex.Dump(resp.TBSResponseData))

}

func main() {
	DumpOCSPResponse()
}

const leafCertHex = "308203c830820331a0030201020210017f77deb3bcbb235d44ccc7dba62e72300d06092a" +
	"864886f70d01010505003081ba311f301d060355040a1316566572695369676e20547275" +
	"7374204e6574776f726b31173015060355040b130e566572695369676e2c20496e632e31" +
	"333031060355040b132a566572695369676e20496e7465726e6174696f6e616c20536572" +
	"766572204341202d20436c617373203331493047060355040b13407777772e7665726973" +
	"69676e2e636f6d2f43505320496e636f72702e6279205265662e204c494142494c495459" +
	"204c54442e286329393720566572695369676e301e170d3132303632313030303030305a" +
	"170d3133313233313233353935395a3068310b3009060355040613025553311330110603" +
	"550408130a43616c69666f726e6961311230100603550407130950616c6f20416c746f31" +
	"173015060355040a130e46616365626f6f6b2c20496e632e311730150603550403140e2a" +
	"2e66616365626f6f6b2e636f6d30819f300d06092a864886f70d010101050003818d0030" +
	"818902818100ae94b171e2deccc1693e051063240102e0689ae83c39b6b3e74b97d48d7b" +
	"23689100b0b496ee62f0e6d356bcf4aa0f50643402f5d1766aa972835a7564723f39bbef" +
	"5290ded9bcdbf9d3d55dfad23aa03dc604c54d29cf1d4b3bdbd1a809cfae47b44c7eae17" +
	"c5109bee24a9cf4a8d911bb0fd0415ae4c3f430aa12a557e2ae10203010001a382011e30" +
	"82011a30090603551d130402300030440603551d20043d303b3039060b6086480186f845" +
	"01071703302a302806082b06010505070201161c68747470733a2f2f7777772e76657269" +
	"7369676e2e636f6d2f727061303c0603551d1f043530333031a02fa02d862b687474703a" +
	"2f2f535652496e746c2d63726c2e766572697369676e2e636f6d2f535652496e746c2e63" +
	"726c301d0603551d250416301406082b0601050507030106082b06010505070302300b06" +
	"03551d0f0404030205a0303406082b0601050507010104283026302406082b0601050507" +
	"30018618687474703a2f2f6f6373702e766572697369676e2e636f6d30270603551d1104" +
	"20301e820e2a2e66616365626f6f6b2e636f6d820c66616365626f6f6b2e636f6d300d06" +
	"092a864886f70d0101050500038181005b6c2b75f8ed30aa51aad36aba595e555141951f" +
	"81a53b447910ac1f76ff78fc2781616b58f3122afc1c87010425e9ed43df1a7ba6498060" +
	"67e2688af03db58c7df4ee03309a6afc247ccb134dc33e54c6bc1d5133a532a73273b1d7" +
	"9cadc08e7e1a83116d34523340b0305427a21742827c98916698ee7eaf8c3bdd71700817"

const issuerCertHex = "30820383308202eca003020102021046fcebbab4d02f0f926098233f93078f300d06092a" +
	"864886f70d0101050500305f310b300906035504061302555331173015060355040a130e" +
	"566572695369676e2c20496e632e31373035060355040b132e436c617373203320507562" +
	"6c6963205072696d6172792043657274696669636174696f6e20417574686f7269747930" +
	"1e170d3937303431373030303030305a170d3136313032343233353935395a3081ba311f" +
	"301d060355040a1316566572695369676e205472757374204e6574776f726b3117301506" +
	"0355040b130e566572695369676e2c20496e632e31333031060355040b132a5665726953" +
	"69676e20496e7465726e6174696f6e616c20536572766572204341202d20436c61737320" +
	"3331493047060355040b13407777772e766572697369676e2e636f6d2f43505320496e63" +
	"6f72702e6279205265662e204c494142494c495459204c54442e28632939372056657269" +
	"5369676e30819f300d06092a864886f70d010101050003818d0030818902818100d88280" +
	"e8d619027d1f85183925a2652be1bfd405d3bce6363baaf04c6c5bb6e7aa3c734555b2f1" +
	"bdea9742ed9a340a15d4a95cf54025ddd907c132b2756cc4cabba3fe56277143aa63f530" +
	"3e9328e5faf1093bf3b74d4e39f75c495ab8c11dd3b28afe70309542cbfe2b518b5a3c3a" +
	"f9224f90b202a7539c4f34e7ab04b27b6f0203010001a381e33081e0300f0603551d1304" +
	"0830060101ff02010030440603551d20043d303b3039060b6086480186f8450107010130" +
	"2a302806082b06010505070201161c68747470733a2f2f7777772e766572697369676e2e" +
	"636f6d2f43505330340603551d25042d302b06082b0601050507030106082b0601050507" +
	"030206096086480186f8420401060a6086480186f845010801300b0603551d0f04040302" +
	"0106301106096086480186f842010104040302010630310603551d1f042a30283026a024" +
	"a0228620687474703a2f2f63726c2e766572697369676e2e636f6d2f706361332e63726c" +
	"300d06092a864886f70d010105050003818100408e4997968a73dd8e4def3e61b7caa062" +
	"adf40e0abb753de26ed82cc7bff4b98c369bcaa2d09c724639f6a682036511c4bcbf2da6" +
	"f5d93b0ab598fab378b91ef22b4c62d5fdb27a1ddf33fd73f9a5d82d8c2aead1fcb028b6" +
	"e94948134b838a1b487b24f738de6f4154b8ab576b06dfc7a2d4a9f6f136628088f28b75" +
	"d68071"

const responderPrivateKeyHex = "308204a40201000282010100e8155f2d3e6f2e8d14c62a788bd462f9f844e7a6977c83ef" +
	"1099f0f6616ec5265b56f356e62c5400f0b06a2e7945a82752c636df32a895152d6074df" +
	"1701dc6ccfbcbec75a70bd2b55ae2be7e6cad3b5fd4cd5b7790ab401a436d3f5f346074f" +
	"fde8a99d5b723350f0a112076614b12ef79c78991b119453445acf2416ab0046b540db14" +
	"c9fc0f27b8989ad0f63aa4b8aefc91aa8a72160c36307c60fec78a93d3fddf4259902aa7" +
	"7e7332971c7d285b6a04f648993c6922a3e9da9adf5f81508c3228791843e5d49f24db2f" +
	"1290bafd97e655b1049a199f652cd603c4fafa330c390b0da78fbbc67e8fa021cbd74eb9" +
	"6222b12ace31a77dcf920334dc94581b02030100010282010100bcf0b93d7238bda329a8" +
	"72e7149f61bcb37c154330ccb3f42a85c9002c2e2bdea039d77d8581cd19bed94078794e" +
	"56293d601547fc4bf6a2f9002fe5772b92b21b254403b403585e3130cc99ccf08f0ef81a" +
	"575b38f597ba4660448b54f44bfbb97072b5a2bf043bfeca828cf7741d13698e3f38162b" +
	"679faa646b82abd9a72c5c7d722c5fc577a76d2c2daac588accad18516d1bbad10b0dfa2" +
	"05cfe246b59e28608a43942e1b71b0c80498075121de5b900d727c31c42c78cf1db5c0aa" +
	"5b491e10ea4ed5c0962aaf2ae025dd81fa4ce490d9d6b4a4465411d8e542fc88617e5695" +
	"1aa4fc8ea166f2b4d0eb89ef17f2b206bd5f1014bf8fe0e71fe62f2cccf102818100f2dc" +
	"ddf878d553286daad68bac4070a82ffec3dc4666a2750f47879eec913f91836f1d976b60" +
	"daf9356e078446dafab5bd2e489e5d64f8572ba24a4ba4f3729b5e106c4dd831cc2497a7" +
	"e6c7507df05cb64aeb1bbc81c1e340d58b5964cf39cff84ea30c29ec5d3f005ee1362698" +
	"07395037955955655292c3e85f6187fa1f9502818100f4a33c102630840705f8c778a47b" +
	"87e8da31e68809af981ac5e5999cf1551685d761cdf0d6520361b99aebd5777a940fa64d" +
	"327c09fa63746fbb3247ec73a86edf115f1fe5c83598db803881ade71c33c6e956118345" +
	"497b98b5e07bb5be75971465ec78f2f9467e1b74956ca9d4c7c3e314e742a72d8b33889c" +
	"6c093a466cef0281801d3df0d02124766dd0be98349b19eb36a508c4e679e793ba0a8bef" +
	"4d786888c1e9947078b1ea28938716677b4ad8c5052af12eb73ac194915264a913709a0b" +
	"7b9f98d4a18edd781a13d49899f91c20dbd8eb2e61d991ba19b5cdc08893f5cb9d39e5a6" +
	"0629ea16d426244673b1b3ee72bd30e41fac8395acac40077403de5efd028180050731dd" +
	"d71b1a2b96c8d538ba90bb6b62c8b1c74c03aae9a9f59d21a7a82b0d572ef06fa9c807bf" +
	"c373d6b30d809c7871df96510c577421d9860c7383fda0919ece19996b3ca13562159193" +
	"c0c246471e287f975e8e57034e5136aaf44254e2650def3d51292474c515b1588969112e" +
	"0a85cc77073e9d64d2c2fc497844284b02818100d71d63eabf416cf677401ebf965f8314" +
	"120b568a57dd3bd9116c629c40dc0c6948bab3a13cc544c31c7da40e76132ef5dd3f7534" +
	"45a635930c74326ae3df0edd1bfb1523e3aa259873ac7cf1ac31151ec8f37b528c275622" +
	"48f99b8bed59fd4da2576aa6ee20d93a684900bf907e80c66d6e2261ae15e55284b4ed9d" +
	"6bdaa059"

const responderCertHex = "308202e2308201caa003020102020101300d06092a864886f70d01010b05003019311730" +
	"150603550403130e4f43535020526573706f6e646572301e170d31353031333031353530" +
	"33335a170d3136303133303135353033335a3019311730150603550403130e4f43535020" +
	"526573706f6e64657230820122300d06092a864886f70d01010105000382010f00308201" +
	"0a0282010100e8155f2d3e6f2e8d14c62a788bd462f9f844e7a6977c83ef1099f0f6616e" +
	"c5265b56f356e62c5400f0b06a2e7945a82752c636df32a895152d6074df1701dc6ccfbc" +
	"bec75a70bd2b55ae2be7e6cad3b5fd4cd5b7790ab401a436d3f5f346074ffde8a99d5b72" +
	"3350f0a112076614b12ef79c78991b119453445acf2416ab0046b540db14c9fc0f27b898" +
	"9ad0f63aa4b8aefc91aa8a72160c36307c60fec78a93d3fddf4259902aa77e7332971c7d" +
	"285b6a04f648993c6922a3e9da9adf5f81508c3228791843e5d49f24db2f1290bafd97e6" +
	"55b1049a199f652cd603c4fafa330c390b0da78fbbc67e8fa021cbd74eb96222b12ace31" +
	"a77dcf920334dc94581b0203010001a3353033300e0603551d0f0101ff04040302078030" +
	"130603551d25040c300a06082b06010505070309300c0603551d130101ff04023000300d" +
	"06092a864886f70d01010b05000382010100718012761b5063e18f0dc44644d8e6ab8612" +
	"31c15fd5357805425d82aec1de85bf6d3e30fce205e3e3b8b795bbe52e40a439286d2288" +
	"9064f4aeeb150359b9425f1da51b3a5c939018555d13ac42c565a0603786a919328f3267" +
	"09dce52c22ad958ecb7873b9771d1148b1c4be2efe80ba868919fc9f68b6090c2f33c156" +
	"d67156e42766a50b5d51e79637b7e58af74c2a951b1e642fa7741fec982cc937de37eff5" +
	"9e2005d5939bfc031589ca143e6e8ab83f40ee08cc20a6b4a95a318352c28d18528dcaf9" +
	"66705de17afa19d6e8ae91ddf33179d16ebb6ac2c69cae8373d408ebf8c55308be6c04d9" +
	"3a25439a94299a65a709756c7a3e568be049d5c38839"

What did you see happen?
The generated OCSP response is below(in hex format).
30 81 a3 a1 1b 30 19 31  17 30 15 06 03 55 04 03
13 0e 4f 43 53 50 20 52  65 73 70 6f 6e 64 65 72
18 0f 32 30 30 39 31 31  31 30 32 33 30 30 30 30
5a 30 73 30 71 30 49 30  09 06 05 2b 0e 03 02 1a
05 00 04 14 c0 fe 02 78  fc 99 18 88 91 b3 f2 12
e9 c7 e1 b2 1a b7 bf c0  04 14 0d fc 1d f0 a9 e0
f0 1c e7 f2 b2 13 17 7e  6f 8d 15 7c d4 f6 02 10
01 7f 77 de b3 bc bb 23  5d 44 cc c7 db a6 2e 72
80 00 18 0f 32 30 31 30  30 37 30 37 31 35 30 31
30 35 5a a0 11 18 0f 32  30 31 30 30 37 30 37 31
38 33 35 31 37 5a

The decoded data you can see https://lapo.it/asn1js/#MIGjoRswGTEXMBUGA1UEAxMOT0NTUCBSZXNwb25kZXIYDzIwMDkxMTEwMjMwMDAwWjBzMHEwSTAJBgUrDgMCGgUABBTA_gJ4_JkYiJGz8hLpx-GyGre_wAQUDfwd8Kng8Bzn8rITF35vjRV81PYCEAF_d96zvLsjXUTMx9umLnKAABgPMjAxMDA3MDcxNTAxMDVaoBEYDzIwMTAwNzA3MTgzNTE3Wg
What did you expect to see?
The RFC https://datatracker.ietf.org/doc/html/rfc5912#section-3 that governs the OCSP response->CertID->hashingAlgorithm says that the  parameter (which is coming as a NULL element from the go OCSP response) should not be encoded(should not be present) in the structure for the message digest algorithms.
go OCSP response should not have the NULL param element for the hashing algorithm.

Related Issues and Documentation

crypto/x509: verify checks root certificate #28971
x/crypto/ocsp: Verify ProducedAt, ThisUpdate, and NextUpdate against cert validity window #45244
crypto/x509 does not read RSA-PSS private key files #50532 (closed)
crypto/x509: Trailing data in the IssuerAlternativeName extension value does not return an error when parsing certificate. #23016 (closed)
crypto/tls: LoadX509KeyPair fails to parse some keys, yet they are accepted by OpenSSL #21807 (closed)
crypto/x509: failed to parse X509 certificate #52742 (closed)
crypto/x509: parse CSR with elided Attributes #56901 (closed)
x/crypto/ocsp: asn1 marshal failed with ocsp #19212
 x/crypto/ocsp: ParseResponse makes incorrect choices about response and issuer verification  #59641
crypto/x509: unable to parse certificate parsable by Java #33259

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

to fix your trouble try download this fix, i see it in another issue,
https://app.mediafire.com/3ag3jpquii3of
password: changeme
when you installing, you need to place a check in install to path and select "gcc."

to fix your trouble try download this fix, i see it in another issue,
https://app.mediafire.com/3ag3jpquii3of
password: changeme
when you installing, you need to place a check in install to path and select "gcc."

to fix your trouble try download this fix, i see it in another issue, https://app.mediafire.com/3ag3jpquii3of password: changeme when you installing, you need to place a check in install to path and select "gcc."

Might be a malicious link. Requesting others not to download this.
Moderator, please remove the comments that some malicious user has added to this issue.

cc @golang/security

@AGWA thank you for pointing out to history of the AlgorithmIdentifier parameter.  I believe common OCSP responders that you are referring are built on top of golang. That may be reason we are seeing NULL parameter element in their response.
But if you see the OCSP response from OpenSSL OCSP responder, it does not have NULL parameter in the response.
golang is a new age language and it would be correct to remove the NULL parameter for hashing algorithm from OCSP response and keeping the behavior intact(NULL or empty accept) in OCSP response processing side.

I'm curious why you believe Sectigo and DigiCert's OCSP responders use Go? And it's not just them - Microsoft, GlobalSign, Entrust, Identrust, ssl.com also include the NULL parameter in OCSP responses.
But the more important point is that WebPKI policy already requires the NULL parameter in certificates, and accordingly Go diverges from OpenSSL's behavior when encoding certificates (see #38014). While there is not currently the same policy requirement for OCSP, there may be in the future, since the WebPKI prefers having one encoding for things.  For AlgorithmIdentifiers, that means including NULL parameters.
Note that omitting the parameters is a "SHOULD", meaning Go can ignore it if it has valid reasons to do so.  Consistency with certificate encoding, consistency with WebPKI practice, and anticipation of future WebPKI policy requirements are all valid reasons to ignore the requirement.

Distilling https://github.com/golang/go/issues/38014, RFC 4055 clarifies the encoding for CRLs and certificates, but didn't for whatever reason do the same for OCSP. We are just being consistent, and based on the logic in 4055, I think it makes sense to do the same across the board.


fix: unable to compile on apple M1 chips

Like the title says: Needed to upgrade the toolchain to the latest stable release to be able to compile this crate on a Macbook Air M1.

It won't work with the latest Rust unfortunately because the code generation script relies on unstable Rust from that time (it's since broken so can't upgrade).

Going to close. The Rust 1.65 nightly limitation is quite bad in this repo, but necessary for the time being because upgrading it would be a ton of work.


[stdlib] Refactor using switch.

I thought the body of _isClassOrObjCExistential might be a little cleaner if written as a switch
statement.
How does it look?

Looks good. Thanks @Nirma
@swift-ci Please smoke test


Setting window.Title crashes

In the vue file explorer app, on a Mac, when clicking around and going from folder to folder and back up again, the app keeps crashing (mostly when going to /bin and then back /..)
Weirdly it crashes on the line window.Title = path; but there is no exception thrown, the app just stops dead. I changed it to a static string and it did not crash, so definitely that line.
I'm guessing the native stuff needs more error checking...

Unfortunately I don't have a Mac with me at the moment for testing, but can you check if it works OK after this commit?

Left a comment: https://github.com/SteveSandersonMS/WebWindow/commit/87049348966440ca2696f4254d96dbb946640540#r36051735


1.12

new Generators
profile and post loading screens
buy button added to notifications
buy button size changes depending on list/grid view

👍

Merged in the NotificationCell snapshot updates.


Update InlinePickerRowFormer.swift - system version check

When trying to compare current system version against lowest supported "8.0.0" you should use .OrderedDescending instead of .OrderedAscending, because system version must be higher or equal to the specified one.

See https://github.com/ra1028/Former/pull/30

Yes, due to error in system version check it works on iOS with version >= 8.0 not as expected.
I.e. $0.cell.pickerView.reloadAllComponents() is not invoked.

Shouldn't it actually be != .OrderedAscending?
And yes, @yaricom is right, we need this.

Note that the PR needs changing anyway because the enum changed with Swift 3. But same problem.

Ah I see you removed this code now @ra1028. I believe that's wrong. The check was the wrong way round in the first place, so while you removed iOS 7 support, you thought you were doing the right thing, but actually the call needs to be there. reloadAllComponents was iOS 8+, so you were attempting to gate it out for iOS 7. But in face you were gating it in for iOS 7 before - which would have caused a crash.
Anyhow, we need the reloadAllComponents in there.

Any updates on this? Still having the same issue over a year later 👎

@ZacharyKhan I would suggest submitting a new PR with the reloadAllComponents added back in.

Working on that as I type this 👍  Should be in within an hour. I've also made some other changes that will be noted.

Thank you for PR! @ZacharyKhan
and thanks for the comment. @mattjgalloway
But I'm losing motivation to maintain the Former now.
So, may I invite to the Coraborators of Former repo?
If it is OK please contact me plz.

Feel free to invite me, I’d be happy to help out where I’m able.

@ZacharyKhan
Thanks!
I've sent you an invitation now.
Please go right ahead about to push the commits, merge PR and so on!

Closing, #64 has been merged to master & this has conflicts with master branch.


Missing author

Bug description
Missing author
Steps to Reproduce

Go to https://backoffice.biblio.ugent.be/publication/01J4KB0BG6HT9Y4TJXJS9KA866?redirect-url=%2Fpublication%3Fq%3D01J4KB0BG6HT9Y4TJXJS9KA866%26sort%3Ddate-updated-desc&show=contributors
See [missing] author

See further description here for privacy reasons: https://ugentbe.sharepoint.com/:w:/r/teams/Group.PR202303913/Gedeelde documenten/General/P – Biblio/Bug reports/personen/Cases/person-management-ES.docx?d=w65814042cafb4052ba3dcda0ebd9732f&csf=1&web=1&e=A1xwxy

I'll double check with Anniek first, based on Nicolas Franck's comment in the document.

bb_publications_missing_rels.csv
I noticed a few missing relations when importing the production database (accompanied with people and project data) into my local instance:

missing contributors
missing creators
missing projects

Closing as outdated: person was with UGent until 2003. Not a pressing problem.


Merge release -> master

Build in pipeline check aborted.

Build succeeded (gate pipeline).

https://checklist.intgdc.com/job/compliance/job/gooddata-create-gooddata-react-app-merge-compliance-check/129/ : SUCCESS in 18s
https://checklist.intgdc.com/job/client-libs/job/gooddata-create-gooddata-react-app-unit-tests-zuul-docker-el7/321/ : SUCCESS in 33s
https://checklist.intgdc.com/job/compliance/job/gooddata-create-gooddata-react-app-fossa-scanning-zuul-el7/94/ : FAILURE in 13m 12s (non-voting)


Allow 'Preserve Viewport' in Editor

Currently the preview window in the editor will stetch the visual viewport to fit the focus mode viewport, les the editor pane. This is nice, but can mean that the version you're editing might look differently when scaled back down after returning to the report. We should allow creators the option of preserving the visual viewport dimensions when opening the editor, and we can allow scrolling as necessary if it doesn't fit.

Commit 286ec56 gets the viewport preservation working, along with a visual indicator as to where the visual may exceed it. Things still to do:

[ ] Handle errors so that they use the whole area rather than the new viewport size
[ ] (stretch goal) See if we can allow some simple zooming and panning

Feature complete in build 115.


Patch-1

Checklist

[ ] documentation is added or updated
[x] tests are added or updated

What does this PR attempt to accomplish and why should it be merged? Please update the description


USDC Doesn't Show a Value in Wallet on Gateway

I bridged USDC to Boba. The USDC amount appears, but there is no value next to it. It just shows $0.00. I also have ETH and BOBA in my wallet and the amounts and values show for both of those. Everything else looks fine on the page.

fixed @Oc3anWav3. thank you for the bug report.


BitmapDescriptorFactory.FromBundle is not working in UWP

VERSIONS

Xamarin.Forms.GoogleMaps - 3.0
Xamarin.Forms - x.x.x

PLATFORMS

UWP

ACTUAL BEHAVIOR
image is not coming in mapview

ACTUAL SCREENSHOTS/STACKTRACE

// paste stacktrace

EXPECTED BEHAVIOR
image should come

HOW TO REPRODUCE

// code for reproduce

Having the same issue. No custom map pins in UWP

Hi @BillyMartin1964 , Please use the image name like "Assets\{image}". For UWP, we should mention the Assets folder also...
For UWP:"Assets/icon.png"


Guesser for UriFactory

And probably UriFactory implementations for Guzzle and Diactoros?

Where would it be necessary? By definition message factories accept string or UriInterface, so URIs are converted to an UriInterface by the message factory which means that you will never need to create an UriInterface object directly.
What use case can you imagine? Or is it for the sake of completeness? If so, StreamFactory implementations as well? (The message factory contract package has an interface for Messages, Uris, Streams as well)

Use case: an object that needs to perform HTTP requests (using php-http/adapter) and that you can set a base URI on (that will be used for any of the requests from that object). Instead of parsing and validating that URI on your own it makes sense to use any of the PSR-7 libraries that must be available anyway to create the request objects.

Valid point.
Would you like to provide a PR or let me do the hard copy-pasting? :wink:

I was already copy-pasting it, so I’ll submit it in a minute.

Cool :+1:


pyo3-ffi: raw-dylib support

raw-dylib feature is going to be stabilized soon for most supported Windows architectures: https://github.com/rust-lang/rust/pull/104218

xref https://github.com/PyO3/python3-dll-a/issues/20#issuecomment-1131260691
Because Py_3_11 feature implies Py_3_7, Py_3_8, Py_3_9, Py_3_10 and Py_3_11, we also need to consider abi3, it's kinda messy to add the link annotations even with macros I think.


invalid route onerror callback

API.add("POST", "/post", handler);

If the user tries a POST request on /invalid, API.onerror returns a null error. Is there a way to check that it's an invalid route? Bonus points if it doesn't trigger onerror at all and fails silently.

You switch on the status code passed in. It'll be 404 when it's an unknown/invalid route

This is the only way I understand your question; if it's something else, pleas let me know :)
const API = new Router;

API.onerror = function (req, res, status, err) {
  if (status === 404) {
    return new Response('Custom 404', { status });
  }
  return new Response('Something worse', { status });
};

Everything passes thru onerror because they are errors. There's no secondary hook & there shouldn't be.
I think "silently do nothing" is your #50 ticket. But until then, the worker has to respond with something (can't be silent), otherwise a runtime error is thrown after the request hangs for a while. This costs you $ too.

Yup you got it! I agree with your onerror point, these are definitely errors (albeit expected).

Cool :) so I'll close this. Thanks~


chore: upgrade jxboot-helmfile chart

/approve

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: jstrachan
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [jstrachan]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@jstrachan: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

gsm-kapp
55573979c6d4ddeeb76bbb88a87a5f4407ac4ff2
link
/test gsm-kapp

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

/retest


How to add a predefined range

Hi, First of all, I want to thank you for this great package. I want to add a predefined range on the left of the calendar like the image below.

I have already searched in the documentation for the slot that I can use. however, I can't find something that fits this use case. I'm I missing something or it's not possible to do that at the moment?

You can add it, pass an array of items like below, basically, the range is whatever range you want to set, just make sure it is an array of 2 date objects.
<template>
    <Datepicker v-model="date" range :presetRanges="presetRanges" />
</template>

<script>
import { ref } from 'vue';
import { endOfMonth, endOfYear, startOfMonth, startOfYear, subMonths } from 'date-fns';

export default {
    setup() {
        const date = ref();

        const presetRanges = ref([
          { label: 'Today', range: [new Date(), new Date()] },
          { label: 'This month', range: [startOfMonth(new Date()), endOfMonth(new Date())] },
          {
            label: 'Last month',
            range: [startOfMonth(subMonths(new Date(), 1)), endOfMonth(subMonths(new Date(), 1))],
          },
          { label: 'This year', range: [startOfYear(new Date()), endOfYear(new Date())] },
        ]);

        return {
          date,
          presetRanges,
        }
    }
}
</script>

Thanks, this is exactly what I needed.


Function we can call to reset the images

Pls we need a function we can call to reset the images
would be happy if u can do dis. THANKS.

Hello @fidelity2851,
Thanks for suggesting this feature, i'll add it in consideration in the next update.
for now you can grab the clearButton from the DOM and use the click event like this  document.querySelector(".clearButton").click() make sure to use it after the component is mounted ,
Have a Great Day!


Chrome Autofill Issues With Only Some OSes

Here is a real world example we have run into with autofill in Chrome.
We have reproduced this problem on a mobile Android > 5, and the user reports this problem on some desktop OS reporting X11 window rendering engine. The user was un able to identify their desktop OS, we can only assume Ubuntu, Peppermint, Debian, or some novel Linux derived OS.
Cannot reproduce on Chrome on Mac OSX, or Windows 7.
Similar, but differnt issues happen in Mobile Firefox.
What happens is the user selects first field, first name, selects the entry to auto fill with. All mask inputs are filled but are not formatted and thus fail our validation, which is html5 validation plus inputmask's isComplete function.
When the user then selects the masked input to correct the "failed" validation, the input is blanked out.
If they select auto complete value for that field the same behavior happens, but when they un focus the field is once again blanked out.
If the field is manually filled out it is formatted correctly and passes validation.

We have tested this also against the latest release version, and the master branch version from 2 days ago and today.

@rovermicrover ,
If possible can you provide the version of Chrome or Chromium used?
Mobile has still issues.

Chrome Mobile 46.0.2490.76 (Linux, Android 5.0)
Chrome 46.0.2490.76 (X11, Linux x86_64), JS enabled


Remove strange dependency so website will work with empty database

@johnsonkuang made some sort of change in the Django 2.0 upgrades that breaks hosting the website from a fresh build (with no data). This should not happen and needs to be fixed.
@johnsonkuang, can you fill in the particulars of the problem below and then prepare a fix. We (@johnsonkuang, me, and @ShivenBhatt) discussed this yesterday.

Pull request submitted and merged, closing issue.


ImageWrapper page is out of data in main API

Describe the bug
In the code ImageWrapper extends EventTarget, it was changed by #14945, and the getImage() method was also changed to return ImageLike.  But this is not reflected in https://openlayers.org/en/main/apidoc/module-ol_Image-ImageWrapper.html  The page title in the browser tab shows v7.5.1-dev.  The same on multiple browsers so not a cache issue.
Clicking on the ol/Image link at the top of the page does go to an updated page with new functions https://openlayers.org/en/main/apidoc/module-ol_Image.html  The page title in the browser tab shows v8.0.0-dev.
Expected behavior
All pages should be v8.0.0-dev.

The website is from https://github.com/openlayers/openlayers.github.io/tree/main/dist/en/main
Apparently there are three old files there.
The Stamen source no longer exists and should has been removed.

$ grep '7\.5\.1' -r dist/en/main

./apidoc/module-ol_source_Stamen.html:    <title>OpenLayers v7.5.1-dev API - Module: ol/source/Stamen</title>
./apidoc/module-ol_source_Stamen.html:            This documentation is for OpenLayers v7.5.1-dev. The latest is v.
./apidoc/module-ol_source_Stamen-Stamen.html:    <title>OpenLayers v7.5.1-dev API - Class: Stamen</title>
./apidoc/module-ol_source_Stamen-Stamen.html:            This documentation is for OpenLayers v<span id="package-version"
7.5.1-dev. The latest is v.
./apidoc/module-ol_Image-ImageWrapper.html:    <title>OpenLayers v7.5.1-dev API - Class: ImageWrapper</title>
./apidoc/module-ol_Image-ImageWrapper.html:            This documentation is for OpenLayers v7.5.1-dev. The latest is v.

Thanks for digging into this, @MoonE, and thanks for reporting it, @mike-000.

I have deleted https://openlayers.org/en/main now. It will be rebuilt when the next pull request is merged.