proof of concept: custom runspace to run PS code from ST

This is an experimental branch. Do not use other than for testing.
This branch adds funspace.exe, a 'server' that runs PS code using
the PS hosting API. funspace.exe is written in F#.
ST communicates with funspace.exe via stdin and stdout redirection.
At the moment, funspace integration simply lets you:

run the current line in ST
see the output in the console

funspace.exe works asynchronously, so waiting for PS code to run
should not block ST UI thread.
It's pretty broken, by the way, but it's cool :)
To use:

checkout this branch
copy folder content to Packages/PowerShell
open a file
type in a valid PS command line (e.g. 'Get-Variable')
open Command Palette
select 'PowerShell: Run Current Line'
open the ST console to see the output

Cannot try it. Keep getting crash in funspace.exe

I think I fixed the crashing on startup. Also, the PS result is now shown in an output panel resembling the PowerShell console.

If we go ahead with this experiment and turn it into a feature, we need to vendorize my sublime_plugin_lib, as it actually lives in its own repo.

cool, finally works for me! I had some issue with reloading project, ST didn't want to understand that there is a new command now.
Observations:

Need a session state (probably a session per tab), so can reuse variables from previous run.
Separating output from input is a way that powershell_ise already tried and failed. We need to work on integration output directly to the page.

I will check out the code and provide more feedback.

need to capture error, warning and verbose stream as well

@guillermooo I think it's awesome proof of concept and I would like to work with you to make it a prototype. I was thinking about packaging story and I think you should create a separate repository (perhaps, instead of https://github.com/SublimeText/PowerShellUtils) for this work.
There are few reasons:

It's not going to be cross-platform right away, unlike current Sublime/PowerShell
People who use Sublime/PowerShell may not carry about running PS inside ST.
You will have to ship CLR binaries. Since you cannot unload dll, upgrade story will be way more painful then for any other sublime package. (althought we can use powershell Add-Type to do it better)
having a granular packaging is a good thing. Be modular, you know.

P.S.: I would recommend remove PowerShellUtils from list of ST packages.

The name is very generic.
I cannot make it work, so I assume it's broken.
If you will create a separe project for this work, please use something more descriptive, maybe like 'PowerShell REPL' or 'PowerShell terminal'.

I'm starting to think we should probably create a PowerShell org? Again, MS may be uncomfortable with this, so perhaps we'll have to call it ST PowerShell, PS Sublime Text or something like that.
For the time being, I'll create a the new repo under my account, though.

Whatever you find appropriate. I would like to have some working stuff to publish first :)

Development will happen at my Funspace repo when it does...


v1.12

Language

[x] #222
[x] #95
[x] #202
[ ] #182
[ ] #162
[x] #271
[x] #119
[x] #270
[x] #224
[x] #225
[x] #226
[x] #261
[x] #263
[x] #264
[x] #265
[x] #266
[x] #267
[x] #268
[x] #269
[x] #275
[x] #276
[ ] #277
[x] #281
[x] #280

Lib

[x] #223
[x] #228
[x] #262
[ ] #272
[x] #278

Bug Fix

[x] #220
[x] #221
[x] #229

https://github.com/pikasTech/pikascript/commit/9718b1a482caa6bc27264f4e8b12ee2ef80d4b65


Document How To Manage a Swarm Registry

File: engine/swarm/admin_guide.md, CC @mstanleyjones
It would be very useful if there was some complete documentation on how to run a docker registry local to the swarm.
I have found many references to this on the internet, but they are all incomplete in detail, so it is not possible to recreate those solutions.
This is perhaps the best solution I have discovered, but I cannot reproduce it.
https://stackoverflow.com/questions/39370925/docker-swarm-worker-nodes-not-finding-locally-built-image

@stevvooe can you help out with this?

Is there anything that is specifically missing from the documentation? https://github.com/docker/docker.github.io/blob/master/registry/deploying.md should cover this.


Support/wagtail-50

Wagtail 5.0 release notes: https://docs.wagtail.org/en/stable/releases/5.0.html

Update testing for Wagtail 5.0 and Django 4.2.
Dropped support for Python 3.7.

Thanks for the PR, @katdom13 !
Please don't forget to update the docs as well 🙏 https://github.com/jazzband/wagtailmenus/blob/master/docs/source/index.rst
(I can also do it on the weekend if you don't have the time)

Hi @MrCordeiro ,
Thank you for the reminder,
I updated the version compatibility here:
https://github.com/jazzband/wagtailmenus/pull/457/files#diff-4eec6cec5f6fab1548b85433ea8ca81315ae165db4b7f84019f287df9015699f,
Please let me know if I forgot something.
Thanks!


Adds 1.16.3 to help work around upgrade issues

fixes #274

typo fixed here 746e254 we currently don't have matrix tests setup for old versions, all we do is validate the tar.gz and date.


Fix broken link

Also, as a side note, I found this link confusing. I was expecting it to take me to a list of pre-made estimators. Not a definition of what a pre-made estimator is. (maybe the glossary definition should link to a list of pre-made estimators?)

@MarkDaoust about the link going to glossary instead of API docs.
Thanks for the link fix.

Maybe the glossary definition should link to a list of pre-made estimators?

SGTM. Fixed internally. Will get pushed out to github soon.


'BigUInt' is ambiguous for type lookup in this conte

after pod update,this error is shown:'BigUInt' is ambiguous for type lookup in this conte

Try updating cocoapods. It worked for me, hope it works for you.
sudo gem install cocoapods --pre

podfile updated

Beta version of CocoaPods doesn't work for me. Ended up using this:
import struct BigInt.BigUInt
instead of:
import BigInt

You can use release version of cocoapods


validate shape of api key

Current dependencies on/for this PR:

main

PR #554   👈

This stack of pull requests is managed by Graphite.


Use cmake to find packages

Merge in changes to CMakeList.txt
This merge includes some cleanup to the CMakeList:

Executables are linked to a static library (rather than the shared one)
Packages are found using CMake's own find_package function rather than environment variables or hardcoded paths.
Source files are found by globbing rather than listed explicitly


Test Code lenses won't work if GitLens extension is installed.

Environment data

VS Code version: 1.31.0
Extension version (available under the Extensions sidebar): 2019.1.0
OS and version: Windows 10 (1809)
Python version (& distribution if applicable, e.g. Anaconda): Python 3.7.2
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): N/A
Relevant/affected Python packages and their versions: PyTest 4.0.1, 4.1.1, 4.2.0

Expected Behaviour
If both GitLens and Python extensions are installed, I'd expect both code lenses to show up.
Actual Behavior
If the GitLens extension is installed, there seems to be a conflict with how CodeLenses are handled, and GitLens wins.
Steps to reproduce:

Install the Python extension
Run Test Discovery
Notice that the code lenses show up
Install the GitLens extension
Run Test Discovery
Notice that the Python code lenses no longer show up

Looks to be the same as #4239

Closed as dup of #4239


Properly register console actions and console disconnected messages

ContextActions can now be registered by the parent container instead of passed in
Overflow actions are passed in and shown
Pass in a node for displaying when console is disconnected unexpectedly

Fixes #112

Found a couple other issues I needed to address before merging


Storage performance issues for azure files mount

This issue is a: (mark with an x)

[x] bug report -> please search issues before submitting
[ ] documentation issue or request
[ ] regression (a behavior that used to work and stopped in a new release)

Issue description
We are evaluating running Appsmith in Azure Container Apps (in West Europe region), but their Git feature is very disk intensive and by using volumes with Azure Files, there are plenty of performance issues, which doesn't appear to happen by using an AKS cluster with the default storage class (disk.csi.azure.com) or by running our own VM with a SSD and Docker.
I also tried to use Premium file storage shares to check if the IOPS bump would solve it, but the performance issues persisted.
Is there any clear performance difference between using disks and azure files? Or maybe latency issues?

Hi, Can you send your details to acasupport at microsoft dot com? we will investigate.

Email sent

@rhuanbarreto were you able to solve this issue? I am in a similar situation - building a service which would be performing local git operations on large repositories - and I am looking into using Azure Container Apps but even the Premium storage Azure Files mount has poor performance for all of the file operations.
I also noticed https://github.com/microsoft/azure-container-apps/issues/485 which could potentially solve this but would also be probably very expensive.

Is there a workaround this? As the performance hit is quite hefty is certain scenarios.


[QA] Backpack:  wearables are not properly changed

Explorer Alpha build version:
0.3.250-main-08f208c
Issue Description:
When the user changes wearables, they are not properly changed.
Steps to reproduce:

Go to the main build
Go to the backpack
Change your lower body wearables and try some shorts

Expected behaviour:
Changes should be reflected
Current behaviour:
Changes are not reflected
Reproduction rate:

[ ] < 10%
[ ]  < = 25%
[ ]  50%
[ ]  < = 75%
[X ]  100%

Severity:

[ ] Cosmetic
[ ] Minor
[ ] Medium
[X ] High
[ ] Critical
[ ] Blocker

Priority:

[ X] High
[ ] Medium
[ ] Low

Platforms / OS:

[X ] Windows 11
[ ] Windows 10
[ ] Mac Sonoma
[ ] Mac (specify the version on Additional Notes)

Evidence:
https://github.com/decentraland/unity-explorer/assets/146749313/3c3d54b7-ba8f-48bb-938b-16265cd206bb

Asset bundles for some of the off-chain wearables are missing because they have been redeployed recently because of the genderless feature, but they are already in the queue to be converted. After that finishes, this problem should be fixed

