BUG: DataFrame.describe() breaks with numeric columns and a column index of object type

Preparing a commit for another issue in .describe(), I encountered this puzzling bug, surprisingly easy to trigger.
Symptoms
df = pd.DataFrame({'A': list("BCDE"), 0: [1,2,3,4]})
df.describe()
# Long traceback listing formatting and internal functions...
ValueError: Buffer dtype mismatch, expected 'Python object' but got 'long'

However:
df.describe(include='all')
               0    A
count   4.000000    4
unique       NaN    4
top          NaN    D
freq         NaN    1
mean    2.500000  NaN
std     1.290994  NaN
min     1.000000  NaN
25%     1.750000  NaN
50%     2.500000  NaN
75%     3.250000  NaN
max     4.000000  NaN

# It's OK if we don't print on screen:
x = df.describe()
x.columns
Out[8]: Index([0], dtype='int64')

# Fixing this suspicious index (int works too):
x.columns = x.columns.astype(object)
x
Out[10]:
              0
count  4.000000
mean   2.500000
std    1.290994
min    1.000000
25%    1.750000
50%    2.500000
75%    3.250000
max    4.000000

Same issue happens with a simpler data frame:
df0 = pd.DataFrame([1,2,3,4])
# It's  OK now
df0.describe()
Out[28]:
              0
count  4.000000
mean   2.500000
std    1.290994
min    1.000000
25%    1.750000
50%    2.500000
75%    3.250000
max    4.000000

# Modify column index:
df0.columns = pd.Index([0], dtype=object)
df0.describe()
# ...
ValueError: Buffer dtype mismatch, expected 'Python object' but got 'long'

Current version (but the bug is also present in pandas release 0.18.1):
pd.show_versions()

INSTALLED VERSIONS
------------------
commit: None
python: 3.5.1.final.0
python-bits: 64
OS: Linux
OS-release: 4.1.20-1
machine: x86_64
processor<EMAIL_ADDRESS>byteorder: little
LC_ALL: None
LANG: en_US.UTF-8

pandas: 0.18.1+64.g7ed22fe.dirty
nose: 1.3.7
pip: 8.1.2
setuptools: 21.0.0
Cython: 0.24
numpy: 1.11.0
scipy: 0.17.0.dev0+3f3c371
IPython: 4.0.1
...

Reason
Some internal function gets confused by dtypes of a column index, I guess. But the faulty index is created in .describe().
# Output from %debug df.describe()
# NDFrame.describe() in pandas/core/generic.py:
#
   4943             data = self
   4944         else:
   4945             data = self.select_dtypes(include=include, exclude=exclude)
   4946
   4947         ldesc = [describe_1d(s, percentiles) for _, s in data.iteritems()]
   4948         # set a convenient order for rows
   4949         names = []
   4950         ldesc_indexes = sorted([x.index for x in ldesc], key=len)
   4951         for idxnames in ldesc_indexes:
   4952             for name in idxnames:
   4953                 if name not in names:
   4954                     names.append(name)
   4955
   4956         d = pd.concat(ldesc, join_axes=pd.Index([names]), axis=1)
1> 4957         d.columns = self.columns._shallow_copy(values=d.columns.values)
   4958         d.columns.names = data.columns.names
   4959         return d

_shallow_copy() in the marked line changes d.columns:
ipdb> p d.columns
Int64Index([0], dtype='int64')
ipdb> n
> /home/users/piotr/workspace/pandas-pijucha/pandas/core/generic.py(4958)describe()
1  4957         d.columns = self.columns._shallow_copy(values=d.columns.values)
-> 4958         d.columns.names = data.columns.names
   4959         return d
ipdb> p d.columns
Index([0], dtype='int64')

Possible solutions
Lines 4957-4958 are actually used to fix issues that pd.concat brings about. They try to pass the column structure from self to d.
I think a simpler solution is replacing these lines with:
 d = pd.concat(ldesc, join_axes=pd.Index([names]), axis=1)
 d.columns = data.columns
 return d

or
d = pd.DataFrame(pd.concat(ldesc, axis=1), index = pd.Index(names), columns = data.columns)
return d

data is a subframe of self and retains the same column structure.
pd.concat has some parameters that help pass a hierarchical index but can't do anything on its own with a categorical one.
I'm going to submit a pull request with this fix together with some others related with describe(). I hope I haven't overlooked anything obvious. But if so, any comments are very welcome.

simple enough to stringify columns.

https://github.com/pydata/pandas/blob/master/pandas/core/generic.py#L4957
should be
d.columns = Index(d.columns, dtype='object')

Separately, this violates our guarantees on Index creation. I think we should assert that the dtype of a create Index is object if its not a sub-class.
@sinhrks
In [2]: i = Index([0,'A'])

In [3]: i._shallow_copy([0])
Out[3]: Index([0], dtype='int64')

Not sure if I understand. Don't we want d.columns to be of the same type as self.columns?

