Bug in example servers (toolResult confusion)

Describe the bug
A clear and concise description of what the bug is.
it seems like a couple of servers are returning content within toolResult.
Visible in this search (puppeteer/google maps): https://github.com/search?q=repo%3Amodelcontextprotocol%2Fservers toolResult&type=code
From the MCP client typescript completions, I see that content should be NEXT TO toolResult, not inside it.
Expected behavior
It makes sense to me that content is the "chat response" and toolResult is arbitrary data that the tool returns, so content should never be inside the result. Please tell me if this is a wrong assumption (since we have no examples of full featured clients).
Additional context
I am playing with the client and trying to understand inputs/outputs, vscode with zod make it really hard to see what's happening.
Since I played with created my own MCP, I can see why the bug can easily happen, this is what I get as autocomplete:
server.setRequestHandler(CallToolRequestSchema, async (request) => {

return {
// autocomplete list I get in vscode (all of these are `unknown`):
capabilities
completion
content
contents
messages
prompts
protocolVersion
resources
resourceTemplates
serverInfo
then
tools
_meta
description
isError
}

It seems to be like a bunch of these don't belong here
No toolResult as an option at all
Nothing has a type

From the client side, I just see these from callTool { content, isError, toolResult, _meta }
Thanks! MCP is cool!

Cool, one more question - is toolResult an official thing still?
It would be really nice to keep it as an option, so some clients could do their own formatting decisions?

If there is a need, it might be best to open an issue in the specification repo detailing the problem you are trying to solve and preferable a suggested solution. This way we might include it into the draft for the next revision.

I very much want it back, I was playing around with implementing a client and having JUST ONE arbitrary data field makes developing compatible (to each other) client+servers much more feasible while still using the content for chat-related feature of the tool call, while being able to pass ANYTHING in toolResult

also, honestly, doing the data formatting decision for both the client and the AI makes them less powerful, a "raw result" option just makes future stuff more composable?

thank you, I did open an issue, but while it is being resolved, I noticed another problem -
The docs site shows the typescript example returning toolResult while the python returns the content array (not an object).
However in the error handling section, I see both typescript and python returning an object with isError (not just content array).


Containerize your microservice using Docker

As a DevOps
I needContainerize your microservice using Docker
So that [benefit]
Details and Assumptions
* [document what you know]

Acceptance Criteria
gherkin
Given [some context]
When [certain action is taken]
Then [the outcome of action is observed]

OK


CSharper does not recognize class primary constructor

Input:
When we try to enter a class with a primary constructor (c#12)
public class MyClass(string value)
{
    public string Value { get; };
}

Output:
CSharpier doesn't work, et return the following message
Failed to compile so was not formatted.

What version of CSharpier do you use?
To check the version use  dotnet tool list or  dotnet tool list -g

I was using version 0.20 installed from the Rider plugin, which had not been updated automatically.
By manually updating csharpier, it works.
Sorry for the inconvenience


Add multiple file upload selection in the docs

@Titozzz can you please restart the CI build? I've only changed the docs, which shouldn't make the tests fail, since previously it passed.

Ignore the test failure -- they'll go away when #395 is merged.


SerializationAbortException: AOT serializer was missing for type 'BetterEventEntry.OdinSerializedData' when running on iOS

First of all: great package! Really improves the serialization of events compared to the native UnityEvents.
I have been using BetterEvents fine when developing on a PC and deploying to Android, however, when I test on iOS, my BetterEvents don't run correctly and I repeatedly get this error in the XCode log window:
No AOT serializer was pre-generated for the type 'BetterEventEntry.OdinSerializedData'. Please use Odin's AOT generation feature to generate an AOT dll before building, and ensure that 'BetterEventEntry.OdinSerializedData' is in the list of supported types after a scan. If it is not, please report an issue and add it to the list manually.
Stacktrace is not supported on this platform.
(Filename: ./Runtime/Export/Debug/Debug.bindings.h Line: 48)

SerializationAbortException: AOT serializer was missing for type 'BetterEventEntry.OdinSerializedData'.
  at Sirenix.Serialization.Serializer.LogAOTError (System.Type type, System.ExecutionEngineException ex) [0x00000] in <00000000000000000000000000000000>:0
  at Sirenix.Serialization.Serializer.Create (System.Type type) [0x00000] in <00000000000000000000000000000000>:0
  at Sirenix.Serialization.Serializer.Get (System.Type type) [0x00000] in <00000000000000000000000000000000>:0
  at Sirenix.Serialization.Serializer.Get[T] () [0x00000] in <00000000000000000000000000000000>:0
  at Sirenix.Serialization.SerializationUtility.DeserializeValue[T] (Sirenix.Serialization.IDataReader reader, System.Collections.Generic.List`1[T] referencedUnityObjects) [0x00000] in <00000000000000000000000000000000>:0
  at Sirenix.Serialization.SerializationUtility.DeserializeValue[T] (System.IO.Stream stream, Sirenix.Serialization.DataFormat format, System.Collections.Generic.List`1[T] referencedUnityObjects, Sirenix.Serialization.DeserializationContext context) [0x00000] in <00000000000000000000000000000000>:0
  at Sirenix.Serialization.SerializationUtility.DeserializeValue[T] (System.Byte[] bytes, Sirenix.Serialization.DataFormat format, System.Collections.Generic.List`1[T] referencedUnityObjects, Sirenix.Serialization.DeserializationContext context) [0x00000] in <00000000000000000000000000000000>:0
  at BetterEventEntry.OnAfterDeserialize () [0x00000] in <00000000000000000000000000000000>:0

I have added that entry to Odin's AOT Generation preferences, but I am still getting the issue (enabling automatic AOT generation before build or manually generating the dlls doesn't make a difference - still broken):

Unity version is 2019.1.4f1

FYI I have opened an issue with the devs of Odin here: https://bitbucket.org/sirenix/odin-inspector/issues/558/serializationabortexception-aot-serializer
Figured out that the type to be added to the Support Serialized Types list has to follow this format:  “BetterEventEntry+OdinSerializedData” - with that it seems to work.
Still trying to figure out why they're not picked up by Odin's automated scan.

I suffer from this issue, too.
It's really annoying that the type doesn't get added to the supported serialized types automatically.

Not sure if this is a specific case when it is not found during scan but with the current version (3.0.2) of Odin, it found BetterEvents fine in my use case and added it with a + as well.

Did you find any solution?

I have managed to fix it myself on iOS by implementing ISerializationCallbackReceiver recursively on all classes that reference BetterEventEntry.
Here is my code as an example:
public class CutsceneManager : MonoBehaviour, ISerializationCallbackReceiver
{
    public List<CutsceneData> cutscenes;

    public void OnBeforeSerialize()
    {
        foreach (var cutscene in cutscenes)
            cutscene.OnBeforeSerialize();
    }

    public void OnAfterDeserialize()
    {
        foreach (var cutscene in cutscenes)
            cutscene.OnAfterDeserialize();
    }

    [System.Serializable]
    public class CutsceneData : ISerializationCallbackReceiver
    {
        public List<CutsceneEvent> cutsceneEvents;

        public void OnAfterDeserialize()
        {
            foreach (var cEvent in cutsceneEvents)
                cEvent.OnAfterDeserialize();
        }

        public void OnBeforeSerialize()
        {
            foreach (var cEvent in cutsceneEvents)
                cEvent.OnBeforeSerialize();
        }
    }

    [System.Serializable]
    public class CutsceneEvent : ISerializationCallbackReceiver
    {
        public BetterEventEntry cutsceneEvent;

        public void OnAfterDeserialize()
        {
            cutsceneEvent.OnAfterDeserialize();
        }

        public void OnBeforeSerialize()
        {
            cutsceneEvent.OnBeforeSerialize();
        }
    }
}

My guess is that because the MonoBehaviour was not implementing ISerializationCallbackReceiver, the internal classes were not getting picked up by Odin (just a guess...)
Hopefully this helps someone!


Angular SSR with  MSAL.JS CDN - working with types

Please follow the issue template below. Failure to do so will result in a delay in answering your question.
Library

[ ]<EMAIL_ADDRESS>
Description
Hello, I am going to attempt to get Angular Universal working with MSAL.JS.  I will have to use the CDN version to make this work as I already tried with non-CDN and there were too many issues.
Do you have the types I could install?
I am declaring the global MSAL variable like this.
declare var msal: any;
However, you can see in this screenshot I would need to have any types all over the place since the MSAL namespace is not recongized.

Examples:
Angular 9/10

@jrmcdona Unfortunately, the types are included in the main npm package, so you can try installing @azure/msal-browser via npm, which will load the types into your project, but then use the CDN version of the library in your app.

Hey @jasonnutter I am attempting a POC for using Angular SSR so I can't load @azure/msal-browser at it has a lot of issues with SSR.
Therefore I am trying to go straight to CDN, and having those types would be nice but will need to try without a types for now it is looking like.

@jasonnutter I could just manually copy over the types for now but this may be something you want available for people using trying to get SSR to work which means no loading of @azure/msal-browser

@jrmcdona SSR with MSAL Browser will be fixed in #2073


Fix map leak

Fix leak introduced by #209

FYI @omer-s @harryhk

Codecov Report

Merging #211 (54037e1) into master (88cf946) will decrease coverage by 0.16%.
The diff coverage is 52.38%.

@@            Coverage Diff             @@
##           master     #211      +/-   ##
==========================================
- Coverage   91.47%   91.30%   -0.17%
==========================================
  Files         108      109       +1
  Lines       10140    10184      +44
==========================================
+ Hits         9276     9299      +23
- Misses        864      885      +21

Impacted Files
Coverage Δ

test/oss-fuzz/set-st-0.cpp
38.77% <38.77%> (ø)

immer/detail/hamts/champ.hpp
91.34% <100.00%> (+0.05%)
:arrow_up:

test/oss-fuzz/map-st-0.cpp
58.82% <100.00%> (+20.52%)
:arrow_up:

Continue to review full report at Codecov.

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


Components are not responsive

Not only do we want to support desktop browsers when they are resized to be small, but we also want the whole suite of components to perform well on mobile browsers.

[ ] Compose
[ ] ConversationList
[ ] ConversationListItem
[ ] Message
[ ] MessageList
[ ] Messenger
[ ] Toolbar
[ ] ToolbarButton

Any update on this issue?

@shabab477 Unfortunately not. I would like to put some time into it at some point and figure out how it would work. It would entail more than just adding CSS media queries (ideally), because on mobile devices, this UI should have a "master-detail" structure.
Happy to review PRs in the meantime. Also would like to rewrite them using hooks.

@sejr I did work a version where I use grid and media queries to make it responsive. It was mostly a quick fix. An ideal solution should be that the sidebar is collapsible on mobile view and expanded on desktop view

@sejr Hey you need any help in this ? I would love to do so!


Readme: Link to feature request issue. Minor style improvements.

Making the feature request/issue visible.
Hope it helps moving it.

@2blockchainz ping


Linguistic Buildings: Only display locale resources on the home page

Currently, the Build with tBTC section pulls all resources. This means that
it's agnostic to locales, which means there can be an English home page that
lists non-English resources, even though there are enough English resources to
populate that space.
To fix this, the Resources component is removed, since it was a static
component. Instead, the home page's query now has two allMarkdownRemark
queries, distinguished via GraphQL aliases, to pull news items and resources.
The resources are rendered inline on the home-page template, very similarly to
how news items are.
One notable result is that in languages that don't have enough resources,
the build section may be empty or short. This is an issue shared with news
items, so for now it'll have to do.
Closes #282 .

Should actually work now. Let's see how it goes.

'Tworks 🎊


Course cards do not announce the right course when using Voiceover on iOS

Description
LEARNER-2907
Course cards do not announce the right course when using Voiceover on iOS

Codecov Report

Merging #1037 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master    #1037   +/-   ##
=======================================
  Coverage   48.86%   48.86%
=======================================
  Files         409      409
  Lines       25912    25912
=======================================
  Hits        12662    12662
  Misses      13250    13250

Impacted Files
Coverage Δ

Source/CoursesTableViewController.swift
90.9% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


SignalR.Client 1.0.0-preview1-final - Could not AOT the assembly Microsoft.AspNetCore.Sockets.Abstractions.dll

I'm using Microsoft.AspNetCore.SignalR.Client 1.0.0-preview1-final on a mobile app with Xamarin Forms in .Net Standard 2.0. It works well in DEBUG however in Release I got the following build error on iOS.

MTOUCH : error MT3001: Could not AOT the assembly '/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/Microsoft.AspNetCore.Sockets.Abstractions.dll'

Is the file available? And the mono command line? (and surrounding files -- not sure is needed).

2018-03-29T19:03:25.9038010Z   AOT Compilation exited with code 2, command:
2018-03-29T19:03:25.9066530Z   MONO_PATH=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build /Library/Frameworks/Xamarin.iOS.framework/Versions/<IP_ADDRESS>/bin/arm64-darwin-mono-sgen --debug -O=gsharedvt -O=-float32  --aot=mtriple=arm64-ios,data-outfile=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/arm64/System.Threading.Tasks.Extensions.aotdata.arm64,static,asmonly,direct-icalls,full,nodebug,dwarfdebug,msym-dir=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/Msym,outfile=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/arm64/System.Threading.Tasks.Extensions.dll.s "/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/System.Threading.Tasks.Extensions.dll"
2018-03-29T19:03:25.9116270Z   Cannot open assembly '/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/System.Threading.Tasks.Extensions.dll': File does not contain a valid CIL image.
2018-03-29T19:03:25.9138050Z
2018-03-29T19:03:25.9172590Z   AOT Compilation exited with code 134, command:
2018-03-29T19:03:25.9281410Z   MONO_PATH=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build /Library/Frameworks/Xamarin.iOS.framework/Versions/<IP_ADDRESS>/bin/arm64-darwin-mono-sgen --debug -O=gsharedvt -O=-float32  --aot=mtriple=arm64-ios,data-outfile=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/arm64/Microsoft.AspNetCore.Sockets.Abstractions.aotdata.arm64,static,asmonly,direct-icalls,full,nodebug,dwarfdebug,msym-dir=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/Msym,outfile=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/arm64/Microsoft.AspNetCore.Sockets.Abstractions.dll.s "/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/Microsoft.AspNetCore.Sockets.Abstractions.dll"
2018-03-29T19:03:25.9310940Z   Mono Ahead of Time compiler - compiling assembly /Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/Microsoft.AspNetCore.Sockets.Abstractions.dll
2018-03-29T19:03:25.9334980Z   AOTID 4EE3496B-602D-49D2-676A-C3DEED97C005
2018-03-29T19:03:25.9360650Z   Could not load signature of Microsoft.AspNetCore.SignalR.Internal.ChannelReaderExtensions:ReadAsync due to: Could not load file or assembly 'System.Threading.Tasks.Extensions, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. assembly:System.Threading.Tasks.Extensions, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 type: member:
2018-03-29T19:03:25.9471880Z   * Assertion at /Users/builder/data/lanes/5808/1c6f300e/source/xamarin-macios/external/mono/mono/mini/mini-generic-sharing.c:3670, condition mono_error_ok (&error)' not met 2018-03-29T19:03:25.9493780Z    2018-03-29T19:03:25.9513240Z    2018-03-29T19:03:25.9532410Z   AOT Compilation exited with code 134, command: 2018-03-29T19:03:25.9591740Z   MONO_PATH=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build /Library/Frameworks/Xamarin.iOS.framework/Versions/<IP_ADDRESS>/bin/arm64-darwin-mono-sgen --debug -O=gsharedvt -O=-float32  --aot=mtriple=arm64-ios,data-outfile=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/arm64/System.Threading.Channels.aotdata.arm64,static,asmonly,direct-icalls,full,nodebug,dwarfdebug,msym-dir=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/Msym,outfile=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/arm64/System.Threading.Channels.dll.s "/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/System.Threading.Channels.dll" 2018-03-29T19:03:25.9621430Z   Mono Ahead of Time compiler - compiling assembly /Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/System.Threading.Channels.dll 2018-03-29T19:03:25.9646860Z   AOTID FB480F97-7EE0-A503-622D-D52F8B972C22 2018-03-29T19:03:25.9674330Z   Could not load signature of System.Threading.Channels.ChannelReader1[T]:ReadAsync due to: Could not load file or assembly 'System.Threading.Tasks.Extensions, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. assembly:System.Threading.Tasks.Extensions, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 type: member:
2018-03-29T19:03:25.9720310Z   * Assertion at /Users/builder/data/lanes/5808/1c6f300e/source/xamarin-macios/external/mono/mono/mini/mini-generic-sharing.c:3670, condition mono_error_ok (&error)' not met 2018-03-29T19:03:25.9743340Z    2018-03-29T19:03:25.9763190Z    2018-03-29T19:03:26.9259770Z   AOT Compilation exited with code 2, command: 2018-03-29T19:03:26.9287490Z   MONO_PATH=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build /Library/Frameworks/Xamarin.iOS.framework/Versions/<IP_ADDRESS>/bin/arm64-darwin-mono-sgen --debug -O=gsharedvt -O=-float32  --aot=mtriple=arm64-ios,data-outfile=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/arm64/System.Runtime.CompilerServices.Unsafe.aotdata.arm64,static,asmonly,direct-icalls,full,nodebug,dwarfdebug,msym-dir=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/Msym,outfile=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/arm64/System.Runtime.CompilerServices.Unsafe.dll.s "/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/System.Runtime.CompilerServices.Unsafe.dll" 2018-03-29T19:03:26.9317490Z   Cannot open assembly '/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/System.Runtime.CompilerServices.Unsafe.dll': File does not contain a valid CIL image. 2018-03-29T19:03:26.9339580Z    2018-03-29T19:03:29.2265700Z   AOT Compilation exited with code 2, command: 2018-03-29T19:03:29.2292090Z   MONO_PATH=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build /Library/Frameworks/Xamarin.iOS.framework/Versions/<IP_ADDRESS>/bin/arm64-darwin-mono-sgen --debug -O=gsharedvt -O=-float32  --aot=mtriple=arm64-ios,data-outfile=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/arm64/System.Memory.aotdata.arm64,static,asmonly,direct-icalls,full,nodebug,dwarfdebug,msym-dir=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/Msym,outfile=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/arm64/System.Memory.dll.s "/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/System.Memory.dll" 2018-03-29T19:03:29.2320820Z   Cannot open assembly '/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/System.Memory.dll': File does not contain a valid CIL image. 2018-03-29T19:03:29.2342230Z    2018-03-29T19:03:29.7759220Z   AOT Compilation exited with code 2, command: 2018-03-29T19:03:29.7786500Z   MONO_PATH=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build /Library/Frameworks/Xamarin.iOS.framework/Versions/<IP_ADDRESS>/bin/arm64-darwin-mono-sgen --debug -O=gsharedvt -O=-float32  --aot=mtriple=arm64-ios,data-outfile=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/arm64/System.Buffers.aotdata.arm64,static,asmonly,direct-icalls,full,nodebug,dwarfdebug,msym-dir=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/Msym,outfile=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/arm64/System.Buffers.dll.s "/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/System.Buffers.dll" 2018-03-29T19:03:29.7815730Z   Cannot open assembly '/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/System.Buffers.dll': File does not contain a valid CIL image. 2018-03-29T19:03:29.7836820Z    2018-03-29T19:03:31.6536790Z   AOT Compilation exited with code 134, command: 2018-03-29T19:03:31.6564110Z   MONO_PATH=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build /Library/Frameworks/Xamarin.iOS.framework/Versions/<IP_ADDRESS>/bin/arm64-darwin-mono-sgen --debug -O=gsharedvt -O=-float32  --aot=mtriple=arm64-ios,data-outfile=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/arm64/System.Buffers.Primitives.aotdata.arm64,static,asmonly,direct-icalls,full,nodebug,dwarfdebug,msym-dir=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/Msym,outfile=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/arm64/System.Buffers.Primitives.dll.s "/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/System.Buffers.Primitives.dll" 2018-03-29T19:03:31.6593170Z   Mono Ahead of Time compiler - compiling assembly /Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/System.Buffers.Primitives.dll 2018-03-29T19:03:31.6617290Z   AOTID 6DF4AA81-61D1-F709-7051-31DE5CFD6489 2018-03-29T19:03:31.6642520Z   Could not load signature of System.Buffers.IMemoryList1[T]:get_Memory due to: Could not load file or assembly 'System.Memory, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. assembly:System.Memory, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 type: member:
2018-03-29T19:03:31.6668750Z   * Assertion at /Users/builder/data/lanes/5808/1c6f300e/source/xamarin-macios/external/mono/mono/mini/mini-generic-sharing.c:3670, condition `mono_error_ok (&error)' not met
2018-03-29T19:03:31.6690170Z
2018-03-29T19:03:31.6708910Z
2018-03-29T19:03:32.5053760Z   AOT Compilation exited with code 1, command:
2018-03-29T19:03:32.5082490Z   MONO_PATH=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build /Library/Frameworks/Xamarin.iOS.framework/Versions/<IP_ADDRESS>/bin/arm64-darwin-mono-sgen --debug -O=gsharedvt -O=-float32  --aot=mtriple=arm64-ios,data-outfile=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/arm64/System.IO.Pipelines.aotdata.arm64,static,asmonly,direct-icalls,full,nodebug,dwarfdebug,msym-dir=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/Msym,outfile=/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/arm64/System.IO.Pipelines.dll.s "/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/System.IO.Pipelines.dll"
2018-03-29T19:03:32.5111690Z   Mono Ahead of Time compiler - compiling assembly /Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/System.IO.Pipelines.dll
2018-03-29T19:03:32.5135980Z   AOTID 25225CBB-2A32-9763-0273-DA7CC954B213
2018-03-29T19:03:32.5162660Z   Failed to load method 0x60000d5 from '/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/System.IO.Pipelines.dll' due to Could not load file or assembly 'System.Memory, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. assembly:System.Memory, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 type: member:.
2018-03-29T19:03:32.5190550Z   Run with MONO_LOG_LEVEL=debug for more information.
2018-03-29T19:03:32.5212350Z   AOT of image /Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/System.IO.Pipelines.dll failed.
2018-03-29T19:03:32.5233550Z
2018-03-29T19:03:46.3955100Z MTOUCH : error MT3001: Could not AOT the assembly '/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/Microsoft.AspNetCore.Sockets.Abstractions.dll' [/Users/vsts/agent/2.131.0/work/1/s/Platforms/MyApp.iOS/MyApp.iOS.csproj]

@jaykrell https://www.nuget.org/packages/Microsoft.AspNetCore.Sockets.Abstractions/1.0.0-preview1-final. I'm assuming i has something to do with System.Memory.

Note that this on vsts. I can build DEBUG | iPhone on my machine and install the app on my iPhone. And as soon I use a device rather than the simulator it does AOT compilation normally. So I don't understand why it compiles on my machine and not on VSTS. I'll try to compile on release on my machine to see if any differences.

It also builds fine on Release | iPhone on my machine.

Do you know which Xamarin.iOS version is getting used VSTS?

Actually on my pc the xamarin.ios version is <IP_ADDRESS> but on my mac it is <IP_ADDRESS>. When I build from the pc connected to the mac I don't really know what is used.

Also mono on vsts is 5.8.0 while I'm on 5.8.1

I'm trying to make my mac a private agent of vsts and see if it works.

I managed to run the vsts build defintion on my mac with a private agent.
And I got the same vsts error:

MTOUCH : error MT3001: Could not AOT the assembly '/Users/francois/myagent/_work/2/s/Platforms/MyApp.iOS/obj/iPhone/Release/mtouch-cache/Build/Microsoft.AspNetCore.Sockets.Abstractions.dll'

So I'm lost. It works on my machine from (Visual Studio connected to my mac) nut not on vsts running on my mac :-(

Could you upload the obj/iPhone/Release/mtouch-cache directory ?

What do you mean by upload?
But it's true that my local build uses that cache folder whereas vsts doesn't.

Are you looking for something specific in that directory? I can't upload it here unfortunately as this is client's code so I don't think I'd have the right to do so :-(
Unless I try to reproduce the behavior with a a sample app...

The same directory but within the agent directory for vsts doesn't have Microsoft.AspNetCore.Sockets.Abstractions.dll
It only has Microsoft.AspNetCore.Sockets.Abstractions.aotdata.arm64

Trying to compare MTOUCH args:
When running with VS (same line twice):
-r=/Users/francois/Library/Caches/Xamarin/mtbs/builds/MyApp.iOS/b4a91b9a48ec7dd4bd9fdcbeb8a49e8c/bin/iPhone/Release/Microsoft.AspNetCore.Sockets.Abstractions.dll
-r=/Users/francois/Library/Caches/Xamarin/mtbs/builds/MyApp.iOS/b4a91b9a48ec7dd4bd9fdcbeb8a49e8c/bin/iPhone/Release/Microsoft.AspNetCore.Sockets.Abstractions.dll

When running with VSTS:
-r=/Users/vsts/.nuget/packages/microsoft.aspnetcore.sockets.abstractions/1.0.0-preview1-final/lib/netstandard2.0/Microsoft.AspNetCore.Sockets.Abstractions.dll


Support Authenticated GitHub Requests in Setup

Using this container provides a great deal of portability, but after a certain amount of usage we ran into GitHub rate limiting in setup.py on container start:
Traceback (most recent call last):
  File "/usr/local/startup_scripts/setup.py", line 57, in <module>
    setup()
  File "/usr/local/startup_scripts/setup.py", line 39, in setup
    get_latest_codeql(args)
  File "/usr/local/startup_scripts/setup.py", line 46, in get_latest_codeql
    latest_online_version = codeql.get_latest_codeql_github_version()
  File "/usr/local/startup_scripts/libs/codeql.py", line 80, in get_latest_codeql_github_version
    return get_latest_github_repo_version("github/codeql-cli-binaries")
  File "/usr/local/startup_scripts/libs/github.py", line 8, in get_latest_github_repo_version
    latest_release = get_latest_github_release(releases)
  File "/usr/local/startup_scripts/libs/github.py", line 14, in get_latest_github_release
    for release in releases:
  File "/usr/local/lib/python3.8/dist-packages/github/PaginatedList.py", line 64, in __iter__
    newElements = self._grow()
  File "/usr/local/lib/python3.8/dist-packages/github/PaginatedList.py", line 76, in _grow
    newElements = self._fetchNextPage()
  File "/usr/local/lib/python3.8/dist-packages/github/PaginatedList.py", line 197, in _fetchNextPage
    headers, data = self.__requester.requestJsonAndCheck(
  File "/usr/local/lib/python3.8/dist-packages/github/Requester.py", line 275, in requestJsonAndCheck
    return self.__check(*self.requestJson(verb, url, parameters, headers, input, self.__customConnection(url)))
  File "/usr/local/lib/python3.8/dist-packages/github/Requester.py", line 286, in __check
    raise self.__createException(status, responseHeaders, output)
github.GithubException.RateLimitExceededException: 403 {'message': "API rate limit exceeded for x.x.x.x. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)", 'documentation_url': 'https://docs.github.com/rest/overview/resources-in-the-rest-api#rate-limiting'}
Error 1 executing from command.
Exiting...
Command Output:
[2022-12-07 15:14:37,788] INFO: Starting setup...
[2022-12-07 15:14:38,234] INFO: Current codeql version: v2.11.3

Our execution commands were all passing the GITHUB_TOKEN environment variable to docker run, as the intent was to also upload the results to a private GitHub repository. However, we have realized that the instantiation of PyGithub client doesn't pass in or make use of the same env variable for any authentication on requests to public repos to validate the CodeQL CLI version:
https://github.com/microsoft/codeql-container/blob/main/container/libs/github.py#L5
Within our organization, the rate-limiting by IP Address is only going to get worse, and there is no reason for us to not authenticate for these requests.
This Pull Request does the following:

Moves the check for the latest CodeQL CLI version to occur only if CHECK_LATEST_CODEQL_CLI is true (whereas before it always checked and left the value unused).
Checks for an environment variable called "GITHUB_TOKEN" and passes it into the PyGithub ctor to allow for authenticated requests.

The changes are pretty small, but I'm not sure next steps for testing/validation cross-platform, or if that is included in a build process.

@microsoft-github-policy-service agree [company="SPS Commerce"]

@microsoft-github-policy-service agree company="SPS Commerce"

@jacobmsft just checking in to see if you think there is an opportunity to pull this into main ? This is a pretty big problem for us, and this would be fantastic to get it solved here.

Hi travisgosselin,
Thank you for the PR and the detailed description! I think it definitely makes sense to merge to main. I am stuck on account access issues at the moment, hopefully that gets resolved in a couple days and I can merge it.

Thanks @surajjacob

Thank you for the PR and the detailed description! I think it definitely makes sense to merge to main. I am stuck on account access (and hence commenting from my alternate login) issues at the moment, hopefully that gets resolved in a couple days and I can merge it.

Hi @surajjacob / @jacobmsft - any luck in sorting out permissions to be able to merge this?

Thank you for the PR and the detailed description! I think it definitely makes sense to merge to main. I am stuck on account access (and hence commenting from my alternate login) issues at the moment, hopefully that gets resolved in a couple days and I can merge it.

Hi @surajjacob / @jacobmsft - any luck in sorting out permissions to be able to merge this?

Tagging you again @surajjacob / @jacobmsft just in case you see this notification and by chance have permission to merge this in. My organization really badly needs this to continue using this container distribution. Will look at building our own custom version, but would really like to have this issue taken care of in the base here.

Thank you for the PR and the detailed description! I think it definitely makes sense to merge to main. I am stuck on account access (and hence commenting from my alternate login) issues at the moment, hopefully that gets resolved in a couple days and I can merge it.

Hi @surajjacob / @jacobmsft - any luck in sorting out permissions to be able to merge this?

Tagging you again @surajjacob / @jacobmsft just in case you see this notification and by chance have permission to merge this in. My organization really badly needs this to continue using this container distribution. Will look at building our own custom version, but would really like to have this issue taken care of in the base here.

Let me try getting someone else to merge your changes

That would be very much appreciated. Thank you!

@surajjacob / @jacobmsft / @scovetta - thanks for getting this merged in. I pulled down the latest available container in MCR registry and these updates are not in it. Is there a manual process behind the scenes to push updates there?
Struggling a little in general with the visibility and versions in MCR - https://github.com/microsoft/codeql-container/issues/45

@surajjacob / @jacobmsft / @scovetta - thanks for getting this merged in. I pulled down the latest available container in MCR registry and these updates are not in it. Is there a manual process behind the scenes to push updates there?
Struggling a little in general with the visibility and versions in MCR - #45

Hey @travisgosselin , the mcr images are updated every Sunday, you should get it in next week's update. Alternatively, you can clone repository and do docker build.
Visibility and versions are something we need to add more in MCR, I need to figure out what to do for it.

Thanks @surajjacob - that helps knowing the schedule for the MCR builds to know when they drop. Is that on a schedule to run even if no changes to the code base? Just wondering if that schedule implies new query pack releases and precompilation of them every Sunday as well on the latest container?

@surajjacob / @jacobmsft / @scovetta - I'm pulling latest on this image from mcr.microsoft.com/cstsectools/codeql-container:latest and still not seeing any updates. Looks like the container is about 3 months old. Are you sure this is running weekly to update the latest with the newest queries / CLI version?
Also not seeing the changes in this PR or others merged in there, so assuming something has gone wrong with the weekly update. Using the weekly update as a base is very helpful not to rebuild everything.


Css branch

I'm assuming this is still work-in-progress and you know this already, but just in case not: the tests file is empty.

Should be put in python reference: https://raw.githubusercontent.com/mne-tools/mne-python/master/doc/python_reference.rst
cc @larsoner

Test file should probably be in mne/preprocessing/tests

@johnsam7 any time to come back to this in the next couple of weeks? We're aiming to release 0.21 soon and it would be nice to get it into the upcoming release if possible

@johnsam7 any time to come back to this in the next couple of weeks? We're aiming to release 0.21 soon and it would be nice to get it into the upcoming release if possible

I understand, I've got quite a lot of stuff going on right now but I will try to have a look at this!

@johnsam7 would it help if someone pushed some commits to address the remaining issues?

@larsoner @johnsam7 I will work on the remaining issues.

@johnsam7 would it help if someone pushed some commits to address the remaining issues?

Sorry, I've been terribly remiss in dealing with this. Will take care of this now.


Source available?

Is the badge source code available?

Not anywhere I am aware.

Badge source is here http://dmitry.gr/images/defcon_code_1.5.0.tar.bz2


Replace tenent with tenant - Fixes #20

All instances of the misspelling "tenent" have been corrected.

commit changes to develop branch


Unnecessary page title disambiguation in navigation

See here for instance:
https://haxe.org/manual/std-regex-map.html
The titles for the parent nodes are repeated in the navigation, which ends up looking rather strange:

According to @ibilon this happens due to disambiguation, as there are multiple pages with those titles (Map and Implementation Details).

@ibilon if you have time, can you take a look at this ?
Just using Map should be enough?

Fixed by https://github.com/HaxeFoundation/haxe.org/commit/e8501563f17be68dd8406dfd84b6c1b1d095d75a


ignore unclosed players

Not ready for review yet, but going to open this now so I don't forget about it.

Fixing this won't happen soon, as I'm focused on other projects atm. Going to close this so there's not clutter hanging around in the repo.

Acknowledged. Please take your time.

Thank you for tackling the issue!


error related to chromedriver while running serenityjs

Hi,
suddenly my serenityjs based application stopped working. I have upgraded macos sierra version 10.13.1
I am getting following error -
[10:17:16] W/launcher - Ignoring uncaught error WebDriverError: unknown error: cannot get automation extension
from unknown error: page could not be found: chrome-extension://aapnijgdinlhnhlmodcfapnahmbfebeb/_generated_background_page.html
(Session info: chrome=62.0.3202.94)
(Driver info: chromedriver=2.29.461585 (0be2cd95f834e9ee7c46bcc7cf405b483f5ae83b),platform=Mac OS X 10.13.1 x86_64) (WARNING: The server did not provide any stacktrace information)
Command duration or timeout: 10.05 seconds
Build info: version: '3.0.1', revision: '1969d75', time: '2016-10-18 09:48:19 -0700'
System info: host: 'vijays-MacBook-Pro.local', ip: '<IP_ADDRESS>', os.name: 'Mac OS X', os.arch: 'x86_64', os.version: '10.13.1', java.version: '1.8.0_121'
Driver info: org.openqa.selenium.chrome.ChromeDriver
Capabilities [{applicationCacheEnabled=false, rotatable=false, mobileEmulationEnabled=false, networkConnectionEnabled=false, chrome={chromedriverVersion=2.29.461585 (0be2cd95f834e9ee7c46bcc7cf405b483f5ae83b), userDataDir=/var/folders/c0/9ycym1_15ng45kpxrm340m9h0000gn/T/.org.chromium.Chromium.1kgoZ9}, takesHeapSnapshot=true, pageLoadStrategy=normal, databaseEnabled=false, handlesAlerts=true, hasTouchScreen=false, version=62.0.3202.94, platform=MAC, browserConnectionEnabled=false, nativeEvents=true, acceptSslCerts=true, locationContextEnabled=true, webStorageEnabled=true, browserName=chrome, takesScreenshot=true, javascriptEnabled=true, cssSelectorsEnabled=true, unexpectedAlertBehaviour=}]
Session ID: 1173013ba9fd937106a591f8eb80afb1
[10:17:16] E/launcher - BUG: launcher exited with 1 tasks remaining
Please suggest how to fix.
Regards,
Vijay

Could be related to your chromedriver version not being compatible with the version of Chrome you're running? See https://stackoverflow.com/questions/40210169/cannot-get-automation-extension-error-with-chrome-54-0-2840-71

fixed by downgrading  chromedriver to 2.33 .
Thank you for your input.
Closing this issue.


"this function takes 1 parameter but 2 parameters were supplied"

Clone and run https://github.com/Jasperav/CassandraRustMapping, the compile time error will be shown. How can I fix this?

Hi @Jasperav,
I've managed to fix it. This is the git diff from your project:
--- a/src/car.rs
+++ b/src/car.rs
@@ -1,8 +1,8 @@
-use uuid::Uuid;
+use cdrs::frame::IntoBytes;
 use cdrs::query::QueryValues;
+use cdrs::types::from_cdrs::FromCDRSByName;
 use cdrs::types::prelude::*;
-use crate::cdrs::types::from_cdrs::FromCDRS;
-use crate::cdrs::frame::IntoBytes;
+use uuid::Uuid;

diff --git a/src/user.rs b/src/user.rs
index 3d8ac50..8c56ddb 100644
--- a/src/user.rs
+++ b/src/user.rs
@@ -1,8 +1,8 @@
-use uuid::Uuid;
+use cdrs::frame::IntoBytes;
 use cdrs::query::QueryValues;
+use cdrs::types::from_cdrs::FromCDRSByName;
 use cdrs::types::prelude::*;
-use crate::cdrs::types::from_cdrs::FromCDRS;
-use crate::cdrs::frame::IntoBytes;
+use uuid::Uuid;

Please let me know if it helped


Update readme.md to warn about recent botting banwave

This is to stop the issues being created regarding bans

not related to the project


Default scraper "didn't return a streamable url"

When attempting to stream something with the default scraper I get this error:
mov-cli -s films.default house

Good Afternoon, xxxxx.
    It's 02:12 PM on a gorgeous Tuesday!

[INFO] (mov_cli) - Using 'films.default' scraper...
[INFO] (mov_cli) - Searching for 'house'...
[INFO] (mov_cli) - Scrapping episodes for 'House'...
[INFO] (mov_cli) - Scrapping media for 'House'...
[ERROR] (mov_cli) - Scraper didn't return a streamable url.
This is NOT a mov-cli issue. This IS an plugin issue

I can't reproduce this exactly but I did have trouble streaming that and it seems to be a provider issue so we can't fix this.
@r3tr0ananas also what's the reasoning behind returning the url as None?

I can't reproduce this exactly but I did have trouble streaming that and it seems to be a provider issue so we can't fix this.
@r3tr0ananas also what's the reasoning behind returning the url as None?

If this is a provider issue, then why is it still an open problem?


[BUG] Regression in cython 3.0.9

Describe the bug
While building pyarrow 15.0.0 resp. 14.0.2 in conda-forge, we got a regression going from cython 3.0.8 to 3.0.9
[5/141] Compiling Cython CXX source for lib...
 Going back to 3.0.8 fixes the build again.
Code to reproduce the behaviour:
Build pyarrow with cython 3.0.9
Expected behaviour
Build passes
OS
Linux, macOS, Windows
Python version
3.8-3.12
Cython version
3.0.9
Additional context
No response

This is not a regression. It's a new warning that we added, and I think you treat warnings as errors?
Just remove the noexcept. Function calls returning Python objects always check for exceptions, so the noexcept is wrongly used here.

OK. I called it a regression because it's the first 3.0.x patch release to break anything. It's definitely a breaking change relative to what passed compilation before, which is unexpected to me in a patch version, so I don't exactly know what to call it if not a regression.
But if this is something to be fixed in arrow, feel free to close this issue. That just means we'll stay on cython 3.0.8 until this has been fixed upstream.

I think you treat warnings as errors?

Yeah, you're right, this uses --warning-errors; this comes from upstream, though I agree that breakage due to treating-warnings-as-errors is not a regression. If you cannot change warning behaviour in patch releases, it's really too much of a constraint to move forward. I'll raise this on the arrow side. Sorry for the noise.


Line : 731 | WebDriverExecption |

Is there an existing issue for this?

[X] I have searched the existing issues

I'm submitting a ...

[X] bug report
[ ] feature request
[ ] support request --> Contact me over mail for support https://github.com/MShawon

Description
it's constantly showing up even with new or premium proxies, i have google chrome downloaded

Environment
- OS : Win 10
- Python : 3.10
- Script version : 1.8

config.json
{
    "http_api": {
        "enabled": false,
        "host": "<IP_ADDRESS>",
        "port": 5000
    },
    "database": true,
    "views": 24000,
    "minimum": 85.0,
    "maximum": 95.0,
    "proxy": {
        "category": "r",
        "proxy_type": "http",
        "filename": "https://api.proxyscrape.com/v2/?request=displayproxies&protocol=http&timeout=10000&country=all&ssl=all&anonymity=elite",
        "authentication": false,
        "proxy_api": true,
        "refresh": 0.0
    },
    "background": true,
    "bandwidth": true,
    "playback_speed": 1,
    "max_threads": 5,
    "min_threads": 2

i suspect this might be an issue with your port fowarding. you can check if port 5000 is opened in your router.

i have the same issue, started 2 days ago

This only seems to happen when the proxy category is 'r' or 'p', does not happen when it is 'f'


📦  Move ordering inside the Filter class and update tests, docs, and examples

Codecov Report

Merging #58 (1697725) into main (889a05d) will decrease coverage by 1.45%.
The diff coverage is 96.36%.

:exclamation: Current head 1697725 differs from pull request most recent head a389ce0. Consider uploading reports for the commit a389ce0 to get more accurate results

@@             Coverage Diff             @@
##              main      #58      +/-   ##
===========================================
- Coverage   100.00%   98.54%   -1.46%
===========================================
  Files            9        6       -3
  Lines          149      137      -12
===========================================
- Hits           149      135      -14
- Misses           0        2       +2

Impacted Files
Coverage Δ

fastapi_filter/base/filter.py
96.92% <93.10%> (-3.08%)
:arrow_down:

fastapi_filter/contrib/mongoengine/__init__.py
100.00% <100.00%> (ø)

fastapi_filter/contrib/mongoengine/filter.py
100.00% <100.00%> (ø)

fastapi_filter/contrib/sqlalchemy/__init__.py
100.00% <100.00%> (ø)

fastapi_filter/contrib/sqlalchemy/filter.py
100.00% <100.00%> (ø)


Default delegator addition

I've grown accustomed to using a RoutesDelegator.php in my v2 Expressive projects, and specified it as follows in the ConfigProvider.php
public function getDependencies()
    {
        return [
            'delegators' => [
                \Zend\Expressive\Application::class => [
                    RoutesDelegator::class,
                ],
            ],
            'invokables' => [
            ],
            'factories'  => [
            ],
        ];
    }

When creating an Expressive driven modular application it makes module specific routes easier to maintain. (Not sure of the implications for a flat application.)
What are the thoughts of including this in the skeleton starting with v3?
So, other than adding the 'delegators' key to the ConfigProvider.php as part of the getDependencies() return, we could add the RouteDelegator.php with something like:
namespace App;

use App\Handler;
use Psr\Container\ContainerInterface;
use Zend\Expressive\Application;

class RoutesDelegator
{
    /**
     * @param ContainerInterface $container
     * @param string $serviceName Name of the service being created.
     * @param callable $callback Creates and returns the service.
     * @return Application
     */
    public function __invoke(ContainerInterface $container, $serviceName, callable $callback)
    {
        /** @var $app Application */
        $app = $callback();

        // Setup routes:
        $app->get('/', Handler\HomePageHandler::class, 'home');
        $app->get('/api/ping', Handler\PingHandler::class, 'api.ping');

        return $app;
    }
}

Thoughts?

I'm using this in a few projects as well. But I'm not really liking it for the default application, especially if you have a lot of routes. I prefer to have the default application routes in the config/routes.php file as it is in the release-3.0.0 branch.
For modules this solution is perfect though. I would rather see this in the zend-expressive-tooling package as an addition to creating a new module.

I can agree with that.
I think including it in the tooling for module:create, and possibly middleware:create, could be a good step.

Closing this in favor of https://github.com/zendframework/zend-expressive-tooling/issues/57


slices: introduce SliceUniquify working like SliceUnique but in-place

@karasz rebased

Wondering about slices.Sort() followed by a slices.Compact() there you go, core.SliceUnique

Not all types are sortable, or even comparable. That's why we have variants receiving a eq function


Implications of widely distributed draft 0.7.1 implementation(s)

We all would love to see only implementations compatible with the soon to be ratified 1.0 standard. This would ease the software burden and require Linux (etc) distros to have to deal with only RV64GC and RV64GCV variants.
However this is not the world we find ourselves in.
Allwinner is now in full production of their D1 SoC using the Alibaba/T-Head C906 core. I've heard the initial run is 5 million chips. Probably most are destined for some embedded application, but Sipeed has announced they will be selling Linux SBCs using this chip starting at $12.50, and Pine64 has said they'll have one for "under $10". Possibly there will be others too.
At those kinds of prices these may quickly become the most used RISC-V Linux boards.
I don't think we can pretend they don't exist.
About a week ago an engineer at Sipeed offered to run on Allwinner's reference board any test programs I sent him. I sent him my primes benchmark http://hoult.org/primes.txt and we found that at 1.0 GHz it runs 8.7% faster than on the HiFIve Unleashed at 1.0 GHz. I then sent a test that simply probed vsetvli and found that the returned value for e8,m1 is max(avl,16).
This SoC has a vector unit.
Up until this point Sipeed didn't know whether Allwinner had bought the optional vector unit or not. Sipeed has C906 manuals from T-Head, and had a few reference boards from Allwinner, but didn't have documentation from Allwinner yet.
I then got ssh access to a board in Beijing via an engineer at RVboards.org in Shenzhen.
I've run tests on memcpy() and strcpy() using the standard glibc in Debian 11 and using RVV versions basically from the 0.7.1 spec. The results are here:
http://hoult.org/d1_memcpy.txt
http://hoult.org/d1_strcpy.txt
RVV memcpy() is 60% faster for a zero-length memcpy, rising to 3x faster between 8 bytes and 128 bytes, close to 2x at 4K, then gradually converging to both doing 1.1 GB/s once out of L1 cache.
Incidentally, I ran the same test on HiFive Unleashed. It peaked at 1.9 GB/s at 2K size (about the same as the Allwinner using standard glibc) then dropped gradually to 30 MB/s at 64 MB size. The Allwinner maintains 1.1 GB/s at 64 MB size.
RVV strcpy() is 50% faster at 0 string length, 3x faster at 32 bytes and maintains more than 2x all the way to main memory.
It is definitely desirable for owners of these boards that glibc in standard Linux distributions gets versions of these and similar library functions that are RVV optimised for their boards, alongside versions for 1.0-compliant implementations and plain RV64GC systems.
I would say it is desirable for the distribution maintainers also.
It would be nice if at least this kind of simple function could have identical binaries across 0.7.1 and 1.0. Failing that, we need a reliable and easy way to detect which version of V we have.
In general, these functions are going to be fine using just e8,m1 to e8,m8, which have identical encodings in vsetvli across all versions. (this is not true of e16 and e32).
When they match the element size set in VTYPE, 0.7.1's vlb.v/vlbu.v and vsb.v have the same semantics as 1.0's vle8.v and vse8.v. It also seems the store and the old unsigned load have the same encoding, if I haven't had any finger slips.
vlb.v v0,(a1): 12058007
vlbu.v v0,(a1): 02058007
vle8.v v0,(a1): 02058007
vsb.v v0,(a1): 02058027
vse8.v v0,(a1): 02058027
Obviously there are many many things which have zero chance of being compatible between 0.7.1 and the ratified Vector extension. Anything using mixed element sizes without changing VTYPE in between, for a start.
But this one ... unit stride loads and stores of 8 bit elements ... seems to be doable. And it's enough for memcpy.
I haven't checked the instructions needed for strcpy/strlen yet (vlbuff.v, vmseq.vi, vmfirst.m, vmsif.m) but I will shortly.
I just thought I'd get the discussion going sooner rather than later.

I am top posting because the initial points I want to make are not specific
to the details you mention.
I agree that mechanisms to support existing hardware should be advocated
by, and supported by RISCV.org.
I want to point out that this example is not an outlier but rather an
direct and natural consequence of the revolution in hardware design RISCV
has birthed.
How to support "in development" specification hardware releases will be
challenging, but it is only one aspect of the need to support a diverse
production of chips/hardware designs.
The existing typical way does not serve the RISSCV community well.
Incuments benefit from a system that has been geared to their needs over
decadses.
For RISCV to realize its potential bold and innovative approaches are
needed.
Consider errata. Ad hoc patches and fixes to software and hardware across
the full gamut of the industry is the current approach.
Large manufacturers can persuade industry partners and even competitors to
accommodate their design/production/manufacturing flaws.
Small operators are not afforded the same expenditure of effort by OS,
mid-layer, compiler/toolchain and integrators [hardware and software,
debuggers/optimizers/IDEs].
A single nominal flaw can put a producer out of business
ARM, Intel/AMD and IBM may not care about such players, but I understand
that we do.
Similarly, for too long,  Custom ISA extension support has been almost
non-existent.
This is our big advantage and a major differentiator that we have not
leveraged.
On another thread someone mentioned RISCY and problems/complications there.
[I still hope to hear the specifics].
These concerns, Bruce's well articulated issue and, in general, support for
"imperfect or experimental" designs and implementations are the make of
break of RISCV.world domination; it is key for acceptance across all
hardware levels.
Having said all that, how do we do it.
I have various ideas, but I don't think any of mine are needed as a
catalyst to develop the motivation and then the infrastructure to address
the unique and mundane challenges raise by RISCV ISA and RISCV.org.
On Sat, Apr 24, 2021 at 2:42 PM Bruce Hoult @.***>
wrote:

We all would love to see only implementations compatible with the soon to
be ratified 1.0 standard. Tis would ease the software burden and require
Linux (etc) distros to have to deal with only RV64GC and RV64GCV variants.
However this is not the world we find ourselves in.
Allwinner is now in full production of their D1 SoC using the
Alibaba/T-Head C906 core. I've heard the initial run is 5 million chips.
Probably most are destined for some embedded application, but Sipeed has
announced they will be selling Linux SBCs using this chip starting at
$12.50, and Pine64 has said they'll have one for "under $10". POssibly
there will be others too.
At those kinds of prices these may quickly become the most used RISC-V
Linux boards.
I don't think we can pretend they don't exist.
About a week ago an engineer at Sipeed offered to run on Allwinner's
reference board any test programs I sent him. I sent him my primes
benchmark http://hoult.org/primes.txt and we found that at 1.0 GHz it
runs 8.7% faster than on the HiFIve Unleashed at 1.0 GHz. I then sent a
test that simply probed vsetvli and found that the returned value for e8,m1
is max(avl,16).
This SoC has a vector unit.
Up until this point Sipeed didn't know whether Allwinner had bought the
optional vector unit or not. Sipeed has C906 manuals from T-Head, and had a
few reference boards from Allwinner, but didn't have documentation from
Allwinner yet.
I then got ssh access to a board in Beijing via an engineer at
RVboards.org in Shenzhen.
I've run tests on memcpy() and strcpy() using the standard glibc in Debian
11 and using RVV versions basically from the 0.7.1 spec. The results are
here:
http://hoult.org/d1_memcpy.txt
http://hoult.org/d1_strcpy.txt
RVV memcpy() is 60% faster for a zero-length memcpy, rising to 3x faster
between 8 bytes and 128 bytes, close to 2x at 4K, then gradually converging
to both doing 1.1 GB/s once out of L1 cache.
Incidentally, I ran the same test on HiFive Unleashed. It peaked at 1.9
GB/s at 2K size (the same as the Allwinner using standard glibc) then
dropped gradually to 30 MB/s at 64 MB size. The Allwinner maintains 1.1
GB/s at 64 MB size.
RVV strcpy() is 50% faster at 0 string length, 3x faster at 32 bytes and
maintains more than 2x all the way to main memory.
It is definitely desirable for owners of these boards that glibc in
standard Linux distributions gets versions of these and similar library
functions that are RVV optimised for their boards, alongside versions for
1.0-compliant implementations and plain RV64GC systems.
I would say it is desirable for the distribution maintainers also.
It would be nice if at least this kind of simple function could have
identical binaries across 07.1 and 1.0. Failing that, we need a reliable
and easy way to detect which version of V we have.
In general, these functions are going to be fine using just e8,m1 to
e8,m8, which have identical encodings in vsetvli across all versions. (this
is not true of e16 and e32).
When they match the element size set in VTYPE, 0.7.1's vlb.v/vlbu.v and
vsb.v have the same semantics as 1.0's vle8.v and vse8.v. However they
don't have the same encoding.
vlb.v v0,(a1): 12058007
vlbu.v v0,(a1): 02058007
vle8.v v0,(a1): 00058007
vsb.v v0,(a1): 02058027
vse8.v v0,(a1): 00058027
vlbu.v and vle8.v differ in only one bit! And the same with vsb.v and
vse8.v This is MEW in the 1.0 encoding.
If the sense of MEW could be reversed, the encodings would be compatible.
Obviously there are many many things which have zero chance of being
compatible between 0.7.1 and the ratified Vector extension.
But this one .. unit stride loads and stores of 8 bit elements ... could
be made to match. And it's enough for memcpy.
I haven't checked the instructions needed for strcpy/strlen yet (vlbuff.v,
vmseq.vi, vmfirst.m, vmsif.m).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-v-spec/issues/667, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFAWIKMYYDVHPAEGTYMZ6OLTKMGKXANCNFSM43QM5QKQ
.

I expect to have an SBC using the Allwinner D1 with T-Head Xuantie 906 core within the next week and will be able to conduct more extensive investigations of it.
The $99 "Nezha" board is currently available to the public on indiegogo (from Sipeed) and aliexpress (from RVboards). Production of the SoC is currently ramping up. Sipeed are still promising an ~$10 board based on this SoC later in the year which should be a very serious competitor to the Raspberry Pi Zero, and possible sell in relatively large numbers.
I will have more analysis here later but for now I have three concrete proposals to increase compatibility between these chips implementing 0.7.1 and those implementing 1.0:
Revert b8cd98bc946 "Make vlmul bits contiguous in vtype."
This will restore vtype compatibility between 0.7.1 and 1.0 for integral LMUL by putting the vsew field in the same place, allowing code using any of e8,e16,e32 to work on both the Alibaba cores and RVV 1.0 (assuming certain other conditions are met).
Because of changes in loads and stores, code can only be compatible between 0.7.1 and 1.0 if the element width of the load/store is the same as vsew in the current vtype.
Once I have the board I will check its behaviour with respect to masked off and tail elements.
In 0.7.1 masked off elements are required to be unchanged, so the definition of vma=0 as undisturbed is good.
Draft 0.7.1 required vector operations to zero vector tail elements. This is not an option in the current spec, which allows only "undisturbed" and "agnostic" (destination elements can be either undisturbed or all 1s, and differ from element to element). Clearly code that depends on 0.7.1 zeroing the tail elements can not work on 1.0. Similarly 1.0 code that depends on tail elements being undisturbed can not work on 0.7.1.
Code using 1.0 "tail agnostic" will work on 0.7.1 if it is truly agnostic and does not depend on the elements being either undisturbed or all 1s.
The current spec notes: "The value of all 1s instead of all 0s was chosen for the overwrite value to discourage software developers from depending on the value written."
This is a reasonable point of view, but not a very strong one.
If the overwrite value was all 0s then the 0.7.1 tail zeroing behaviour would be a conforming implementation of Tail Agnistic.
In this case, it would be better if the encoding of vta was 0 for agnostic and 1 for undisturbed, not the reverse as at present.
Summary:
The following changes to the current draft spec would very significantly increase binary compatibility between draft 0.7.1 and the current draft, enabling carefully-written code to work on both.

revert b8cd98bc946 "Make vlmul bits contiguous in vtype."

reverse the current sense of the vta field in vtype. Note: does not affect the decision of assembly language default value.

change at least Tail Agnostic to allow all 0s as a valid result, either in place or or in addition to all 1s

As a concrete goal, I would like to see a situation in which all standard library routines that benefit from the V extension can be written to be binary compatible between 0.7.1 and 1.0. This would enable these very common functions to have to choose only between scalar and vectorized versions, not between scalar and multiple vectorized versions.

change at least Tail Agnostic to allow all 0s as a valid result, either in place or or in addition to all 1s

I proposed a form of this over at #650 and ran into strong resistance. Good luck!

We are not going to change the architecture to cater to an implementation of a draft standard.
In the long run, these 5M incompatible chips will represent a tiny fraction of the RVV ecosystem.  Hobbling either the software or the architecture to support them will look foolish in a decade.

I contest that there is any "hobbling" involved.
The exact layout of vtype or whether the sense of vta is inverted is invisible to and of no consequence to assembly language programs or programmers or even to compilers that generate assembly language.  It is also of no consequence to hardware and hardware designers, other than of course that they have to follow the spec and grab the right bits.

@brucehoult - I am glad you continue to post even though the "issue" was closed.
I agree that the pronouncement/reports of this death has been greatly exaggerated [appreciations to Mark Twain].
The discussion in the TG eventually sided on the restructuring because it was cleaner to have the bits contiguous.
The polarity was a secondary concern that more readily resolved once the contiguous bits was "resolved".
The argument that the specification has not been ratified works both ways. Public review could favour the 0.7.1 format for the preexistant bits.
This discussion is by no means finalized in the Vector TG. We move along with consensus, but always are open to revisiting the "tentative decisions", especially when the matters are "bit twiddling".
@all However, the software currently being developed can readily accommodate mixed implementation access [via discovery or flag setting]. We must not penalize early adopters unnecessarily. We should be as accommodating as we can be to those who in good faith support our efforts. We definitely should not be draconian nor Machiavellian.
Similarly, providing zero fill for tail or mask agnostic is in keeping with the spirit of the concept.
Ones fill was not stipulated for any other reason than acknowledging that allowing anything was not verifiable.
Certification with this zero fill as an exception is eminently reasonable.
The discussion in #650 centred on revising the standard.
At this point standardizing with zero fill included would be counter to the agnostic message, diluting it and potentially thwarting portable code before the feature and concept becomes entrenched/instinctive in the community.
We can be flexible and allow choice. We can have our cake and eat it too; when such is a implementation choice. Software and conventions can give us substantial flexibility, to be used when such choice has a definite benefit and low long term maintenance cost.
Navigating this will be challenging, but I believe we collectively are up to that challenge. [Please don't prove me wrong]..

After these walls of text, I stand by my decision to close this ticket.  You can propose a new ISA extension that's compatible with this non-RVV chip if you so choose.  This is not the place to do so.

Certainly you can call me out for rhetoric, bruce called you out for yours.
Wall or prose path to enlightenment, we can let those following the discussion decide. I am, after all,  pro-choice.
But I fully disagree with your conclusion that this is not the correct forum for this discussion.
I mentioned,  these issues were discussed within the TG meetings.
No one there and then said that these issues were off-topic. No one said that they were uncontentious and that there was only one path forward.
It is precisely because of those TG discussions that we must conclude that this is the appropriate forum.
Further, to the extent that there are various remedies possible, presupposing the "a new ISA extension" is the only mechanism for resolution is narrow minded and repressive.
I will raise this issue at the next Vector TG even if its status remains closed, indeed, especially because it was closed prematurely.

I'm unsure what to think about "walls of text". I try to keep my posts succinct, but at the same time an argument requires exposition and evidence.
I don't feel an extension is the appropriate thing here. I suppose one could propose a complete "RVV draft 0.7.1 compatibility mode" extension. In a way that would of course be ideal, but supporting 0.7.1 and 1.0 as modes on the same CPU is far more hardware implementation work than I propose, and I doubt anyone would do it.
At most I'm proposing a "decode vtype differently" mode, along with something like a profile -- a list of opcodes and certain coding restrictions which if followed give binary code that works the same on both 0.7.1 and 1.0.
But as 1.0 is not yet ratified, and no one has shipped hardware using the current draft, by far the simpler course is to simply have 1.0 use a vtype format that is backwardly compatible with 0.7.1 -- as it still had less than a year ago.
One relevant point here is that Alibaba have not implemented 0.7.1 EDIV, and thus the chips expect those two vtype bits to be 0. There is no need to try to map EDIV to fractional LMUL. The chips that are shipping support the standard LMUL 1,2,4,8 and SEW 8,16,32 for integer and 32 for FP. They have 24 valid vtype values.

Revisiting this almost three years later, I believe even more strongly that the wrong decision was made here and gratuitous incompatibility was introduced for merely aesthetic reasons.
The following is just a survey of where we are currently at. I'm not calling for any action now, just hoping to prevent such mistakes in future in situations where what is going to happen is so clearly obvious.
There are of course genuine improvements in RVV 1.0 and fundamental incompatibilities. Code using various 1.0 features is hard to port back to 0.7, but 0.7 code is easy to port to 1.0 except for the issues raised here, chiefly tail-zeroing not being technically compliant with 1.0 tail agnostic (though it would take perverse code to not actually work)

In the long run, these 5M incompatible chips will represent a tiny fraction of the RVV ecosystem. Hobbling either the software or the architecture to support them will look foolish in a decade.

According to Alibaba: "Since the launch of the XuanTie C910, shipments of the XuanTie series of chips have exceeded 4 billion units".
So that's three orders of magnitude off, and though 1.0 is finally starting to emerge, 0.7 is not going away any time in the next five years.
https://www.scmp.com/tech/big-tech/article/3255830/alibabas-damo-academy-plans-launch-latest-version-its-xuantie-risc-v-processor-year
C906 with RVV 0.7.1 is everywhere. Half a dozen companies have chips and boards in the $5-$10 range with them, running embedded Linux in 64 MB RAM. It's in my car's media/nav player (Allwinner F133) C910 with RVV 0.7.1 (sometimes called C920) is in the highest performing RISC-V machine available, the 64 core 2.0 GHz 128 GB RAM Milk-V Pioneer.
Many of these boards are being GIVEN to developers with suitable project proposals by RISC-V International.
Meanwhile, there is right now only still only one RVV 1.0 SoC available, the Kendryte K230, with a single 1.6 GHz C908 CPU. It's been available for a couple of months on the CanMV-K230 SBC with 0.5 GB RAM, making it not a great software development machine compared to the 8 GB or 16 GB quad core U74 and C910 boards.
"Horse Creek", if it ever hits the market, doesn't have RVV at all.
More serious RVV 1.0 things are coming this year. Finally.
Banana Pi have pre-announced an 8 core 1.6 GHz board (BPI-F3) with RVA22+V. No price or availability date yet.
Sophgo are updating the 64 core SG2042 to an RVA22+RVV 1.0 version. Also hopefully supporting FP exceptions and not trapping on unknown fence instructions (e.g. fence.tso) :-)
Sophgo also have the upcoming 16 core P670 (and some X280s) SG2380 with Milk-V and Sipeed promising boards this year. That's the most exciting general purpose machine announced as the cores are twice the speed of C910 and U74.
That's great stuff, but it's going to take many years for them to overtake the RVV 0.7.1 installed base, which won't be standing still.
To be fair, I don't know what is happening in embedded space. Maybe RVV 1.0 is already shipping bigtime there. If so, no one is talking about it.
Anyway that's not relevant to questions such as what ISA(s) shrink-wrapped Linux distros should support.
Speaking of which, the best recent software news is that not only is RVV 0.7.1 support (under the name "xtheadvector") now upstreamed into the upcoming gcc 14 (and matching binutils), the standard C intrinsics for RVV can generate code for either RVV 0.7.1 or 1.0.
Someone recently published on Reddit a project using fairly extensive RVV intrinsics. They didn't have any 1.0 hardware and could only test it on qemu.  I was able to very quickly and easily (just changing compiler options in the makefile, no source code changes needed) able to use gcc 14 to build and run it in RVV 0.7.1 on my C910-based LicheePi 4A.
https://reddit.com/r/RISCV/comments/1b57gib/comment/kt4t428/
That now clears the way to libraries using the ifunc (or other) mechanism to provide RV64GC, RVV 1.0, and RVV 0.7.1 implementations, either hand writing two (very similar) RVV assembly language versions or one version using intrinsics and just compile it twice.

I acknowledge Bruce's comments. While I don't have strong opinions myself about the current state of affairs, I do feel more strongly about a certain terminological issue:

RVV 0.7.1 support (under the name "xtheadvector")

I prefer to restrict "RVV" to refer to the ratified standard V-extension, and "XTheadVector" to refer to Alibaba's (nonconforming, nonstandard) extension.

First of all, Alibaba are the ones calling it so: see, for example, the XTheadVector spec, the toolchain options Alibaba has added, etc.

Second, XTheadVector deviates (slightly and superficially) from the RVV 0.7.1 draft spec (see previous link). For a newcomer faced with the alphabet soup of RISC-V extensions, and their versions, and the various repositories where the documentation is scattered, I think it's helpful to clarify that this is something specific to Alibaba's cores, thus it's crucial to examine Alibaba's documentation. Imagine your confusion if you started out by looking at this repo (at 0.7.1), but then none of the assembly mnemonics worked (because you forgot to prepend "th.").

Last, it's natural to parse "1.0" as somehow technologically better or more advanced than "0.7.1". I don't think this has been convincingly established, and it probably never will be.

I acknowledge that there is some inertia referring to XTheadVector as "RVV 0.7.1", so I'll leave it up to Alibaba to fight a marketing battle.


website : fix jwt link and content

Motivation

JWT content is not linked well.  This PR tries to fix the link
Modifications
Add support from 2.4.0.
Verifying this change
build website locally, verify links for 2.4.0, 2.4.1, 2.4.2 works well.

@Jennifer88huang  Your comments seems be out of the motivation of this PR. Would you please open another issue for these requirements?

Could you please also copy the security-jwt.md file into 2.4.1 and 2.4.2 folders?

2.4.1 and 2.4.2 will auto reference the current version. no need to copy them.

We've updated the structure of the Security chapter, could you please update the sidebars.json file in 2.4.0, 2.4.1, and 2.4.2 with that in master?

For the old version, Maybe fix the bug is enough?


Link across pages not working

If I put a link Link that returns 404 as link would not be rewriten

Can you explain more about the issue?

I'm sorry, my bad, got a wrong file path, everything works as expected


[DO NOT MERGE] Auto PR to update dependencies of pilot

This PR will be merged automatically once checks are successful.
none

@istio-testing: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/pilot-presubmit.sh
a08e01f738436f8fff09e78a2acd6583976eebbe
link
/test pilot-presubmit

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 kubernetes/test-infra repository. I understand the commands that are listed here.


iocs directory needs work

I have created an iocs directory containing an example IOC.  It builds the pcocam2App application.  There is an iocBoot/iocPcocam2 directory with an st.cmd file that creates a detector instance.  However, I don't know what databases it should load and what else it should do.
@ulrikpedersen can someone at Diamond fix and test the st.cmd file?

I can take a look at this.

It looks like Ben undid a number of my changes.
My iocs/pcocam2IOC/configure/RELEASE file looks like this:
corvette:iocs/pcocam2IOC/configure>more RELEASE
#RELEASE Location of external products
# Run "gnumake clean uninstall install" in the application
# top directory each time this file is changed.

ADPCOWIN=$(TOP)/../..

-include $(TOP)/../../../configure/RELEASE_PRODS_INCLUDE
-include $(TOP)/RELEASE.local
-include $(TOP)/configure/RELEASE.local

But that got replaced by one that Oksana had to change back to what I had.

Hi Mark - I apologise for this mess. I was having issues with running the IOC at our end - I shouldn't have committed the changes to this file.

I believe this issue has been resolved and can be closed.

Closing this.


Lecture 4 - Slide 72 - Grammatical

"what type of solutions are we more likely to prefer?"
did you mean "what types of solutions are we more likely to prefer?"

Agreed. Thanks. 1 point


implement bitmap_distinct function using bitmap

Is your feature request related to a problem or challenge? Please describe what you are trying to do.
Like #1115 implement u8, i8, u16, i16, u32, i32 by using bitmap called bitmap_distinct
Describe the solution you'd like
I will use arrow-bitmap  and roaring-bitmap  and check the performance of both

i have implement a initial version get below result:
1million_rows_10thousand_distinct.parquet
1. count distint
+----------------------------+
| COUNT(DISTINCT test.value) |
+----------------------------+
| 10000                      |
+----------------------------+
1 row in set. Query took 0.237 seconds.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2. bitmap distinct (roaring-rs)

+---------------------------------+
| BITMAPCOUNTDISTINCT(test.value) |
+---------------------------------+
| 10000                           |
+---------------------------------+
1 row in set. Query took 0.052 seconds
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3. approx distinct (hll)

+----------------------------+
| APPROXDISTINCT(test.value) |
+----------------------------+
| 9943                       |
+----------------------------+
1 row in set. Query took 0.047 seconds.

the bitmap used is this
i have checked influx_iox use croating-rs
@alamb Sorry to bother you 😂, could you share some info why use croating-rs, if you have a bench result that would be fantastic 👍  !

i have implement a initial version get below result: 1million_rows_10thousand_distinct.parquet
1. count distint
+----------------------------+
| COUNT(DISTINCT test.value) |
+----------------------------+
| 10000                      |
+----------------------------+
1 row in set. Query took 0.237 seconds.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2. bitmap distinct (roaring-rs)

+---------------------------------+
| BITMAPCOUNTDISTINCT(test.value) |
+---------------------------------+
| 10000                           |
+---------------------------------+
1 row in set. Query took 0.052 seconds
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3. approx distinct (hll)

+----------------------------+
| APPROXDISTINCT(test.value) |
+----------------------------+
| 9943                       |
+----------------------------+
1 row in set. Query took 0.047 seconds.

the bitmap used is this i have checked influx_iox use croating-rs @alamb Sorry to bother you 😂, could you share some info why use croating-rs, if you have a bench result that would be fantastic 👍 !

Could you please file the draft of the pull request?
@Ted-Jiang

Test result of use roaring-rs and croaring-rs (use same logic: insert one value one time)
1million_rows_10thousand_distinct.parquet
bitmap distinct

(roaring-rs)
+---------------------------------+
| BITMAPCOUNTDISTINCT(test.value) |
+---------------------------------+
| 10000                           |
+---------------------------------+
1 row in set. Query took 0.052 seconds

（croaring-rs）
+---------------------------------+
| BITMAPCOUNTDISTINCT(test.value) |
+---------------------------------+
| 10000                           |
+---------------------------------+
1 row in set. Query took 0.038 seconds.

1million_1million.parquet
roaring-rs
+---------------------------------+
| BITMAPCOUNTDISTINCT(test.value) |
+---------------------------------+
| 631504                          |
+---------------------------------+
1 row in set. Query took 0.175 seconds(roaring-rs).

croaring-rs
+---------------------------------+
| BITMAPCOUNTDISTINCT(test.value) |
+---------------------------------+
| 631504                          |
+---------------------------------+
1 row in set. Query took 0.052 seconds （croaring-rs）.

@alamb Sorry to bother you 😂, could you share some info why use croating-rs, if you have a bench result that would be fantastic 👍 !

IOx is using croaring for its "ReadBuffer" (an optimized in memory format we use rather than straight up RecordBatches).
@e-dard  is the expert. There is more information from the Feb 2 2021 tech talk: https://github.com/influxdata/influxdb_iox/tree/main/docs#iox-tech-talks
Specifically:
Recording:  https://www.youtube.com/watch?v=KslD31VNqPU
Slides: https://www.slideshare.net/influxdata/influxdb-iox-tech-talks-intro-to-the-influxdb-iox-read-buffer-a-readoptimized-inmemory-query-execution-engine
Sorry for the delayed response

@e-dard Thanks a lot for your info! What an admirable work in IOX.


Update durable-functions-orchestrations.md

@skoblilovmax : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#label:"aq-pr-triaged"

#sign-off


Compile error with<EMAIL_ADDRESS>and up

I noticed that the lib breaks when Vue is on version 3.2.46 and up.
When downgrading to 3.2.45, it compiles and run just fine.
See screenshot below.

Yep, all good now ! Thanks !


Create .pk6 parser

It should be able to read a .pk6 file (or a Buffer containing one) and extract all of the relevant info into an easy-to-use format.
This story doesn't include integrating it into porybox, just a standalone library for reading in a pk6 and outputing a json object with everything we want in it.

This is pretty much done (the parser can be tested in the browser here). There are still a few helper functions that could be added to the module, but they're not necessary to move forward.


Rails 3.1 compatibility

Are there any Rails 3.1 compatibility issues?
I'm getting a
$(a).autocomplete is not a function

sandrods,
Where do above requires go?
Thanks
rkgordon3

in your application.js (app/assets/javascripts)

Thanks...I figured this out minutes after posting. I felt like a bonehead!
Rob
On Wed, Nov 30, 2011 at 6:01 AM, Sandro Duarte <
<EMAIL_ADDRESS>
wrote:

in your application.js (app/assets/javascripts)

Reply to this email directly or view it on GitHub:
https://github.com/crowdint/rails3-jquery-autocomplete/issues/76#issuecomment-2958499

--
Rob Gordon


support Darwin in Makefile

@dghubble how does this look to you? I'm heading towards running bootcfg etc. directly on OS X, and testing with VirtualBox.

You said you're testing locally and ~/.bootcfg seems like a fine choice if it works for you. Since the Makefile is used for building and installing the source release for the deployment docs we'd want that to choose config and data directories for users to run a cross compiled bootcfg in production.
On Linux, the /var/lib/boocfg default and /etc/bootcfg default locations were chosen since they're the conventional service data and env locations according to the Linux FHS. For OSX, I'm not positive what the conentional/good-citizen system directories would be.
We were planning to include a pre-compiled binary for darwin next release so OSX is something we will want to think about.


Feature request: support multiple runs per parameter choice with grouping (monte carlo cross validation support)

wandb, version 0.8.30
Python 3.8.2
Linux
Description
When doing hyperparameter search for deep learning, individual runs tend to have some variance, that's why one usually does monte carlo cross validation (run multiple runs with the same config, and then average over the results). Please add support for having multiple runs per parameter choice within one group – and have the shown results of that group been the average of the individual values. Bonus points for plots with error bars/additional table entries for error bars.

Hi Marcel, this is a good feature request. @adrnswanberg let's talk about including this in the run queue tool.

Hi, any updates? I'm also interested in having the possibility to group multiple runs (one per k in k-fold cross validation) in Sweeps.

Still working on a more integrated solution but we we put together an example of how to accomplish k-fold cross validation with our current library and sweeps product:
https://github.com/wandb/examples/tree/master/sweeps-cross-validation
The solution requires some contortions for the wandb library to spawn multiple jobs on behalf of a launched sweep job.
The basic idea is:

The agent requests a new set of parameters from the cloud hosted parameter server. This is the run called sweep_run in the main function.
Send information about what the folds should process over a multiprocessing queue to waiting processes
Each spawned process logs to their own run, organized with group and job_type to enable auto-grouping in the UI
When the process is finished, it sends the primary metric over a queue to the parent sweep run
The sweep run reads metrics from the child runs and logs it to the sweep run so that the sweep can use that result to impact future parameter choices and/or hyperband early termination optimizations

Example visualizations of the sweep and k-fold grouping can be seen here:
Sweep: https://app.wandb.ai/jeffr/examples-sweeps-cross-validation/sweeps/vp0fsvku
K-fold Grouping: https://app.wandb.ai/jeffr/examples-sweeps-cross-validation/groups/vp0fsvku

Thank you for putting these examples together! Looking forward to the more integrated solution.

Push

* Send information about what the folds should process over a multiprocessing queue to waiting processes

* Each spawned process logs to their own run, organized with group and job_type to enable auto-grouping in the UI

Do you know any workaround to avoid multiprocessing? Basically, I'm interested in running each fold sequentially in the main process, by keeping the same organization with group and job_type.
Currently, I tried by just invoking a train function in the for loop without the multiprocessing code, but the run of the i+1-th fold overwrite the run of the i-th fold, even if the job_type is different (in my case i=1, ..., 5).
Considering the sweeps-cross-validation example, I need something similar to:
def train(worker_data):
    reset_wandb_env()
    run_name = "{}-{}".format(worker_data.sweep_run_name, worker_data.num)
    config = worker_data.config
    run = wandb.init(
        group=worker_data.sweep_id,
        job_type=worker_data.sweep_run_name,
        name=run_name,
        config=config,
    )
    val_accuracy = random.random()
    run.log(dict(val_accuracy=val_accuracy))
    wandb.join()
    return WorkerDoneData(val_accuracy=val_accuracy)

def main():
    num_folds = 5

    sweep_run = wandb.init()
    sweep_id = sweep_run.sweep_id or "unknown"
    sweep_url = sweep_run.get_sweep_url()
    project_url = sweep_run.get_project_url()
    sweep_group_url = "{}/groups/{}".format(project_url, sweep_id)
    sweep_run.notes = sweep_group_url
    sweep_run.save()
    sweep_run_name = sweep_run.name or sweep_run.id or "unknown"

    metrics = []
    for num in range(num_folds):
        result = train(WorkerInitData(
                sweep_id=sweep_id,
                num=num,
                sweep_run_name=sweep_run_name,
                config=dict(sweep_run.config),
            )
        )

        # log metric to sweep_run
        metrics.append(result.val_accuracy)

    sweep_run.log(dict(val_accuracy=sum(metrics) / len(metrics)))
    wandb.join()

Still working on a more integrated solution but we we put together an example of how to accomplish k-fold cross validation with our current library and sweeps product:
https://github.com/wandb/examples/tree/master/sweeps-cross-validation
The solution requires some contortions for the wandb library to spawn multiple jobs on behalf of a launched sweep job.
The basic idea is:
* The agent requests a new set of parameters from the cloud hosted parameter server. This is the run called sweep_run in the main function.

* Send information about what the folds should process over a multiprocessing queue to waiting processes

* Each spawned process logs to their own run, organized with group and job_type to enable auto-grouping in the UI

* When the process is finished, it sends the primary metric over a queue to the parent sweep run

* The sweep run reads metrics from the child runs and logs it to the sweep run so that the sweep can use that result to impact future parameter choices and/or hyperband early termination optimizations

Example visualizations of the sweep and k-fold grouping can be seen here:
Sweep: https://app.wandb.ai/jeffr/examples-sweeps-cross-validation/sweeps/vp0fsvku
K-fold Grouping: https://app.wandb.ai/jeffr/examples-sweeps-cross-validation/groups/vp0fsvku

Thank you, unfortunately, this doesn't work for us, because we need two levels of grouping. We already use the grouping for cross-validation, so we are already doing the workaround. It would be great if you could implement the more integrated solution you were talking about!

This feature would be amazing.


How make windows style none?

Subj

The first step would be setting HasSystemDecorations=false on your window

@Gillibald thx, but its no draggable. I cannot move windows

You have to implement managed dragging yourself. https://github.com/VitalElement/AvalonStudio.Shell/blob/e6b8d79a340607f556f0d3933ab0518bdc94241f/src/AvalonStudio.Shell/Controls/MetroWindow.cs

While it's possible to have completely custom decorated window (see 1 and 2), consider not doing this unless absolutely required. It severely breaks the user experience on macOS and various Linux desktop environments.


adds raw blocks to prevent parsing

Hello,
This PR adds the ability to wrap content in {{{{raw}}}} blocks and not have it parse ot try to render it.
I've spent a few days hammering away on this, and it's probably the longest its ever taken me to write ~35 LOC. I was/am woefully ignorant of RLTK and of the codebase, so I apologize if this is not the absolute best way to go about it; I spent a lot of time fighting RLTK errors, and my own ignorance.
So, this mostly works. the quad brackets isn't a real block type, and I can't for the life of me get it to work with a hash like {{{{#raw}}}} despite every incantation I can think of.
Happy to discuss and make any changes to get this out the door.

Can you bump the version for me so that I can can run rake release? Ta.

Certainly! I pushed up a version bump

Merged. Thanks!


Cannot vmap methods of Brax environments

Hi, thanks for all your work with Brax! I'm just getting into it, and am running into surprising behavior on a simple example:
import jax
from brax import envs

env = envs.create('inverted_pendulum')  # Other envs give similar errors.

batch_rng = jax.random.split(jax.random.PRNGKey(0), 64)
batch_state = jax.vmap(env.reset)(batch_rng)
print(batch_state.obs)

(runnable version here: https://colab.research.google.com/drive/1c8jDkShgSRdeBp9fcC9R3PTfMRNbjOlj?usp=sharing)
Expected: prints a batch of initial observations of shape (64, 4).
Actual: raises a TracerArrayConversionError inside of a brax.jumpy.scan call:
[/usr/local/lib/python3.7/dist-packages/jax/_src/traceback_util.py](https://localhost:8080/#) in reraise_with_filtered_traceback(*args, **kwargs)
    161     try:
--> 162       return fun(*args, **kwargs)
    163     except Exception as e:

[/usr/local/lib/python3.7/dist-packages/jax/_src/api.py](https://localhost:8080/#) in vmap_f(*args, **kwargs)
   1473         lambda: flatten_axes("vmap out_axes", out_tree(), out_axes)
-> 1474     ).call_wrapped(*args_flat)
   1475     return tree_unflatten(out_tree(), out_flat)

[/usr/local/lib/python3.7/dist-packages/jax/linear_util.py](https://localhost:8080/#) in call_wrapped(self, *args, **kwargs)
    167     try:
--> 168       ans = self.f(*args, **dict(self.params, **kwargs))
    169     except:

[/usr/local/lib/python3.7/dist-packages/brax/envs/wrappers.py](https://localhost:8080/#) in reset(self, rng)
     86   def reset(self, rng: jp.ndarray) -> brax_env.State:
---> 87     state = self.env.reset(rng)
     88     state.info['first_qp'] = state.qp

[/usr/local/lib/python3.7/dist-packages/brax/envs/wrappers.py](https://localhost:8080/#) in reset(self, rng)
     65   def reset(self, rng: jp.ndarray) -> brax_env.State:
---> 66     state = self.env.reset(rng)
     67     state.info['steps'] = jp.zeros(())

[/usr/local/lib/python3.7/dist-packages/brax/envs/inverted_pendulum.py](https://localhost:8080/#) in reset(self, rng)
    134
--> 135     qp = self.sys.default_qp(joint_angle=qpos, joint_velocity=qvel)
    136     obs = self._get_obs(qp, self.sys.info(qp))

[/usr/local/lib/python3.7/dist-packages/brax/physics/system.py](https://localhost:8080/#) in default_qp(self, default_index, joint_angle, joint_velocity)
    170       xs = (joint_angle, joint_velocity, joint_rot, joint_ref)
--> 171       _, (local_rot, local_ang) = jp.scan(local_rot_ang, (), xs, len(joint))
    172

[/usr/local/lib/python3.7/dist-packages/brax/jumpy.py](https://localhost:8080/#) in scan(f, init, xs, length, reverse, unroll)
    116       ys.append(y)
--> 117     stacked_y = jax.tree_map(lambda *y: onp.vstack(y), *maybe_reversed(ys))
    118     return carry, stacked_y

[/usr/local/lib/python3.7/dist-packages/jax/_src/tree_util.py](https://localhost:8080/#) in tree_map(f, tree, is_leaf, *rest)
    183   all_leaves = [leaves] + [treedef.flatten_up_to(r) for r in rest]
--> 184   return treedef.unflatten(f(*xs) for xs in zip(*all_leaves))
    185

[/usr/local/lib/python3.7/dist-packages/jax/_src/tree_util.py](https://localhost:8080/#) in <genexpr>(.0)
    183   all_leaves = [leaves] + [treedef.flatten_up_to(r) for r in rest]
--> 184   return treedef.unflatten(f(*xs) for xs in zip(*all_leaves))
    185

[/usr/local/lib/python3.7/dist-packages/brax/jumpy.py](https://localhost:8080/#) in <lambda>(*y)
    116       ys.append(y)
--> 117     stacked_y = jax.tree_map(lambda *y: onp.vstack(y), *maybe_reversed(ys))
    118     return carry, stacked_y

<__array_function__ internals> in vstack(*args, **kwargs)

[/usr/local/lib/python3.7/dist-packages/numpy/core/shape_base.py](https://localhost:8080/#) in vstack(tup)
    278         _arrays_for_stack_dispatcher(tup, stacklevel=2)
--> 279     arrs = atleast_2d(*tup)
    280     if not isinstance(arrs, list):

<__array_function__ internals> in atleast_2d(*args, **kwargs)

[/usr/local/lib/python3.7/dist-packages/numpy/core/shape_base.py](https://localhost:8080/#) in atleast_2d(*arys)
    120     for ary in arys:
--> 121         ary = asanyarray(ary)
    122         if ary.ndim == 0:

[/usr/local/lib/python3.7/dist-packages/jax/core.py](https://localhost:8080/#) in __array__(self, *args, **kw)
    536   def __array__(self, *args, **kw):
--> 537     raise TracerArrayConversionError(self)
    538

UnfilteredStackTrace: jax._src.errors.TracerArrayConversionError: The numpy.ndarray conversion method __array__() was called on the JAX Tracer object Traced<ShapedArray(float32[4])>with<BatchTrace(level=1/0)> with
  val = [...]

A similar error arises when env.step is wrapped in vmap (see notebook link above).
I understand that the recommended approach to work with batches of states is to pass the batch_size argument to envs.create, (which does work), but I would also have expected env.reset and env.step to transform and compose like normal JAX functions.
Is this behavior intended?

@davmre I'll close the issue for now since I think the behavior is intended due to the jumpy library, but please feel free to re-ope if there are any other issues!

@btaba @erikfrey Jitting the reset function doesn't work. Any idea how to get this to work?

@jamesheald sorry to hear you're having trouble with jax.jit(reset),  can you give a repro?

It is the same issue as the one raised by the original poster. But as with the issue I encountered here (https://github.com/google/brax/issues/321), it goes away if I install brax from source instead of via 'pip install brax'; there seem to be multiple issues with brax when installed via 'pip install brax'. If I can do anything to help you identify and correct the issues, let me know.


[ignition-common3] patch for ffmpeg6

I guess the fasted solution is to simply use the upstream patch for ffmpeg 6 for ignition-common3

why patch and not new version?

Because it is less work. Feels free to open a PR yourself and update ignition-common3

Because it is less work. Feels free to open a PR yourself and update ignition-common3

No need to attack me. I am just trying to help and understand. If there is an issue to update to the new version I would be happy to know.


APLS evaluation

After training the baseline model and postprocessing to get the submission csv, how do i get the APLS of my predictions against the ground truth?

Hi, the APLS metric is not in this repo. You can find that at: https://github.com/CosmiQ/apls/tree/master


Show dial code overrides current phone number

Am I right in saying that showDialCode: true in inputOptions overrides the current phone number?
I am playing with the CodePen here: https://codesandbox.io/s/vue-tel-input-playground-wznqo . I have changed the value of showDialCode to true and the number (phone:<PHONE_NUMBER>) is not shown on the screen as seen here: https://wznqo.csb.app/ .
Is there a way to show the dial code if there is no number supplied only or is this a bug or a feature? Also, is there a way to show the dial code in addition to a value, in this case phone, in the code sandbox linked?
Edit: I see the scenario above is happening because mode is international. Can a selected dial code be appended to a non international phone number any way by clicking on it?
The constant closing and reopening was not to draw attention. I genuinely thought I had gotten somewhere and then realised I hadn't.

I am having the same problem here.. Thanks !

@LouisCharles70 If it helps, the input event has a isValid object which contains the international version of the number, isValid.number.international. You can use this to populate your input field. isValid.number.international is the value of the phone number you had previously and any selected phone extension.

From v5 you can turn off the auto format option by autoFormat: false.

From v5 you can turn off the auto format option by autoFormat: false.