Union type field is not read properly between flatc -> flatcc

I have prepared the following flatbuffers schema to show the case
namespace TestMSG;

table MsgPing {
	text: string;
	length: ushort;
}

table MsgPong {
	text: string;
	length: ushort;
}

union MessageUnion { MsgPing, MsgPong}

table ComboMessage {
	message: MessageUnion;
}

root_type ComboMessage;

The ComboMessage message is a container for any type of message defined by the union.
For test purposes I've used flatc to generate Python wrapper, created a message and wrote it to a file:
import flatbuffers
from TestMSG import ComboMessage
from TestMSG import MessageUnion
from TestMSG import MsgPing
from TestMSG import MsgPong

TEXT = "Hello Python!"

# Generate the message
builder = flatbuffers.Builder(1024)
textToUse = builder.CreateString(TEXT)

MsgPing.Start(builder)
MsgPing.AddText(builder, textToUse)
MsgPing.MsgPingAddLength(builder, len(TEXT))
ping = MsgPing.End(builder)

ComboMessage.Start(builder)
ComboMessage.AddMessage(builder, ping)
ComboMessage.AddMessageType(builder, MessageUnion.MessageUnion().MsgPing)
combo_message = ComboMessage.End(builder)

builder.Finish(combo_message)
buf = builder.Output()

with open("flatbuffer_msg.bin", "wb") as f:
    f.write(buf)

print(f"{buf!r}")

Then using flatcc I've prepared reader sample:
#include <stdio.h>
#include "testmsg_test_reader.h"

int main(void) {
    char buffer[1024];

    FILE *in_file = fopen("flatbuffer_msg.bin", "rb");

	size_t size = fread(buffer, sizeof(char), 1024, in_file);
    printf("Read %ld\n", size);

	TestMSG_ComboMessage_table_t msg = TestMSG_ComboMessage_as_root(buffer);
	TestMSG_MessageUnion_union_type_t type = TestMSG_ComboMessage_message_type_get(msg);
	printf("Message type is: %s [%d]\n", TestMSG_MessageUnion_type_name(type), type);

    fclose(in_file);
	return 0;
}

I'd expect to get the Message type to be shown as "MsgPing", instead the output of the application is:

Read 60
Message type is: NONE [0]

Verification snipped using Python shows the correct type:
with open("flatbuffer_msg.bin", "rb") as f_read:
    read_buf = f_read.read()
    read_message = ComboMessage.ComboMessage.GetRootAs(read_buf, 0)
    print("Read message type: ", read_message.MessageType())

Read message type:  1

Could you please try dump the hex content of the binary file using the new feature
https://github.com/google/flatbuffers/tree/master/tests/annotated_binary
It requires a recent flatc build, I don't think it has been released yet.

Sure thing I've build both flatc and flatcc from the latest sources:
`// Annotated Flatbuffer Binary
//
// Schema file: testmsg_test.fbs
// Binary file: flatbuffer_msg.bin
header:
+0x00 | 0C 00 00 00             | UOffset32  | 0x0000000C (12) Loc: +0x0C | offset to root table TestMSG.ComboMessage
vtable (TestMSG.ComboMessage):
+0x04 | 08 00                   | uint16_t   | 0x0008 (8)                 | size of this vtable
+0x06 | 0C 00                   | uint16_t   | 0x000C (12)                | size of referring table
+0x08 | 07 00                   | VOffset16  | 0x0007 (7)                 | offset to field message_type (id: 0)
+0x0A | 08 00                   | VOffset16  | 0x0008 (8)                 | offset to field message (id: 1)
root_table (TestMSG.ComboMessage):
+0x0C | 08 00 00 00             | SOffset32  | 0x00000008 (8) Loc: +0x04  | offset to vtable
+0x10 | 00 00 00                | uint8_t[3] | ...                        | padding
+0x13 | 01                      | UType8     | 0x01 (1)                   | table field message_type (UType)
+0x14 | 0C 00 00 00             | UOffset32  | 0x0000000C (12) Loc: +0x20 | offset to field message (union of type MsgPing)
vtable (TestMSG.MsgPing):
+0x18 | 08 00                   | uint16_t   | 0x0008 (8)                 | size of this vtable
+0x1A | 0C 00                   | uint16_t   | 0x000C (12)                | size of referring table
+0x1C | 08 00                   | VOffset16  | 0x0008 (8)                 | offset to field text (id: 0)
+0x1E | 06 00                   | VOffset16  | 0x0006 (6)                 | offset to field length (id: 1)
table (TestMSG.MsgPing):
+0x20 | 08 00 00 00             | SOffset32  | 0x00000008 (8) Loc: +0x18  | offset to vtable
+0x24 | 00 00                   | uint8_t[2] | ..                         | padding
+0x26 | 0D 00                   | uint16_t   | 0x000D (13)                | table field length (UShort)
+0x28 | 04 00 00 00             | UOffset32  | 0x00000004 (4) Loc: +0x2C  | offset to field text (string)
string (TestMSG.MsgPing.text):
+0x2C | 0D 00 00 00             | uint32_t   | 0x0000000D (13)            | length of string
+0x30 | 48 65 6C 6C 6F 20 50 79 | char[13]   | Hello Py                   | string literal
+0x38 | 74 68 6F 6E 21          |            | thon!
+0x3D | 00                      | char       | 0x00 (0)                   | string terminator
padding:
+0x3E | 00 00                   | uint8_t[2] | ..                         | padding
`
Here is the binary file itself:
hexdump --canonical flatbuffer_msg.bin  00000000  0c 00 00 00 08 00 0c 00  07 00 08 00 08 00 00 00  |................| 00000010  00 00 00 01 0c 00 00 00  08 00 0c 00 08 00 06 00  |................| 00000020  08 00 00 00 00 00 0d 00  04 00 00 00 0d 00 00 00  |................| 00000030  48 65 6c 6c 6f 20 50 79  74 68 6f 6e 21 00 00 00  |Hello Python!...| 00000040

From a quick inspection, that buffer looks OK, and the type should be 1 and not 0, so it appears that something is wrong with flatcc or the way that it is being used.
Your char buffer is not aligned correctly - a common mistake - but that is unlikely to be the problem if you are using an x86 based system - it will however affect the flatcc verifier if you choose to call it.
I am involved in projects where flatcc is used extensively with unions that interoperate with Go and Javascript, so in general unions should be working.
I will need to have a closer look. I suspect it might specifically be the direct accessor to the union type that is somehow wrong: TestMSG_ComboMessage_message_type_get
You could try to get the union as a struct with two fields: a type and an offset and see what that returns - as per documentation.
And just to rule it out: sometimes people test something different from what they think that they are testing, so please double check it is the correct buffer that you are reading.

Note that you are reading 60 bytes, but there 0x40 bytes = 64 dec. bytes in the hexdump.
In C you are only reading 60 bytes. Truncation is not necessarily a cause of the problem at hand, but it might suggest that you are reading another buffer.

When I compile your program with the buffer you provided, I get the expected result:
Read 64
Message type is: MsgPing [1]

You are right, in both cases. First I messed up with the files and after double check I did observe that the result is okay, but the problem I have is XY-kind problem and I tried to reproduce it first on the X86 platform.
So the problem is that even if this works on X86 but it stops working on the real environment. I'm sending the fltabuffer by the network to Zephyr-based ARM embedded system, and then I always get that the message id is 0, even if the same binary data are used on X86 it works.
I guess it might be because of the alignment that you mentioned? Or is there something else I should check?

I wrote the below before your edit, but it still applies:
I am not familiar with ARM Zephyr. Recent ARM appear to not mind unaligned access much. Some relatively new ones take a performance hit, but the latest not so much - I have no direct experience with this. Other older or embedded / low-end platforms might object more aggressively, but then you would expect a segfault.
Another issue is that older ARMs might be big endian. While this should not be a problem for flatcc, and the binary buffer is the same in all cases, it might trigger some code paths that are not regularly testet.
However, flatcc v0.4 has been extensively test with big endian.
As to your new question on alignment:
Alignment is based on the largest datatype stored in the buffer. This is minimum 4 bytes because the offset to the root table is 4 bytes. If you have an int64 type or a double float, it will be 8 bytes. If you explictly use a FlatBuffer attribute to align structs to more than that, you will need to align to that.
Since not all buffers of the same schema necessarily use the largest data type, flatcc builder can give you information on the required alignment for the actual buffer. But generally, you should know in advance based on the schema.
In your test program you can use alignas(4) char buf[1024]; (from memory). If you use malloc, it depends on the platform, but most implementations will align to at least 8 bytes.
Even if your platform does not support alignas, it will be available with flatcc due the portable library. It is needed to ensure structs are aligned correctly in generated code.

Oh, and there is a portable aligned_alloc and aligned_free with flatcc that you can use if you need more than what malloc provides. See test programs in flatcc, they use these. aligned_alloc is C11 std., but aligned_free is flatcc specific and defaults to free on C11, but other platforms need specialized free operations for aligned allocation, so flatcc needs aligned_free to accommodate.

So I wasn't clear in my last answer.
I told you how to find out how much to align, but not what to align.
You must align the memory buffer where you read the buffer from.
Some CPU's have an address system where an address must be aligned to 4 bytes if they try to read a word of 4 bytes an so forth. More recent CPU's and Intel for a long time, can read from other addresses, but internally it typically means the CPU makes a special case and reads two words, then shifts the result. This is slower on some hardware, but barely noticable on modern high end hardware. However, you still have a similar problem when reading across cache lines - which will work, but it will be slower. This is not directly relevant to the discussion, but this is one reason why FlatBuffers makes it possible to align to more than 8 bytes along with hardware mapping of I/O & graphics.


Support for Alfred 4?

Is your feature request related to a problem? Please describe.
Alfred 4 complains that this workflow requires Alread 5 and above because it uses the "Workflow User Configuration".
Describe the solution you'd like
Is there a way that this workflow can be used with Alfred 4, even if it means some features/configurations will not be available?
Thank you for considering!

Hey!
There is no plan to support Alfred 4 since the "Workflow User Configuration" is a crucial part of the workflow. Sorry!

Thanks for the answer! Maybe this will be the trigger for me to finally upgrade to Alfred 5 🤣


[Event Request] Codeunit 5921 "ServComponent-Copy from BOM" – New Event “OnBeforeShowErrorText”

Could we please have a new publisher “OnBeforeShowErrorText” in Function “OnRun”, Codeunit 5921 "ServComponent-Copy from BOM" including a handle pattern?
    trigger OnRun()
*** start new code ***
    var
        IsHandled: Boolean;