The trouble is the columns are split up by dtype, so the sub-indexes need to be constructed similarly. ._shallow_copy is an internal (to Index) method and should not be used here.
actually you don't even need to specify the dtype, I think
```d.columns = d.columns.copy()will prob work here. The problem is.values`` converts to a base form which may change things (e.g. try this with a datetime for the columns and see what happens).

Oh, you mean
d.columns = data.columns.copy()    #(1)

and earlier
d.columns = Index(data.columns, dtype='object').  #(2)

(1) does work. Or at least it passes tests from the repository plus some others I tried. (Actually, I ran nosetests with d.columns = data.columns but it shouldn't make a difference I guess.)
On the other hand, (2) fails with datetime64[ns] in columns. When I specify dtype=data.columns.dtype, it breaks with localized datetime.
My understanding is that since data = self.loc[bool_arr], then data.columns is just a subset of the original column index and preserves its structure (including dtype and dtypes of its elements). So, why not just simply pass/copy it to d.
Another advantage of (1) is that we can skip the next line
d.columns.names = data.columns.names

yeah (2) is not what we want, we don't need to coerce. so use (1). This was using some internal code which it shouldn't have. (Index has a public API and we try to use whenever possible, except when deeply needed). The reason is that there are certain guarantees, which in this case were violated (the separate issue I opened).

@jreback Thanks for clarifying.


vsdbg-ui Crash With No Information

Please paste the output from your clipboard: OK, now that is a cool "reporting" feature!
Issue Description
I've been having vsdbg-ui crashing occasionally but with no usable stack trace.
I saw https://github.com/OmniSharp/omnisharp-vscode/wiki/Diagnosting-'Debug-adapter-process-has-terminated-unexpectedly' which doesn't have information for linux, but I know a little about using "coredumpctl".
I've got ~18 entries for vsdbg-ui and the most I get from those is a Signal 11 (SEGV):
Process 18473 (vsdbg-ui) of user 1000 dumped core.

                Stack trace of thread 19320:
                #0  0x0000000700000000 n/a (n/a)

Steps to Reproduce
Even though it supposedly crashed 18 times, I haven't yet noticed what I did when it happened.

I wouldn't be able to switch windows or minimize or anything.
I was just working on a "Web/Empty" project and also had another instance of vscode open to work on the browser debugging of javascript.
Yes, I know about "serverReadyAction", but there's issues that shouldn't be delved into on top of this issue.
Expected Behavior
Actual Behavior
Logs
I'd love to provide some usable logs, but seem to have none, other than what I mention here.
I found the vsdbg-ui command and saw it has parameters:
--engineLogging: Log communications to /home/username/vsdbg-ui.log.
--consoleLogging: Log communications console.

That file doesn't exist and and I don't know how I would go about setting the parameters when it's already running in vscode.
OmniSharp log
Post the output from Output-->OmniSharp log here
I've got "omnisharp.loggingLevel": "trace" set and I don't think you want all of that output.
There is no stack information found in there.
C# log
Post the output from Output-->C# here
There is literally nothing in here.
The option is there, but there is no actual output.
Environment information
VSCode version: 1.38.0-insider
C# Extension: 1.21.1
Mono Information
        OmniSharp using built-in mono
Dotnet Information
.NET Core SDK (reflecting any global.json):
 Version:   3.0.100-preview8-013656
 Commit:    8bf06ffc8d
Runtime Environment:
OS Name:     arch
OS Version:
OS Platform: Linux
RID:         linux-x64
Base Path:   /opt/dotnet/sdk/3.0.100-preview8-013656/
Host (useful for support):
Version: 3.0.0-preview8-28405-07
Commit:  d01b2fb7bc
.NET Core SDKs installed:
2.2.105 [/opt/dotnet/sdk]
3.0.100-preview6-012264 [/opt/dotnet/sdk]
3.0.100-preview8-013656 [/opt/dotnet/sdk]
.NET Core runtimes installed:
Microsoft.AspNetCore.App 3.0.0-preview6.19307.2 [/opt/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.0.0-preview8.19405.7 [/opt/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.2.3 [/opt/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.0.0-preview6-27804-01 [/opt/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 3.0.0-preview8-28405-07 [/opt/dotnet/shared/Microsoft.NETCore.App]
To install additional .NET Core runtimes or SDKs:
https://aka.ms/dotnet-download

Visual Studio Code Extensions

Extension
Author
Version

arm
dan-c-underwood
0.3.0

cortex-debug
marus25
0.3.0

cortex-debug-dp-stm32f1
marus25
1.0.0

cortex-debug-dp-stm32f4
marus25
1.0.0

cpptools
ms-vscode
0.24.1

csharp
ms-vscode
1.21.1

debug
webfreak
0.23.1

debugger-for-chrome
msjsdiag
4.11.7

Doxygen
bbenoist
1.0.0

html-snippets
abusaidm
0.2.1

ilspy-vscode
icsharpcode
0.7.5

linkerscript
ZixuanWang
1.0.0

msbuild-project-tools
tintoy
0.2.55

mssql
ms-mssql
1.5.0

riscv
zhwu95
0.0.4

view-in-browser
qinjia
0.0.5

vscode-eslint
dbaeumer
1.9.1

vscode-nuget-package-manager
jmrog
1.1.6

vscode-solution-explorer
fernandoescolar
0.3.1

xml
DotJoshJohnson
2.4.0

@vindicatorr Thanks for the report! I am actually not sure why a segv would cause system unresponsiveness except maybe if your computer was busy writing out a coredump? So it might not be related to that. If you want to email me (greggm at microsoft.com) a private link to the coredump (ex: Drop Box, OneDrive, etc) I can try to poke around and see if there is any better hint as to what the problem might me.
Here are instructions for turning on debugger logs: logging

I would agree with coredump making my system busy.
Hopefully you got my email from before.
I tried to get it to crash while using the "Full method", but it just wouldn't.
I went back to the normal "Quick Method" and left it up and running, but never did any actual programming for most of the day.

Today, I had gone back to the "Full method" and spent the whole day programming with 3 instances of vscode open (1: CLI, 2: web server, 3: javascript/browser). I made changes in all of them, but there was just no crash.
Oh, also mind you that when I say "crash", vscode remains open even though vsdbg-ui crashes and get a memory dump.

Just putting it out there that this issue is still around. I just hadn't been doing any dev work in quite awhile.
The same scenario of no-crashing using the full-method, and sigsegv-11 using the quick-method.
Using the quick-method, I went ahead and started an instance, loaded the page, and copied the output to a notepad.
Then I put a "*****" delimiter/separator so I could easily find the end/start of sections, rebuilt and restarted and reloaded the page and caused a sigsegv:
...
<- (E) {"seq":314,"type":"event","event":"output","body":{"category":"stdout","output":"Microsoft.Hosting.Lifetime: Information: Hosting environment: Development\n"}}
Microsoft.Hosting.Lifetime: Information: Hosting environment: Development
<- (E) {"seq":315,"type":"event","event":"output","body":{"category":"stdout","output":"\u001B[40m\u001B[32minfo\u001B[39m\u001B[22m\u001B[49m: Microsoft.Hosting.Lifetime[0]\n"}}
info: Microsoft.Hosting.Lifetime[0]
<- (E) {"seq":316,"type":"event","event":"output","body":{"category":"stdout","output":"      Content root path: /home/<pathTo>/RazorWebApp\n"}}
      Content root path: /home/<pathTo>/RazorWebApp
<- (E) {"seq":317,"type":"event","event":"output","body":{"category":"stdout","output":"Microsoft.Hosting.Lifetime: Information: Content root path: /home/<pathTo>/RazorWebApp\n"}}
Microsoft.Hosting.Lifetime: Information: Content root path: /home/<pathTo>/RazorWebApp
*****
-> (C) {"command":"disconnect","arguments":{"restart":true},"type":"request","seq":17}
<- (E) {"seq":340,"type":"event","event":"output","body":{"category":"console","output":"The program '[3077169] RazorWebApp.dll' has exited with code 0 (0x0).\n"}}
The program '[3077169] RazorWebApp.dll' has exited with code 0 (0x0).
<- (E) {"seq":341,"type":"event","event":"exited","body":{"exitCode":0}}
<- (E) {"seq":342,"type":"event","event":"terminated","body":{}}
<- (E) {"seq":343,"type":"event","event":"output","body":{"category":"telemetry","output":"VS/Diagnostics/Debugger/vsdbg/DebugCompleted","data":{"VS.Diagnostics.Debugger.vsdbg.AdapterId":"coreclr","VS.Diagnostics.Debugger.vsdbg.DebugCompleted.BreakCounter":0,"VS.Diagnostics.Debugger.vsdbg.Distribution.Name":"arch","VS.Diagnostics.Debugger.vsdbg.OSFamily":"Linux","VS.Diagnostics.Debugger.vsdbg.Version":"16.5.20117.1 commit:2a72eb2aadc6bc6a29b05ebcc642a2699007df45"}}}
<- (R) {"seq":344,"type":"response","request_seq":17,"success":true,"command":"disconnect"}
-> (C) {"command":"initialize","arguments":{"clientID":"vscode","clientName":"Visual Studio Code - Insiders","adapterID":"coreclr","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en-us","supportsProgressReporting":true},"type":"request","seq":1}
-> (C) {"command":"launch","arguments":{"name":".NET Core Launch (web)","type":"coreclr","request":"launch","preLaunchTask":"build webapp","program":"/home/<pathTo>/RazorWebApp/bin/Debug/netcoreapp5.0/RazorWebApp.dll","args":[],"cwd":"/home/<pathTo>/RazorWebApp","stopAtEntry":false,"env":{"ASPNETCORE_ENVIRONMENT":"Development","ASPNETCORE_URLS":"https://localhost:5001;http://localhost:5000"},"sourceFileMap":{"/Views":"/home/<pathTo>/Views"},"logging":{"engineLogging":false},"internalConsoleOptions":"openOnSessionStart","__sessionId":"3e799715-2304-459c-b490-5fcc4b447c93"},"type":"request","seq":2}
<- (E) {"seq":3,"type":"event","event":"output","body":{"category":"console","output":"-------------------------------------------------------------------\nYou may only use the Microsoft .NET Core Debugger (vsdbg) with\nVisual Studio Code, Visual Studio or Visual Studio for Mac software\nto help you develop and test your applications.\n-------------------------------------------------------------------\n"}}
-------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (vsdbg) with
Visual Studio Code, Visual Studio or Visual Studio for Mac software
to help you develop and test your applications.
-------------------------------------------------------------------
<- (R) {"seq":4,"type":"response","request_seq":2,"success":true,"command":"launch"}
...

While I don't know what I'd be looking for, I'm not seeing any error/failure/crash standing out in the log.
I DID also notice that it wasn't just sigsegv, but that is BY FAR the most prevalent. There was also signal-6 (sigiot):
       Message: Process 3070873 (vsdbg-ui) of user 1000 dumped core.

                Stack trace of thread 3070873:
                #0  0x00007beab43e5ce5 raise (libc.so.6 + 0x3bce5)
                #1  0x00007beab43cf857 abort (libc.so.6 + 0x25857)
                #2  0x00007beab44292b0 __libc_message (libc.so.6 + 0x7f2b0)
                #3  0x00007beab443074a malloc_printerr (libc.so.6 + 0x8674a)
                #4  0x00007beab4432662 _int_free (libc.so.6 + 0x88662)
                #5  0x00007beab43e85e3 __run_exit_handlers (libc.so.6 + 0x3e5e3)
                #6  0x00007beab43e86ee exit (libc.so.6 + 0x3e6ee)
                #7  0x00007beab43d102a __libc_start_main (libc.so.6 + 0x2702a)
                #8  0x000000000040194b n/a (/home/username/.vscode-insiders/extensions/ms-dotnettools.csharp-1.21.17/.debugger/vsdbg-ui + 0x194b)

I noticed my OP mentioned it happens for web projects and that's still the same this time. I don't recall if it happens when dealing with console projects.

I FINALLY caught a coredump (sort of, aborted) using the full-method.
It was probably a fluke and I couldn't tell you the cause. I just started to run my program (which I've done many times before) that I'm working through, and it just hung up (didn't hit any breakpoints).
So I tried to start it again, but all I saw was the small cycling progress bar, but it never ran.
I noticed my system was sluggish, so I looked into the cause for that and saw the coredump happening.
Then I looked at my vsdbg full-method (vsdbg-ui --server), to see if anything was in there (never was before) and I saw:
...
>> accepted connection from client
>> client connection closed
>> accepted connection from client
Unhandled exception. System.ArgumentNullException: Value cannot be null. (Parameter 'key')
   at System.Collections.Generic.Dictionary`2.TryInsert(TKey key, TValue value, InsertionBehavior behavior)
   at Ilrun.AbstractObjectSlot.SetField(Slot value, FieldInfo field)
   at Ilrun.MscorlibHooks.System_Array.InternalGetReference(VirtualMachine vm, MethodBase method, CallArgs args)
   at Ilrun.VirtualMachine2.ExecuteHookedMethod(HookedMethod hook, CallArgs args)
   at Ilrun.VirtualMachine2.ForwardLoop()
   at Ilrun.VirtualMachine2.RunForward()
   at Ilrun.VirtualMachine2.ExecuteMethodInternal(MethodBase method, CallArgs args, IVirtualStackFrame inspectionFrame)
   at Ilrun.VirtualMachine2.ExecuteMethod(MethodBase method, CallArgs args)
   at Microsoft.VisualStudio.VIL.VisualStudioHost.VilEvaluationServices.EvaluateToString(DkmInspectionContext inspectionContext, VilEvaluationResult evalResult)
   at Microsoft.VisualStudio.Debugger.EntryPoint.IDkmClrValueInspectionCallback_EvaluateToString(IntPtr pvClassInfo, IntPtr ClrValue, IntPtr InspectionContext, IntPtr& Result)
   at Microsoft.VisualStudio.Debugger.Evaluation.ClrCompilation.NativeDkmClrValue.Proc3AF35B63B30CFA5A1D212BEE27AC26D5(IntPtr pThis, IntPtr InspectionContext, IntPtr& Result)
   at Microsoft.VisualStudio.Debugger.Evaluation.ClrCompilation.DkmClrValue.EvaluateToString(DkmInspectionContext InspectionContext)
   at Microsoft.CodeAnalysis.ExpressionEvaluator.Formatter.GetValueString(DkmClrValue value, DkmInspectionContext inspectionContext, ObjectDisplayOptions options, GetValueFlags flags)
   at Microsoft.VisualStudio.Debugger.EntryPoint.IDkmClrFormatter_GetValueString(IntPtr pvClassInfo, IntPtr ClrValue, IntPtr InspectionContext, IntPtr FormatSpecifiers, IntPtr& ValueString)
   at Microsoft.VisualStudio.Debugger.Evaluation.ClrCompilation.NativeDkmClrValue.Proc6C4DE7505B979C71E3E02EB952475CC3(IntPtr pThis, IntPtr InspectionContext, IntPtr FormatSpecifiers, IntPtr& ValueString)
   at Microsoft.VisualStudio.Debugger.Evaluation.ClrCompilation.DkmClrValue.GetValueString(DkmInspectionContext InspectionContext, ReadOnlyCollection`1 FormatSpecifiers)
   at Microsoft.CodeAnalysis.ExpressionEvaluator.ResultProvider.GetResult(DkmInspectionContext inspectionContext, EvalResult result, DkmClrType declaredType, DkmClrCustomTypeInfo declaredTypeInfo, String displayName, String displayValue, String displayType, Boolean useDebuggerDisplay)
   at Microsoft.CodeAnalysis.ExpressionEvaluator.ResultProvider.GetResultAndContinue(EvalResult result, WorkList workList, DkmClrType declaredType, DkmClrCustomTypeInfo declaredTypeInfo, DkmInspectionContext inspectionContext, Boolean useDebuggerDisplay, CompletionRoutine`1 completionRoutine)
   at Microsoft.CodeAnalysis.ExpressionEvaluator.ResultProvider.GetRootResultAndContinue(DkmClrValue value, WorkList workList, DkmClrType declaredType, DkmClrCustomTypeInfo declaredTypeInfo, DkmInspectionContext inspectionContext, String name, String fullName, ReadOnlyCollection`1 formatSpecifiers, CompletionRoutine`1 completionRoutine)
   at Microsoft.CodeAnalysis.ExpressionEvaluator.ResultProvider.<>c__DisplayClass7_0.<Microsoft.VisualStudio.Debugger.ComponentInterfaces.IDkmClrResultProvider.GetResult>b__1()
   at Microsoft.CodeAnalysis.ExpressionEvaluator.ResultProvider.WorkList.Execute()