Duplicated from #862 , the solution implemented is the same for both


Test failures on Arch Linux with master

Running ./Staging/Test after a build gets me numerous test failures:
clFFT client API version:  2.6.0
clFFT runtime version:     2.6.0

    CL_PLATFORM_PROFILE:     FULL_PROFILE
    CL_PLATFORM_VERSION:     OpenCL 2.0 AMD-APP (1642.5)
    CL_PLATFORM_NAME:        AMD Accelerated Parallel Processing
    CL_PLATFORM_VENDOR:      Advanced Micro Devices, Inc.
    CL_PLATFORM_EXTENSIONS:  cl_khr_icd cl_amd_event_callback cl_amd_offline_devices

    CL_DEVICE_NAME:                      Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
    CL_DEVICE_VERSION:                   OpenCL 1.2 AMD-APP (1642.5)
    CL_DRIVER_VERSION:                   1642.5 (sse2,avx)
    CL_DEVICE_TYPE:                      CPU
    CL_DEVICE_MAX_CLOCK_FREQUENCY:       3801
    CL_DEVICE_ADDRESS_BITS:              64
    CL_DEVICE_AVAILABLE:                 TRUE
    CL_DEVICE_COMPILER_AVAILABLE:        TRUE
    CL_DEVICE_OPENCL_C_VERSION:          OpenCL C 1.2
    CL_DEVICE_MAX_WORK_GROUP_SIZE:       1024
    CL_DEVICE_MAX_WORK_ITEM_DIMENSIONS:  3
                         Dimension[ 0 ]  1024
                         Dimension[ 1 ]  1024
                         Dimension[ 2 ]  1024
    CL_DEVICE_HOST_UNIFIED_MEMORY:       TRUE
    CL_DEVICE_MAX_CONSTANT_BUFFER_SIZE:  65536 ( 64 KB )
    CL_DEVICE_LOCAL_MEM_SIZE:            32768 ( 32 KB )
    CL_DEVICE_GLOBAL_MEM_SIZE:<PHONE_NUMBER>8 ( 15935 MB )
    CL_DEVICE_MAX_MEM_ALLOC_SIZE:<PHONE_NUMBER> ( 3983 MB )
    CL_DEVICE_EXTENSIONS:                cl_khr_fp64 cl_amd_fp64 cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_3d_image_writes cl_khr_byte_addressable_store cl_khr_gl_sharing cl_ext_device_fission cl_amd_device_attribute_query cl_amd_vec3 cl_amd_printf cl_amd_media_ops cl_amd_media_ops2 cl_amd_popcnt cl_khr_spir cl_khr_gl_event

Result comparison tolerance is 0.001
Random test's seed is 129553170
[==========] Running 4218 tests from 12 test cases.
[----------] Global test environment set-up.
[----------] 10 tests from test_harness_tests_buffer
...
[----------] 10 tests from test_harness_tests_buffer (35 ms total)

[----------] 67 tests from clfft_UnitTest
...
[----------] 67 tests from clfft_UnitTest (722 ms total)

[----------] 220 tests from accuracy_test_pow2_single
...
 But it seems it's using AMD's CPU version. Any thoughts on why this is happening?

Is this a regression from a previous version of the library? or are you seeing this for the first time?

With the 2.4 release I can't even get the test program to start testing:
clFFT client API version:  2.4.0
clFFT runtime version:     2.4.0

OpenCL platform [ 0 ]:
    CL_PLATFORM_PROFILE:     FULL_PROFILE
    CL_PLATFORM_VERSION:     OpenCL 2.0 AMD-APP (1642.5)
    CL_PLATFORM_NAME:        AMD Accelerated Parallel Processing
    CL_PLATFORM_VENDOR:      Advanced Micro Devices, Inc.
    CL_PLATFORM_EXTENSIONS:  cl_khr_icd cl_amd_event_callback cl_amd_offline_devices

OpenCL platform [ 1 ]:
    CL_PLATFORM_PROFILE:     FULL_PROFILE
    CL_PLATFORM_VERSION:     OpenCL 1.2 CUDA 7.5.9
    CL_PLATFORM_NAME:        NVIDIA CUDA
    CL_PLATFORM_VENDOR:      NVIDIA Corporation
    CL_PLATFORM_EXTENSIONS:  cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll cl_nv_copy_opts

OpenCL platform [ 2 ]:
    CL_PLATFORM_PROFILE:     FULL_PROFILE
    CL_PLATFORM_VERSION:     OpenCL 1.2 LINUX
    CL_PLATFORM_NAME:        Intel(R) OpenCL
    CL_PLATFORM_VENDOR:      Intel(R) Corporation
    CL_PLATFORM_EXTENSIONS:  cl_khr_icd cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_spir cl_intel_exec_by_local_thread cl_khr_depth_images cl_khr_3d_image_writes cl_khr_fp64

OPENCL_V_THROWERROR< CLFFT_DEVICE_NOT_FOUND > (385): Getting OpenCL devices ( ::clGetDeviceIDs() )
terminate called after throwing an instance of 'std::runtime_error'
  what():  OPENCL_V_THROWERROR< CLFFT_DEVICE_NOT_FOUND > (385): Getting OpenCL devices ( ::clGetDeviceIDs() )
/home/ruben/rubenvb-AUR/clfft/PKGBUILD: line 32: 24081 Aborted                 (core dumped) ./staging/Test

This remains so even if only the AMD CPU OpenCL ICD is present.

Gave my answer in #115. Closing this.


'md-option' is not a known element

Bug, feature request, or proposal:
Bug (or wrong usage?)
What is the expected behavior?
Options should be displayed within the select element.
What is the current behavior?
The whole application does not render
What are the steps to reproduce?
Tried to reproduce it with a plunkr, was happy when i edited your template and saw i got the same error. after opening and verifying it in a new private window the error disappeared.
So i assumed it could be a client cache problem, but after retrying with different browsers i still get not managed this problem.
Which versions of Angular, Material, OS, browsers are affected?
I am using Material 2.0.0-alpha.11-3 with Angular 2.2.4
Is there anything else we should know?
I am using Angular-CLI
Unhandled Promise rejection: Template parse errors:
'md-option' is not a known element:
1. If 'md-option' is an Angular component, then verify that it is part of this module.
2. If 'md-option' is a Web Component then add "CUSTOM_ELEMENTS_SCHEMA" to the<EMAIL_ADDRESS>of this component to suppress this message. ("h2>User hinzufügen</h2>
					<md-select [(ngModel)]="aUserId" name="user" placeholder="User">
						[ERROR ->]<md-option *ngFor="let item of aUser" value="5">{{item.firstname}} {{item.lastname}}</md-option>
					<"): MyComponent@17:6
TemplateParser</TemplateParser.prototype.parse@http://localhost:4200/vendor.bundle.js:18368:19 [<root>]
RuntimeCompiler</RuntimeCompiler.prototype._compileTemplate@http://localhost:4200/vendor.bundle.js:40389:30 [<root>]
RuntimeCompiler</RuntimeCompiler.prototype._compileComponents/<@http://localhost:4200/vendor.bundle.js:40309:56 [<root>]
RuntimeCompiler</RuntimeCompiler.prototype._compileComponents@http://localhost:4200/vendor.bundle.js:40309:9 [<root>]
RuntimeCompiler</RuntimeCompiler.prototype._compileModuleAndComponents/createResult@http://localhost:4200/vendor.bundle.js:40205:13 [<root>]
Zone$1</Zone</Zone.prototype.run@http://localhost:4200/vendor.bundle.js:95823:24 [<root> => <root>]
scheduleResolveOrReject/<@http://localhost:4200/vendor.bundle.js:96219:52 [<root>]
Zone$1</Zone</Zone.prototype.runTask@http://localhost:4200/vendor.bundle.js:95861:28 [<root> => <root>]
drainMicroTaskQueue@http://localhost:4200/vendor.bundle.js:96115:25 [<root>]

Hi, I had a similar issue, I destroyed the node_modules folder and reinstalled using npm install, the issue was gone.

I had to import the MdSelectModule separate to the MaterialModule to get it to work.

@stefan-niedermann @tariknz  Can you try destroying the node_modules folder and reinstalling, as Matthieu did?  You shouldn't have to import the select module separately, given that the select module is part of the MaterialModule.  It sounds like something in the build hasn't updated.

Hi folks, thanks for the tip. I will try this and then post the result here :)

Since this seems like a node_modules issue, I'm going to close this. Feel free to open a new issue if a fresh install doesn't help.

For the people reading this in the future: for me update from 2.0.0-alpha.11 to 2.0.0-alpha.11-3

That's fine thanks @kara haven't been to replicate it since.

@kara unfortunately, I'm hitting the very same problem right now. I just initialized a new project with angular-cli and added @angular/material as per getting started. Code itself works fine, but ng test fails with 'md-tab-group' is not a known element.
Here you will find a repo that replicates problem, including Travis build that shows it's failing.

Disregard previous comment, I had mis-configured TestBed.

Hi,
I am facing same issue with
angular-material 2.0.0-beta.2, Angular 2.4.10
Unhandled Promise rejection: Template parse errors:
Can't bind to 'value' since it isn't a known property of 'md-option'.