*** stop new code ***
    begin
        ServItem.Get("No.");
        ServItem.TestField("Item No.");
…
            until BOMComp.Next = 0;
        end else
*** start new code ***
        begin
            IsHandled := false;
            OnBeforeShowErrorText(IsHandled);
            if not (IsHandled) then
*** stop new code ***
                Error(
              Text000,
              BOMComp.TableCaption, ServItem.FieldCaption("Item No."), ServItem."Item No.");
*** start new code ***
        end;
*** stop new code ***
    end;
…
*** start new code ***
    [IntegrationEvent(false, false)]
    local procedure OnBeforeShowErrorText(var IsHandled: boolean)
    begin
    end;
*** stop new code ***

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


UPDATE

update to UCS NAMES AND CHAT MESSAGES

umm.... what?

He wants strings to be in Unicode again.

yes but that doesn't match the current protocol standard.

Pretty sure there already is UCS names and chat messages.

He's using my protocol 6 Cigar but he wants the Unicode strings back.
this guy is weird

@Luka967 help me please i love you  , jaralowell already added emoticons to his protocol 6


Give --runtime-config-file a default of spin-up.toml

Applies only to "local" apps (not e.g. spin up --bindle)
spin-up.toml is searched for "next to" spin.toml
If the default doesn't exist, there is no error (unlike --runtime-config-file missing.toml)

Defining the name of the runtime config file makes sense to me and using spin up brings clarity that it is execution time configuration. +1 from me

Do we yet have a likely sense of the 'scope' of a runtime config file, e.g.:

Are runtime configs portable across machines?  (That is, should they be checked into source control.)
Are runtime configs likely to contain secrets?  (That is, would it be actively bad if they were checked into source control.)
Are runtime configs specific to applications or general to environments?  (E.g. this is my Vault server, this is my scratch database directory, don't make me repeat them for every app.)

My guess is that they're not going to be very portable, so at the very least we'll want to advise people to .gitignore them (and add that to template gitignores).  But I think the Vault one depends on EVs for secrets, so it's not a big deal if someone does commit one.  Is that right?  And it sounds like we think the third one is specifically per-application?

For the use cases I have made up in my head I would expect runtime config to not be checked in to public repositories.
I don't have a good sense of whether runtime configs would be reused between apps much. Probably not, if you are following good security practices. :neutral_face:

@itowlson I wonder if we should not only .gitignore .spin in templates, but actually prohibit templates from installing anything under .spin in the same way that git repos aren't allowed to check out anything under .git.

That's probably a good plan.  We don't want a third-party template installing a runtime config file that maps the default store to Evil J Hacker's Personal Data Emporium And Secrets Mart.


downloading interruption

After running it for a while I got this error:
Traceback (most recent call last):
File "D:\Python27\Scripts\YahooTickerDownloader.py", line 140, in
main()
File "D:\Python27\Scripts\YahooTickerDownloader.py", line 97, in main
downloadEverything(downloader, tickerType, args.insecure)
File "D:\Python27\Scripts\YahooTickerDownloader.py", line 51, in downloadEvery
thing
print (" " + unicode(symbols[1]))
UnicodeEncodeError: 'gbk' codec can't encode character u'\xc3' in position 27: i
llegal multibyte sequence
If I restart it, it will go further before throwing another one. Is this just Yahoo issue or something else?

I've also got this error.
I think it comes when the scripts tries to output some results from the latest requests and chokes on some characters from the stock name (for example, in this output the error happens just when printing the second Stock):
req https://finance.yahoo.com/lookup/?s=d&r=&m=ALL&t=S&b=1100
Got 20 downloaded Stock symbols:
 Stock DRYN PNK DRAYTON RICHDALE NEW
A exception occurred while downloading. Suspending downloader to disk
Successfully saved download state
Remove downloader.pickle if this error persists
Issues can be reported on https://github.com/Benny-/Yahoo-ticker-symbol-downloader/issues

Traceback (most recent call last):
  File "YahooTickerDownloader.py", line 139, in <module>
    main()
  File "YahooTickerDownloader.py", line 96, in main
    downloadEverything(downloader, tickerType, args.insecure)
  File "YahooTickerDownloader.py", line 50, in downloadEverything
    print (" " + unicode(symbols[1]))
  File "C:\Python27\lib\encodings\cp850.py", line 12, in encode
    return codecs.charmap_encode(input,errors,encoding_map)
UnicodeEncodeError: 'charmap' codec can't encode character u'\x81' in position 59: character maps to <undefined>

There is a work around for this. If you are on linux you can set these environment variables:
LANGUAGE=en_US.UTF-8
LC_ALL=en_US.UTF-8

Hi,
I'm on windows. After a few hours trying to make the decoding/encoding working i gave up and end catching that exception and letting it pass:
try:
    print (" " + unicode(symbols[0]))
    print (" " + unicode(symbols[1]))
    print ("  ect...")
except:
    pass

I think the encoding on the Yahoo database isn't standarized. For example the BR symbol BEES4.SA looks like:

Banestes S.A - Banco do Estado do EspÃrito Santo S.A. (BEES4.SA)

But if you take a look at SDIL11.SA:

SDI Logística Rio - Fundo de Investimento Imobiliário - FII (SDIL11.SA)

So here the accented chars looks right.
I think if I'm going to use Yahoo's finance data, it may need a character encoding detection somewhere :-(

I think the problem lies in the systems default char encoding. If it is not set to UTF it will not be possible to display all unicode characters in the output device and hence the error. It tries to encode unicode into something for which there is no proper mapping.
I consider @alanbertadev's solution to be the best solution.
But there might be valid reasons to have a odd char encoding, so I will implement @underdpt's solution into master:
			try:
				print (" " + unicode(symbols[0]))
				print (" " + unicode(symbols[1]))
				print ("  ect...")
			except:
				print (" Could not display some ticker symbols due to char encoding")

This issue is better explained @ #9


Does ASP.Net Core uses MSAL behind the scene?

Is ASP.Net core identity built on MSAL or MSAD library?
Otherwise how is it different from MSAD (or MSAL) libraries?
When should one select ASP.Net Core Identity framework over MSAL library for .Net  and what business cases does it enables that is not covered by MSAL libraries?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 94bfd895-d2af-390b-0801-428b36a27ff4
Version Independent ID: 0e0d870e-e49a-e16c-c259-68d58e701b8f
Content: Introduction to Identity on ASP.NET Core
Content Source: aspnetcore/security/authentication/identity.md
Product: aspnet-core
Technology: aspnetcore-security
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

See https://github.com/dotnet/aspnetcore/tree/master/src/Identity

@Rick-Anderson   Thanks you very much !


Optgroups don't inherit font family and font style in Firefox

The font family and font style are not inherited by optgroup labels and options within an optgroup in Firefox 45 (probably happens in some older versions too). The screenshot below demonstrates this using the normalize.css UI tests page:

This can be fixed by setting optgroup {font-family: inherit; font-style: inherit;} and optgroup option {font-style: inherit;}.

After further digging it seems that adding optgroup {font: inherit; font-weight: bold;} is a better solution since only the font size is set to be inherited.

It looks like the optgroup was removed by mistake in 0c90242.


Update on-demand-workspace-overview.md

Adding a note about the query time of 30 minute (please verify). reference: https://docs.microsoft.com/en-us/answers/questions/425867/query-timeout-expired-synapse-serverless-built-in.html

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

While in understand the maintenance overhead. Only having the content in the constraints doesn't make this very discoverable. Not sure the best way to solve this; but this is a significant limitation and is not very well documented or publicized.

@filippopovic Should this pull request remain open?
Thanks.

@jasonhorner I agree with Filip's feedback, duplicating the limits will lead to maintainence issue. I see your point though, so instead of adding the limit value directly, I added a note that links to the constraints doc. You can see my PR above; the changes will go live tomorrow. We will close your PR now.
#please-close

@sign-off


R/library/haven/libs/haven.so: undefined symbol: libiconv    Execution halted

(padloc) user:~/storage/tool/padloc-1.1.0/test$ ../bin/padloc --fna GCA_000218745.1.fa --cpu 8 --force
[12:53:32] >> Predicting protein-coding genes with prodigal
[12:53:35] >> Scanning GCA_000218745.1.fa for defence system proteins
[12:54:49] >> Searching GCA_000218745.1.fa for defence systems
Error: package or namespace load failed for ‘tidyverse’ in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/home/user/anaconda3/envs/padloc/lib/R/library/haven/libs/haven.so':
/home/user/anaconda3/envs/padloc/lib/R/library/haven/libs/haven.so: undefined symbol: libiconv
Execution halted
[12:54:50] ERROR >> errexit on line 397
Hi, I am trying to execute padloc but it's giving 'undefined symbol' error. I also tried to install tidyverse but didn't work. Any help is greatly appreciated. Thanks

It seems this issue is quite well-known and explained here.
It worked for me after removing haven (which also removed padloc) and reinstalling tidyverse and padloc.


terminal.integrated.automationShell.osx does not allow for using a login shell

Issue Type: Bug
The default shell used for automations on macOS is a login shell. Unfortunately, if I use 'terminal.integrated.automationShell.osx' to override the shell, there's no way to make this a login shell as there's no way to pass shell args. This is really aggravating as I use Fish as my default shell, which is not suitable for automations (as it's not sh-compliant), so I need to override the automation shell to /bin/bash. But doing so means it's not a login shell, and so does not pick up any of the non-system-default tools I've installed.
I can think of three potential solutions:

Let me specify an array for this setting, where the first element is the shell path and the rest are arguments.
Define a separate 'terminal.integrated.automationShellArgs.osx' setting I can use to provide args.
Define a 'terminal.integrated.automationProfile.osx' setting so I can specify a terminal profile. This is my least favorite option as it's the most complicated setup (I don't even know offhand how to define terminal profiles).

Allowing me to pass an array for 'terminal.integrated.automationShell.osx' seems like the simplest solution.


Copy function docs to Toolshed; hide submodules

Currently h/1 helper does not show useful info for individual functions due to delegation (https://github.com/elixir-toolshed/toolshed/pull/132). Here is one proposal to improve docs.
Alternative solution:  https://github.com/elixir-toolshed/toolshed/pull/141
Changes

add function docs to all the delegation definitions
hide submodules

Outcome
Running h/1

All the submodules are hidden from the package users now that all the info is in the top-level module.

Notes

one disadvantage of this approach is that function docs are located away from implementation
maybe we can justify it by seeing the top-level module as centralized public docs as opposed to private docs in the other modules 🤔

Probably https://github.com/elixir-toolshed/toolshed/pull/141 is better overall.


explicitly specify CMake libdir as lib

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[x] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew tests with your changes locally?
[x] Have you successfully run brew man locally and committed any changes?

On Linux distributions with a lib64 directory (i.e. RHEL/CentOS 7), CMake will by default install libraries in the lib64 directory of the formula cellar rather than lib.  This is incorrect because Homebrew only uses lib as a library directory in a cellar.  Some formulae have explicitly added the argument -DCMAKE_INSTALL_LIBDIR=lib to their CMake arguments to fix this.  In this issue  https://github.com/Homebrew/linuxbrew-core/pull/21651#issuecomment-734496372 it was suggested to just add that argument to std_cmake_args because all formula built with CMake should always use lib, regardless of OS. This not expected to have any effect on macOS or Linux distributions without a lib64 directory, as CMake will already use lib anyway.

cc @iMichka

LGTM, this is the strategy we have been using on linux since years. We do not support the concept of the lib32/lib64/lib split, which is specific to RHEL/CentOS (I always found the implmenentation weird anyway). For Homebrew, we have just one single lib dir.
Once this is merged, we can make a small cleanup in homebrew-core, I see this has been used for the cmark and for the simple-amqp-client formulae and will not be needed anymore.

Thanks for contributing to Homebrew, @danielnachun! This has been merged.


Update CHANGELOG.md [ci skip]

Coverage remained the same at 100.0% when pulling 5c49c8e0e1ea42300017037b759ba58fe9341f87 on develop into 8e47b3c2fe78fa6053b9e2a650fa84f34ac02927 on master.


JAWS doesn't read integrated terminal

Issue Type: Bug

With JAWS running, open latest Insiders build of VS code.
Make sure screen-reader optimization is on, Alt+F1, Ctrl+E for permanent optimization.
Try to build a project with Ctrl+Shift+B to get an integrated terminal window with some output to open.
Press F6 until you reach the integrated terminal area.
JAWS will report to use Ctrl+Up/Down to navigate the terminal's buffer. Try to use Ctrl+Up/Down.

Actual: JAWS is silent and does not read the terminal's output.
Expected: Ctrl+Up/Down will read the terminal's output line by line.
VS Code version: Code - Insiders 1.66.0-insider (6b7453421201c888b81eae5c04ec822a6423608f, 2022-03-11T05:17:19.559Z)
OS version: Windows_NT x64 10.0.22000
Restricted Mode: No

System Info

Item
Value

CPUs
Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz (12 x 2904)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
31.85GB (16.77GB free)

Process Argv
C:\repos\fabric-internal\packages\excel_substrate_logger --crash-reporter-id 55dec8bb-14d6-4c04-87d0-0c4ef8a63220

Screen Reader
yes

VM
0%

Extensions (2)

Extension
Author (truncated)
Version

vscode-eslint
dba
2.2.2

prettier-vscode
esb
9.3.0

A/B Experiments
vsliv695:30137379
vsins829:30139715
vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyl392:30422396
pythontb:30258533
pythonvspyt551cf:30291413
pythonptprofiler:30281269
vshan820:30294714
pythondataviewer:30285072
vscod805cf:30301675
pythonvspyt200:30323110
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
pythonvs932:30404738
wslgetstarted:30449409
vsclayoutctrc:30405799
dsvsc009:30440021
pythonvsnew555:30438690
vscscmwlcmt:30428973
vscgsvid1:30433757
dockersurvey3:30438168
pynewfile477:30451556

@MS-AlexB thanks for opening this issue.
@TylerLeonhardt @meganrogge Alex is working for MS and we can reach out to him if more details are needed.
This sounds familiar. Are there more issues with JAWS + terminal? Can I help somehow here?

Hello. I have just installed the latest versions of Windows 11 22H2, JAWS 2023, NVDA, and VS Code on a laptop.
I can’t read the output on my braille display from the integrated terminal. Normally pressing INSERT+Z in JAWS (to turn off the Virtual Cursor) or INSERT+SPACEBAR in NVDA (focus mode) would let me read line by line when pressing CTRL+Up Arrow Key. But I am not getting the output. Instead, I am reading list numbers such as 45 of 47.
Currently to read the output with JAWS I must do this:
Press F6 to navigate to the integrated terminal. Then press INSERT+Z, then CTRL+Up Arrow Key, then press the Plus Key on the Numpad twice. I can then read the output. Then I press CTRL+Up Arrow Key to move up a line and double tap the Plus Key on the Numpad to read the output.
For NVDA:
Press F6 to navigate to the integrated terminal. Press CTRL+Up Arrow Key, then press INSERT+SPACEBAR to read the output. Then press CTRL+Up Arrow Key to move up a line. Then press INSERT+SPACEBAR. Then INSERT+SPACEBAR again to read a line.
I hope this information can helps to resolve the issue.
Paul

/duplicate #164988

@meganrogge  How is this a duplicate of #164988. This is something that used to work well in the passt. #164988 can be considered a feature request because it is asking for something that screen readers do not normally do, which is reading a line when the change in cursor position has not been initiated by the user.

I think it was meant to be this one: https://github.com/microsoft/vscode/issues/154027

Yes my mistake @rperez030 , I did mean #154027. I am aware that this is a regression not a feature request and plan to look into it this iteration


Fix SELinux detection warning

Checking if SELinux is in Enforcing mode, if so- offers to change it to permissive mode and refers to further documentation.

@NoamLandress - please resolve conflicts with the other PR submitted or reconcile to one PR for review

New one created


Form builder with optional third-party UI library code generation.

The form builder is a great feature.
I'm just requesting to take it another level by providing option to generate code according to a third-party library.
For example, I use ant. If I use form builder and copy code, I still have to change the fields according to ant specific fields API. If there is someway I can choose what library I use, and the code sample has code with ant's Input field and they are registered like you show in Work with UI library section.
I know there are a ton of UI libraries, but this feature request is just a thought.

It sounds like a great idea! the tricky part is to deal with all the lib's component Props, HTML standstill but those external UI can change anytime, which can make maintaining it hard.

Agreed.


Add segmentation module

@gwaybio This should be good for review! I will raise an issue for the no corresponding object error.

Got it! Thanks for clarifying. Only three other comments:

It looks like you're using the cyto cellpose model. I thought that we were using the nucleus model? If we're using the cyto, we need to update the README and justify why not nuclei
I'm seeing a keyboard interrupt in the jupyter notebook - would it take too long to re-run the full notebook to completion to prevent this?
Do you have documentation about your troubleshooting solutions for installing cellpose? Did you have to create a new conda environment? I imagine that if not yet, we will have to make a separate one soon for the DeepProfiler implementation

Comments 1 & 2 should be resolved in the latest commit, let me know what you think.
Regarding comment 3, the issues were solved by installing CellPose from conda-forge instead of pip. I did not create a separate environment for this module but think that might be a good idea. I have opened an issue for this (https://github.com/WayScience/mitocheck_data/issues/6) which we can discuss during our in-person meeting.


Weird error

Hey ! With recent changes, when I upgrade to NodeJS 22, I have this error.

@louistiti I think it's related to ESM/CommonJS with recent changes on NodeJS 20+

@Arthur-GYT hi, thanks for reporting. I committed a fix, can you please help to check?

@louistiti I try to remove node_modules folder, reinstall nodejs version with nvm and I have the same error...

My bad, I have this error when I remove server/dist directory

It work fine now, Thanks louis ^^


Slowdown redeliveries, add timeout metrics

Talked with Kiran, set the nack redelivery delay to 25 milliseconds for now. We can tune it later.

Coverage increased (+0.3%) to 67.206% when pulling f9cc46c302302b174b100421db2721addcde3822 on slow_down into 8f826a732e27f1ce5e983353572a23478e3f1da4 on master.

Coverage increased (+0.6%) to 67.582% when pulling c76c0706a14c4296fcea7abb54aff06ad69fe2ce on slow_down into 8f826a732e27f1ce5e983353572a23478e3f1da4 on master.


Client hangs for around 15 minutes during network hiccup although short socket_timeout is specified

Version:

redis-py: 3.5.3

Platform:

Python 3.9.5

Description:
Network hiccup results in ~15 minutes hang before TimeoutError is raised although socket_timeout is defined while instantiating the client.
The client is created like this:
from redis import StrictRedis

redis_client = StrictRedis.from_url(my_redis_url, socket_timeout=0.3, socket_connect_timeout=0.1)

During network hiccups, the client hangs for ~15 minutes (between 938-939 seconds to be exact) in hget before raising a TimeoutError. Stack trace of the exception (note that ddtrace is being used but I doubt it'd affect this):
 File \"/home/user/my-app/my-module.py\", line 99, in my_function\n    the_stuff_read_from_redis: Optional[bytes] = redis_client.hget('my-hash', 'my-key')\n
 File \"/home/user/.venv/lib/python3.9/site-packages/redis/client.py\", line 3010, in hget\n    return self.execute_command('HGET', name, key)\n
 File \"/home/user/.venv/lib/python3.9/site-packages/ddtrace/contrib/redis/patch.py\", line 85, in traced_execute_command\n    return func(*args, **kwargs)\n
 File \"/home/user/.venv/lib/python3.9/site-packages/redis/client.py\", line 901, in execute_command\n    return self.parse_response(conn, command_name, **options)\n
 File \"/home/user/.venv/lib/python3.9/site-packages/redis/client.py\", line 915, in parse_response\n    response = connection.read_response()\n
 File \"/home/user/.venv/lib/python3.9/site-packages/redis/connection.py\", line 739, in read_response\n    response = self._parser.read_response()\n
 File \"/home/user/.venv/lib/python3.9/site-packages/redis/connection.py\", line 470, in read_response\n    self.read_from_socket()\n
 File \"/home/user/.venv/lib/python3.9/site-packages/redis/connection.py\", line 442, in read_from_socket\n    raise TimeoutError(\"Timeout reading from socket\")\n"

Just to note, the Redis server and the client process are not running in the same machine. Also, I assume this is similar to https://github.com/andymccurdy/redis-py/issues/722 although there the consensus seemed to be that setting socket_timeout should help (and it's relatively old issue).

Something similar is happening with celery beat which uses redis backend. The timing matches (938-939 second "breaks"). The difference is that there's no TimeoutError or any other exception present but I assume that's swallowed somewhere in the call stack (e.g. inside celery code). Related thread in the celery-users Google Group.


feat(): add validating webhook (delete) to prevent vpn key rotation config delete

…deletion

Description

Fixes #
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

Checklist:

[ ] The title of the PR states what changed and the related issues number (used for the release note).
[ ] Does this PR requires documentation updates?
[ ] I've updated documentation as required by this PR.
[ ] I have performed a self-review of my own code.
[ ] I have commented my code, particularly in hard-to-understand areas.
[ ] I have tested it for all user roles.
[ ] I have added all the required unit test cases.

Does this PR introduce a breaking change for other components like worker-operator?

@PuranAdhikari re-requesting review!


Add warning if no backend provided on cloud channel

Summary
Details and comments
Fixes part of #1416

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 5 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.009%) to 81.536%

Totals

Change from base Build<PHONE_NUMBER>:
0.009%

Covered Lines:
5074

Relevant Lines:
6223

💛  - Coveralls


Use standard project structure on legacy branch

The only downside of moving files around is that we are losing option to compare files between branches (with master) but that's not a big problem after all ;-)
LGTM 👍

The only downside of moving files around is that we are losing option to compare files between branches (with master) but that's not a big problem after all ;-)

I guess we could do the same on master.


update request

add different python version compatibility (varCollector)
add string mode to AES encryption
after transformers add transformer to encrypt full code (save imports to pyinstaller)
add flow obfuscation with random code (math, etc.) (#6)
put xortable after imports

that'll be more effort than its worth, i don't want to remake the assembler
sure, added in the next update
dynamicCodeObjLauncher exists, that's basically what it does already
already done
why

that'll be more effort than its worth, i don't want to remake the assembler
sure, added in the next update
dynamicCodeObjLauncher exists, that's basically what it does already
already done
why

write in python without assembler (if u can)
idk, it will be look good

By assembler he means this not actual assembly code.

By assembler he means this not actual assembly code.

both, the assembly itself is also different on 3.10, for example


rethink downloads page and installation page

Originally: https://github.com/influxdb/influxdb.com/issues/279
It's tough keeping them in sync and the version-specific download and installation data should probably live in only one place.
Also maybe we should link Downloads in the left side nav of the docs.
@beckettsean

+1 for linking downloads in the docs left side nav.

Please also move the blog post about available linux repos to the Download page.


component will not work when debug info is disabled

The methods .scope() and .isolateScope() of an angular.element will return undefined when debug info is disabled: $compileProvider.debugInfoEnabled(false); as stated here and  here.
So this piece of code won't work while running your app on production mode:
function getOptionValue(nyaBsOption) {
  var scopeOfOption;
  if(valueExpFn) {
    scopeOfOption = nyaBsOption.scope(); // won't work on prod
    return valueExpFn(scopeOfOption);
  } else {
    if(nyaBsSelectCtrl.valueIdentifier || nyaBsSelectCtrl.keyIdentifier) {
      scopeOfOption = nyaBsOption.scope(); // won't work on prod
      return scopeOfOption[nyaBsSelectCtrl.valueIdentifier] || scopeOfOption[nyaBsSelectCtrl.keyIdentifier];
    } else {
      return nyaBsOption.attr('value');
    }
  }
}

+1

+1

+1

It is hard to fix this.

Hi !
This issue seems to be resolved in 'src' files but not replicated in 'dist' compilation ... How to use a version with last commits ?
Thanks

I'll draft a release in this weekend.
Although This bug was fixed, but there are several other changes need to be tested and other bugs need to be resolved.


java.lang.NoSuchMethodError: 'io.opentracing.Scope io.opentracing.Tracer$SpanBuilder.startActive(boolean)

Hi, i found problem, my dependency tree is:
+--- io.opentracing.contrib:opentracing-spring-jaeger-cloud-starter:3.1.1
|    |    +--- io.opentracing.contrib:opentracing-spring-jaeger-starter:3.1.1 (*)
|    |    --- io.opentracing.contrib:opentracing-spring-cloud-starter:0.5.0
|    |         +--- io.opentracing.contrib:opentracing-spring-rabbitmq-starter:2.0.5
|    |         |    --- io.opentracing.contrib:opentracing-spring-rabbitmq:2.0.5
in pom of spring-cloud-starter:0.5.0 no version param for opentracing-spring-rabbitmq-starter.

In my project i see error in runtime:
[m java.lang.NoSuchMethodError: 'io.opentracing.Scope io.opentracing.Tracer$SpanBuilder.startActive(boolean)'
at io.opentracing.contrib.spring.rabbitmq.RabbitMqTracingUtils.buildReceiveSpan(RabbitMqTracingUtils.java:45) ~[opentracing-spring-rabbitmq-2.0.5.jar!/:?]
May be need to fix used version of starters in pom spring-cloud-starter:0.5.0. May be this usie help people to find this version compability problem

when fix io.opentracing.contrib:opentracing-spring-rabbitmq:2.0.5 to 3.0.1 all work good


Make all the "Selection Tools" functions optional and configurable

🎉

This part was actually deliberately removed because it is now possible to customize selection tools, and too many translation tools seem a bit messy.

This part was actually deliberately removed because it is now possible to customize selection tools, and too many translation tools seem a bit messy.

That's exactly the reason why I want them to be optional :laughing:

I lean towards only keeping some particularly necessary tools as presets, such as translating any language into the user's language, and translating any language into the internationally common English. For other needs, users can customize directly, and there is no need to add more built-in presets.

So this patch will make both the "Translate (To Chinese)" & "Translate (Bidirectional)" functions not directly enabled, so it should be good with the idea? Or do you mean you'd entirely redesign this part of the feature? Thanks.

My current point is that there are two options that can't be turned off which may cause me to click the wrong one or decrease the efficiency in selecting the right one :laughing:
Screenshot:

You can export all data and edit the activeSelectionTools field, clear out the old preset tools, and then re-import.

Just to clarify, is this extra step only necessary for existing users? It seems like a fresh install wouldn't have this issue, right? If that's the case, then we can close this PR for sure! Thanks!

@PeterDaveHello This step is only needed by a very small number of users, as only in specific versions were these two options set to be enabled, and in many versions since then they have been turned off by default. If you have never modified the activated tools, or have never activated these two tools, then upgrading to the new version will not encounter this problem.

Got it, thanks again!


Chore/rush pnpm

:thumbsup: 3+ times faster builds. Since the time spent on building the packages doesn't differ that much between the approaches, the win only measuring resolving and installing deps is probably more around ~10x.
:thumbsup: No hoisting required. Avoids phantom deps and enables versioning differences between the packages. Latter frequently comes up when a package with a newer version for a dep is added or a dep is updated in one packages. Currently it forces us to add another no-hoist flag or change the version(and sometimes the implementation) everywhere else. We cannot allow contrib packages to be coupled in such a way long term.
:thumbsdown: Since pnpm extensively uses symlinking, some packages may not be able to load it's plugins, etc. That was an issue with<EMAIL_ADDRESS>and webpack@4 neither of which we use. Not currently an issue but can be in the future. However having lerna-related issues in the repo is not foreign either.
:thumbsdown: No native support by Renovate. There are configuration options though: https://github.com/renovatebot/renovate/issues/3681

Codecov Report

Merging #58 (adc0416) into main (670797a) will decrease coverage by 4.17%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main      #58      +/-   ##
==========================================
- Coverage   95.91%   91.73%   -4.18%
==========================================
  Files          13      113     +100
  Lines         856     5107    +4251
  Branches      178      981     +803
==========================================
+ Hits          821     4685    +3864
- Misses         35      422     +387

Impacted Files
Coverage Δ

...lugin-react-load/src/BaseOpenTelemetryComponent.ts

...y-instrumentation-long-task/src/instrumentation.ts

...trumentation-document-load/src/enums/EventNames.ts

...entation-document-load/src/enums/AttributeNames.ts

...strumentation-document-load/src/instrumentation.ts

...lemetry-instrumentation-document-load/src/utils.ts

...umentation-user-interaction/src/instrumentation.ts

...ation-user-interaction/src/enums/AttributeNames.ts

...etapackages/auto-instrumentations-web/src/utils.ts

...etry-plugin-react-load/src/enums/AttributeNames.ts

... and 110 more

Any idea how this affects non-linux build hosts?

I would bet this can be made much faster by caching the .pnpm store as well

Any idea how this affects non-linux build hosts due to extensive use of symlinks?
pnpm supports Windows, and rush doesn't add complexity on that front afaik so I don't think it will be a problem.

I would bet this can be made much faster by caching the .pnpm store as well
Possibly, yes. I didn't want get deep into optimizing it before covering all the usecases first(releasing, etc).


enhancement(log): show file contents of selected file in log view

Obsolete by other branch, closing this


Add College System

https://www.ccsnh.edu/

@nmalby Thank you for your patience while waiting for a review and processing your request. Pull request merged. Please start applying for JetBrains educational subscription at https://www.jetbrains.com/shop/eform/students in an hour, to allow the changes to propagate through JetBrains systems.


fix airy amplitude scaling

fix airy amplitude scaling (fixes #14)
fix moffat FWHM conversion
add tests

@sefffal Turns out I had the math completely wrong- this change will be breaking for both the Moffat and Airydisk functions. If you want to give a pull and check it works like you want you can, otherwise I'll merge and register in a day or two.

Looks good, thanks for the quick fix @mileslucas!
I haven't done a side by side comparison to see what changed, but the output looks good to me and fixes the issue I noted.


prompts for MATH are not uploaded

The prompts for the MATH dataset are not uploaded. Could you please upload them?

Sorry, we actually haven't implemented reasoning algorithms on this dataset. The folder is pushed by mistake


PR's against a fork are included in the changelog

When releasing a new version, the builder compares the Pull Requests against the fork of the user.
i.e.:
VWA-77: cancel subscriptions"
string(96) "Merge pull request #102 from man-andy/man-andy-overview-datatables
VWA-112: Overview datatables"
string(113) "Merge pull request #5 from jaapromijn/overview-datatables
Remove methods that have been moved to activity plugin"
string(109) "Merge pull request #4 from jaapromijn/overview-datatables

Thanks. This causes a Not Found error if the project has no Pull Request with the same number, or an faulty changelog if it's a (different, unrelated) Pull Request in the project.


Search using the sitemap instead of UG search

90% of tabs match the artist and song name perfectly so can be used for search.

And many of the others would be extremely close

print(f"Total rows: {total_rows}")
Total rows: 15459
print(f"Artist match: {artist_match} {artist_match/total_rows}")
Artist match: 14180 0.9172650236108416
print(f"Name match: {name_match} {name_match/total_rows}")
Name match: 14557 0.9416521120382948

data processing and basic version of search external done

need a way to route unscraped tablinks to their highest rated versions.
e.g. search external returns search results, only unique title/artist/type and arbitrarily picks one of the taburls.
On click, that taburl is scraped, in its metadata should include the ratings of alt versions, you are then redirected to the highest rated one. Two queries, but 0 queries on search


add Equality.jl with method for edges and added tests for MinimumEdgeDominatingSet

I addded a new file for methods that check equlity. This is because the types of some of our objects are unions of types, so these methods can help compare between these representations. The only method so far is for undurected edge comparison.
This method is used in unit tests... more to come soon! I also think I have a more valid way of testing the domination methods, kind of by inspection and case by case, but it doesn't use the logic of the methods. By inspection is still a bit suspect... what else should you do for unit tests, though?
Pull Request Checklist
Thank you for contributing to GraphProperties.jl!
Documentation and Style

[X] I have added docstrings to any new functions or types, as applicable.
[X] My code follows the project's coding style and guidelines.

New Features and Code Changes

[X] If you have added a new algorithm or function, you have also included corresponding unit tests.
[X] I confirm that any code added is my own work and is not copied from other sources.

Review Process

[X] I have requested a review from at least one other contributor.

Additional Notes

Please describe any additional changes or information relevant to this PR.

Developer's Declaration:
By submitting this Pull Request, I confirm the following:

[X] The code I am submitting is my own work and I have the rights to use and distribute it.
[X] I confirm that the code I have added is not copied from other sources and that I have appropriately cited or acknowledged any external code or references used.
[X] I understand that my code will be reviewed and any changes requested must be addressed.

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[X] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no API changes)
[ ] Documentation content changes
[X] Unit Testing
[ ] Other... Please describe:

What is the new behavior (if this is a feature change)?

[X] Yes: added first equals method
[ ] No

Does this PR introduce a breaking change?

[ ] Yes
[X] No

New commit is pushed; I think all issues have been addressed. I do have a question, though @RandyRDavila . Would it benefit compilation to declare a_set and b_set at the top of the function since they get initialized using short circuit logic?
Also, I see the automatic checks have failed, but I don't understnad why... I'll try to look into it.

@joshyaffee If the Tests ever fail but they are passing locally, then just restart the tests by clicking on the details button and then rerun failed jobs.

I thought about our options and I believe that it makes sense to override == on the AbstractOptimalEdgeSet level and I made the changes to this brach accordingly. One drawback: I assume that only undirected edge sets extend AbstractOptimalEdgeSet. If we want to group together both undirected and directed edge sets, I would suggest a hierarchy like this:
AbstractOptimalEdgeSet
|-AbstractOptimalUndirectedEdgeSet
|  |-MinimumEdgeDominatingSet
|  |- ...
|-AbstractOptimalDirectedEdgeSet
|  |-...
and override == at the AbstractOptimalUndirectedEdgeSet and AbstractOptimalDirectedEdgeSet level for each of those abstract types. Hopefully my diagram is readable
Note that this design choice allows us to implement a separate == override for necessarily ordered edge sets such as walks (although this may be defined with nodes instead for simple graphs). e.g. AbstractOptimalUndirectedEdgeSequece.
Finally, I see that the auto tests continue to fail. Should I be concerned?

@joshyaffee I changed Equality.jl to equality.jl, which fixed the tests. Super weird that this didn't show up locally when running Julia. I found this bug by looking at the failures in GitHub and then sending them to GPT4. I'm going to merge this PR now. Thanks for all the hard work!


Added Firefox Developer Edition version 89.0b13.

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?

[x] Does your manifest conform to the 1.0 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

/azp run


Please raise issues about checkpoints here

Please raise issues about checkpoints here
See checkpoints

Hi! I want to download your model checkpoint but find that model_best.pth.tar cannot be extracted. It seems that the tar file is not correct. I have tried using tar -xvf on Linux and also the WinRAR on Windows but still cannot solve the problem.
Can you check whether the model file is okay? Or did I miss anything important? Thanks for your help.


[ERROR] In modules/gateways/btcpay/createinvoice.php: Invoice error: 'invalid json:

I just installed btc pay server and downloaded whmcs modules from https://github.com/btcpayserver/whmcs-plugin
I have uploaded the module in gateways and i added my api key and URI to your BTCPay server ( wich i am guesing is my btcserver.domain.com ? ) Is what i did, i placed an order on my whmcs portal and i got the following error
//modules/gateways/btcpay/createinvoice.php
[ERROR] In modules/gateways/btcpay/createinvoice.php: Invalid invoice id #0
[ERROR] In modules/gateways/btcpay/createinvoice.php: Invoice error: 'invalid json:
400 Bad Request
The plain HTTP request was sent to HTTPS port
nginx
'
Any ideeas please?
Thank You

+1 on this one.
Just got the same error:
[ERROR] In modules/gateways/btcpay/createinvoice.php: Invoice error: 'invalid json:
400 Bad Request
The plain HTTP request was sent to HTTPS port
nginx
'
Running with WHMCS 7.10.3
Will post an update here if my investigation will bear any fruit...

ok, I think I solved this one:
In your BTCPay server payment gateway settings in WHMCS ensure that you have not forgotten to put "https://" in the "URI to your BTCPay server" field.
It looks like it is trying to send data to HTTP by default, which is pretty weird in 2024 imho.
I've also updated and restarted the server, but it feels like it's not related to this issue, as it's "the plain HTTP request was sent to HTTPS port"
Cheers


Add IEMOCAP dataset

Adding a Dataset

Name: IEMOCAP
Description: acted, multimodal and multispeaker database
Paper: https://sail.usc.edu/iemocap/Busso_2008_iemocap.pdf
Data: https://sail.usc.edu/iemocap/index.html
Motivation: Useful multimodal dataset

cc @anton-l
Instructions to add a new dataset can be found here.

Hi! We can contact the authors to see if they are interested in hosting the dataset on the Hub. In the meantime, feel free to work on a script with manual download.

Hi @mariosasko . Thanks for your response. Sure, I will mail them and find out if they're open to this.
Work on a script with manual download ? This is new to me, any guidelines would be helpful here.

Thanks for your response. Sure, I will mail them and find out if they're open to this.

It's best to leave this part to us because we have to explain how login would work and (potentially) set up a custom verification for the dataset.

Work on a script with manual download ? This is new to me, any guidelines would be helpful here.

For instance, this is one of the scripts with manual download: https://huggingface.co/datasets/arxiv_dataset. Compared to the standard dataset, it has the manual_download_instructions attribute and uses dl_manager.manual_dir (derived from load_dataset(..., data_dir="path/to/data")) to access the dataset's data files.

It's best to leave this part to us because we have to explain how login would work and (potentially) set up a custom verification for the dataset.

Yes. That would be perfect. Thanks.

Okay. Thanks for giving a reference. This is helpful. I will go through it.

@flckv I think the gating mechanism is what you are looking for.

@mariosasko Thanks, but no. I would like to keep my HuggingFace Dataset private and train a model on it. Is this possible?


Add Reference to marcelodiiorio/My-Azure-AD-B2C-use-cases

There is a ton of useful knowledge here:
marcelodiiorio/My-Azure-AD-B2C-use-cases.  This repo should be linked to in the B2C documentation!
@marcelodiiorio

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 245ef8a4-a811-19b7-676c-aa9b82e2126f
Version Independent ID: ad2ec743-2aa7-b3c7-3350-2986a78d7c90
Content: What is Azure Active Directory B2C?
Content Source: articles/active-directory-b2c/active-directory-b2c-overview.md
Service: active-directory-b2c
GitHub Login: @davidmu1
Microsoft Alias: davidmu

Thank you, @spottedmahn! I really appreciate your feedback!

@spottedmahn Thanks for the feedback !  I have assigned this issue to content author to investigate and update the document as appropriate.

@spottedmahn, @SaurabhSharma-MSFT: I appreciate the pointer to the information. We don't typically link to external repositories. If there is specific information that you think should be added to the overview, we can open a work item to cover it, but for now I don't think there is anything specific that can be done with this article.
#please-close


Adding ifxbgt60dev to documentation index for distro

I'd like ifxbgt60dev to be indexed and documented on ros.org.

The necessary changes are done:

"There must be a LICENSE file. Either each package in the repository should have a LICENSE file, or the source repository should have a top-level LICENSE file. If the repository is under multiple licenses, then it is encouraged (but not required) to have one LICENSE. file per license.
The license should be one of the open-source ones listed in https://opensource.org/licenses (preferably one of the "Popular licenses").
The license must be reflected in the package.xml file of all sub-packages in the repository."

The missing license is added in the "package.xml" file.

"The structure of your repository is a little unusual. Usually the package is either in the root if it's intended to be a single package repository, or all packages are in subdirectories of the root for easy discoverability."

Since ifx_bgt60_device is the first package released now, a multi-package repository structure is chosen.

"I would also strongly suggest adding at least a little bit of documenation to your package such as a description with real content in the package.xml and some content into your README."

The basic information about ifxbgt60dev is added in README.md.

"You don't appear to have made a release. This whole stanza should not be included. bloom will generate it when you make a release following the first time release tutorial http://wiki.ros.org/bloom/Tutorials/FirstTimeRelease"

The information for the release will be added later.
Thank you for your time and attention.

Thanks for the update overall you've addressed all of it. One small thing for the license is that the first part of it says that you should literally have a file named LICENSE that contains the text of the license. So that people can know exactly what you're talking about.


Release 0.1.18

The more relevant changes in the new version are the following:

Added support for the expiration_timestamp attribute of the Cluster type.

FYI: @vkareh


What's the status/strategy of this project?

This is really a great project and thanks for making it available. But I wonder what the status is. Looking at it today it's 3k+ commits behind the plotly/dash project. How are we compatible with latest version dash? And what's the longer term strategy of this project? Thanks.

have the same question

This repo pops up when searching for websocket pushing strategies. It seems that subclassing app.callback is a bit heavier than subclassing Output.

Just wanted to update as a user not as a developer. I use this in my project, something i inherited. The new dash components are not compatible with the dash-devices. I don't remember off-hand which dash version is compatible with this project, but its the older dash version. (I think for my purpose, the latest stable dash is dash==1.19.0). I am in process of working around dash-devices to switch to newer dash compatibility.


todo review

-ToDo list was created dynamically with
html css and javascript.
it gets and stores data in the local storage
it removes data from the local storage when deleted
data are persistent after refresh.

Hi @emmanuelsteven , 👋
Good job so far 👏🏽!
There are some issues that I think you need to work on to make your code follow the the KISS pattern 💪


Proposal: add (optional) section on content-negotiation

The distribution spec currently does not describe active content negotiation, leaving it up to individual implementations whether (and how) content negotiation should be performed.
This proposal is still a draft, and many "blanks" to fill, but I thought I'd open it, to allow having a discussion on this topic.
1. "Problem" statement
Currently, the client is responsible for picking the right variant for multi-manifest ("multi arch") repositories. While this works well, it requires at multiple steps, and multiple requests to get the image manifest;

(GET /v2)
(optional) check if cache can be used: HEAD /v2/<name>/manifests/<reference>
fetch manifest-list: GET /v2/<name>/manifests/<reference>
(parse manifest-list and resolve digest for best match)
fetch image manifest: GET /v2/<name>/manifests/<DIGEST>
fetch blob: /v2/<name>/blobs/<digest> (repeat for each blob)

Content-negotiation can avoid multiple request, which could bring some performance improvements, and (if implemented by the registry), simplify logic in the client.
In addition, content-negotiation can assist in providing backward-compatibility (as outlined in the next section).
2. Existing uses of content-negotiation
Content negotiation is already in use by some registry implementations, such as Docker Hub (mostly for backward-compatibility). Here's some tests against docker hub;

Note: for formatting on GitHub, I removed application/vnd.docker.distribution prefixes for the content-types in the table below.

Accept
Multi?
Result
Notes

<not present>
:white_check_mark:
manifest.v1+prettyjws
v1, linux/amd64, for backward compatibility with old, non-v2 clients

*/*
:white_check_mark:
manifest.v1+prettyjws
v1, linux/amd64, for backward compatibility with old, non-v2 clients (same as above)

application/json
:white_check_mark:
manifest.v1+prettyjws
v1, linux/amd64, for backward compatibility with old, non-v2 clients (same as above)

manifest.v1+json
:white_check_mark:
manifest.v1+prettyjws
v1, matching Accept header (linux/amd64 for backward compatibility)

manifest.v2+json
:white_check_mark:
manifest.v2+json
v2, matching Accept header (linux/amd64 for backward compatibility)

manifest.list.v2+json
:white_check_mark:
manifest.list.v2+json
v2 manifest list, matching Accept header

manifest.list.v2+json, manifest.v2+json, manifest.v1+json
:white_check_mark:
manifest.list.v2+json
v2 manifest list, matching first Accept header

manifest.v2+json, manifest.list.v2+json, manifest.v1+json
:white_check_mark:
manifest.v2+json
:warning: prefers manifest list over manifest (ignoring order?)

<not present>
-
manifest.v1+prettyjws
same as multi-manifest repo

*/*
-
manifest.v1+prettyjws
same as multi-manifest repo

application/json
-
manifest.v1+prettyjws
same as multi-manifest repo

manifest.v1+json
-
manifest.v1+prettyjws
same as multi-manifest repo

manifest.v2+json
-
manifest.v2+json
same as multi-manifest repo

manifest.list.v2+json
-
manifest.list.v2+json
:warning: somewhat unexpected to return a v1 manifest for a v2-capable client

manifest.list.v2+json, manifest.v2+json, manifest.v1+json
-
manifest.list.v2+json
v2 manifest, matching first "acceptable" Accept header (by lack of a manifest-list)

manifest.v2+json, manifest.list.v2+json, manifest.v1+json
-
manifest.v2+json
v2 manifest, matching first "acceptable" Accept header (by lack of a manifest-list)

To try these (use repo library/hello-world for multi-manifest, and armhf/hello-world for single manifest);
export repo=library/hello-world

export token="$(curl -fsSL "https://auth.docker.io/token?service=registry.docker.io&scope=repository:${repo}:pull" | jq --raw-output '.token')";

curl -v -X HEAD -I -fsSL -H "Authorization: Bearer $token" \
    -H 'Accept: application/vnd.docker.distribution.manifest.v2+json' \
    -H 'Accept: application/vnd.docker.distribution.manifest.list.v2+json' \
    -H 'Accept: application/vnd.docker.distribution.manifest.v1+json' \
    "https://registry-1.docker.io/v2/${repo}/manifests/latest"

2.1. Omissions in current implementations
Besides some (edge) cases highlighted (:warning:) in the previous section, current implementations appear to have some omissions;

No Vary header is returned (rfc7231, section 7.14)
No 300 or 406 statuses are used

3. Proposal: server-side content-negotiation as optional feature
I suggest this feature to be OPTIONAL to keep backward compatibility with existing registries, and to facilitate static registries (which would not be able to perform server-side content negotiation).
Registries that do not perform content-negotiation, would return either;

a manifest-list for multi-arch repositories (allowing the client to select the best-matching variant)
a v2 manifest for v2 repositories
a v1 manifest for v1 repositories

3.1. Approaches to content-negotiation
Looking for recommendations, and "correct" approaches, I did some reading-up on the HTTP RFCs. From those, there are multiple alternatives, see (rfc7231, section 5.3 - "Content Negotiation", rfc7231, section 3.4.1 - "Proactive Negotiation", and rfc7231, section 3.4.2 - "Reactive Negotiation"), each with their respective "pros" and "cons".
3.2. "Proactive Negotiation" rfc7231, section 3.4.1
With proactive negotiation, the registry picks the most suitable variant, and in case no acceptable variant can be selected, can return a 406 Not Acceptable response, allowing the client to select the variant;
Proactive negotiation is advantageous when the algorithm for
selecting from among the available representations is difficult to
describe to a user agent, or when the server desires to send its
"best guess" to the user agent along with the first response (hoping
to avoid the round trip delay of a subsequent request if the "best
guess" is good enough for the user).  In order to improve the
server's guess, a user agent MAY send request header fields that
describe its preferences.

The RFC does come with some warnings (outlined under "Proactive negotiation has serious disadvantages" in the RFC), although not all of those would apply to the distribution-spec.
If no acceptable match is found, a 406 Not Acceptable (rfc7231, section 6.5.6) can be returned, as outlined in rfc7231, section 5.3.2
(...) If the header field is present in a request and none of the available
representations for the response have a media type that is listed as acceptable,
the origin server can either honor the header field by sending a 406 (Not
Acceptable) response or disregard the header field by treating the
response as if it is not subject to content negotiation.

Note current implementations that handle Content Negotiation do not return a 406 Not Acceptable (rfc7231, section 6.5.6) status if no acceptable alternative is found. Neither do they return a Vary header to indicate which request headers were considered during negotiation.

Despite the downsides mentioned, this variant;

addresses the "multiple requests"; a client can specify what variants are acceptable, and get the best match directly from the registry.
largely corresponds with current implementations that perform content-negotiations; the registry selects the variant to serve.

3.3. "Reactive Negotiation" rfc7231, section 3.4.2
This variant mostly matches the behavior of current registries that do not perform content negotiation, but offers slightly more "assistance":
With reactive negotiation (a.k.a., agent-driven negotiation),
selection of the best response representation (regardless of the
status code) is performed by the user agent after receiving an
initial response from the origin server that contains a list of
resources for alternative representations. (...)

The above roughly corresponds with the registry returning a manifest-list, although the spec seems to indicate the response can be both the actual content ("best manifest"), and a list of alternatives;
(...) If the user agent is not satisfied by the initial response representation,
it can perform a GET request on one or more of the alternative resources (...)

Reactive negotiation can return a 406 Not Acceptable (rfc7231, section 6.5.6)  or 300 Multiple Choices (rfc7231, section 6.4.1) response, the latter including a Location header with the "best alternative" as determined by the registry, and which  the client can respect. In both cases, the response body SHOULD return a list of alternatives. The spec is unclear what format this list should have, but in case of the registry spec, I think a "manifest-list" would fit this bill.
Reactive negotiation suffers from the disadvantages of transmitting a
list of alternatives to the user agent, which degrades user-perceived
latency if transmitted in the header section, and needing a second
request to obtain an alternate representation.  Furthermore, this
specification does not define a mechanism for supporting automatic
selection, though it does not prevent such a mechanism from being
developed as an extension.

Although this approach somewhat corresponds with the current distribution spec, there are differences, and points of attention;

Current implementation do not return 406 Not Acceptable  or 300 Multiple Choices responses
While the 300 Multiple Choices response has a Location header that the client MAY follow, there is a likely possibility that clients automatically follow the redirect.
If a client decides to accept the Location redirect, doing so may (should) strip authentication, making this not a good option.
As mentioned, this alternative does not bring the benefits of "Proactive Negotiation" (no reduction of requests).

4. Proposal/example: automatic platform selection (os, os-version, arch, variant)

Note: this part is written with images distributed through the registry in mind. With other content types becoming more common for distribution through OCI registries, similar proposals/approaches could be taken for other content.

A client can specify multiple variants that are acceptable, optionally with a "Quality" (q) parameter to indicate relative weight (see rfc7231, section 5.3.1 and rfc7231, section 5.3.2);

Note: rfc7231, section 5.3.2 mentions the q value not being "optional" in some cases.  For example platform=linux/arm/* and platform=linux/arm are equivalent ("any linux arm image").
Wildcards can also be useful for OS-versions, particularly for Windows images, which (lacking a stable Windows kernel API) come in variants specific to Kernel versions. Kernel stability has improved with recent versions of Windows, however, and should not be a problem when using "Hyper-V" isolation, in which case any kernel version could be acceptable for clients.
However, using the suggested string representation may require additional changes:

NOTE
While the image-spec defines the Platform descriptor, I don't think it currently specifies how the platform should be represented as a string. Currently, platforms are represented  as a JSON struct/map/object (pick your preferred name for this);
Windows image:
{
  "platform": {
    "architecture": "amd64",
    "os": "windows",
    "os.version": "10.0.17763.1577"
  }
}

Linux, ARM v5
{
  "platform": {
    "architecture": "arm",
    "os": "linux",
    "variant": "v5"
  }
}

As an alternative to the string representation, separate parameters could be provided for each property, for example:
Accept: application/vnd.docker.distribution.manifest.v2+json;platform.os=linux,platform.architecture=arm,platform.variant=v8

Omitting a property is equivalent to * (e.g. platform.variant=*)
5. Backward compatibility
(I think) This proposal would be backward-compatible with existing implementations that perform content-negotiation;

clients that want to perform client-side content-negotiation can explicitly request the manifest list (Accept: application/vnd.docker.distribution.manifest.list.v2+json), or put the manifest-list before the (v2) manifest in the list of Accept headers.
if a client does not send an Accept header, registries continue to select the "most appropriate" response (see "Backward compatibility (pre-v2 clients)" above)

5.1. Backward compatibility (v2 clients)
For backward-compatibility, clients MUST include a application/vnd.docker.distribution.manifest.list.v2+json and/or a application/vnd.docker.distribution.manifest.v2+json (without platform specification or q parameter) in the list, in order of preference. The platform and  q parameters must be omitted for compatibility with current implementations, which may not expect/handle these.
5.2. Backward compatibility (pre-v2 clients)
In case a registry supports both v1 and v2 manifests, and a client does not send an Accept header (or sends an Accept: */*), which would be the case for pre-v1 clients, the registry SHOULD return the oldest manifest type it supports (v1).
Or, as outlined in rfc7231, section 5.3.2
(...) A request without any Accept header field implies that the user agent
will accept any media type in response. (..)

and
(...) If the header field is present in a request and none of the available
representations for the response have a media type that is listed as acceptable,
the origin server can either honor the header field by sending a 406 (Not
Acceptable) response or disregard the header field by treating the
response as if it is not subject to content negotiation.

Hmm, I am not sure I see any reason for conneg in a content addressable store. It kind of makes sense for the old manifest formats, although arguably we should have used a different endpoint. A modern registry should only return what was uploaded, so there is no choice to negotiate.

@thaJeztah - I think this information is useful, but does not actually change the API defined in the spec (correct me if I'm wrong). It provides a useful framework of how one might leverage the API effectively.
Do you take any issue with scheduling this to be included in a 1.1.0 release?

@jdolitsky this is essentially my first point from https://github.com/opencontainers/distribution-spec/issues/211 described way more completely than I ever could have imagined.
As it stands, it's impossible to read this spec and write a client that works with Docker Hub (really, most registries), which seems pretty important.
Even if we don't want to do any content negotiation in this spec, we at least need to document something about this "legacy" (in quotes because AFAIK this is in prod for all major registries) content negotiation for 1.0.

Hmm, I am not sure I see any reason for conneg in a content addressable store

I agree that for /v2/<name>/manifests/<DIGEST> it doesn't make sense (that's content-addressable), but /v2/<name>/manifests/<TAG> is not content-addressable, and (I think) could do content-negotiation.

I think this information is useful, but does not actually change the API defined in the spec (correct me if I'm wrong). It provides a useful framework of how one might leverage the API effectively.

I see it as an optional extension to the API, but would help to improve interoperability, and define host registries can handle content negotiation (what dimensions (Accept headers, including parameters) should/can be used), and what fallbacks to implement for older clients (or how to respond to clients not sending Accept headers if they do implement content-negotiation).

I agree that for /v2/<name>/manifests/<DIGEST> it doesn't make sense (that's content-addressable), but /v2/<name>/manifests/<TAG> is not content-addressable, and (I think) could do content-negotiation.

I think this is a useful distinction to make. The original spec didn't speak to this at all, and I'm curious about the behavior for other registries. GCR will just 404 if you ask for a manifest by digest without the appropriate accept headers, which had led to some confusion. It would be nice to settle on an expected behavior here.
It also seems like not mentioning the Accept headers at all puts registries in a really weird spot:
A client author reading this spec will see no indication that they need to supply Accept headers, so they will be missing on manifest fetches. A registry that expects Accept headers so that it can support older clients will be non-conforming by returning a schema 1 manifest, and the client should (rightly, per the spec) complain about the registry. What is a registry maintainer to do? Do you drop support for older clients or not support newer clients?
It should be possible for a registry to implement both the docker spec and the OCI spec, and they are currently mutually exclusive (or the OCI spec is incomplete), per my reading.

While manifests are not strictly content addressable, they in effect are. Registries must not change them, there may be external signatures (eg Notary) that depend on the bits. Everything needs to be round tripped for this to work correctly, although we have not made this 100% clear in the spec (@stevvooe often says it though!). There is no sane way to support a tag that can Vary based on Accept now, this is purely legacy behaviour. Its actually really weird how some registries return you garbage generated manifests if you don't put the right Accept headers, and we need to phase this out.

So I had a brief chat with @tonistiigi yesterday, and of course he was able to punch a big gap in my idea w.r.t. content-negotiation for multi-arch (I hate it when he does that :joy:);
While it can be useful to get just the image/arch you're interested in for a specific request; performing content-negotiation on the registry has the downside that the "root" (manifest-list) is skipped. So while it would still be possible to verify (the digest of) that image-manifest, when consuming multiple architectures, it would not be possible to verify that those images are part of the same manifest-list. For example (simplified, trying to describe what I think the problem is with that);

pull image foo:latest (Accept: platform=linux/amd64)

content-negotiation -> resolves digest for linux/amd64 image manifest

(meanwhile) foo:latest manifest is updated; new versions for linux/amd64 and linux/armv7 are pushed
pull image foo:latest (Accept: platform=linux/armv7)

content-negotiation -> resolves digest for linux/armv7 image manifest

Now, while both images are valid, they were never part of the same manifest-list; in other words; they contain different versions of foo:latest, and because the manifest-list itself (the "root" of the tree) is skipped, it's not possible to detect that situation.
Of course this may not be an issue if you're only interested in a single arch, but (as mentioned), could also be an issue if the manifest-list itself is expected to be signed.
content-negotiation could still be interesting to store different artifact types in a repository (e.g., store helm-charts and images in the same namespace), although those could of course all be stored in a single manifest-list, and using content-negotiation to pull either one or the other would no longer make this an optional feature (and therefore exclude static registries).

While manifests are not strictly content addressable, they in effect are. Registries must not change them, there may be external signatures (eg Notary) that depend on the bits

Do you mean GET /v2/<name>/manifests/<TAG> should always return the same (effectively: immutable tags, so latest can never be updated)? Or do you mean "should not be rewritten, based on "accept" headers (or "user-agent")?

Its actually really weird how some registries return you garbage generated manifests if you don't put the right Accept headers, and we need to phase this out.

Which would mean: registries MUST NOT perform content-negotiation, which could be a valid outcome of this proposal/ticket as well
(possibly with an addendum for backward-compat? Not sure how/when it can be phased out).

Regarding Accept headers and general content-negotiation - can somebody summarize this in 200-300 words or less and suggest which section of the spec to put it in?
Alternatively, we can create some external content-negotiation.md and link to it from spec.md.
We are presented with a lot of (good) information here with no suggestion for how to proceed.

There is no sane way to support a tag that can Vary based on Accept now, this is purely legacy behaviour. Its actually really weird how some registries return you garbage generated manifests if you don't put the right Accept headers, and we need to phase this out.

Doesn't Docker Hub? And docker/distribution? GCR does this. I would expect that most registries do this.
I agree with you that we should phase this out. In my experience, this is the biggest stumbling point for people trying to interact with registries by far.
At the same time, not including this in the spec would dramatically reduce the usefulness of the spec until it really is phased out. Registries will probably continue to return schema 1 images if you don't supply the right Accept header unless we specifically require something in this spec about NOT doing content negotiation for OCI media types (or until every customer using an old version of docker has migrated).
I see that schema 1 was deprecated about a year ago in https://github.com/docker/distribution/pull/3000. Is that sufficient warning to break any clients relying on this behavior? With my client and registry maintainer hat on, I'm 100% in favor of no longer supporting schema 1 anywhere; but, if I put on my customer support hat, that would feel irresponsible.
I think I would be okay with this:

Acknowledge current behavior

Someone using this spec to write a client will be quite likely to encounter a docker v2 schema 2 image (you don't really know what's on the other side of a GET /v2/.../manifests/<tag>). Registries use only Accept headers to determine what they should do here. If the client doesn't supply the Accept header, it will receive a v2 schema 1 image. A client based on this spec will have no idea what to do with that, but would be able to handle either a v2 schema 2 image or a manifest list just fine.
At the very least, we should mention this in the GET manifest section and link to a backwards compatibility doc or the legacy spec.

Decide and document the behavior we want

Registries will be doing this content negotiation already. We should be explicit about what they should be doing for OCI compliance. For example, GCR will not do this conversion for artifacts uploaded with OCI media types; however, we do expect clients to provide these media types in their Accept headers, and will 404 if they are not present.
What is the correct behavior here?

I don't believe any new registry (ie one you create now, or indeed created in the last few years) needs to do any conneg at all, and should just be round tripping blobs as uploaded, regardless of any Accept headers. Existing registries should be able to start phasing this behaviour out I would think. It is mostly old Docker engines that would have issues, although some API clients that are not sending Accept headers now might get confused, looking at the stats on Docker Hub there are still small numbers of old clients but I rather suspect other registries have none, most are retrieving public images.

@justincormack just to confirm; in your view all clients should be required to understand manifest lists? (I think that's fair, I just want to be explicit).

@amouat I think the current practise of redirecting (well actually its not a redirect, that would be better) to the linux/amd64 version is pretty questionable yes, again there is backward compatibility issue but its not something that should be encouraged. If your client is not manifest list aware, you can still point it at the correct location via a different tag/sha. I don't know how many clients break on this (which versions?) but they will already not be working on Arm machines for example, so I don't see how this can be justified...

I've opened https://github.com/opencontainers/distribution-spec/pull/218, adding a new "content-negotation.md" linking to this issue. I think this doc can be updated over time

does this proposal have to be resolved before a 1.0.0?

does this proposal have to be resolved before a 1.0.0?

Looks like I LGTM'd https://github.com/opencontainers/distribution-spec/blob/main/content-negotiation.md but we might want to make this more "OCI specific". the "manifest.v1" refers to the docker schema1 manifest and that's not entirely clear.
How realistic is it to deprecate schema1 at this point? From there, pulls by tag can down convert if a manifest is requested by tag.

Looks like I LGTM'd https://github.com/opencontainers/distribution-spec/blob/main/content-negotiation.md but we might want to make this more "OCI specific". the "manifest.v1" refers to the docker schema1 manifest and that's not entirely clear.
How realistic is it to deprecate schema1 at this point? From there, pulls by tag can down convert if a manifest is requested by tag.

Does that need to be reverted before the 1.1 final release?


manin_3_feb>python -m pip install -r requirements.txt problem

The command generates a lot of errors

Remove pycairo in the requirements file, see my tutorial on YouTube.

Thanks


doc(basics): fix typo

@massimocode Thank you for contributing this pull request! We're truly excited and honored to have you as a member of our community. We look forward to working together with you to further build the Aurelia platform.
We noticed that you haven't yet signed our CLA. We would appreciate it if you would consider doing that for us. Before signing, please take a few minutes to read our contributing guidelines. These guidelines will help get you up to speed on how our community likes to operate and how the pull request process works. Once you have read that, assuming you are in agreement, simply sign our online CLA.
After you've signed, please ping this issue to let us know and we'll get your improvements merged in.
Thank you again!
The Aurelia Team

Hi Rob, I've signed the CLA and reworded the commit messages as per the CLA. Thanks!

Thanks!


retire the connection ID sent in the preferred_address transport parameter

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@7fbf539). Click here to learn what that means.
The diff coverage is 96.08%.

@@            Coverage Diff            @@
##             master    #2251   +/-   ##
=========================================
  Coverage          ?   86.49%
=========================================
  Files             ?      106
  Lines             ?     7841
  Branches          ?        0
=========================================
  Hits              ?     6782
  Misses            ?      795
  Partials          ?      264

Impacted Files
Coverage Δ

internal/handshake/transport_parameters.go
97.09% <96.08%> (ø)

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 7fbf539...ccb518c. Read the comment docs.


My v4 dev

It just draft

@Josephpaik Could you please change the target to v4-dev, add a title and a description?


Move to Netty5 package names

Motivation:
Use the latest Netty 5 binaries.
Modifications:
Move to Netty 5 package names
Result:
Use the latest Netty 5 binaries.

@violetagg Can you try rebasing and see if that gets you a PR build started?

@violetagg Can you try rebasing and see if that gets you a PR build started?

sure ... done


fix [EMI-1820]: do not add purchase button for inactive offers

Believe it should be good to rely on offer 'isActive' as it seems to be updated properly when the works become unavailable.

Merging this.


hmtx.lsb sometimes is off by one unit

I noticed that, in fonts generated by fontmake, sometimes the left sidebearing of some glyphs is smaller by one unit than what I should be, and by "should" I mean the xMin coordinate in the glyph.
When that happens, the bit 1 of the head table flags is turned off by fonttools, because not all glyphs in the font have the left sidebearings equal to the respective xMin.
The problem is that ufo2ft is using math.floor instead of round when setting the left sidebearing in the hmtx table:
https://github.com/googlei18n/ufo2ft/commit/a1ee5514
It turns out that, when removing overlaps with booleanOperations, coordinates may be converted from int to float even though they remain exactly as they were, well almost the same, e.g. they may go from 12 to 11.9999999999999. The loss of precision is probably due to the fact that they are scaled before being sent to pyclipper, and then the result is scaled again.
Now, when we give to math.floor such a value, that is going to return 11. But we know that the value was really a 12, and in fact the xMin coordinate in the glyf table for that glyph will be 12,
In TTF, coordinates are always rounded to integers, and we currently do that inside the fonttools ttGlyphPen.
In CFF, coordinates may be floats, though currently fontmake-generated fonts are always rounded. Fonttools added support for a round tolerance in t2CharStringPen, but support for this hasn't been added to ufo2ft and fontmake yet.
I think that if we want the lsb to always be the same as the xMin, we need to use the same round function that we use to round the coordinates.
Otherwise we end up with lsb which may not match the xMin values in the glyf table, and the head flag 1 being turned on/off in a seemingly random fashion.
Comments?

Sounds very reasonable, as far as I can tell.

Done in #118


refactored if else statements for clarity and less checks

refactored unorganized if else statements mainly to reduce the number of comparisons that occur (useless to check some conditions if the first is not met). And also for clarity

@smithneo100 My goal of this pull request is mainly to improve readability, so future developers can easily handle different conditions separately, which improves scalability and facilitates future development. Should I merge it like this ?

@jaykay99992 The main goal is readability and you believe that the current structure of your code achieves that while still being efficient and maintainable, then you can consider merging it.

Code merged


FR: React-native support for Alchemy Signer

Is your feature request related to a problem? Please describe.
At present, there is no official support for Alchemy Signer in the React Native application. It requires a web environment to embed an iframe or I'm missing something?
When I tried to add AlchemyAccountProvider from @alchemy/aa-alchemy/react package I received an error indicating the absence of the document object, due to the lack of a DOM tree on RN application.
I also tried this without any results (no way to render iframe)
Describe the solution you would like
Add support for different way for render Turnkey component?
Describe alternatives you have considered
__
Additional context
I want to use embedded account with email sign in, I know it's working with pk/mnemonic.

we're exploring making the signer RN compatible at the moment


vanilla Client assumes that arguments have been preprocessed by GetOpts

https://github.com/nicolodavis/boardgame.io/blob/master/src/client/client.js#L219
This prevents it from being used directly with local multiplayer (useful in unit tests).

A unit test (after fixing the above) currently looks like this:
  const client = Client({
    game: Game({
      moves: {
        A: (G, ctx, arg) => ({ arg }),
      },
    }),
    multiplayer: { local: true },
  });

  await client.updatePlayerID('0');
  await client.connect();

  expect(client.getState().G).toEqual({});
  client.moves.A(42);
  expect(client.getState().G).toEqual({ arg: 42 });

Perhaps we should bundle in a test-friendly client that is able to switch players more seamlessly without needing to call connect each time.

Fixed (https://github.com/nicolodavis/boardgame.io/commit/9d11d6201770a2cb5b523fb77690c5021d2ce7d1).


Remove unnecessary lines in testcase

Purpose
Remove unnecessary lines in testcase
Goals

Describe the solutions that this feature/fix will introduce to resolve the problems described above

Approach

Describe how you are implementing the solutions. Include an animated GIF or screenshot if the change affects the UI (email<EMAIL_ADDRESS>to review all UI text). Include a link to a Markdown file or Google doc if the feature write-up is too long to paste here.

Release note

Brief description of the new feature or bug fix as it will appear in the release notes

Documentation

Link(s) to product documentation that addresses the changes of this PR. If no doc impact, enter “N/A” plus brief explanation of why there’s no doc impact

Automation tests

Unit tests

Code coverage information

Integration tests

Details about the test cases and coverage

Security checks

Followed secure coding standards in http://wso2.com/technical-reports/wso2-secure-engineering-guidelines? yes
Ran FindSecurityBugs plugin and verified report? yes
Confirmed that this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets? yes

Samples

Provide high-level details about the samples related to this feature

Related PRs

List any other related PRs

Test environment

List all JDK versions, operating systems, databases, and browser/versions on which this feature/fix was tested

Codecov Report

Merging #1273 into master will decrease coverage by 0.02%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #1273      +/-   ##
============================================
- Coverage     62.04%   62.02%   -0.03%
  Complexity       35       35
============================================
  Files           619      619
  Lines         24941    24941
  Branches       3909     3909
============================================
- Hits          15475    15470       -5
- Misses         8172     8176       +4
- Partials       1294     1295       +1

Impacted Files
Coverage Δ
Complexity Δ

.../siddhi/core/util/event/handler/StreamHandler.java
62% <0%> (-12%)
0% <0%> (ø)

...e/src/main/java/io/siddhi/core/util/Scheduler.java
81.41% <0%> (-1.29%)
0% <0%> (ø)

...c/main/java/io/siddhi/core/util/ThreadBarrier.java
100% <0%> (+20%)
0% <0%> (ø)
:arrow_down:

Continue to review full report at Codecov.

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


prerender build file size is higher then build generate

Environment
------------------------------
- Operating System: Darwin
- Node Version:     v20.17.0
- Nuxt Version:     3.13.2
- CLI Version:      3.14.0
- Nitro Version:    2.9.7
- Package Manager<EMAIL_ADDRESS>- Builder:          -
- User Config:      -
- Runtime Modules:  -
- Build Modules:    -
------------------------------

Reproduction
I had impression that if i set on my pages to prerender that it will build static files like it does with generate?
But inspecting in browser the response resource size is higher basically same as if i did not provide any routeRules options
nuxt build && nuxt preview

nuxt generate && nuxt preview

Describe the bug
Repo: https://github.com/MariuzM/test__nuxt/tree/main
Additional context
No response
Logs
No response

i’m not sure what the issue is you are highlighting? are you saying that the JS files are a different size?

When setting to prerender i was expecting nuxt to build static files because my impression that this is what it does, no?
So i compared to nuxt generate where it builds those static files and size is different


Force HTML & JS refresh

Am currently working on a project that uses a webview that carries a heavy (arguably too heavy) load of JS and HTML. When I'm making JS & HTML changes I'm forced to completely uninstall the app to see the newest changes. Is there a way to ignore cached (?) version and always pull from directory? The HTML & JS used is pulled in locally - none of them are pulled over http.
<WebViewBridge
        ref="webviewbridge"
        onBridgeMessage={this.onBridgeMessage.bind(this)}
        source={require("../../webview/my_project.html")}/>```

The problem probably stems from using the CommonJS require. While I'm not too familiar with it myself, the module loader has an internal cache and is intended either for static files or JS modules in RN, I'm not sure how it handles loading arbitrary files like this.


TypeError: i is undefined

Describe the bug
To Reproduce
Expected behavior
Screenshots
Applicable Versions:

Netlify CMS version<EMAIL_ADDRESS>Git provider: git-gateway
Browser version: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0

CMS configuration
backend:
  name: git-gateway
  branch: master
  commit_messages:
    create: Create {{collection}} “{{slug}}”
    update: Update {{collection}} “{{slug}}”
    delete: Delete {{collection}} “{{slug}}”
    uploadMedia: "[skip ci] Upload “{{path}}”"
    deleteMedia: "[skip ci] Delete “{{path}}”"
media_folder: static/img
public_folder: /img
collections:
  - name: work
    label: Work
    folder: src/pages/work
    create: true
    fields:
      - label: Template Key
        name: templateKey
        widget: hidden
        default: work-post
      - label: Title
        name: title
        widget: markdown
      - label: Publish Date
        name: date
        widget: datetime
        hide: true
      - label: Description
        name: description
        widget: markdown
      - label: Featured Image
        name: featuredimage
        widget: image
      - label: Background Color
        name: color
        widget: color
    publish: true
    type: folder_based_collection
    sortable_fields:
      - commit_date
      - date
      - commit_author
      - description
    view_filters: []
    view_groups: []
  - name: pages
    label: Pages
    files:
      - file: src/pages/index.md
        label: Landing Page
        name: index
        fields:
          - label: Template Key
            name: templateKey
            widget: hidden
            default: index-page
          - label: Image
            name: image
            widget: image
      - file: src/pages/info/index.md
        label: Info Page
        name: info
        fields:
          - label: Template Key
            name: templateKey
            widget: hidden
            default: info-page
          - label: Contact
            name: contact
            widget: markdown
          - label: About
            name: about
            widget: markdown
          - label: CV
            name: cv
            widget: markdown
          - label: image
            name: image
            widget: image
    publish: true
    type: file_based_collection
    sortable_fields:
      - commit_date
      - commit_author
    view_filters: []
    view_groups: []
publish_mode: simple
slug:
  encoding: unicode
  clean_accents: false
  sanitize_replacement: "-"
isFetching: false
error: null

Additional context

Hi @johnshlee1, can you provide a reproduction scenario per our issue template https://github.com/netlify/netlify-cms/issues/new?assignees=&labels=type%3A+bug&template=bug_report.md&title=Please+replace+with+a+clear+and+descriptive+title