Fatal error. Internal CLR error. (0x80131506)
   at Microsoft.VisualStudio.Debugger.Evaluation.ClrCompilation.NativeDkmClrValue.Proc3AF35B63B30CFA5A1D212BEE27AC26D5(IntPtr, IntPtr, IntPtr ByRef)
   at Microsoft.VisualStudio.Debugger.Evaluation.ClrCompilation.NativeDkmClrValue.Proc3AF35B63B30CFA5A1D212BEE27AC26D5(IntPtr, IntPtr, IntPtr ByRef)
   at Microsoft.VisualStudio.Debugger.Evaluation.ClrCompilation.DkmClrValue.EvaluateToString(Microsoft.VisualStudio.Debugger.Evaluation.DkmInspectionContext)
   at Microsoft.CodeAnalysis.ExpressionEvaluator.Formatter.GetValueString(Microsoft.VisualStudio.Debugger.Evaluation.ClrCompilation.DkmClrValue, Microsoft.VisualStudio.Debugger.Evaluation.DkmInspectionContext, Microsoft.CodeAnalysis.ObjectDisplayOptions, Microsoft.CodeAnalysis.ExpressionEvaluator.GetValueFlags)
   at Microsoft.VisualStudio.Debugger.EntryPoint.IDkmClrFormatter_GetValueString(IntPtr, IntPtr, IntPtr, IntPtr, IntPtr ByRef)
   at Microsoft.VisualStudio.Debugger.Evaluation.ClrCompilation.NativeDkmClrValue.Proc6C4DE7505B979C71E3E02EB952475CC3(IntPtr, IntPtr, IntPtr, IntPtr ByRef)
   at Microsoft.VisualStudio.Debugger.Evaluation.ClrCompilation.NativeDkmClrValue.Proc6C4DE7505B979C71E3E02EB952475CC3(IntPtr, IntPtr, IntPtr, IntPtr ByRef)
   at Microsoft.VisualStudio.Debugger.Evaluation.ClrCompilation.DkmClrValue.GetValueString(Microsoft.VisualStudio.Debugger.Evaluation.DkmInspectionContext, System.Collections.ObjectModel.ReadOnlyCollection`1<System.String>)
   at Microsoft.CodeAnalysis.ExpressionEvaluator.ResultProvider.GetResult(Microsoft.VisualStudio.Debugger.Evaluation.DkmInspectionContext, Microsoft.CodeAnalysis.ExpressionEvaluator.EvalResult, Microsoft.VisualStudio.Debugger.Clr.DkmClrType, Microsoft.VisualStudio.Debugger.Evaluation.ClrCompilation.DkmClrCustomTypeInfo, System.String, System.String, System.String, Boolean)
   at Microsoft.CodeAnalysis.ExpressionEvaluator.ResultProvider.GetResultAndContinue(Microsoft.CodeAnalysis.ExpressionEvaluator.EvalResult, WorkList, Microsoft.VisualStudio.Debugger.Clr.DkmClrType, Microsoft.VisualStudio.Debugger.Evaluation.ClrCompilation.DkmClrCustomTypeInfo, Microsoft.VisualStudio.Debugger.Evaluation.DkmInspectionContext, Boolean, Microsoft.CodeAnalysis.ExpressionEvaluator.CompletionRoutine`1<Microsoft.VisualStudio.Debugger.Evaluation.DkmEvaluationResult>)
   at Microsoft.CodeAnalysis.ExpressionEvaluator.ResultProvider.GetRootResultAndContinue(Microsoft.VisualStudio.Debugger.Evaluation.ClrCompilation.DkmClrValue, WorkList, Microsoft.VisualStudio.Debugger.Clr.DkmClrType, Microsoft.VisualStudio.Debugger.Evaluation.ClrCompilation.DkmClrCustomTypeInfo, Microsoft.VisualStudio.Debugger.Evaluation.DkmInspectionContext, System.String, System.String, System.Collections.ObjectModel.ReadOnlyCollection`1<System.String>, Microsoft.CodeAnalysis.ExpressionEvaluator.CompletionRoutine`1<Microsoft.VisualStudio.Debugger.Evaluation.DkmEvaluationResult>)
   at Microsoft.CodeAnalysis.ExpressionEvaluator.ResultProvider+<>c__DisplayClass7_0.<Microsoft.VisualStudio.Debugger.ComponentInterfaces.IDkmClrResultProvider.GetResult>b__1()
   at Microsoft.CodeAnalysis.ExpressionEvaluator.ResultProvider+WorkList.Execute()
   at Microsoft.CodeAnalysis.ExpressionEvaluator.ResultProvider.Microsoft.VisualStudio.Debugger.ComponentInterfaces.IDkmClrResultProvider.GetResult(Microsoft.VisualStudio.Debugger.Evaluation.ClrCompilation.DkmClrValue, Microsoft.VisualStudio.Debugger.DkmWorkList, Microsoft.VisualStudio.Debugger.Clr.DkmClrType, Microsoft.VisualStudio.Debugger.Evaluation.ClrCompilation.DkmClrCustomTypeInfo, Microsoft.VisualStudio.Debugger.Evaluation.DkmInspectionContext, System.Collections.ObjectModel.ReadOnlyCollection`1<System.String>, System.String, System.String, Microsoft.VisualStudio.Debugger.DkmCompletionRoutine`1<Microsoft.VisualStudio.Debugger.Evaluation.ClrCompilation.DkmEvaluationAsyncResult>)
   at Microsoft.VisualStudio.Debugger.EntryPoint.IDkmClrResultProvider_GetResult(IntPtr, IntPtr, IntPtr, IntPtr, IntPtr, IntPtr, IntPtr, IntPtr, IntPtr, IntPtr)
Aborted (core dumped)

I'm just keeping a full-method instance live on a console all of the time now since there's the least number of crashes that way.
This just happened to be the first one I caught this way.


Creating a job inside an existing view

Hello,
Creating a job inside an existing view is not supported.
I suggest something like :
createJob(String viewName, String jobName, String jobXml)

But now,  this method is not existe, how do you solve this problem? Thanks....


Talk: Writing type-checked web services in Rust

Abstract
We'll create a backend service in Rust: we'll talk about architecture, code organisation, testing and discuss commonly requested features like rate limiting, logging and database integration. We'll see the benefits of using Rust in terms of safety and compile time guarantees. We're also going to explore deployments on (fly.io) a developer friendly cloud provider with a free plan - so you can hit the ground running and start delivering value.
Your name (and pronouns)
Federico Rampazzo (he)

[ ] This will be my first tech talk

Contact Details
<EMAIL_ADDRESS>https://twitter.com/air_framp_one
Location & Time frame
Paphos, anytime
Code of Conduct

[x] I've read and agree to the Code of Conduct

Moved to https://github.com/cyprusrust/CyprusRust/issues/1


Unable to send cookie using ActionCableZwei

Using:

Python 2.7.12
Rails 5.1.2
Ruby 2.4.1

I am using ActionCable on webpage which works fine in rails, now trying to connect from python using https://github.com/tobiasfeistmantl/python-actioncable-zwei ActionCableZwei - A Python 3 client for Rails' Action Cable
Below line connects successfully:
connection = Connection(url='ws://localhost:4000/cable', origin='http://localhost:4000/')
and I get proper logs in rails.
Now, I want to send cookies with sockets but Below line is unable to connect nor do I get any logs in rails.
connection = Connection(url='ws://localhost:4000/cable', origin='http://localhost:4000/', log_ping=False, cookie=coo)
Also tried using log_ping to True/False
Below is full code that am trying:
from actioncable.connection import Connection
from actioncable.subscription import Subscription
from actioncable.message import Message
import datetime
import random
from time import sleep
import Cookie

coo = Cookie.SimpleCookie()
coo["fig"] = "newton"
coo["sugar"] = "wafer"

# connection = Connection(url='ws://localhost:4000/cable', origin='http://localhost:4000/')
connection = Connection(url='ws://localhost:4000/cable', origin='http://localhost:4000/', cookie=coo)
connection.connect()

subscription = Subscription(connection, identifier={'channel': 'TestChannel'})
subscription.create()

sleep(30)

subscription.remove()
connection.disconnect()

I just don't get any ping/log in rails about trying to connect. How can I fix this?

Have you tested it with Python 3?

No, Now will test with python 3 and will let you know

Tested in Python 3.5.2 , not working

Test to create the connection directly with the websocket client and see if there is a Rails response:
Something like this:
import websocket

def on_event:
    pass

ws = websocket.WebSocketApp(
    <your_url>,
    cookie=<your_cookie>,
    on_message=on_event,
    on_close=on_event)

ws.run_forever(ping_interval=5, ping_timeout=3, origin=self.origin)

Testing with above code does not respond but if i remove cookie param like below then it responds in rails
ws = websocket.WebSocketApp('ws://localhost:4000/cable',on_message=on_event,on_close=on_event)
Do, i need to check about websocket module version or something like that ?
Am mostly from rails background, so you might need to support me :)
Also one trick, can you support for header in websockets ?
ref: https://github.com/websocket-client/websocket-client/blob/9a28437252c7c953e208ed07ff1811d1dc7b8c41/websocket/_app.py#L58

It looks like it's a bug in the websocket-client lib. But you could try an older version of the library or use the new added header parameter.


Add JSR support

Please review my changes so it support deployment into the JSR registry. For example here is the JSR scope that use this PR: https://jsr.io/@bureaudouble-forks/use-isomorphic-layout-effect

What's the goal of this PR? can't JSR pull dependencies from npm?

This PR makes some changes to your package to allow it to be delivered via the JSR.io registry. I wanted to make those changes open source and submit a PR to share the work with the community.
JSR can pull dependencies from npm, which is correct.
I needed to have this package on JSR because I can't easily replace the React peer dependency if it was pulled via the npm registry.
I also thought that the reason for this PR would be to promote the use of this registry, which I believe is more modern. It aims to improve upon npm by providing native TypeScript support, focusing on ECMAScript modules, offering cross-runtime compatibility, and delivering an outstanding developer experience while ensuring fast, secure, and reliable package management.
Regarding the deno-types, they are specific to Deno, which is correct. They are needed because React doesn't ship with native types, and Deno doesn't automatically look at the @types repository.


Add checkbox to build for Pi Pico W

With the Pi Pico, it'd be nice to be able to generate projects with the correct board flag to build for the Pi Pico. This adds a new command line option and a new checkbox in the GUI to generate a Pi Pico W project.

I'm currently doing a major rewrite of this area in the PPG, which will allow specifying multiple board types, I hope to push it to a testing branch in the next couple of days. UI should make this PR unnecessary, but, thanks for it anyway!

I agree that it'd be nicer to have a generic "board type" option, rather than a boolean "is this Pico or Pico W" option :+1:

I'll upload the working branch tomorrow - it has a board selection option, with the list obtained from the boards folder in the SDK.

The PicoW branch is here https://github.com/raspberrypi/pico-project-generator/tree/pico-w-support
Needs testing if anyone has time! Only tested on Lubuntu, not on Win or Mac yet.

Haven't done any testing, but left some comments based on a very quick scan of the changes in https://github.com/raspberrypi/pico-project-generator/commit/d2e62dbd19f977330f829fcd49ba53b807f8fd82

Closing as the other branch has been merged.


Issue #2 - Further refactor the map related classes into MVVM architecture

#2 Development:
This PR builds upon our attempts to model our application into an MVVM architecture by refactoring the map related classes (and especially the MapFragment). The following points detail the changes that this PR introduces:
1) Refactor the way we handle buildings images:

The Building model has been updated to include an extra variable that stores the resource id of the building image.
Updated map repository to initialize the resource id of the buildings images when initializing the campus buildings.
Refactored map fragment by moving the logic to retrieve the resource id of the buildings images to the map viewModel