If 'md-option' is an Angular component and it has 'value' input, then verify that it is part of this module.
If 'md-option' is a Web Component then add "CUSTOM_ELEMENTS_SCHEMA" to the<EMAIL_ADDRESS>of this component to suppress this message.
("ct name="processVar" placeholder="" ngDefaultControl>
<md-option *ngFor="let vars of variables" [ERROR ->][value]="vars.variable_id">
{{ vars.variable_name }}

"): VariableList@1:46
'md-option' is not a known element:
If 'md-option' is an Angular component, then verify that it is part of this module.
If 'md-option' is a Web Component then add "CUSTOM_ELEMENTS_SCHEMA" to the<EMAIL_ADDRESS>of this component to suppress this message. ("
[ERROR ->]<md-option *ngFor="let vars of variables" [value]="vars.variable_id">
{{ vars.variable_na"): VariableList@1:4
'md-select' is not a known element:
If 'md-select' is an Angular component, then verify that it is part of this module.
If 'md-select' is a Web Component then add "CUSTOM_ELEMENTS_SCHEMA" to the<EMAIL_ADDRESS>of this component to suppress this message. ("[ERROR ->]
<md-option *ngFor="let vars of vari"): VariableList@0:0 ; Zone:  ;

@niranjanwnmt Did you manage to fix the issue? I'm also having an issue. I'm using angular-seed as a setup

probably you just forgot to import MdSelectModule and include to your module imports array

Started working after adding import { MaterialModule } from '@angular/material';
import { MdSelectModule } from '@angular/material';
and importing it to array like below on the same module as where the form is. If added to app.module.ts it was still giving error
imports: [
BrowserModule,
FormsModule,
HttpModule,
MaterialModule,
MdSelectModule
],

MaterialModule seems to be deprecated.

I got it to work, and my full material.module.ts file now looks like this
`import { NgModule } from '@angular/core';
import {
MdButtonModule,
MdMenuModule,
MdToolbarModule,
MdIconModule,
MdCardModule,
MdDialogModule,
MdFormFieldModule,
MdSelectModule
} from '@angular/material';
@NgModule({
imports: [
MdButtonModule,
MdMenuModule,
MdToolbarModule,
MdIconModule,
MdCardModule,
MdDialogModule,
MdFormFieldModule,
MdSelectModule
],
exports: [
MdButtonModule,
MdMenuModule,
MdToolbarModule,
MdIconModule,
MdCardModule,
MdDialogModule,
MdFormFieldModule,
MdSelectModule
]
})
export class MaterialModule {}`
Then I import it into my app.module.ts file, like this:
import { MaterialModule } from './material/material.module'; @NgModule({ ...   imports: [ ...     MaterialModule, ... ] })

Another way is to use class attribute of button element. <button class='md-button md-raised'> Foo </button>. Ultimately md-button or md-raised are css classes.


Change number of joint keypoint from 29 to 17

Hi, thanks for your work.
I have successfully replicated your work, and it is truly impressive. However, I have encountered an issue regarding multiperson videos. The pose estimation becomes unstable when there are multiple people in the video. To address this, I have attempted to track the skeleton of each person using Alphapose and MotionBert, which resulted in obtaining 17 3D joint keypoints. I am curious to know if this work can still produce the same result even if the input number of joint keypoints is not 29. Thanks.

Hi @pinya52,
As the author said in this issue #121, the model also gives the format of 24/17 joints output.


Is it bad practice to use app.add_background_task() given it reuses the current connection

The database connection is stored in g.connection when auto-acquired in QuartDB.before_request().
Now if app.add_background_task() is used the app context g is copied over to the background task so that

a single DB connection will be used in 2 different tasks, which is not supported by the postgres protocol
the connection will be prematurely released when the main task (the request handling function) ends while the background task still runs and it actually needs an open connection.

Above said, shouldn't app.add_background_task() be avoided so that the DB connection is not shared by two tasks?

I agree this is a problem. I think usage of g.connection in a background task is a bad idea - I've not noticed this as I always use async with quart_db.connection() as connection: in a background task.
I think Quart is maybe at fault for copying rather than creating a new context for background tasks. Would you agree?

I think Quart is maybe at fault for copying rather than creating a new context for background tasks. Would you agree?

Yes, in this particular case of a non-sharable resources such a db connection, this context attribute should not be copied. Then for sake of framework simplicity, no context should be copied over to the background task at all. The framework still allows for context copying if a developer desires to do so.

I've changed how the background task app context is created in Quart 0.19, this should now be fixed.


Recommended list of secondary DNS providers with NOTIFY and AXFR

Requirements:

Provide secondary DNS services
Should support NOTIFY and AXFR

NOTE: Also add any known limitations and cons to each network, if it has been generally experienced by users.
<EMAIL_ADDRESS>uses: FreeDNS and ClouDNS

DNS Made Easy

CloudDNS

FreeDNS

CloudDNS

Do we really need this ?

It is a good list for people without a lot of knowledge. I spent a lot of time not know about this 3 weeks ago. I didn't even know what secondary DNS was before March :P

https://inwx.com
Info about secondary DNS is here:
https://kb.inwx.com/index.php?action=artikel&cat=22&id=207&artlang=en

https://ns-global.zone/


beta adaptive icon

imo that outline style looks more like icon for some iconpack
or I have a bad taste idk

Looking at the icon on my homescreen I kinda have to agree with @wight554, this does not look good as an application icon because it stands out in stark contrast with everything else I have on my phone. All the people I've shown the icon to have told me they want the ability to use the old icon should I choose to merge this PR, and that does not bode well for this change.

I agree. It looks completely different on a phone - it doesn't scale well. Back to the drawing board :)

@splendidbits No I'm not fixated on any colors, the burgundy from the original logo can very well go. The app is pretty much an independent project with its own set of features and an arguably better UI, but I've retained the name to reflect the original goal of why I started with this as well as retaining a slight brand identification for newcomers to recognize the utility of the application.


The transition animation disappears, and the problem occurs when the transiton component is used with the router-view and keepalive.（transition组件和router-view和keepalive一起用时，动画消失）

Version
2.5.16
Reproduction link
https://github.com/varjay/testanime
Steps to reproduce

If the A page is keepalive, the B page is not keepalive. When returning from the B page to the A page, the B page has no transition and disappears directly from the dom.
What is expected?
Can you make transition, router-view, and keepalive work together?
What is actually happening?
Transition animation did not happen.

Resolved, don't use 'if' to customize the show keepalive, use keepalive's 'include'.


How can i disable Reddison auto configuration ? There is a test environment where we dont want redis.

Spring boot app does not start as we dont have cache in test env.

@sumitsonkhla
I think your solution is the only way to disable it.


List of known working wifi dongles

We need a page that lists know working and problematic wifi dongles, so we can recommend them to users.
 Front conversations

Add 2.4/5GHz dongles, and have internal advice on how to choose a dongle that works.

Done: https://docs.resin.io/hardware/wifi-dongles/


Inherit language from file vname when creating new anchor.

This helps to create anchors from other languages. For example JavaScript indexer can create "imputes" edges pointing from .java files.
Tested:
bazel test //kythe/javatests/...

Ah, not only that, but this was supposed to have been the behaviour all along.
I should probably document that better.

I didn't update implicit anchors because it was breaking jvm edges.


[SPARK-46044][PYTHON][TESTS] Improve test coverage of udf.py

What changes were proposed in this pull request?
Improve test coverage of udf.py
Why are the changes needed?
Subtasks of SPARK-46041 to improve test coverage
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Test changes only.
Was this patch authored or co-authored using generative AI tooling?
No

Merged to master.


Node version limitation

While trying to install this module I faced an issue with node version
yarn add strapi-plugin-redcron
yarn add v1.22.19
warning ../../../../package.json: No license field
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
error<EMAIL_ADDRESS>The engine "node" is incompatible with this module. Expected version ">=14.19.1 <=18.x.x". Got "20.11.0"
error Found incompatible module.

I think if claimed compatibility with base stapi mentioned

Then it should support same node versions as strapi core.
https://github.com/strapi/strapi/blob/develop/package.json#L146
Currently it's locked to
"node": ">=18.0.0 <=20.x.x",

@cpaczek this is still an issue now. Any plan to support the plugin further?

@cpaczek this is still an issue now. Any plan to support the plugin further?

Pretty sure @derrickmehaffy added this functionality to the base redis plugin for v5

Yup it was merged into my redis plugin for v5


Fix for a UI issue on website

Purpose
This is a fix for UI issue on https://ballerina.io/learn/quick-tour/ page.
The bash keyword is shown in the website as it is before showing the bash command.
Related PRs

List any other related PRs.

Special notes

Any special testing needed to verify integrity.

Any checklist items to be verified before production deployment?
Special styling concerns?
Related media files?


Create Authority Failed

Version:

commit 522e1826946e8e5b0f661a5ffb637838827f7cec
Author: Rick Breidenstein<EMAIL_ADDRESS>Date:   Mon Mar 13 18:45:10 2017 -0400
added python3-dev to dependencies (#724)

make release fails without it

Log:

[2017-03-14 05:42:09,927] ERROR in schema: 'NoneType' object cannot be interpreted as an integer
Traceback (most recent call last):
File "/www/lemur/lemur/common/schema.py", line 158, in decorated_function
resp = f(*args, **kwargs)
File "/www/lemur/lemur/authorities/views.py", line 223, in post
return service.create(**data)
File "/www/lemur/lemur/authorities/service.py", line 110, in create
cert = upload(**kwargs)
File "/www/lemur/lemur/certificates/service.py", line 220, in upload
cert = Certificate(**kwargs)
File "", line 4, in init
File "/www/lemur/lib/python3.5/site-packages/sqlalchemy/orm/state.py", line 414, in _initialize_instance
manager.dispatch.init_failure(self, args, kwargs)
File "/www/lemur/lib/python3.5/site-packages/sqlalchemy/util/langhelpers.py", line 60, in exit
compat.reraise(exc_type, exc_value, exc_tb)
File "/www/lemur/lib/python3.5/site-packages/sqlalchemy/util/compat.py", line 187, in reraise
raise value
File "/www/lemur/lib/python3.5/site-packages/sqlalchemy/orm/state.py", line 411, in _initialize_instance
return manager.original_init(*mixed[1:], **kwargs)
File "/www/lemur/lemur/certificates/models.py", line 123, in init
cert = lemur.common.utils.parse_certificate(kwargs['body'])
File "/www/lemur/lemur/common/utils.py", line 53, in parse_certificate
return x509.load_pem_x509_certificate(body, default_backend())
File "/www/lemur/lib/python3.5/site-packages/cryptography/x509/base.py", line 43, in load_pem_x509_certificate
return backend.load_pem_x509_certificate(data)
File "/www/lemur/lib/python3.5/site-packages/cryptography/hazmat/backends/multibackend.py", line 341, in load_pem_x509_certificate
return b.load_pem_x509_certificate(data)
File "/www/lemur/lib/python3.5/site-packages/cryptography/hazmat/backends/openssl/backend.py", line 1169, in load_pem_x509_certificate
mem_bio = self._bytes_to_bio(data)
File "/www/lemur/lib/python3.5/site-packages/cryptography/hazmat/backends/openssl/backend.py", line 490, in _bytes_to_bio
data_char_p = self._ffi.new("char[]", data)
TypeError: 'NoneType' object cannot be interpreted as an integer
'NoneType' object cannot be interpreted as an integer
Traceback (most recent call last):
File "/www/lemur/lemur/common/schema.py", line 158, in decorated_function
resp = f(*args, **kwargs)
File "/www/lemur/lemur/authorities/views.py", line 223, in post
return service.create(**data)
File "/www/lemur/lemur/authorities/service.py", line 110, in create
cert = upload(**kwargs)
File "/www/lemur/lemur/certificates/service.py", line 220, in upload
cert = Certificate(**kwargs)
File "", line 4, in init
File "/www/lemur/lib/python3.5/site-packages/sqlalchemy/orm/state.py", line 414, in _initialize_instance
manager.dispatch.init_failure(self, args, kwargs)
File "/www/lemur/lib/python3.5/site-packages/sqlalchemy/util/langhelpers.py", line 60, in exit
compat.reraise(exc_type, exc_value, exc_tb)
File "/www/lemur/lib/python3.5/site-packages/sqlalchemy/util/compat.py", line 187, in reraise
raise value
File "/www/lemur/lib/python3.5/site-packages/sqlalchemy/orm/state.py", line 411, in _initialize_instance
return manager.original_init(*mixed[1:], **kwargs)
File "/www/lemur/lemur/certificates/models.py", line 123, in init
cert = lemur.common.utils.parse_certificate(kwargs['body'])
File "/www/lemur/lemur/common/utils.py", line 53, in parse_certificate
return x509.load_pem_x509_certificate(body, default_backend())
File "/www/lemur/lib/python3.5/site-packages/cryptography/x509/base.py", line 43, in load_pem_x509_certificate
return backend.load_pem_x509_certificate(data)
File "/www/lemur/lib/python3.5/site-packages/cryptography/hazmat/backends/multibackend.py", line 341, in load_pem_x509_certificate
return b.load_pem_x509_certificate(data)
File "/www/lemur/lib/python3.5/site-packages/cryptography/hazmat/backends/openssl/backend.py", line 1169, in load_pem_x509_certificate
mem_bio = self._bytes_to_bio(data)
File "/www/lemur/lib/python3.5/site-packages/cryptography/hazmat/backends/openssl/backend.py", line 490, in _bytes_to_bio
data_char_p = self._ffi.new("char[]", data)
TypeError: 'NoneType' object cannot be interpreted as an integer

Lemur is python3 only.

Which authority plugin are you using?

Plugin: CFSSL

Do you have CFSSL_ROOT set in your config?

Judging from your other issues this seems like it was resolved, is that the case?


Containers using other containers net namespace don't have IP addresses

This particularly affects k8s, where every container uses a pause containers net namespace.
The IP should show up in the details panel, and we should ignore pause containers for the purpose of rendering.

we should ignore pause containers for the purpose of rendering.

In the container view? Why?
If I don't want to see the gory insides of a pod, surely I'd use the Pod view, in which case none of the individual containers should show up.

Sorry I wasn't being clear.  I mean for the purpose of rendering edges; we currently can't attribute short lived connection edges to containers on k8s as every net namespace is shared.  We can do better if we ignore pause containers for this purpose.

We can do better if we ignore pause containers for this purpose.

How so? In general a single pod will be made up of multiple containers plus the pause container, all sharing the same netns. Which container would you attribute connections to?

Duplicate if https://github.com/weaveworks/scope/issues/986

How so? In general a single pod will be made up of multiple containers plus the pause container, all sharing the same netns.

Yes, in general we can't solve this problem with conntrack data.  But I don't think its actually that usual to have multiple containers per pod, so we can do better in the case when their is only one by ignoring the pause container.

Which container would you attribute connections to?

If there is more than one container with the IP we ignore that edge as we can't deterministically pick the right one.
Right now we'd attribute the edge to a pause container, which is just wrong.

If there is more than one container with the IP we ignore that edge as we can't deterministically pick the right one.

The pause container would deterministically be the right one.

Right now we'd attribute the edge to a pause container, which is just wrong.

I actually think it's exactly right.
As I said above, if a user doesn't care about the innards of pods, then they should be using the pod view, not the container view.


Template Sensors - historical data missing

Checklist

[ x] I updated the card to the latest version available
[ x] I cleared the cache of my browser
[ x] I verified that I'm really running the lastest version in my browser console
[ x] I checked if there is another issue opened with the same problem

Describe the bug
I'm using a couple of template sensors in apexcharts-cards.
After a restart from Home Assistant the chart doesn't show historical date - the curve started at the time of the restart

If I click on the entity, I can see, that the historical data is available
Version of the card
Version: 2.0.4
To Reproduce
This is the configuration I used:
Template sensor:

name: "SollWohnzimmer"
unit_of_measurement: "°C"
state_class: "measurement"
state: >
{{state_attr('climate.shelly_trv_wohnzimmer','temperature') }}

apexcharts-card:
type: custom:apexcharts-card
graph_span: 12h
yaxis:

id: first
decimals: 0
max: 25
apex_config:
tickAmount: 8
id: second
opposite: true
decimals: 0
min: 0
apex_config:
tickAmount: 8
header:
show: true
title: Heizungssteuerung
show_states: true
colorize_states: true
series:
entity: sensor.shelly_trv_wohnzimmer_temperature
type: line
yaxis_id: first
entity: sensor.sollwohnzimmer
type: line
curve: stepline
yaxis_id: first
entity: number.shelly_trv_wohnzimmer_valve_position
type: line
curve: stepline
yaxis_id: second

Expected behavior
I want to see also the data bevor restart of HA
Works with e.g. mini graph card or standard sensor card from HA
Desktop (please complete the following information):

Browser [chrome]
Version [Version 117.0.5938.134 (Offizieller Build) (64-Bit)]

Additional context
Tested from other HA user - could reproduce the isse with template sensors

any news on this issue?

the issue still exists - pls help


"splunk_hec/platform_logs" and "splunk_hec/platform_metrics" "context deadline exceeded (Client.Timeout exceeded while awaiting headers)"

Hi team,
Have seen frequent reports from users of exporting failed due to context deadline exceeded (Client.Timeout exceeded while awaiting headers). Wondering if this is an opportunity to tune the chart timeout values to be more resilient when sending to Splunk Cloud or customer managed Splunk, especially in the event of any back pressure?
https://github.com/signalfx/splunk-otel-collector-chart/blob/97dc6dca6f04a764a1fe48658453de72ed747a35/helm-charts/splunk-otel-collector/values.yaml#L47-L48
Here's an example of my collector sending from k8s to Splunk Cloud and hitting timeouts and eventually dropping metrics/logs
2022-04-06T22:09:21.013Z	info	exporterhelper/queued_retry.go:215	Exporting failed. Will retry the request after interval.	{"kind": "exporter", "name": "splunk_hec/platform_logs", "error": "Post \"https://http-inputs-foo.splunkcloud.com/services/collector\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)", "interval": "9.43516099s"}
2022-04-06T22:09:27.279Z	info	exporterhelper/queued_retry.go:215	Exporting failed. Will retry the request after interval.	{"kind": "exporter", "name": "splunk_hec/platform_metrics", "error": "Post \"https://http-inputs-foo.splunkcloud.com/services/collector\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)", "interval": "3.892538109s"}

Eventually it continues to retry until:
2022-04-06T22:16:07.084Z	error	exporterhelper/queued_retry_inmemory.go:106	Exporting failed. No more retries left. Dropping data.	{"kind": "exporter", "name": "splunk_hec/platform_logs", "error": "max elapsed time expired Post \"https://http-inputs-foo.splunkcloud.com/services/collector\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)", "dropped_items": 4615}
go.opentelemetry.io/collector/exporter/exporterhelper.onTemporaryFailure
	/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.47.0/exporter/exporterhelper/queued_retry_inmemory.go:106
go.opentelemetry.io/collector/exporter/exporterhelper.(*retrySender).send
	/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.47.0/exporter/exporterhelper/queued_retry.go:199
go.opentelemetry.io/collector/exporter/exporterhelper.(*logsExporterWithObservability).send
	/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.47.0/exporter/exporterhelper/logs.go:132
go.opentelemetry.io/collector/exporter/exporterhelper.(*queuedRetrySender).start.func1
	/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.47.0/exporter/exporterhelper/queued_retry_inmemory.go:118
go.opentelemetry.io/collector/exporter/exporterhelper/internal.consumerFunc.consume
	/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.47.0/exporter/exporterhelper/internal/bounded_memory_queue.go:99
go.opentelemetry.io/collector/exporter/exporterhelper/internal.(*boundedMemoryQueue).StartConsumers.func2
	/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.47.0/exporter/exporterhelper/internal/bounded_memory_queue.go:78

2022-04-06T22:16:10.201Z	error	exporterhelper/queued_retry_inmemory.go:106	Exporting failed. No more retries left. Dropping data.	{"kind": "exporter", "name": "splunk_hec/platform_metrics", "error": "max elapsed time expired Post \"https://http-inputs-foo.splunkcloud.com/services/collector\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)", "dropped_items": 478}
go.opentelemetry.io/collector/exporter/exporterhelper.onTemporaryFailure
	/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.47.0/exporter/exporterhelper/queued_retry_inmemory.go:106
go.opentelemetry.io/collector/exporter/exporterhelper.(*retrySender).send
	/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.47.0/exporter/exporterhelper/queued_retry.go:199
go.opentelemetry.io/collector/exporter/exporterhelper.(*metricsSenderWithObservability).send
	/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.47.0/exporter/exporterhelper/metrics.go:133
go.opentelemetry.io/collector/exporter/exporterhelper.(*queuedRetrySender).start.func1
	/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.47.0/exporter/exporterhelper/queued_retry_inmemory.go:118
go.opentelemetry.io/collector/exporter/exporterhelper/internal.consumerFunc.consume
	/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.47.0/exporter/exporterhelper/internal/bounded_memory_queue.go:99
go.opentelemetry.io/collector/exporter/exporterhelper/internal.(*boundedMemoryQueue).StartConsumers.func2
	/builds/o11y-gdi/splunk-otel-collector-releaser/.go/pkg/mod/go.opentelemetry.io/collector@v0.47.0/exporter/exporterhelper/internal/bounded_memory_queue.go:78

@jvoravong  can you please take a look and see if it makes sense to update the timeout value?

Here are the timeout and retry configurations:

timeout (default = 10s): Time to wait per individual attempt to send data to a backend.
retry_on_failure
--   enabled (default = true)
--   initial_interval (default = 5s): Time to wait after the first failure before retrying
--   max_interval (default = 30s): Is the upper bound on backoff
--   max_elapsed_time (default = 300s): Is the maximum amount of time spent trying to send a batch
sending_queue
--   enabled (default = true)
--   num_consumers (default = 10): Number of consumers that dequeue batches; ignored if enabled is false
--   queue_size (default = 5000): Maximum number of batches kept in memory before dropping. User should calculate this as num_seconds * requests_per_second where: num_seconds is the number of seconds to buffer in case of a backend outage requests_per_second is the average number of requests per seconds.

When we start dropping metrics:

If we have failed to send data to the backend after 300s of retrying, drop the data.
If we have more than 5000 batches of data retrying in the sending queue, start dropping batches retrying from the queue.

It's reasonable to increase the connection timeout to a value between 20-60s with no harmful affects.
Our users facing this issue could really use better default values or the ability to configure at least the retry_on_failure.max_elapsed_time and  sending_queue.queue_size configs. The size of the sending queue directly affects our memory usage, the retry_on_failure.max_elapsed_time affects how fast the sending queue will fill when the backend has pressure. Without some of sort of performance metrics or testing, I'm unsure what default values would be good for  retry_on_failure and sending_queue configs.
Action Items I'd recommend:

Increase the connection timeout to 30s.
Expose the retry_on_failure and sending_queue configurations so they are configurable within the values.yaml. Users would still use default values, but this way users have full control. Users who are willing to use more memory can configure higher values for the retry_on_failure.max_elapsed_time and sending_queue.queue_size configs.

Thanks Josh!

HTTP timeout 10s is very high already. If http connection cannot be established in 10s, it must be something wrong with the backend or in the middle. I'm pretty sure tuning timeout setting won't help in these cases. I don't think we should expose this setting. Better to get https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/6803 merged and expose the full set of http setting for those who really need them.

Noticed the Splunk Hec Exporter defaults for max_content_length_logs and max_content_length_metrics are set to 2MiB.
Some of the Splunk Cloud docs say we should avoid having max content lengths above 1MB.
Splunk Cloud Platform service limits and constraints
HEC maximum content length size limit = 1 MB
There is a recommended limit to the HEC payload size in Splunk Cloud Platform to ensure data balance and ingestion fidelity. A HEC request can have one or more Splunk events batched into it but the payload size should be no larger than this limit. If you exceed this limit, you may experience performance issues related to data balance and ingestion fidelity.
For the Splunk Cloud Hec Exporters, I propose we set max_content_length_logs and max_content_length_metrics to equal 1MB.

Yeah thats a "soft" limit. Enterprise default max is 5MB. Keeping under 1MB is probably wise.

I have created a PR(https://github.com/signalfx/splunk-otel-collector-chart/pull/460) to expose batch, retry_on_failure and sending_queue config in values.yaml file. It will not fix this issue but users can update these configs according to their needs.

@harshit-splunk thanks. I am going to mark this issue as resolved, now that those settings are exposed.
Matthew, please make sure to open a new issue if you see more timeout errors.


:bento: Add go2rtc

Source: https://raw.githubusercontent.com/AlexxIT/go2rtc/master/assets/logo.png

Closing this PR. Duplicate of #675.

@walkxcode Please consider this PR instead of #675. @AlexxIT FYI.


Sometimes quickSreamChannel isWritable will always return false

I use it to implement echo service, when I use multiple streams on a quic channel to send data for a long time, sometimes quickSreamChannel isWritable will return false on the server side, and it will not become true. I found that streams capability=0, so this problem should be a bug in quiche.

Please provide a reproducer

I'm trying to make it easier to reproduce

Thanks!


multipass: 1.14.0 -> 1.15.0

This commit is a fairly big one:

Package up the new 1.15.0-rc4 release
Include the Flutter desktop application
Move to pkgs/by-name

I've pushed this a little early while we're still in the late rc phase of the Multipass release to get feedback on the restructuring. I noted the following in the commit that introduces the GUI element:
This commit breaks down multipass into two intermediate packages,
`multipassd` and `multipass-gui`. These are then packaged up with
`symlinkJoin` to work around some intricacies in the
`buildFlutterApplication` process which would otherwise be difficult
to patch.

The multipass repo is setup upstream such that the flutter app would
be built as part of the regular cmake process, but that can't work
here due to the fetching of the flutter dependencies. The upstream
multipass project builds `libdart_ffi.so`, which is needed in the
LD_LIBRARY_PATH of the GUI. Building the two derivations seperately
enables that to be done relatively simply.

Hopefully that makes sense! Tested locally on my machine and all works as expected.
Perhaps @RossComputerGuy could give some feedback on this approach, seems they have lots of involvement with the Flutter tooling in nixpkgs.
Things done

Built on platform(s)

[x] 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

[x] 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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
25.05 Release Notes (or backporting 24.11 and 25.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

[x] Fits CONTRIBUTING.md.

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

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 363626

x86_64-linux

:white_check_mark: 1 package built:

multipass

Also is there a reason to be updating to a release candidate instead of waiting for a stable release?

Thanks for the feedback, I'll make those changes today - and nice tip on the desktop file, i'd not spotted that before.
Indeed my intention was to wait until the 1.15.0 release, I meant to mark this as draft while i got feedback on the approach 🤦♂

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 363626

x86_64-linux

:white_check_mark: 1 package built:

multipass

@SuperSandro2000 @getchoo feedback addressed, and also now bumped to the actual release, not the RC. Hopefully good to go now! Thanks for the help.

And some screenshots 😄

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 363626

x86_64-linux

:white_check_mark: 1 package built:

multipass


Performance problem even with data directory

I have run the redis container with the following command, and I have already a running instance in Redis, The native redis runs 264270.62 queries per second whereas in container it runs 117744.02 queries per second. It is almost a 2.25x slow down, which makes using it questionable. What is the problem?  Even the diff shows no change:
$ docker diff 6605
A /data

$ docker run -v /home/mustafa/redis-data:/data -d -p 9000:6379 dockerfile/redis
66058a4b3cdf6e2307cce43742b93c65c90575061d19f0a9cf8424790e3b642e
$ time redis-benchmark -t set -n 1000000 -p 6379
====== SET ======
  1000000 requests completed in 3.78 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

100.00% <= 0 milliseconds
264270.62 requests per second

real	0m3.852s
user	0m0.417s
sys	0m3.434s

$ time redis-benchmark -t set -n 1000000 -p 9000
====== SET ======
  1000000 requests completed in 8.49 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

99.89% <= 1 milliseconds
100.00% <= 2 milliseconds
100.00% <= 2 milliseconds
117744.02 requests per second

real	0m8.562s
user	0m1.236s
sys	0m4.854s

I have found that bridged interface causes this, running the following made it run at the same speed as native:
docker run -v /home/mustafa/redis-data:/data -d --net host dockerfile/redis


105 pack is broken

Fixes pathing bugs that show up in the pack command due to support for non-local input files.
This involved some additional complication because pack needs pathing at parse while most other pathing handled at the rsopt level deals with pathing at run time, which will be different.
I'm not sure this was handled in the cleanest manner.

I think all comments have been addressed and it is passing testing still.
Let me know if there is anything else that should be done @jeinstei .

I think all comments have been addressed and it is passing testing still. Let me know if there is anything else that should be done @jeinstei .

Nothing crazy that I see. I have no issues while reviewing functionality.


How to set reverseLayout when LazyList has reverseLayout = true?

Currently, I'm using this hack to achieve the required behaviour. RotationX = 180F
Scrollbars(
    state = scrollbarsState,
    modifier = Modifier.graphicsLayer { rotationX = 180F }
)


Multiple deployed contracts UI

I didn't find any discussion about handling multiple contracts. I think it could be nice to add some UI for it (that would only render when there actually are multiple contracts).
Should this be explored further and build something like this:

Or is it 'good enough' to let a developer figure it out on his own, and just add additional ContractUI components underneath like so:

    <ContractUI contractName="YourContract" />
    <ContractUI contractName="OtherContract" />

Which looks like this:

Or is it 'good enough' to let a developer figure it out on his own, and just add additional ContractUI components underneath like so

This is how it's done in SE1.
But I guess we could easily parse the hardhat_contract file, and display the deployed contracts on the selected network in the Debug Contract page.
Thoughts?
Not a priority tho!

I'm leaning towards adding this. I believe scaffold-eth should cater to all types of learners, so also to people that focus on solidity and just want a nice contract debugging interface, but don't necessarily want to learn how to mess with react.
The interface for desktop is simple and clear enough I believe. I'll try and iterate a bit on a suitable mobile design.

I think you can create something like const CONTRACTS_TO_SHOW = ["YourContract", "YourContractTwo", "YourContractThree"]; at the top of your /debug page and map through it. And also create a header like Contract: YourContract for every contract, and some divider between contracts.

oh, I didn't see tabs for contracts. Probably it will be even better

I think you can create something like const CONTRACTS_TO_SHOW = ["YourContract", "YourContractTwo", "YourContractThree"];

I'd lean into getting the deployed contracts dynamically from hardhat_contracts.json (from the current target network). The tabs looks cool!

On mobile, I kept mostly the same "pills", but instead of wrapping, they're horizontally scrollable:


fix relationshipRecords for non-ptr relationships

If you have N relationships, only the last one was taken into account. GGWP.

May I should note that the current release (without this patch) does not update ID fields of models inserted within one-level of recursion when the relationsip is not a slice of pointers.
This is, if A has many Bs, after doing astore.Save(&a), a.bs[i].ID is still 0. I'm not sure if this patch fixes that behaviour too.

Also, (I apologize for the doublepost), and this is a little weird, if we have the following scenario:
type A struct {
    kallax.Model
    ID int64 `pk:"autoincr"`

    Bs []*B // Note the pointer
}

type B struct {
    kallax.Model
    ID int64 `pk:"autoincr"`

    Cs []C // Note this is not a pointer
}

type C struct {
    kallax.Model
    ID int64 `pk:"autoincr"`
}

Doing
astore.Save(&a) // This works, inserts a and its Bs, and sets `a.bs[i].ID` in memory
// for each a.bs
bstore.Save(&a.bs[i]) // cs are NOT saved

Does NOT trigger the insertion of any C, despite a.bs[i].ID being correctly set.

Ok, everything should be fixed now. I'm merging this and releasing. If it's not, please raise an issue.


Unused variable warnings when compiling with NDEBUG

In some places the result of an operation is stored and only used in an assertion. When compiling with NDEBUG the assertion becomes a noop, and the compiler sees the variable as unused. See https://stackoverflow.com/questions/777261/avoiding-unused-variables-warnings-when-using-assert-in-a-release-build for some discussion.
CC @marcinz who encountered a myriad of such warnings while building a Legion conda package. Here are all the unique warnings he saw:
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/legion/garbage_collection.h:415:65: warning: 'creator.Legion::Internal::IndexPartCreator::result' may be used uninitialized in this function [-Wmaybe-uninitialized]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/legion/legion_context.cc:13833:55: warning: 'type_tag' may be used uninitialized in this function [-Wmaybe-uninitialized]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/legion/legion_context.cc:4686:55: warning: 'type_tag' may be used uninitialized in this function [-Wmaybe-uninitialized]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/legion/legion_domain.inl:1012:15: warning: unused variable 'type' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/legion/legion_domain.inl:244:20: warning: unused variable 'CHECK' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/legion/legion_domain.inl:752:20: warning: unused variable 'CHECK' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/legion/runtime.h:41:9: warning: array subscript 5 is outside array bounds of 'const Legion::DomainPoint [1]' [-Warray-bounds]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/legion/runtime.h:41:9: warning: array subscript 6 is outside array bounds of 'const Legion::DomainPoint [1]' [-Warray-bounds]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/legion/runtime.h:41:9: warning: array subscript 7 is outside array bounds of 'const Legion::DomainPoint [1]' [-Warray-bounds]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/legion/runtime.h:41:9: warning: array subscript 8 is outside array bounds of 'const Legion::DomainPoint [1]' [-Warray-bounds]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/legion/runtime.h:41:9: warning: array subscript 9 is outside array bounds of 'const Legion::DomainPoint [1]' [-Warray-bounds]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/mappers/default_mapper.cc:3593:14: warning: variable 'picked' set but not used [-Wunused-but-set-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/activemsg.inl:371:10: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/bgwork.cc:224:14: warning: unused variable 'elem' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/bgwork.cc:226:13: warning: unused variable 'mask' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/bgwork.cc:251:13: warning: unused variable 'prev' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/bgwork.cc:292:10: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/deppart/partitions.inl:44:10: warning: variable 'ok' set but not used [-Wunused-but-set-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/deppart/setops.cc:1070:10: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/deppart/setops.cc:1235:10: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/deppart/setops.cc:125:21: warning: array subscript 2 is outside array bounds of 'Realm::Rect<1, int> [1]' [-Warray-bounds]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/deppart/setops.cc:125:21: warning: array subscript 2 is outside array bounds of 'Realm::Rect<1, long long int> [1]' [-Warray-bounds]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/deppart/setops.cc:125:21: warning: array subscript 2 is outside array bounds of 'Realm::Rect<1, unsigned int> [1]' [-Warray-bounds]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/deppart/setops.cc:130:19: warning: array subscript 2 is outside array bounds of 'Realm::Rect<1, int> [1]' [-Warray-bounds]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/deppart/setops.cc:130:19: warning: array subscript 2 is outside array bounds of 'Realm::Rect<1, long long int> [1]' [-Warray-bounds]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/deppart/setops.cc:130:19: warning: array subscript 2 is outside array bounds of 'Realm::Rect<1, unsigned int> [1]' [-Warray-bounds]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/deppart/setops.cc:1473:10: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/event_impl.cc:1314:14: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/event_impl.cc:1318:14: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/event_impl.cc:2652:12: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/event_impl.cc:3476:14: warning: unused variable 'check' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/event_impl.cc:3522:14: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/event_impl.cc:3551:14: warning: unused variable 'check' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/inst_impl.cc:123:9: warning: unused variable 'ret' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/inst_impl.cc:1356:12: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/inst_impl.cc:709:12: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/inst_impl.h:132:16: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/logging.cc:128:13: warning: ignoring return value of 'size_t fwrite(const void*, size_t, size_t, FILE*)' declared with attribute 'warn_unused_result' [-Wunused-result]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/logging.inl:600:20: warning: 'tag' may be used uninitialized in this function [-Wmaybe-uninitialized]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/mem_impl.cc:1003:22: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/mem_impl.cc:133:14: warning: unused variable 'target' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/mem_impl.cc:158:14: warning: unused variable 'target' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/mem_impl.cc:501:14: warning: unused variable 'target' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/mem_impl.cc:637:14: warning: unused variable 'target' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/mutex.cc:1039:16: warning: unused variable 'mutex_prev' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/mutex.cc:1063:16: warning: unused variable 'mutex_prev' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/mutex.cc:370:9: warning: unused variable 'ret' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/mutex.cc:958:16: warning: unused variable 'mutex_prev' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/mutex.cc:984:16: warning: unused variable 'mutex_prev' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/network.cc:257:10: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/openmp/openmp_api.cc:1225:27: warning: unused variable 'work2' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/openmp/openmp_api.cc:1662:14: warning: unused variable 'orig' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/openmp/openmp_api.cc:491:14: warning: unused variable 'orig' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/openmp/openmp_threadpool.cc:167:14: warning: unused variable 'limit_overshoot' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/openmp/openmp_threadpool.cc:434:14: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/openmp/openmp_threadpool.cc:493:10: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/proc_impl.cc:1431:16: warning: unused variable 'count' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/proc_impl.cc:1501:12: warning: unused variable 'creator_node' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/proc_impl.cc:206:16: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/proc_impl.cc:219:16: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/proc_impl.cc:230:16: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/proc_impl.cc:283:16: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/proc_impl.cc:305:18: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/proc_impl.cc:316:18: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/proc_impl.cc:753:14: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/proc_impl.cc:851:14: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/proc_impl.cc:859:14: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/proc_impl.cc:943:12: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/python/python_module.cc:572:19: warning: unused variable 't' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/python/python_module.cc:784:22: warning: unused variable 'gilstate' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/rsrv_impl.cc:1393:16: warning: unused variable 'reader_count' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/rsrv_impl.cc:1459:13: warning: unused variable 'old_state' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/rsrv_impl.cc:802:30: warning: unused variable 'prev' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/runtime_impl.cc:1191:12: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/runtime_impl.cc:1204:14: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/runtime_impl.cc:1226:14: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/runtime_impl.cc:2878:10: warning: unused variable 'duplicate' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/subgraph_impl.cc:102:14: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/subgraph_impl.cc:117:14: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/subgraph_impl.cc:157:14: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/subgraph_impl.cc:172:14: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/subgraph_impl.cc:895:12: warning: unused variable 'creator_node' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/threads.cc:759:11: warning: unused variable 'ret' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/threads.cc:791:11: warning: unused variable 'ret' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/threads.cc:910:11: warning: unused variable 'ret' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/channel.cc:3830:24: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/channel.cc:4882:10: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/channel.cc:5300:36: warning: unused variable 'amt' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/channel.cc:5329:36: warning: unused variable 'amt3' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/channel.cc:5463:40: warning: unused variable 'amt2' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/channel.cc:5483:36: warning: unused variable 'amt2' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/channel.cc:5512:36: warning: unused variable 'amt3' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/channel.cc:5842:30: warning: unused variable 'in_port' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/channel.cc:5856:16: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/channel.cc:597:16: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/channel.cc:645:18: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/channel.cc:785:9: warning: unused variable 'act_dim' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/channel.cc:793:9: warning: unused variable 'act_dim' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/lowlevel_disk.cc:200:15: warning: unused variable 'ret' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/lowlevel_disk.cc:211:16: warning: 'fd' may be used uninitialized in this function [-Wmaybe-uninitialized]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/transfer.cc:1950:12: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/transfer.cc:2093:14: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/transfer.cc:2107:14: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/transfer.cc:2281:18: warning: unused variable 'bytes' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/transfer.cc:2317:18: warning: unused variable 'bytes' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/transfer.cc:2765:14: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/transfer.cc:2789:12: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/transfer.cc:2842:12: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/transfer.cc:2889:16: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/transfer.cc:2906:14: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/transfer.cc:2936:14: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/transfer.cc:2945:16: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/transfer.cc:3063:14: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/transfer.cc:3087:12: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/transfer.cc:3142:12: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/transfer.cc:3187:14: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/transfer.cc:3210:14: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/transfer.cc:3220:16: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/transfer.cc:3243:16: warning: unused variable 'ok' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/transfer/transfer.cc:3711:16: warning: unused variable 'exp_dst_size' [-Wunused-variable]
/gpfs/fs1/mzalewski/.pyenv/versions/anaconda3-2021.11/conda-bld/legate-core_1651870699951/work/legion/runtime/realm/utils.inl:230:7: warning: 'inst.Realm::RegionInstance::id' may be used uninitialized in this function [-Wmaybe-uninitialized]

Does conda require the use of NDEBUG?  Turning assert fails into inexplicable crashes, memory corruption, and the like seems like an anti-feature to me.

Maybe it's time to move to a custom assert? We've had a variety of (usually first-time) users who assume NDEBUG is desirable and then try to build that way as their first experience with Legion. We could avoid this as a footgun by making our own assert (e.g. fatal_assert or legion_assert or what have you) that ignores NDEBUG and therefore can't be turned off. (And also introduces the possibility of adding any other features we care about.)

I was planning to do exactly that for Legion as soon as the control replication branch merges back into master and I don't end up introducing a zillion conflicts with long-lived branches.

Yes, I think it's time to do that.  As mike says, it's massively disruptive to any other branch in progress, which is why we keep putting it off, but that won't get any better.

Does conda require the use of NDEBUG? Turning assert fails into inexplicable crashes, memory corruption, and the like seems like an anti-feature to me.

Good point @streichler. I think the NDEBUG flag comes from here:
https://github.com/conda-forge/ctng-compiler-activation-feedstock/blob/018d4fcb2d5dd612feb0c625b1d4669d8463ff94/recipe/conda_build_config.yaml#L51
I think I missed the reason for the warnings. If the NDEBUG flag is the issue, we can fix that in our build script for the recipe. I agree that in the long term it would be best to have NDEBUG behave in the expected way, but I think I can fix this in the build for now by just overwriting the conda defaults.
cc: @m3vaz


Test Connection (with error reason)

Is your feature request related to a problem? Please describe.
I know isConnected() exists to check whether the database driver is connected to the database, but is there some universal way of determining why the database is not connected if this is false?
For instance, if an invalid database is selected, isConnected just returns false but as isConnected could be false for many reasons it would be very helpful (e.g., to better aid with debugging) to have some way of retrieving the cause for the connection failure.
Describe the solution you'd like
Perhaps for backwards compatibility and simplicity, add a new method for this feature - testConnection() that could return:

a failure reason string or object on error and null on success
or, alternatively, a single object of a form similar to { isConnected: boolean; reason?: string; }

I'm not sure what other metadata might be useful to include, but at the very least a reason string would be helpful.
This might have to be implemented at the driver level.
Describe alternatives you've considered

Not bothering to test at all - this allows getting the actual reason for a failure when it happens in the form of an exception - but in some applications, it might not be immediately obvious that the database connection has failed and this could cause problems later on as users try to interact with the application.
Checking if isConnected() is false and then issuing a test query to the database to determine the reason. The issue with this is that there does not seem to be one universal query across all database types that is valid and which does not make any modifications, see: https://stackoverflow.com/questions/3668506/efficient-sql-test-query-or-validation-query-that-will-work-across-all-or-most (and that's not even mentioning MongoDB too).

What the isConnected method does is doing a select 1 query and returns false if there is an exception. Surely we can have another method which will give you the exception back.

I assume it's different for Mongo though? And some databases might not support SELECT 1 particularly if more are supported in future?
In any case - yes - I would say it would definitely be worth having the additional method.

There is no way to detect a broken connection, you need to do a query and catch the error. And this wont work with mongo, if that's you case, they changed some internals with the last major I think and removed the way to detect live connection completely. We could try the same approach with a random query maybe.

Of course - I do get that a query of some kind needs to be run and then an error handled, I just wasn't sure of there was enough control over the lower level driver stuff to handle the error without exceptions (it's really of a micro-optimization honestly) - as I personally prefer to use exceptions only in exceptional circumstances as a matter of efficiency.
Anyway, that aside, perhaps it's worth having logic in the core to execute a test query and then driver-specific code to determine what that query is? That would hopefully give the flexibility to implement a solution for Mongo too.
Mongo's implementation could maybe use the ping command: https://www.mongodb.com/docs/manual/reference/command/ping/
or fetch DB stats: https://stackoverflow.com/a/7984054

The ping could be a good candidate for this.


Fix linter warnings in Dockerfiles

Silly changes to fix linter warnings:
FromAsCasing: 'as' and 'FROM' keywords' casing do not match
LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy "ENV key value" format

is it a linter you ran locally?

It's part of the images builds, locally and everywhere else.


update intro tutorial (part ii)

Addresses issue #1479: https://github.com/uber/pyro/issues/1479
This is a start of a reworked tutorial.  The original tutorial was difficult to follow, quite complex in ways that perhaps weren't necessary, and had some errors (particularly regarding the posterior distribution for the example). References to marginal distributions removed as discussed. Visualizations improved, and now it shows how SVI recovers something close to the true posterior. I've also rearranged / rewrote some things for clarity.
Also, importance sampling removed as this will be another tutorial as discussed in referenced issue. I have also removed comments regarding using the guide for importance sampling; this may not be a good recommendation. The way KL divergence is minimised with SVI will not cover tails correctly and variance can become quite large (expectation propagation does not have this problem, as the KL is minimised in other direction).
Anyways, this is something I made mainly for some colleagues who found the original tutorial confusing, but you may find it useful and wish to merge. Happy to make further changes based on feedback.

Hi @eb8680, I have implemented your suggestions. Hopefully this will be a good step forward to clearer tutorials. Something to consider is introducing a constraint for the sigma parameter in the guide (I think this tutorial is slim enough now to add some more content, particularly constraints), but I'll leave that for you to consider in a future PR. :)


Update tankix to 614

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.
[x] The commit message includes the cask’s name and version.

Thank you for the contribution. It was merged directly as 62e8d9e2f68029d6eecf86b947e1e50b82ca67b1. Your contribution is still credited to you.


Clarify supported "integrations"

Describe the proposal
I saw redis mentioned in the samples, but it's very hard to get a complete overview of the supported "integrations". There should be a list, and for each item in the list, list a configuration, with (important) optional and required params.
For example, I have no idea if both redisHost and redisPassword are required for the state.redis integration (is that what it's called?). I would assume that password is optional, but there's no easy way to find out.

After submitting this, I realize that theres kindof an existing list already, but under "howtos", for example there's a list of supported state store backends here: https://github.com/dapr/docs/tree/master/howto/setup-state-store. Imho, this is not the best way to organize this documentation (relates to #249 I guess)

@yaron2 I can work on this, I've recognized the same situation with https://github.com/dapr/components-contrib - pls assign if suitable

@trondhindenes I would be interested in your feedback.
Currently, we're listing all supported "integrations" inside components-contrib, e.g. for components-contrib/bindings.
We are also duplicating this information inside docs and also provide detail information how you need to configure this, e.g. docs/concepts/bindings/ and docs/concepts/bindings/specs/kafka.
You are correct - this is missing for the other components, like state etc.
I can clean this up / align it, but maybe you have another idea?

Thanks @RicardoNiepel
I would maybe do something like this:

What
Input Binding
Output Binding
State Store
Pub-Sub

Redis
No
Yes (link to instructions)
Yes (link to instructions)
Yes (link to instructions)

Kafka
Yes (link to instructions)
Yes (link to instructions)
No
No

I would give a nice overall view of other tech that can be used together with dapr, and could also serve as a "main page" from where to point all setup instructions that are specific to each "technology" such as Redis etc.
Just a thought.

@trondhindenes  - Can we close this issue, given that now we have all the components with a single format layout. For example see https://v1-0.docs.dapr.io/operations/components/setup-bindings/supported-bindings/

yes I believe we can :-)


Fix newline in help.

Before this commit, it was possible for the following output to be
generated:
s += setLink(json, "Message_field", "field", " Abcd efg hij
klm nop");

This broke the form when viewed in the browser.

Thank you :)


New Device (Matter Switch) U-Tec Matter

Check all that apply
Type of Change

[ X] WWST Certification Request

If this is your first time contributing code:

[ ] I have reviewed the README.md file
[ ] I have reviewed the CODE_OF_CONDUCT.md file
[ ] I have signed the CLA

[ ] I plan on entering a WWST Certification Request or have entered a request through the WWST Certification console at developer.smartthings.com

[ ] Bug fix
[ ] New feature
[ ] Refactor

Checklist

[ X] I have performed a self-review of my code
[ ] I have commented my code in hard-to-understand areas
[ ] I have verified my changes by testing with a device or have communicated a plan for testing
[ ] I am adding new behavior, such as adding a sub-driver, and have added and run new unit tests to cover the new behavior

Description of Change
WWST Fingerprint submission for a Matter outlet. According to the DCL the Matter Device Type for this device is "x10A".
Summary of Completed Tests

@nickolas-deboom or @hcarter-775 Would a better fit for this device be the plug-binary profile?

@nickolas-deboom or @hcarter-775 Would a better fit for this device be the plug-binary profile?

Yeah I would say plug-binary seems to be a better fit - the same capabilities but uses the SmartPlug category rather than Switch.

@nickolas-deboom Thank you I have changed this.

@nickolas-deboom or @hcarter-775 Would a better fit for this device be the plug-binary profile?

Yeah I would say plug-binary seems to be a better fit - the same capabilities but uses the SmartPlug category rather than Switch.

T

@nickolas-deboom Thank you I have changed this.

@nickolas-deboom or @hcarter-775 Would a better fit for this device be the plug-binary profile?

Yeah I would say plug-binary seems to be a better fit - the same capabilities but uses the SmartPlug category rather than Switch.

Can you review this PR today by chance please?

Ok great! I am ready to approve now, but had one more quick question. The deviceLabel being used is "U-tec Smart Matter Plug" while the Product Name in the DCL is "U-tec Smart Plug". I can't remember - are these supposed to match exactly or does that not matter?


chore: shift ios project to this project

Fixes #604

@iamareebjamal travis is one hell of a mess. It does not allow you to use android language on macOS image.
Timeline:

Thought of running gradle on macOS by downgrading the jdk to 8.
It was still building the android project even when I was building a specific module with
./gradlew BadgeMagicModule:packForXcode
I finally managed to make it work by not including the android project in gradle.settings
So, I combined it all and removed the android project on macOS push.

Let me know your thoughts on this approach. This is a workaround and I'm sure there must be a better way or we can switch to Github Workflow which might be better as a whole.

@iamareebjamal if we can manage to build only the module we can solve this without issues, but for some reason even after specifying the module with the command it builds the android project which fails for some unknown reason https://travis-ci.com/fossasia/badge-magic-android/jobs/272179208.

Merge after changing the PR title

The build is failing because gradle is built on JDK 12 and JDK 13 is installed on the platform. gradle only supports JDK <= 12
So, if you can use that, it'll fix the error

@iamareebjamal Yes, Even I thought the same and tried all jdk's from 8 to 12, all failed because of Kotlin NullPointerException in Databinding. Here are the links of all builds, It should not build the android project as I was specifying the module specifically, but for some reason it was.
jdk8 - https://travis-ci.com/fossasia/badge-magic-android/jobs/272161844
jdk9 - https://travis-ci.com/fossasia/badge-magic-android/jobs/272180978
jdk11 - https://travis-ci.com/fossasia/badge-magic-android/jobs/272181067
jdk12 - https://travis-ci.com/fossasia/badge-magic-android/jobs/272181305


Lecture 8: Causal Discovery and Inference

https://abhilasharavichander.github.io/pgm-spring-2019/

Hi all, thanks for scribing the lecture notes! I've added some comments / suggestions.
Most importantly, please fix the broken LaTeX equations and add missing figures/proofs.
Some topics missing in the scribe notes are bi-directed paths (50:13), Constraint-Based Causal Discovery (1:09:14), PC algorithm (1:10:09): https://scs.hosted.panopto.com/Panopto/Pages/Viewer.aspx?id=51529b86-51dd-41eb-840f-a9d00129b93c Can you add these?

@AbhilashaRavichander, @Aniruddh1997, @tyyan, @kdgutier, what's the status on this? Please address the feedback provided by @lileee and let her know when to look again.
Also, it looks like your notes don't follow the format provided in the guidelines, hence lots of stuff doesn't render correctly (or render at all). We can't accept the notes in the current form, unfortunately. Please follow the guidelines, they are very straightforward. Thanks!

Hi we have reflected the requested changes. Could you have another look?

Did you update https://abhilasharavichander.github.io/pgm-spring-2019/notes/lecture-08/ ? The equations still don't render there.

@kdgutier @AbhilashaRavichander @Aniruddh1997 @tyyan Hey all, the notes look good, thanks for your hard work.
Can you address my suggestions here: https://github.com/sailinglab/pgm-spring-2019/pull/8/files/71b9e0746f057a6b5ff07925f0893daebb2a1a35#diff-c7019466a648c1c3068d3b8ef68d01d7 but once these are resolved, I think we can push the notes to master branch.

Hey TA's, can you take another look at the notes? Thanks!

Pushed fixes here: https://github.com/sailinglab/pgm-spring-2019/pull/8/commits/a19be3497e12de139ab7ab4e3e544363fd86e977
Merging to master branch now.


[#562][DotNet] Add Azure Storage Queues tests to the test solution

Addresses # 562
Description
This PR adds the Azure Storage Queue tests to the new Integration test project.
Detailed Changes

Added Microsoft.Bot.Builder.Dialogs.Adaptive and Microsoft.Bot.Builder.Azure.Queues dependencies to the Integration.csproj.
Added the Storage section with the ConnectionString to the appsettings.json file, that will be used to connect to the Emulator or Storage Account resource.
Added the AzureQueueBaseFixture.cs file that will be in charge of corroborating if the Storage service is up and running, otherwise the tests will fail.
Added AzureQueueStorageTests.cs file with 5 new tests that execute the QueueActivityAsync method under different situations.

Each test will create its own Queue container to prevent collisions.

Testing
The following images show the new Storage Queue tests added to the Integration project, alongside the configuration and folder structure.

Closed in favor of #143


Bump rust-toolchain to 1.77.2

Update rust-toolchain to 1.77.2. In an attempt to shrink down #4806 which requires 1.74.0 stable, I tried to upgrade as high as I could and we're just two versions behind (1.79 is currently stable). I tried to go to the current stable, but the amount of extra warnings (tons of field x is never read etc.) made me uncomfortable pursuing this further.
Once merged it should slightly decrease the size of #4806 PR.

bors r+


Issue with rendering dicom images from the server Ohif Viewr

Hi,
I am using OHIF Viewer to rendering the dicom images in the viewer. But i am getting following issue while going through it.

I am trying to render .dcm format images so i have cretaed an api and changed the url directly from the source code.
When it is hitting to the sever it gives CORS policy error..In the response api i have added all the headers in the repsonse but i am getting the same issue.
If i have dcm format images how i need to send it in the response ? For example i am using core php api for the image and i am using "file_get_content" method to send response when image instance api calling...So will it be good way to return the response Or i need to change the way i am sending in the response.

Please help me in the above 2 points..I am really not getting how can i resolve it. Please help me.
Thanks

Hii @ravikant-cisin ,  we tried recently to render .dcm files with OHIF viewer support. Its rendered fine as expected. we tried both by browsing internal files and by passing configurable structured JSON.
For reference, u can find node.js sample code here https://github.com/VinayBaviri/ohif-viewer.
Thank you.

Hello @VinayBaviri, I am searching for similar solution and found your sample code very impressive.
One thing I wanted to understand is: I have series of .dcm files like this example. In your sample code at route /view there is a variable imageUrl. What could be the best way to pass file(s) or folder to generate JSON at once?
Many thanks.

Could you please review our comprehensive documentation on Cross-Origin Resource Sharing (CORS) and OHIF? Below are the links provided for your reference.

https://docs.ohif.org/deployment/cors
https://docs.ohif.org/deployment/iframe