2) Refactor the traversal and storing of the campus buildings list:

Both map repository and viewModel have been updated to store a list of all Concordia buildings as a class variable. This is to ensure that the list of buildings is only created once (through campus buildings traversal) and that the logic to create this list of all buildings is the responsibility of map repository only.

3) Replace hard coded campuses coordinate with external file reading:

Update external buildings.json with coordinates for both campuses
Update external buildings.json to be up to date with the JTs branch (highlight remaining buildings) so that future merge conflicts can be avoided.
Refactor Map Repository to read campus coordination from the external buildings.json file rather than hard coding those coordinates in the map repository class.

I ran the app, tested it manually, ran the tests. I also verified all the commits. Everything checks out. Left minor comments for you to address.
Really great work! Honestly, this refactoring is really inspiring. I'm looking at clean code that I initially didn't know how to properly structure. I am definitely learning a lot from this 🥇

I have built upon this branch with highlightRemaningBuildings. I fixed some of the errors in this PR (related to buildings), as soon as this PR is merged, I will make a PR for my branch - so that master is 100% stable
Otherwise, amazing work! The singleton is a beast tamed in 039b5bc 😆


[WIP] Infra State Persistence RFC

Proposes a dynamic Kubernetes storage solution to be used by both automated and manual testnet deployments for persisting application state across redeployments and non-intentional destructive operations.
Checklist:

[ ] Document code purpose, how to use it

Mention expected invariants, implicit constraints

[ ] Tests were added for the new behavior

Document test purpose, significance of failures
Test names should reflect their purpose

[ ] All tests pass (CI will check this if you didn't)
[ ] Serialized types are in stable-versioned modules
[ ] Does this close issues? List them:

Closes #6271

In the sections at the bottom that still need to be fleshed out, it would be nice to see some mention of StatefulSets, and the tradeoffs for using them to manage our PersistentVolumeClaims for us (seems like they do some of this logic automatically, if I understand the docs correctly).

Hey, for sure and will do though the general gist of the decision away from StatefulSets comes down to flexibility (in both pod naming scheme and persistent-volume claim binding) and avoiding the added overhead of having to create a headless service to associate with each StatefulSet. StatefulSets are considerable bespoke when it comes to provisioned pod names (based on the ordinal naming scheme) and persistent-volume claim names as well as lack the same degree of customizability that we get by merely using templated PVCs and allowing per pod volume mounting scoped to common defaults or overridden if desired with specific values as expressed within Values.yaml.
The overhead of having to manually create "headless" services for each StatefulSet isn't massive though again unnecessary and also requires that we migrate from using Deployments with additional overhead there without much gain and added constraints. It's probably worth noting that StatefulSets also don't automatically clean up storage/volume resources created during provisioning - that cleanup is left as a manual task and again speaks to the lack of reasoning to make the switch.

Network artifacts should probably just be merged all into a single ReadOnlyMany shared persistent volume role (genesis ledger, genesis proof, genesis epoch ledgers, daemon config, possibly even wallet keys as well since they are baked into the ledger). These network artifacts are all typically going to be unique for each network, and will be the same across all mina nodes operating on that network, so the additional division of these artifacts into separate roles seems unnecessary.

Sure, makes sense for the most part though I think the keyword in all of that is typically, as in "typically going to be unique for each network". Again the design goal here is to provide flexibility for cases outside of the typical scenario while also enabling a simple/convenient means to achieve the typical scenario.
This is where named templates come into the picture as they allow sane/common defaults defined once and used by all entities within a network, if desired, while also enabling customization for a subset of entities if the situation is desired. So basically the essentially required common + tightly coupled resources (genesis ledger, genesis proof, genesis epoch ledgers) could be merged into a single shared PV while the typically though necessarily common resources (daemon configs, wallet keys) could be defined per pod though leveraging named templates again with common defaults and the potential for customizability if/when desired.

Two other small notes: I think wallet keys should be ReadOnlyMany as opposed to ReadWriteMany, and runtime state should be only ReadOnly as opposed to ReadOnlyMany.

Hmmm oh ok got it though not familiar with the ReadOnly setting. Just ReadOnlyMany, ReadWriteOnce and ReadWriteMany based on the docs.

It also seems as though the user agent, faucet, and echo service only need the wallet keys at most, and not the genesis ledger or daemon config (since they just talk to a daemon running in the same workload, and only that daemon actually needs access to those).

Copy that. The table is a sort of in a rough state but doesn't really breakdown the per container volumeMounts. So agreed on the above though maybe think in terms of what's needed within the Pod.

I noticed that you have the epoch ledger role set to ReadWriteMany. I want to clarify something around epoch ledger usage for our daemons. There is a new network artifact which (in cases of hard forks) needs to be made available with the genesis ledger, genesis proof, etc, called "genesis epoch ledgers". These should be ReadOnly, just like the genesis ledger and genesis proof, and will not be overwritten or changed by daemons on the network. Similar to the genesis ledger, daemons will copy this ledger into their local state in ~/.coda-config and operate on a copy of that, which they will then mutate for their own view of the network state. It would be unsafe for multiple daemons on the network to write to these local epoch ledgers at the same time, and it's expected that nodes could temporarily have slightly different views of what is stored in their local epoch ledgers. Thus, the epoch ledger volume role (which is really the "genesis epoch ledgers" volume role) should be ReadOnlyMany, and the only volume role that needs to have Write privileges is the runtime state.

Ah ok cool got it.

Two other small notes: I think wallet keys should be ReadOnlyMany as opposed to ReadWriteMany, and runtime state should be only ReadOnly as opposed to ReadOnlyMany.

Hmmm oh ok got it though not familiar with the ReadOnly setting. Just ReadOnlyMany, ReadWriteOnce and ReadWriteMany based on the docs.

Oh, my bad. I meant to say "runtime state should be ReadWriteOnce as opposed to ReadOnlyMany", as each pod should have their own unique volume which they have both read and write privileges to.


[test] Update Jacobi_cpp test for latest AMD compiler version

Closes UES-1727

Codecov Report

Merging #2145 (6c2c7ff) into master (da18b68) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2145   +/-   ##
=======================================
  Coverage   86.15%   86.15%
=======================================
  Files          53       53
  Lines        9465     9465
=======================================
  Hits         8155     8155
  Misses       1310     1310

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 da18b68...6c2c7ff. Read the comment docs.

Hello @jgphpc, Thank you for updating!

In the file cscs-checks/tools/profiling_and_debugging/notool.py:

Line 43:10: E114 indentation is not a multiple of four (comment)
Line 43:10: E117 over-indented (comment)

Do see the ReFrame Coding Style Guide

@jenkins-cscs retry all


added Platform tokens for hoopoe

added AVAXAG, AVAXAU and USDH
their code verified and published

hey @MuhammadAwaisAhmad as per the instructions in the readme, the image files must be named logo.png


Will pip-licenses fail if one of my dependencies has a non-permissive license?

Will pip-licenses fail if one of my dependencies has a non-permissive license?
Im looking to use it in a CI setting so I would like it to return something other than 0 in a case like that.

Please read the documentation for the --fail-on option.
https://github.com/raimon49/pip-licenses#option-fail-on

This issue is deemed resolved.


Fully scroll collection elements into view when keyboard navigating

Closes https://github.com/adobe/react-spectrum/issues/2766
EDIT: overzealous when thinking this fixed the other scroll into view issues, seems like it still happens (albeit rarely locally)
✅ Pull Request Checklist:

[ ] Included link to corresponding React Spectrum GitHub Issue.
[ ] Added/updated unit tests and storybook for this change (for new code or code which already has tests).
[ ] Filled out test instructions.
[ ] Updated documentation (if it already exists for this component).
[ ] Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:
Test that components that have keyboard navigation are scrolled into view upon keyboard navigating e.g. TableView, ListView, Calendar (standalone and in overlay) , Tabs, non-virtualized collections (useSelectableList stories, useTab stories). Use the "scrolling" checkbox to enable scroll in the stories (you'll have to tab to the component to bring it into view).
Also test popovers in general since we've updated how the positioning coords are applied to the popover.
Note: behavior at varying pinch zoom levels/on mobile emulation is a bit finicky, digging
🧢 Your Project:
RSP

@ktabors Did you scroll the entire datepicker out of view when you noticed that bug? If so, then that is a separate issue not handled by this PR. We've had some discussions about making all elements scroll into view upon keyboard interaction to fix such a case but punted for future PRs due to the number of edge cases/complexity that were discovered.

Hi @LFDanLu I just came across this PR that I think is related with one think is happening to me:
I have a text input and on ArrowDown in that input I do:
const state = useListState<T>({
  items: options,
  children,
  selectionBehavior: 'toggle',
  selectionMode: 'multiple'
})
const onArrowDown = () => {
  state.selectionManager.setFocusedKey(state.collection.getFirstKey(), 'first')
  state.selectionManager.setFocused(true)
}

But the useListBox first element is scrolled this way:

The question
Any idea why is scrolling into view the first item but in reality is scrolling out of view?

Hey @LFDanLu sorry for the delay. Your request of doing a codesandbox served me as rubber duck 🦆 . I found my problem.
In this sandbox I replicated part of my implementation.
https://codesandbox.io/s/sleepy-keller-qjygke?file=/src/hooks/useKeyboarEvents.ts
The issue is not present in that sandbox but because I'm wrapping my component inside a Radix popover and for some reason inside it useListBox things it needs to scroll down pass first item as in the image. As you said is because this code
So the fix was to event.preventDefault inside the useKeyboard I'm using.
Thanks! 🎉


[DO NOT MANUAL MERGE] Release Qualification

Trigger release qualification jobs
none

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

Test name
Commit
Details
Rerun command

prow/daily-e2e-cluster_wide-auth.sh
52085fcf2f486ae8cbf208c6fe7752d4b5efd1fa
link
/test daily-e2e-cluster_wide-auth

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

@silverdev: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/daily-e2e-cluster_wide-auth.sh
52085fcf2f486ae8cbf208c6fe7752d4b5efd1fa
link
/test daily-e2e-cluster_wide-auth

prow/daily-e2e-cluster_wide-auth-default.sh
52085fcf2f486ae8cbf208c6fe7752d4b5efd1fa
link
/test daily-e2e-cluster_wide-auth-default

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

@silverdev: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/daily-e2e-cluster_wide-auth.sh
52085fcf2f486ae8cbf208c6fe7752d4b5efd1fa
link
/test daily-e2e-cluster_wide-auth

prow/daily-e2e-cluster_wide-auth-default.sh
52085fcf2f486ae8cbf208c6fe7752d4b5efd1fa
link
/test daily-e2e-cluster_wide-auth-default

prow/daily-e2e-rbac-no_auth-default.sh
52085fcf2f486ae8cbf208c6fe7752d4b5efd1fa
link
/test daily-e2e-rbac-no_auth-default

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

@silverdev: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/daily-e2e-cluster_wide-auth.sh
52085fcf2f486ae8cbf208c6fe7752d4b5efd1fa
link
/test daily-e2e-cluster_wide-auth

prow/daily-e2e-cluster_wide-auth-default.sh
52085fcf2f486ae8cbf208c6fe7752d4b5efd1fa
link
/test daily-e2e-cluster_wide-auth-default

prow/daily-e2e-rbac-no_auth-default.sh
52085fcf2f486ae8cbf208c6fe7752d4b5efd1fa
link
/test daily-e2e-rbac-no_auth-default

prow/daily-e2e-rbac-no_auth.sh
52085fcf2f486ae8cbf208c6fe7752d4b5efd1fa
link
/test daily-e2e-rbac-no_auth

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

@silverdev: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/daily-e2e-cluster_wide-auth.sh
52085fcf2f486ae8cbf208c6fe7752d4b5efd1fa
link
/test daily-e2e-cluster_wide-auth

prow/daily-e2e-cluster_wide-auth-default.sh
52085fcf2f486ae8cbf208c6fe7752d4b5efd1fa
link
/test daily-e2e-cluster_wide-auth-default

prow/daily-e2e-rbac-no_auth-default.sh
52085fcf2f486ae8cbf208c6fe7752d4b5efd1fa
link
/test daily-e2e-rbac-no_auth-default

prow/daily-e2e-rbac-no_auth.sh
52085fcf2f486ae8cbf208c6fe7752d4b5efd1fa
link
/test daily-e2e-rbac-no_auth

prow/daily-e2e-rbac-auth.sh
52085fcf2f486ae8cbf208c6fe7752d4b5efd1fa
link
/test daily-e2e-rbac-auth

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


Use self-documenting f-strings where possible

Could maybe be added to flake8-simplify.
my_var = 42_000

# bad (if target=py3.8+)
f"my_var={my_var}"
f"my_var = {my_var}"
f"my_var = {my_var:,}"

# good
f"{my_var=}"
f"{my_var = }"
f"{my_var = :,}"

This would be nice, and would help make those who don't know this feature aware of it 🙂
The only snag is that f-strings are not part of the formal grammar until Python 3.12 - see PEP 701 - so they're tricky to do much with right now.
Other test cases to include for unbalanced spacing:
# bad (if target=py3.8+)
f"my_var= {my_var}"
f"my_var ={my_var}"

# good
f"{my_var= }"
f"{my_var =}"

I think this is a RUF rule or FLY (recently introduced in #4196, see https://github.com/ikamensh/flynt) rule, but sounds like a good idea :)

Ah, this is made difficult by the fact that ruffpython-ast apparently already parses f"{my_var=}" as
[
  Located { range: 119..131, custom: (), node: Constant { value: Str("my_var="), kind: None } },
  Located { range: 119..131, custom: (), node: FormattedValue {
    value: Located { range: 122..128, custom: (), node: Name { id: "my_var", ctx: Load } },
    conversion: 114,
    format_spec: None
  }}
]

so it's not easy to distinguish between already correctly formed expressions and those that need changing 🤔

Tbh I'm out of my depth on AST and grammar. At the risk of going against orthodoxy and sounding low-status, if the grammar doesn't formalize f-strings below 3.12, maybe a regex can help distinguish true positives? 😄

Ah, this is made difficult by the fact that ruffpython-ast apparently already parses f"{my_var=}" as
[
  Located { range: 119..131, custom: (), node: Constant { value: Str("my_var="), kind: None } },
  Located { range: 119..131, custom: (), node: FormattedValue {
    value: Located { range: 122..128, custom: (), node: Name { id: "my_var", ctx: Load } },
    conversion: 114,
    format_spec: None
  }}
]

so it's not easy to distinguish between already correctly formed expressions and those that need changing thinking

The two nodes differ in that the second has conversion  set to b'r'. I don't know why conversion is an usize instead the ConversionFlags that RustPython uses internally or just the char (@youknowone do you know why?). But I think it could allow us to tell the two formats apart.
https://github.com/charliermarsh/RustPython/blob/50b8570bc262098b84dac86092133d3ee26caf23/compiler/core/src/bytecode.rs#L328-L342

Python.asdl refers it as int and RustPython naively convert it to actual int. We didn't care about it that much because we were the sole ast user, but that need to be enhanced.
There are 7 int values and 2 refers bool and another one is conversion.
I recently changes bool values to actual bool and going to work on conversion too.
It will be ConversionFlag or  Option<ConversionFlag>. I didn't investigate enough which one is more correct.


nuclei: 3.3.0 -> 3.3.1

Diff: https://github.com/projectdiscovery/nuclei/compare/refs/tags/v3.3.0...v3.3.1
Changelog: https://github.com/projectdiscovery/nuclei/releases/tag/v3.3.1
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 335199 run on x86_64-linux 1

1 package built:

nuclei


adds code coverage support to ci: uses code-cov for static analysis, …

…adds forked version for e-c-code-coverage with support for transpiled sources. updates gradle build to run ember test with coverage. removes custom yarn version. removes broken fancy tree dep. minor refactor to WIP fetch wrapper: adds doc and exports

Coverage remained the same at 27.176% when pulling 05022f5f2c75bccd0f43673ac8a82e2d4ad48d3f on theseyi:field-review into 60d5e58df5121bb5a0718a1cdcaa499382b00917 on linkedin:master.

Codecov Report

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

@@            Coverage Diff            @@
##             master     #882   +/-   ##
=========================================
  Coverage          ?   35.26%
=========================================
  Files             ?      307
  Lines             ?     8231
  Branches          ?     1532
=========================================
  Hits              ?     2903
  Misses            ?     5328
  Partials          ?        0

Impacted Files
Coverage Δ

wherehows-web/app/utils/api/fetcher.ts
29.88% <10.52%> (ø)

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 60d5e58...05022f5. Read the comment docs.

Coverage remained the same at 27.176% when pulling a932b4cf5e86d9ee0f0c922973c084d042fd7597 on theseyi:field-review into 60d5e58df5121bb5a0718a1cdcaa499382b00917 on linkedin:master.

Coverage remained the same at 27.176% when pulling 5d41f06731265ae1fb08fa44047998c964d0ff33 on theseyi:field-review into 60d5e58df5121bb5a0718a1cdcaa499382b00917 on linkedin:master.

Coverage remained the same at 27.176% when pulling 6f388d89fea3634b1b15b4817a5b613e294622fa on theseyi:field-review into 60d5e58df5121bb5a0718a1cdcaa499382b00917 on linkedin:master.


testParseRemoteXML fails on fresh checkout

Is this what others experience or is this environment-specific? Here's roughly what I did:
docker run --name alpine-openj9 -it adoptopenjdk/openjdk8-openj9:x86_64-alpine-jdk8u212-b04_openj9-0.14.2
then something like:
apk add git mvn bash
apk update && apk upgrade
bash

then I cloned the repo, checked out the latest tag, and mvn clean install. There are numerous errors exceptions and error messages logged, but only one test failure:
testParseRemoteXML(com.onelogin.saml2.test.settings.IdPMetadataParserTest): expected:<https://try[].onelogin.com/trust/...> but was:<https://try[-demo].onelogin.com/trust/...>
# mvn -v
Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 2019-04-04T19:00:29Z)
Maven home: /usr/share/java/maven-3
Java version: 1.8.0_212, vendor: Eclipse OpenJ9, runtime: /opt/java/openjdk/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-60-generic", arch: "amd64", family: "unix"

Is there another manual step I need to take to setup before building which I overlooked?
Do note this is with Alpine and OpenJ9, so not exactly the most common type of environment.

FWIW I wanted to test if updating xmlsec past https://nvd.nist.gov/vuln/detail/CVE-2019-12400 would break anything. Both before and after updating, I get the same test failure given above.

The above test failure blocks a couple of projects from building, but when I add -Dmaven.test.failure.ignore=true there are no additional test failures (after upgrading xmlsec, which is probably irrelevant).

Thanks for letting me know about the CVE.
I will review why that test is failing, update the xmlsec and release a new java-saml version

That fixes the test
https://github.com/onelogin/java-saml/commit/4cd854373202d5d10cde3201842e178f85273464

new xmlsec raises issues on java7, trying to figure it how fix them

https://github.com/onelogin/java-saml/releases/tag/v2.5.0

Wow that was painless for me. Thanks!
I hope discontinuing support for Java 7 doesn't block anyone!

It was the unique option in order to update the xmlsec dependency that is compiled with java8.
Java 7 customers have 2 options:

Migrate to Java 8
Keep using the v2.4.0 of java-saml and patch the xmlsec jar with the fix:
https://github.com/apache/santuario-java/commit/52ae824cf5f5c873a0e37bb33fedcc3b387cdba6


Formatting with merge_imports creates invalid Rust

As noted below the before version is already not valid Rust. However, it would be nice if it could be supported because I run into such cases during refactoring or adding new code.
I use merge_imports to keep the imports looking clean and sometimes I want to merge different sets of imports. Then it can happen that duplicates arise. This is normally handled well, in that duplicates are merged, just not here.
Before rustfmt:
use std::fmt::{self, Display};
use std::fmt;

fn main() {
    println!("Hello, world!");
}

After rustfmt:
use std::fmt::{
    self, {self, Display},
};

fn main() {
    println!("Hello, world!");
}

rustc error after formatting:
error[E0252]: the name `fmt` is defined multiple times
 --> src/main.rs:2:12
  |
2 |     self, {self, Display},
  |     ----   ^^^^ `fmt` reimported here
  |     |
  |     previous import of the module `fmt` here
  |
  = note: `fmt` must be defined only once in the type namespace of this module

rustfmt.toml
merge_imports = true
use_field_init_shorthand = true

rustc + rustfmt versions
$ rustc --version
rustc 1.34.0-nightly (f6fac4225 2019-02-03)
$ rustfmt --version
rustfmt 1.0.1-nightly (be13559 2018-12-10)

Note that since the input is semantically incorrect, rustfmt is not guaranteed to produce the valid Rust code.

@topecongiro Thanks for pointing out that my example is already invalid code. It was late when I posted this.
I added a small comment to my first message, why I think supporting the merging of duplicate imports is nice, but I agree that it is a low priority.

merge_imports is deprecated. Running this with imports_granularity=Crate produces:
Input
use std::fmt::{self, Display};
use std::fmt;

fn main() {
    println!("Hello, world!");
}

Outupt
use std::{
    fmt,
    fmt::{self, Display},
};

fn main() {
    println!("Hello, world!");
}

Trying to compile either the Input or the Output with rustc leads to compilation issues. @calebcartwright do you think there is any actions we can take here since use a; and use a::{self}; are different?

I'm going to close as there's no action to be taken. The title is misleading, as the only thing that's happening is that rustfmt is not converting invalid rust code to valid rust code by deduping an import, but that is intentional as it's not a change rustfmt can make because doing so is not always semantics preserving and can actually convert valid rust code to invalid rust code.


Isolation scope name problems

Problem 1
How to be when scope named as state property is not enough:
// this needs 'child' from onion state
isolate(Child, 'child')({onion, HTTP)

// and this needs 'child' from onion state,
// but HTTP source needs different scope not to mess with `Child`
isolate(AnotherChild, 'child')({onion, HTTP)

Problem 2
What if one need to pass more nested property to child like "some.nested.child"
// with mapping I would pass it like:
onion.state$.map(state => state.some.nested.child)

I think problem 1 can be solved with something like this: https://github.com/staltz/cycle-onionify/issues/3
It also depends if Child and AnotherChild just read state but don't write it. If that's the case, then state$ can be passed instead of sources.onion.
Problem 2:
It depends, if it's read-only state, we can do like I suggested above. Otherwise, we could consider supporting an API like isolate(Child, 'some.nested.child')

'some.nested.child' it is still imperfect solution, as object property itself may contain dot.
I like that onionify tries to unify ideas for managing state, though currently I prefer more transparent and custom solution, something that I described in recent gist: https://gist.github.com/whitecolor/0f015856a335ca418e22d4bba4d97d68

as object property itself may contain dot

I've never seen a single case of this. :)

What about obj['some.dots']?

I've also seen arrays of strings/numbers used to denote a nested path, as in isolate(Child, ['some', 'nested', 'child']). It's a little noisier than a dot-delimited string but it works if you're really worried about having dots in property names.

The lenses proposal in #11 would solve this issue entirely.

Solved by issue #11


ikev1: add ikev1 test - v8

Previous PR: https://github.com/OISF/suricata-verify/pull/351

Only rebased so far.

The failure on the 6 branch will have to be addressed. I don't want to reduce the testing done on that branch, so we'll need checks specifying the correct versions.

I'll see to it and make sure we have tests for both versions.

Next PR: #472


Typos

What does this PR do?

Fixes some typos on the README and on the documentation comments.
Updates wootils version to ^1.1.1.

How should it be tested manually?
yarn test
# or
npm test

Pull Request Test Coverage Report for Build 5

2 of 2 (100.0%) changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 1:
0.0%

Covered Lines:
56

Relevant Lines:
56

💛  - Coveralls

☠


Added parameter to pass a mocked ConnectivityPlus in start method

Please, recreate this PR pointing to dev branch.


setting the right tag: service-bus-messaging

Docs Build status updates of commit 6ef7a4d:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs-ref-services/latest/servicebus-readme.md
:warning:Warning
View (azure-python)
Details

docs-ref-services/latest/servicebus-readme.md

Line 2, Column 1: [Warning-ms-prod-and-service] Only one of the following attributes can exist: 'ms.prod', 'ms.service'. Use ms.prod for on-premise products, or ms.service for cloud services.
Line 9, Column 16: [Warning-ms-prod-technology-invalid] Invalid value for 'ms.technology': 'azure' is not valid with 'ms.prod' value 'azure'.
Line 2, Column 1: [Suggestion-description-missing] Missing required attribute: 'description'.
Line 28, Column 192: [Suggestion-docs-link-absolute] Absolute link 'https://docs.microsoft.com/azure/service-bus-messaging/' will be broken in isolated environments. Replace with a relative link.
Line 46, Column 23: [Suggestion-docs-link-absolute] Absolute link 'https://docs.microsoft.com/azure/service-bus-messaging/service-bus-create-namespace-portal' will be broken in isolated environments. Replace with a relative link.
Line 50, Column 71: [Suggestion-docs-link-absolute] Absolute link 'https://docs.microsoft.com/azure/service-bus-messaging/service-bus-create-namespace-portal' will be broken in isolated environments. Replace with a relative link.
Line 64, Column 55: [Suggestion-docs-link-absolute] Absolute link 'https://docs.microsoft.com/cli/azure' will be broken in isolated environments. Replace with a relative link.
Line 64, Column 327: [Suggestion-docs-link-absolute] Absolute link 'https://docs.microsoft.com/azure/service-bus-messaging/service-bus-create-namespace-portal#get-the-connection-string' will be broken in isolated environments. Replace with a relative link.
Line 78, Column 17: [Suggestion-docs-link-absolute] Absolute link 'https://docs.microsoft.com/azure/service-bus-messaging/service-bus-authentication-and-authorization' will be broken in isolated environments. Replace with a relative link.
Line 86, Column 3: [Suggestion-docs-link-absolute] Absolute link 'https://docs.microsoft.com/azure/service-bus-messaging/service-bus-messaging-overview#queues' will be broken in isolated environments. Replace with a relative link.
Line 88, Column 3: [Suggestion-docs-link-absolute] Absolute link 'https://docs.microsoft.com/azure/service-bus-messaging/service-bus-messaging-overview#topics' will be broken in isolated environments. Replace with a relative link.
Line 90, Column 3: [Suggestion-docs-link-absolute] Absolute link 'https://docs.microsoft.com/azure/service-bus-messaging/service-bus-queues-topics-subscriptions#topics-and-subscriptions' will be broken in isolated environments. Replace with a relative link.
Line 92, Column 49: [Suggestion-docs-link-absolute] Absolute link 'https://docs.microsoft.com/azure/service-bus-messaging/service-bus-messaging-overview' will be broken in isolated environments. Replace with a relative link.
Line 231, Column 107: [Suggestion-docs-link-absolute] Absolute link 'https://docs.microsoft.com/azure/service-bus-messaging/service-bus-messaging-overview#topics' will be broken in isolated environments. Replace with a relative link.
Line 467, Column 70: [Suggestion-docs-link-absolute] Absolute link 'https://docs.microsoft.com/azure/service-bus/' will be broken in isolated environments. Replace with a relative link.
Line 472, Column 16: [Suggestion-docs-link-absolute] Absolute link 'https://docs.microsoft.com/python/api/overview/azure/servicebus/management?view=azure-python' will be broken in isolated environments. Replace with a relative link.
Line 472, Column 16: [Suggestion-preserve-view-not-set] Did you mean to link to a specific version? If so, add &preserve-view=true to the URL: https://docs.microsoft.com/python/api/overview/azure/servicebus/management?view=azure-python

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit deb98f4:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-services/latest/servicebus-readme.md
:bulb:Suggestion
View (azure-python)
Details

docs-ref-services/latest/servicebus-readme.md

Line 471, Column 16: [Suggestion-preserve-view-not-set] Did you mean to link to a specific version? If so, add &preserve-view=true to the URL: /python/api/overview/azure/servicebus/management?view=azure-python

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

#sign-off


Single line breaks turning into wrapped text for some users

Hi, we are on version 5.3 of Company Communicator and as of the last few days have been noticing an issue where single line breaks are turning into wrapped text, although double line breaks are behaving normally:

This is the case both in the message preview and the message itself once it's sent, and happens in both Teams desktop and web.
Strangely this is happening only for some users - many users can see the same messages with the correct line breaks.
All users are on either of the latest Teams versions <IP_ADDRESS>81 or <IP_ADDRESS>72, and there doesn't seem to be any correlation between who is on which version and who can see the messages correctly.
Enabling the Teams Preview toggle appears to resolve the issue for those affected, although we are unable to do this for the whole company.

Is anyone else experiencing this same issue, if so were there any changes that helped?
Did the Teams Preview toggle also resolve this issue for anyone else? If this is the case we suspect a future release of Teams will resolve the issue, although we cannot see any statement from Microsoft regarding this.
Would upgrading to the latest version of Company Communicator make a difference?

Appreciate any help or advice anyone has for this one.

Hi @EMEAWebEnvironmentsTeam ,
Thanks for raising the query. We will look into this and get back to you with proper response.

Hi @EMEAWebEnvironmentsTeam ,
Thanks for the patience. We have checked it from our end it is working as expected on v5.3.
-If you are still facing the issue, we suggest you to update to the latest version as it is accessibility compliant as well. Company Communicator v5.4.1 complies with Microsoft accessibility standards and guidelines for Web, Windows and Mac OS (Grade C). It has not been tested for immersive reader and supports for only JAWS and NVDA for Web and Desktop versions.

Please elaborate on Teams Preview toggle that you are referring to.

Hi Sai,
Thanks for your response.
An upgrade is on the table but we want to avoid it if possible if there's an easier solution - just appears a bit odd that some users are affected and not others, it seems like there is a difference in users somewhere although this is not clear to us.
The Teams preview toggle is the toggle for the new Teams feature:
https://techcommunity.microsoft.com/t5/microsoft-teams-blog/introducing-the-new-microsoft-teams-now-in-preview/ba-p/3774406
As the text appears normal for us in this Teams preview version we assume that a future Teams update will resolve the issue, although it's unclear when this might be.

@EMEAWebEnvironmentsTeam , Please let us know how it goes once after upgrading to the latest version.


Deploying SQL code using Powershell

Deploying SQL code using Powershell

Name: Kirill Kravtsov
Abstract: Discover a way of deploying your SQL code in a reliable and repeatable manner by using Powershell deployment module DBOps. Create multiple deployment configurations, rollback the deployment in case of errors, and even setup Continuous Integration for your database code!
Optional links (remove if not using)

Twitter: @nvarscar
Slack ID: @nvarscar
Blog URL: https://nvarscar.wordpress.com

Thanks again!  Do feel free to submit more proposals : D


Find small dimension typo in reading_comprehension/bidirectional_attention.py

Hi, first of all, thank you very much for your work!
While implementing your code, I found in bidirectional_attention.py line 128,
passage_question_vectors = weighted_sum_layer([encoded_question, passage_question_attention])
should be  = weighted_sum_layer([encoded_passage, passage_question_attention])
Because both C2Q or Q2C attention should be 2d * T, where T is the max_len of passage instead of questions. Only to do so, the end of the merged attention weights would be 8d * T as mentioned in the original paper.
Thank you!

Hi @felizxia - this repository is no longer supported, as we've moved all of our development efforts to AllenNLP.  But, that line of code is actually correct, because of how the WeightedSum works.  The given attention tensor has three dimensions: (batch_size, num_passage_words, num_question_words).  WeightedSum uses the last dimension as weights for summing the encoded_passage, and returns a tensor of shape (batch_size, num_passage_words, encoding_dim).  It's a sum over the encoded question, but it's done for each passage word, so the shapes end up right.

Got it! Thank you very much for clarification!! I was just wondering have your team also posted any solutions to bi-direction-attention method for cloze test? Like for CNN and DailyMaily test set where only entity is the output? Thank you!!

We have this model: https://github.com/allenai/deep_qa/blob/master/deep_qa/models/reading_comprehension/attention_sum_reader.py.  But, again, this library is not supported, I don't remember how to run this anymore, or what data you need to use with this.  Good luck!


Move the TLJH docker plugin to its own repo

For now there is a single TLJH plugin for the whole PlasmaBio stack
However, some users might be interested in using the "Environments" part only. That means being able to build local Docker images from the JupyterHub interface, but without the opinionated choice of using PAMAuthenticator and SystemUserSpawner. For example they could use it on a temporary instance to build a few Docker images and start them with DockerSpawner, which using GitHub for authentication.
PlasmaBio would consume this TLJH plugin either as a Python dependency, or by being installed side-by-side (with an extra --plugin parameter in the TLJH installer command).

The tljh-plasmabio plugin would then mostly consist in setting up the JupyterHub config, as in: https://github.com/plasmabio/plasmabio/blob/1ac4deb897ae5d76099afc072bf7092954de9ef9/tljh-plasmabio/tljh_plasmabio/init.py


[Feature] Support CSS Grid

Report

[x] I have searched existing issues and this is not a duplicate

It's been advised to open a new issue (from this closed issue from 2015). Related react-native issue
It's been 4 years since the issue was closed. This issue is to request evaluating if supporting display: grid is worth reconsidering now.
It is the 11th 8th top request(1st in regards to layout, 8th 3rd trending) at 229(Mar 2019) 359(Feb 2020) votes on React-Native feature requests, the feature request was created in December 2017 with steady response of support from users since then.

I'd like to voice my support.

I'd like to voice my support.

Great! Just give it a positive reaction like many others have done :)
(That goes for anyone else that has an itch to make a +1 comment)

Is anyone aware of other efforts to make a cross-platform implementation of CSS grid? I would love to support this. It's worth remembering that CSS Grid has a larger API surface area than flexbox, so adding it here would be quite an undertaking and a big change to Yoga. Maybe a way forward would be a separate project which could serve as a reference or proof of concept.

@bnjm The css grid polyfill is completely web-independent, and supports most grid features already.
https://github.com/facebook/yoga/issues/47

+1 to get CSS Grid as part of Yoga (and potentially part of React-Native)

I would like that

Please, this would be huge. Since most browsers support this in some way, we're starting to use CSS grid as a standard in our web dev. Would be great to be in sync with RN dev.

@RodRitter same problem for me.

Some of you might be interested to know about a year ago an alternative was announced called Stretch:

I led the Yoga team at Facebook solving exactly this problem. My team built the underlying cross-platform layout engine powering React Native as well as a handful of other internal and open source frameworks. Naturally when we started work on Visly we decided to base it on Yoga, a proven cross-platform layout engine. So why create stretch?

We wanted to move faster than was possible when building on top of Yoga. Due to Yoga powering most of Facebook’s mobile surfaces it is incredibly difficult to make any changes to the algorithm.

And 9 months ago, HackerNews thread, author replies:

Stretch doesn't really enable any new kind of layouts that yoga doesn't but it fixes some fundamental problems in Yoga where Yoga was not compatible with the web implementations.

Long term goal of Stretch is to support multiple layout systems including Grid layout I just started with Flexbox because I know that so well :) Look forward to tackling grid layout soonish (contributions / help very welcome).

Website: https://vislyhq.github.io/stretch/

While it's probably of no use to the majority here that probably want CSS Grid to land in yoga for usage in React-Native, anyone that would be open towards stretch as an alternative, I've raised a related tracking issue for CSS Grid support over on the stretch repo.
Almost a year in since creating this issue, it would be fantastic to hear back from a dev of this project, if there is any hope for seeing Grid support arrive in future.

Agreed!
It’s much harder to share components between web and native if we can’t use grid for component layout in one, when it’s such a lovely feature of making components on the web now.
Sent from my iPhone

On 10 Feb 2020, at 09:55, Rod Ritter<EMAIL_ADDRESS>wrote:

Please, this would be huge. Since most browsers support this in some way, we're starting to use CSS grid as a standard in our web dev. Would be great to be in sync with RN dev.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Any news on this? 🙏🏼

The mentioned stretch project recently started discussing how to start implementing Grid support.
Doesn't seem like there's any interest from devs on yoga. Perhaps at a later date it may be possible to substitute yoga for stretch?
Just subscribe to the issue if you haven't already and you'll be informed of any news. No need to notify everyone with a new message asking, we see the same issue thread content as you :eyes:
Let's try avoid requests for updates, cheers :+1:

sometimes playing with flexbox to make grid like design make a component really heavy. and it impact performance inside react native

I chose to React Native because of Native UI elements. But I'm fairly used to use CSS Grid instead of Flexbox in web development. If there are no plans to integrate a CSS grid layout support I'll have to switch to Flutter because it's a nice one in all solution.

I'm fairly used to use CSS Grid instead of Flexbox in web development. Lack of support for CSS Grid is a deal-breaker to me.

i hope stretch substitute for yoga.

Would be a great addition

Update in 2020?

Update in 2020? Ooops it's almost 2021

2021 already

Update in  2021    ？  2022 will be come

CSS Grid Please

hey yoga team is there any plan to support this feature. or would you mind to please open a proposal for it. Thanks

@TheEhsanSarshar if it wasn't evident to you or anyone else.. Commenting here for the sole purpose of asking for updates or expressing interest doesn't serve any purpose or provide any value than all those that have done the same before you.
Please refrain from this behaviour.
It just annoys all those who are subscribed for notifications and actually hoping to see an update with positive news. If this is something you feel is worthwhile, create a new issue, reference this one and you can all comment there.

It is very clear that anyone that could take this feature forward is not following the issue or taking any interest to get involved in it and provide any details of putting it on the roadmap or why it's not going to happen. You can try reach out to whomever is capable of moving this feature forward via other means, maybe you'll get lucky.
The alternative I mentioned earlier (Stretch) seems to have likewise hit a dead end. Development on the lib itself seems to have become stagnant and no progress on the grid feature.
Someone has to want the feature enough to devote the time into making it happen and that likely won't happen without decent financial backing / incentive.

@polarathene Ok, got it. sorry for that 😉.
if there is no traction on it. and those who could take this feature forward is not following the issue as you mentioned.
so please close the issue. there is no point on it

@TheEhsanSarshar I would not say there's no traction on this, we have 600+ emoji on the top post.
What's the "emoji threshold" to consider the issue not-worthy from the users point of view?
For any team who built its web-application on css-grid feature, having react-native not supporting it is a deal breaker (and btw I seriously don't see any reason to create layouts with flex in 2021, beyond supporting IE11).
But if the yoga team is not considering this feature, a clean statement like "we are not working on this in the foreseeable future" would be much appreciated when closing this issue! 🙃

A bit of an update for everyone on this issue:

The alternative (Stretch) seems to have become stagnant with no activity on the grid feature. If that changes and sharing an update here would be beneficial to notify all subscribers, let us know

Stretch was forked as Taffy in May 2022  under the auspices of the bevy and dioxus projects, and is now seeing regular maintenance, as well as new feature development work.
It should be noted that unlike Stretch, Taffy does not currently have bindings to languages other than Rust. However, we are open to adding them, and would welcome contributors interested in developing and maintaining such bindings (and we'd be able to provide mentorship on the Rust side of things).

Is anyone aware of other efforts to make a cross-platform implementation of CSS Grid?

Also relevant to this issue: we have an in-progress implementation of CSS Grid! The CSS Grid implementation is mostly feature complete at this point, but there are still a few bits of functionality (like baseline alignment) and a lot of testing that needs to happen before we are ready to put out a stable release. For those of you who are interested in using a CSS Grid implementation as a library in their own (non react-native) projects, we have put out an alpha release that you could play with today. And you can track the progress of the CSS Grid implementation in tracking issue (https://github.com/DioxusLabs/taffy/issues/204)

Those who are looking CSS Grid support in React Native specifically may be interested in RFC: Vision for Layout Conformance/Parity, which sets out React Native's vision for layout going forwards. As you can see, they have considered Taffy, but are not planning to adopt it in React Native. I also had some further discussion with @NickGerleman (who has recently taken over maintenance of Yoga, and has already been implementing some welcome and long overdue improvements to things like the build system) where it was explained that the primary reason for this is a strong commitment to bug-for-bug backwards compatibility in React Native's layout engine (on the basis that bugs caused by changes in layout will likely be silent and hard to detect) and a belief that it will be hard to maintain that if switching to a new layout engine (a belief I am inclined to agree with FWIW).
Thus, in terms of getting CSS Grid support into React Native, it seems like the best path forwards may be porting Taffy's implementation into Yoga. This is by no means a small task, and would involve refactoring the existing Flexbox implementation to interoperate with another layout algorithm (while maintaining bug-for-bug compatibility with the existing implementation - possibly behind a flag), as well as implementing the grid algorithm itself. But I think it is achievable with enough effort, and it would be aided by the fact that Taffy is a derivative of Yoga and that the structure of the two projects is still largely similar.

It would be amazing to see this materialize. CSS Grid is something the React Native ecosystem has wanted for a long time, and this thread has many other users of Yoga who would benefit from it as well.
I do think the strategy is doable. A lot of work, but definitely possible.
My ideal would be for Yoga to be conformant by default. The fear of behavior changes has been a stall on Yoga's development that we need to move past, but we need to be smart about it.
I do think we should aim to make Yoga's defaults conformant.
I do also agree with the making Yoga conformant by default.  As I'm sure you can tell I've veered towards caution in behavior changes. I've been playing with 7e96b65790c53359583e480776278159556b7def to add an API YGNodeLayoutAffectedByQuirk, along with YGQuirkAbsolutePercentageAgainstWrongEdge and YGQuirkTrailingColumnMarginIncorrect
but I've been trying to quantify it a bit. I have a pending change adding an API YGNodeLayoutAffectedByQuirk(YGNodeRef node, YGQuirk quirk), with  7e96b65790c53359583e480776278159556b7def code in-engine which sets where the wrong box is being used. That should help us to get a good idea on questions like "What percentage of sessions would see a layout shift if we made this change?", and an some objectivity.
YGQuirkAbsolutePercentageAgainstWrongEdge

It would be amazing to see this materialize. CSS Grid is something the React Native ecosystem has wanted for a long time, and this thread has many other users of Yoga who would benefit from it as well. I have also suspected CSS Grid would be a valuable enough addition to React Native that we could use it as a tool to start driving users to migrate their apps to conformant behavior.
As I'm sure you can tell by the other thread "how can we do this safely" is very top-of-mind. These sorts of shifts have to be done piecemeal, but I do think we have concrete ways to do them. E.g. WPT fixtures for validating the conformance of new changes, or perf testing for any sort of major algorithm change (I don't have confidence the current tests would catch many real-world issues here).

refactoring the existing Flexbox implementation to interoperate with another layout algorithm (while maintaining bug-for-bug compatibility with the existing implementation - possibly behind a flag)

My ideal would be for Yoga to be conformant by default. The fear of behavior changes has been a stall on Yoga's development that we need to move past, but we need to be smart about it.
The model I have been exploring for that is that we:

Add the change, behind a YGExperimentalFeature
Add a branch in code, to set a flag on the Node layout result if the old path was used and would result in a layout change under the new path
Expose the result under an API YGNodeLayoutAffectedByQuirk

Call this within app code, and fire an event if ever true

Measure % sessions in some real apps where we would see a shift
Add the fix, with a legacy flag if there is carnage (some threshold we will need to define 😉)
(In React Native) If there was enough carnage for a flag, lock it behind StrictLayout

Have some work drafted to start doing this for 7e96b65790c53359583e480776278159556b7def, adding YGQuirkAbsolutePercentageAgainstWrongEdge and YGQuirkTrailingColumnMarginIncorrect.
There are also some apps and frameworks inside of Meta which depend on the latest Yoga, but are no longer being actively developed. They won't see any benefit from the new things happening, and are one of the larger risk-areas to our own usage since they are more eyes-off, so I have been working to see if I can freeze them on an older version of Yoga to give a little bit more breathing room to make changes.

The stable 0.3 release of Taffy with CSS Grid was released yesterday. So it's now ready both for production usage, and for porting should anyone wish to take that on.

@NickGerleman

They won't see any benefit from the new things happening, and are one of the larger risk-areas to our own usage since they are more eyes-off, so I have been working to see if I can freeze them on an older version of Yoga to give a little bit more breathing room to make changes.

It has occured to me that the first step towards supporting CSS Grid in Yoga would be refactoring the flexbox implementation such that when it needs to measure children it is able to call into another algorithm rather than always calling recursively into itself. And if we're making this change anyway, I'm wondering if it would make sense to duplicate the flexbox algorithm into "legacy flexbox" (frozen in the current state) and "modern flexbox" (where we could go to town on the breaking changes - perhaps with an effort to get it quite close to standards compliant for the first release so that the breaking changes are mostly a one-off rather than an ongoing thing). This might be simpler than trying to feature flag everything on a fine-grained level...
Taffy uses this trait for this purpose, and in C++ you'd presumably want to use an interface. Making the algorithm logic generic over an interface provides two other benefits:

It decouples the algorithm code from the node storage code, meaning that if Yoga users already have their own tree they can lazily convert styles from that tree into Yoga's format rather than needing the eagerly duplicate everything into a yoga-specific tree.
It allows users of Yoga to take control flow back between each node in the tree and inject their own logic at this point. This could be logic like switching between strict/legacy modes, it could be calling into entirely different layout logic (e.g. FlexLayout, Taffy, or non-css layout modes like AutoLayout, but also things like text layout). It therefore also subsumes the need for MeasureFuncs as it basically is a more powerful variant of MeasureFuncs.

Taffy offers both a low-level API where the user of the library implements the above trait and handles things like caching and tree iteration logic themselves and a high-level API akin the one Yoga currently offers.


test: [M3-8432] - Cypress integration test for Object Storage Gen2: E0 endpoint, some additional unit tests

Description 📝
Add new tests for Object Storage gen2 - bucket create
Changes  🔄
List any change relevant to the reviewer.

Created new objStorageGen2 directory and new file, bucket-create-gen2.spec.ts for new integration tests
Added unit tests for new create bucket drawer

Target release date 🗓
n/a
How to test 🧪

yarn cy:run -s "cypress/e2e/core/objectStorageGen2/bucket-create-gen2.spec.ts"
yarn test OMC_CreateBucketDrawer.test.tsx
yarn test BucketRateLimitTable.test.tsx

As an Author I have considered 🤔
Check all that apply

[x] 👀 Doing a self review
[x] ❔ Our contribution guidelines
[ ] 🤏 Splitting feature into small PRs
[x] ➕ Adding a changeset
[x] 🧪 Providing/Improving test coverage
[ ] 🔐 Removing all sensitive information from the code and PR description
[ ] 🚩 Using a feature flag to protect the release
[ ] 👣 Providing comprehensive reproduction steps
[ ] 📑 Providing or updating our documentation
[ ] 🕛 Scheduling a pair reviewing session
[ ] 📱 Providing mobile support
[ ] ♿  Providing accessibility support

Unskipped the unit test that was failing here (oh man I need to relearn rebase) - we will get to the bottom of this failing test!! :D

Some updates:

adding additional timeout to the failing OMC_CreateBucketDrawer test - this is honestly just a bandaid solution, but will continue investigating the underlying issue
skipping BucketRateLimitTableTests for now - tests are now failing + table crashes the page on the Create Bucket Drawer now, will investigate the issue separately

Will be merging after github status checks (especially for test-manager - will run this a few times) pass


Very Quick Fix for #2455

Fix #2455:  Replace the regexp of the fix for #2048 with a tighter one
Note that there might still be corner cases where this fails, but this at least fixes most scenarios.

It looks like this change is already in the product: https://github.com/flyway/flyway/blob/master/flyway-core/src/main/java/org/flywaydb/core/internal/database/oracle/OracleParser.java#L57
As you said in your comment in #2455:

This migration works in 6.0.0-beta2, however, we get errors there with valid code, and beta versions are no option for production code.

Am I right in thinking the 6.0.0 release therefore fixes this issue?
Also;

we get errors there with valid code

Can you clarify what you meant by this?

Hi, sorry took a while.
I tried our code with the 6.0.0.beta. The error in #2455 did not occur. However we had another (correct) migration that failed. Pinpointing the actual reason is however not easy.
I did not yet try with 6.0.0.GA, but I assume that the error persists. I assume that this will prevent us from switching to 6, so I think we will create a support request.


make v5 backwards compatible with v4 data properties

Hi @theBowja not sure if this is related, but it looks like the latest release of genshin-db-dist is generating properties in the v5 format (I noticed because I had elementType and elementText in characters, but no element field). This of course broke because the latest released version of genhin-db is 4.3.17.
Could genshin-db-dist have both a main (for v5) and v4 branch so that we can use both v4 and v5 concurrently?
I'd also like to install v5 of genshin-db but it doesn't seem released to npm yet.
Thanks again for your great work and let me know if I can help with anything.

Maybe an easier solution is to add some tags to genshin-db-dist, so we can lock to fixed database versions to protect from api changes?

adding tags would surely be a good idea. if i could figure out how to do it o.o

v5 db for 4.3 has already been published as 5.0.4
also i plan on dropping support for v4 db very soon

Nice one, upgrading to 5 now :D

adding tags would surely be a good idea. if i could figure out how to do it o.o

In the actions I see that you are getting the version from genshin-db.version, so I guess just trigger a git tag for that same value at the end of the execution?

I just released genshin-db v5.0.7 which adds an option for backwards compatibility with genshin-db v4.
Simply add the following and all your property accesses should no longer throw errors.
genshindb.setOptions({ v4PropsOnly: true });

Upgrading to 5.x was painless, thank you for that! https://github.com/tractorcow/genshin-teamspin/pull/6


Turn SummaryStatus:Behind into a regular event and summarizerClientEl…

…ection to be false in the stress tests. (#12452)
The SummaryStatus:Behind event is dependent on the number of clients in the quorum, which is currently up to 120 clients during the stress test runs. Taking in consideration we create incidents based on number of errors (currently > 50), a single second in which the clients get behind will trigger up to 120 errors during the stress test runs. Even in production it might skew out our telemetry data. After talking to the OCEs ( Navin, Si) and Jatin, we ve decided to move it to a regular telemetry event for now.
Also, we are taking the chance to enforce summarizerClientElection to be always false during the stress test runs.
Sample incidents:
https://portal.microsofticm.com/imp/v3/incidents/details/340813540/home
https://portal.microsofticm.com/imp/v3/incidents/details/341118841/home
For more information about how to contribute to this repo, visit this page.
For specific guidelines for Pull Requests in this repo, visit this wiki page.
The sections included below are suggestions for what you may want to include.
Feel free to remove or alter parts of this template that do not offer value for your specific change.
Description

A concise description of the changes (bug or feature) and their impact/motivation.
If this description is short enough to be used as the title, delete this section and just use the title.

For bug fixes, also include specifics of how to reproduce it / confirm it is fixed.

If this Pull Request should close/resolve any issues when merged, use the special syntax for that here.

Reviewer Guidance

List any specific things you want to get reviewer opinions on, and anything a reviewer would need to know to review this PR effectively.
Things you might want to include:

Questions about how to properly make automated tests for your changes.
Questions about design choices you made.
Descriptions of how to manually test the changes (and how much of that you have done).
etc.

If you have any questions in this section, consider making the PR a draft until all questions have been resolved.

Does this introduce a breaking change?

If this introduces a breaking change, please describe the impact and migration path for existing applications below.
See Breaking-vs-Non-breaking-Changes for details.
If there are no breaking changes, delete this section.

Any relevant logs or outputs

Use this section to provide either screenshots or output of logs as code snippets

Other information or known dependencies

Any other information or known dependencies that is important to this PR.
Links to internal bug/work tracker items.
TODO that are to be done after this PR.

nit: You should probably remove the template from the description.


added node creation

Codecov Report

Merging #20 (fe459dd) into main (f959f88) will decrease coverage by 0.23%.
The diff coverage is 78.94%.

@@            Coverage Diff             @@
##             main      #20      +/-   ##
==========================================
- Coverage   80.20%   79.97%   -0.24%
==========================================
  Files          10       10
  Lines         768      799      +31
==========================================
+ Hits          616      639      +23
- Misses        106      112       +6
- Partials       46       48       +2

Impacted Files
Coverage Δ

model.go
82.35% <ø> (ø)

node.go
77.71% <45.45%> (-2.29%)
:arrow_down:

smugmug.go
93.33% <92.59%> (-0.67%)
: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 f959f88...fe459dd. Read the comment docs.


Scrollbar click closes modal with long content

Prerequisites

[X] I have searched for duplicate or closed issues
[X] I have validated any HTML to avoid common problems
[X] I have read the contributing guidelines

Describe the issue
Previously on v5.1 when a modal was open, I was able to scroll throw the content by clicking any part of the window scrollbar, now on 5.2 clicking the scrollbar closes automatically the modal.
I tested on bootstrap docs page just to be sure I wasn't doing anything different and the issue can be tested by opening the demo modal for long content and clicking the scrollbar.
Reduced test cases
v5.1 (scroll bar click works)
https://getbootstrap.com/docs/5.1/components/modal/#scrolling-long-content
v5.2.0 (scroll bar click closes modal)
https://getbootstrap.com/docs/5.2/components/modal/#scrolling-long-content
What operating system(s) are you seeing the problem on?
Windows
What browser(s) are you seeing the problem on?
Chrome, Firefox, Microsoft Edge
What version of Bootstrap are you using?
v5.2.0

This issue seems to come from https://github.com/twbs/bootstrap/commit/d05c42a3979be30efc7a932c3c0f483098841b19.

I cant confirm this behaviour as well.


Warning: Cannot read property 'description' of null  Use --force to continue.

I am using Grunt V1.0.1 and grunt-electron-installer V2.0.0, the build is failed with this Warning, and when add --force to grunt command ,there is nothing generated except "update.exe". Does it could be a bug?

it's a known issue.  Please, check, is it the same? https://github.com/electron/windows-installer/issues/41

Maybe, but  https://github.com/electron/windows-installer/issues/41 didn't solve the problem. And the strange thing is the problem do not show anymore when i install Grunt and grunt-windows-installer again, replace with infinite waiting '"Running "create-windows-installer:ia32" (create-windows-installer) task", the release are full of bugs i think, maybe i just go to use electron-packager or  electron-builder.

Seems this project is base on windows-installer, but electron/windows-installer#41 is still open open right now, not solved.

@GeeshangXu yes, but 2.2.0 already released, probably. Could you please re-install grunt-electron-installer and check once again?

@havenchyk  Yes, this problem sovled by replace the old electron-winstaller V2.0.5 in grunt-electron-installer's node_modules with the latest version V2.2.0, thank you!  But the the latest version 2.0.0 of grunt-electron-installer is still depend on the old electron-winstaller 2.0.5, so it need to be updated to fix the issue.

@GeeshangXu glad you solved your issue. Well, I haven't rights to merge pr's, maybe @kevinsawicki could provide them? I'll be glad to update to the latest version.

@GeeshangXu let's wait for new version, fix is already merged.

Good!