OverrideVMSize: redeploys on the same vm size as the previous test case

While running GPU tests, we found an issue related to the implementation of #73
After the 1st test case runs on all it's vm sizes, the 2nd test case only deploys on the last size of the previous test case.

-TestNames 'NVIDIA-GRID-DRIVER-VALIDATION,GPU-PCI-RESCIND'
-OverrideVMSize 'Standard_NV6,Standard_NV12,Standard_NV24'
[LISAv2 Test Results Summary]
Test Run On           : 04/18/2019 11:14:54
ARM Image Under Test  : Canonical : UbuntuServer : 18.10 : latest
Total Test Cases      : 2 (4 Passed, 1 Failed, 1 Aborted, 0 Skipped)
Total Time (dd:hh:mm) : 0:1:48

   ID TestArea             TestCaseName                                                                TestResult TestDuration(in minutes)
-------------------------------------------------------------------------------------------------------------------------------------------
    1 GPU                  NVIDIA-GRID-DRIVER-VALIDATION-Standard_NV6                                        FAIL                 4.01
	Using nVidia driver : GRID
	lsvmbus: Expected "PCI Express pass-through" count: 1, count inside the VM: 1 : PASS
	lspci: Expected "3D controller: NVIDIA Corporation" count: 1, found inside the VM: 1 : PASS
	lshw: Expected Display adapters: 1, total adapters found in VM: 1 : PASS
	nvidia-smi: Expected GPU count: 1, found inside the VM: 0 : FAIL
    2 GPU                  NVIDIA-GRID-DRIVER-VALIDATION-Standard_NV12                                       PASS                 6.79
	Using nVidia driver : GRID
	lsvmbus: Expected "PCI Express pass-through" count: 2, count inside the VM: 2 : PASS
	lspci: Expected "3D controller: NVIDIA Corporation" count: 2, found inside the VM: 2 : PASS
	lshw: Expected Display adapters: 2, total adapters found in VM: 2 : PASS
	nvidia-smi: Expected GPU count: 2, found inside the VM: 2 : PASS
    3 GPU                  NVIDIA-GRID-DRIVER-VALIDATION-Standard_NV24                                    ABORTED                49.59
	Using nVidia driver : GRID
    4 GPU                  GPU-PCI-RESCIND-Standard_NV6                                                      PASS                  6.5
	Using nVidia driver : GRID
	Successfully rescinded the PCI device. :
	lsvmbus: Expected "PCI Express pass-through" count: 4, count inside the VM: 4 : PASS
	lspci: Expected "3D controller: NVIDIA Corporation" count: 4, found inside the VM: 4 : PASS
	lshw: Expected Display adapters: 4, total adapters found in VM: 4 : PASS
	nvidia-smi: Expected GPU count: 4, found inside the VM: 4 : PASS
    5 GPU                  GPU-PCI-RESCIND-Standard_NV12                                                     PASS                 5.13
	Using nVidia driver : GRID
	Successfully rescinded the PCI device. :
	lsvmbus: Expected "PCI Express pass-through" count: 4, count inside the VM: 4 : PASS
	lspci: Expected "3D controller: NVIDIA Corporation" count: 4, found inside the VM: 4 : PASS
	lshw: Expected Display adapters: 4, total adapters found in VM: 4 : PASS
	nvidia-smi: Expected GPU count: 4, found inside the VM: 4 : PASS
    6 GPU                  GPU-PCI-RESCIND-Standard_NV24                                                     PASS                 6.89
	Using nVidia driver : GRID
	Successfully rescinded the PCI device. :
	lsvmbus: Expected "PCI Express pass-through" count: 4, count inside the VM: 4 : PASS
	lspci: Expected "3D controller: NVIDIA Corporation" count: 4, found inside the VM: 4 : PASS
	lshw: Expected Display adapters: 4, total adapters found in VM: 4 : PASS
	nvidia-smi: Expected GPU count: 4, found inside the VM: 4 : PASS

2nd Test case, 1st vm size
GPU-PCI-RESCIND-Standard_NV6 started running.
but lower in the test the test name is tagged as
TestName = NVIDIA-GRID-DRIVER-VALIDATION-Standard_NV24
04/18/2019 12:29:24 : [INFO ] GPU-PCI-RESCIND-Standard_NV6 started running.
04/18/2019 12:29:24 : [INFO ] Current test setup: OneVM
04/18/2019 12:29:24 : [INFO ] Checking the subscription usage...
04/18/2019 12:29:25 : [INFO ] Estimating VM #1 usage.
[...]
04/18/2019 12:29:25 : [INFO ] Estimated subscription usage is under allowed limits.
04/18/2019 12:29:25 : [INFO ] Creating Resource Group : LISAv2-OneVM-ubuntuAz-BD96-20190418122925.
04/18/2019 12:29:25 : [INFO ] Verifying that Resource group name is not in use.
04/18/2019 12:29:25 : [INFO ] Try to delete resource group LISAv2-OneVM-ubuntuAz-BD96-20190418122925...
04/18/2019 12:29:25 : [INFO ] Checking if LISAv2-OneVM-ubuntuAz-BD96-20190418122925 exists...
04/18/2019 12:29:25 : [INFO ] LISAv2-OneVM-ubuntuAz-BD96-20190418122925 does not exists.
04/18/2019 12:29:25 : [INFO ] Using location : westus2
VERBOSE: Performing the operation "Replacing resource group ..." on target
"LISAv2-OneVM-ubuntuAz-BD96-20190418122925".
VERBOSE: 12:29:26 PM - Created resource group
'LISAv2-OneVM-ubuntuAz-BD96-20190418122925' in location 'westus2'
04/18/2019 12:29:26 : [INFO ] Resource Group LISAv2-OneVM-ubuntuAz-BD96-20190418122925 created.
04/18/2019 12:29:26 : [INFO ] Setting LISAv2-OneVM-ubuntuAz-BD96-20190418122925 tag : BuildUser = azure-slave-2$
[...]
04/18/2019 12:29:27 : [INFO ] Setting LISAv2-OneVM-ubuntuAz-BD96-20190418122925 tag : TestName = NVIDIA-GRID-DRIVER-VALIDATION-Standard_NV24
04/18/2019 12:29:28 : [INFO ] Setting LISAv2-OneVM-ubuntuAz-BD96-20190418122925 tag : BuildMachine = WORKGROUP\azure-slave-2
04/18/2019 12:29:28 : [INFO ] Setting LISAv2-OneVM-ubuntuAz-BD96-20190418122925 tag : CreationTime = 2019/04/18 12:29:28

Manually verified the deployed vm with lspcu and lspci we see it has 4 GPU adapters and 24 processor cores, matching size Standard_NV24 GPU optimized virtual machine sizes

The same thing happened when running the tests on NC* Series of virtual machines, (here the tests failed because they could not install the driver) but the Deployed machines are the same
-TestNames 'NVIDIA-CUDA-DRIVER-VALIDATION,GPU-PCI-RESCIND'
-OverrideVMSize 'Standard_NC6,Standard_NC12,Standard_NC24'

    1 GPU                  NVIDIA-CUDA-DRIVER-VALIDATION-Standard_NC6                                        FAIL                 4.04
	Using nVidia driver : CUDA
	lsvmbus: Expected "PCI Express pass-through" count: 1, count inside the VM: 1 : PASS
	lspci: Expected "3D controller: NVIDIA Corporation" count: 1, found inside the VM: 1 : PASS
	lshw: Expected Display adapters: 1, total adapters found in VM: 1 : PASS
	nvidia-smi: Expected GPU count: 1, found inside the VM: 0 : FAIL
    2 GPU                  NVIDIA-CUDA-DRIVER-VALIDATION-Standard_NC12                                       FAIL                 4.91
	Using nVidia driver : CUDA
	lsvmbus: Expected "PCI Express pass-through" count: 2, count inside the VM: 2 : PASS
	lspci: Expected "3D controller: NVIDIA Corporation" count: 2, found inside the VM: 2 : PASS
	lshw: Expected Display adapters: 2, total adapters found in VM: 2 : PASS
	nvidia-smi: Expected GPU count: 2, found inside the VM: 0 : FAIL
    3 GPU                  NVIDIA-CUDA-DRIVER-VALIDATION-Standard_NC24                                       FAIL                 5.43
	Using nVidia driver : CUDA
	lsvmbus: Expected "PCI Express pass-through" count: 4, count inside the VM: 4 : PASS
	lspci: Expected "3D controller: NVIDIA Corporation" count: 4, found inside the VM: 4 : PASS
	lshw: Expected Display adapters: 4, total adapters found in VM: 4 : PASS
	nvidia-smi: Expected GPU count: 4, found inside the VM: 0 : FAIL
    4 GPU                  GPU-PCI-RESCIND-Standard_NC6                                                      FAIL                 5.37
	Using nVidia driver : CUDA
	Successfully rescinded the PCI device. :
	lsvmbus: Expected "PCI Express pass-through" count: 4, count inside the VM: 4 : PASS
	lspci: Expected "3D controller: NVIDIA Corporation" count: 4, found inside the VM: 4 : PASS
	lshw: Expected Display adapters: 4, total adapters found in VM: 4 : PASS
	nvidia-smi: Expected GPU count: 4, found inside the VM: 0 : FAIL
    5 GPU                  GPU-PCI-RESCIND-Standard_NC12                                                     FAIL                 5.44
	Using nVidia driver : CUDA
	Successfully rescinded the PCI device. :
	lsvmbus: Expected "PCI Express pass-through" count: 4, count inside the VM: 4 : PASS
	lspci: Expected "3D controller: NVIDIA Corporation" count: 4, found inside the VM: 4 : PASS
	lshw: Expected Display adapters: 4, total adapters found in VM: 4 : PASS
	nvidia-smi: Expected GPU count: 4, found inside the VM: 0 : FAIL
    6 GPU                  GPU-PCI-RESCIND-Standard_NC24                                                  Aborted                    0

Fixed by https://github.com/LIS/LISAv2/pull/138


Rest easy refactoring

https://issues.jboss.org/browse/ISPN-7734
https://issues.jboss.org/browse/ISPN-7735
This is the fundamental part of removing RESTEasy from our Server code base. The plan is to fully implement it and then "switch" the implementation in Server modules part. This way we will be able to benchmark and compare those two implementation before removing RestEasy.
Highlights:

[x] REST functionality
[x] Server is prepared for both HTTP/1.1 and HTTP/2 (however the latter needs some more tricks on the server side, especially this one)
[ ] Authentication is missing: https://issues.jboss.org/browse/ISPN-7736
[ ] Authorization is missing: https://issues.jboss.org/browse/ISPN-7737
[ ] Server modules bits are missing https://issues.jboss.org/browse/ISPN-7738

@tristantarrant Updated.

@wburns @tristantarrant Comments addressed.
I also added much more tests and implemented handling of Serializable values.

@wburns Comments addressed.
I also created a JMH performance comparison and it looks like this:
Benchmark                                                                         (configurationClassName)  Mode  Cnt     Score     Error  Units
RestPerfComparisonTest.BenchmarkState.perform1KPuts         org.infinispan.rest.profiling.NewServerHandler  avgt   31  1798.611 ± 103.823  ms/op
RestPerfComparisonTest.BenchmarkState.perform1KPuts         org.infinispan.rest.profiling.OldServerHandler  avgt   31  1922.648 ±  86.682  ms/op
RestPerfComparisonTest.BenchmarkState.perform1KPutsAndGets  org.infinispan.rest.profiling.NewServerHandler  avgt   31  3920.441 ± 307.330  ms/op
RestPerfComparisonTest.BenchmarkState.perform1KPutsAndGets  org.infinispan.rest.profiling.OldServerHandler  avgt   31  4313.393 ± 362.056  ms/op
RestPerfComparisonTest.BenchmarkState.perform1KPuts         org.infinispan.rest.profiling.NewServerHandler    ss   31  1878.441 ± 206.807  ms/op
RestPerfComparisonTest.BenchmarkState.perform1KPuts         org.infinispan.rest.profiling.OldServerHandler    ss   31  1998.803 ± 279.613  ms/op
RestPerfComparisonTest.BenchmarkState.perform1KPutsAndGets  org.infinispan.rest.profiling.NewServerHandler    ss   31  3979.594 ± 464.515  ms/op
RestPerfComparisonTest.BenchmarkState.perform1KPutsAndGets  org.infinispan.rest.profiling.OldServerHandler    ss   31  4098.248 ± 182.687  ms/op

It seems that the new version is slightly slower than the old one. This means that I have a date with profiler :)

@slaskawi Seems to hang the hotrod-client test suite, the Jenkins build filled the disk with a 27G infinispan-infinispan-client-hotrod.log.

@danberindei The failures should be fixed now. Thanks for pointing them out.

@tristantarrant oooh righ... git push :)

@gustavonalle mentioned that we could use -Dio.netty.leakDetectionLevel=paranoid for testing.

run performance tests please
cs-rest

Re: using Optional
My general feeling is that the most outward facing APIs should expose Optional, e.g. see Functional Map API. However, internally I'm more keen on not using Optional for a couple of reasons:

Potential performance reasons and reduced memory consumption.
Optional lacks a lot of high order functions to be able to make it really fun to use. E.g. there's no Optional.stream(), so no map, flatmap, fold/collect...etc.

So I'd avoid using Optional internally.

run performance tests please
cs-rest

@galderz This actually a 3rd request to remove those Optionals, so I tend to agree on removing them (//cc @danberindei @wburns).
However I would like use this opportunity to identify what's the performance impact of using Optionals. We are guessing this for a pretty long time and we can finally compare some numbers. So my plan is the following:

Leave it as is (for now)
Change the wiring and use new Netty implementation
Run perf tests
Remove Optionals
Re-reun perf tests

This way we will finally learn, whether Optionals have performance impact or not. I hope you guys are OK with that.

run performance tests please
cs-rest

Tests below will run on Netty (instead of RestEASY + Netty)

run performance tests please
cs-rest

run performance tests please
cs-rest

run performance tests please
cs-rest

run performance tests please
cs-rest

run performance tests please
cs-rest

run performance tests please
cs-rest

run performance tests please
cs-rest

run performance tests please
cs-rest

run performance tests please
cs-rest

CI Failures are not related.
Regarding to performance run1, run2:

The new implementation is much faster with 10 readers
With 10 writers, it's slightly slower (~5% which is in the error margin, so take it with a grain of salt)
For 100 readers and writers the new implementation is slightly faster.

run performance tests please
cs-rest

Now it's faster in all scenarios :dash:

Integrated, awesome work @slaskawi


Counter-clockwise gauges

In some configurations, it would make sense to have an option for a counter-clockwise gauge.  There are situations where I'd like to make a pair of "half-moon" gauges next to each other, but the one on the right needs to rotate in the opposite direction. I tried to hack it up by using (1-VALUE) and reversing the scale, but the valueBox shows 1-VALUE.
I've fiddled the example.
https://jsfiddle.net/4zyovuzk/1/

// Counter clockwise radial gauge
// The value we want to display.
var wantedValue = 40;
// Needle will be maxValue - wantedValue
var needleValue = 100 - wantedValue;
var gauge = new RadialGauge({
renderTo: 'right',
animatedValue:true,
animation: true,
startAngle:180,
ticksAngle:135,
borders:false,
// Reverse the major tick numbers
majorTicks: ["100","80","60","40","20","0"],
highlights: [
// Reverse highlight colors.
{ from: 80, to: 100, color: 'rgba(0,255,0,.15)' },
{ from: 60, to: 80, color: 'rgba(255,255,0,.15)' },
{ from: 20, to: 60, color: 'rgba(255,30,0,.25)' },
{ from: 0, to: 20, color: 'rgba(255,0,225,.25)' }
],
value: needleValue,
// Make sure we display the wanted value in the valueBox
valueText: wantedValue.toFixed(2),
valueBoxWidth: 40
}).draw();


publish<EMAIL_ADDRESS>

Requested by: @nikhars
Merge target: (default)
Quick links:

View changes
View check runs

Assign the accepted label to this issue to approve the release.
Leave a comment containing #retract under this issue to retract the release (original issuer only).
Targets

[x] github
[x] pypi
[x] sentry-pypi

Targets marked with a checkbox have already been executed.  Administrators can manually tick a checkbox to force craft to skip it.

I have added the bypass rule for getsentry bot to allow directly committing to main. That is what failed the release based on the logs.
[debug] Merging release/0.0.3 into: main
Error:  To https://github.com/getsentry/sentry-infra-tools
!	refs/heads/main:refs/heads/main	[remote rejected] (push declined due to repository rule violations)
Done
Pushing to https://github.com/getsentry/sentry-infra-tools
POST git-receive-pack (402 bytes)
remote: error: GH013: Repository rule violations found for refs/heads/main.
remote: Review all repository rules at http://github.com/getsentry/sentry-infra-tools/rules?ref=refs%2Fheads%2Fmain
remote:
remote: - 2 of 2 required status checks are expected.
remote:
error: failed to push some refs to 'https://github.com/getsentry/sentry-infra-tools'

Based on this comment, seems like I should be able to  start over. Going to do that since I also want to test the auto approve workflow I added


PP-1085 Fix bin ranges

WHAT

In the bin ranges file, some of them comes with 6 digits. Since min number and max number can be similar, the rest of the 3 numbers (to complete 9) can go from 0 to 999.So this changes that range. So  it was from XXXXXX000 to XXXXXX000 and now it is from XXXXXX000 to XXXXXX999 so it covers the  desired range.
MCI DEBIT and MCI CREDIT brands of bin ranges file from Worldpay are martercard brand.

👍 will merge as soon as e2e tests come back to life

:+1:


Negative profile measurements on MacOS

I am seeing that sometimes query_result.time.end - query_result.time.start gives me a negative value on mac. Have you seen this before? I could create a mini repo that reproduces the problem if you'd like :).

Yes, this is sort of a known issue, see https://github.com/linebender/vello/pull/475#issuecomment-1979644732
I figure though wgpu_profiler could do some mitigation here:

[ ] document the problem
[ ] warn when negative results come in / invalidate them programmatically

The render/compute pass centric API should not have this issue btw.!

thanks, I will give that a read. what do you mean by the render/compute pass centric API?

scoped_render_pass and scoped_compute_pass
These are the only two supported in WebGPU actually by now - this is not reflected in wgpu 0.19 yet but will be in the next wgpu release

Ah I see.. I'm afraid my application is (only) using scoped_render_pass already though

uhoh! Then wgpu is likely more buggy than I thought this is, will have to look into this

Interested in that mini-repo now. Might be a good starting point. Xcode frame debugger should be able to point out where the time stamp queries go and how that's wrong

I'll see if I can whip something up tonight

I was actually able to reproduce this with the wgpu profiler demo. Just ran cargo run --example demo. I changed the logging a bit in my fork to make it more obvious: https://github.com/Davidster/wgpu-profiler/tree/negative_timestamps_logging.
here's what I got. The times where the 'rendering' scope went into the negative was when I opened up the app switcher.

[examples/demo.rs:68:5] adapter.features() = Features(
    DEPTH_CLIP_CONTROL | TIMESTAMP_QUERY | INDIRECT_FIRST_INSTANCE | SHADER_F16 | BGRA8UNORM_STORAGE | FLOAT32_FILTERABLE | RG11B10UFLOAT_RENDERABLE | DEPTH32FLOAT_STENCIL8 | TEXTURE_COMPRESSION_BC | TEXTURE_COMPRESSION_ETC2 | TEXTURE_COMPRESSION_ASTC | TEXTURE_FORMAT_16BIT_NORM | TEXTURE_COMPRESSION_ASTC_HDR | TEXTURE_ADAPTER_SPECIFIC_FORMAT_FEATURES | MAPPABLE_PRIMARY_BUFFERS | TEXTURE_BINDING_ARRAY | STORAGE_RESOURCE_BINDING_ARRAY | SAMPLED_TEXTURE_AND_STORAGE_BUFFER_ARRAY_NON_UNIFORM_INDEXING | UNIFORM_BUFFER_AND_STORAGE_TEXTURE_ARRAY_NON_UNIFORM_INDEXING | MULTI_DRAW_INDIRECT | PUSH_CONSTANTS | ADDRESS_MODE_CLAMP_TO_ZERO | ADDRESS_MODE_CLAMP_TO_BORDER | POLYGON_MODE_LINE | VERTEX_WRITABLE_STORAGE | CLEAR_TEXTURE | SHADER_UNUSED_VERTEX_OUTPUT | SHADER_PRIMITIVE_INDEX | DUAL_SOURCE_BLENDING,
)
No profiling results available yet!
Got negative time for scope render pass bottom: -19158763.271ms
Got negative time for scope render pass bottom: -19158763.271ms
Got negative time for scope render pass bottom: -20.227ms
Got negative time for scope render pass bottom: -19158812.855ms
Got negative time for scope render pass bottom: -44.057ms
Got negative time for scope render pass bottom: -59.577ms
Got negative time for scope render pass bottom: -47.609ms
Got negative time for scope render pass bottom: -48.838ms
Got negative time for scope render pass bottom: -48.801ms
Got negative time for scope render pass bottom: -48.767ms
Got negative time for scope render pass bottom: -48.956ms
Got negative time for scope render pass bottom: -49.067ms
Got negative time for scope render pass bottom: -48.919ms
Got negative time for scope render pass bottom: -48.934ms
Got negative time for scope render pass bottom: -48.878ms
Got negative time for scope render pass bottom: -48.906ms
Got negative time for scope render pass bottom: -48.908ms
Got negative time for scope render pass bottom: -49.148ms
Got negative time for scope render pass bottom: -48.835ms
Got negative time for scope render pass bottom: -50.496ms
Got negative time for scope render pass bottom: -49.982ms
Got negative time for scope render pass bottom: -50.888ms
Got negative time for scope render pass bottom: -47.313ms
Got negative time for scope render pass bottom: -47.949ms
Got negative time for scope render pass bottom: -50.249ms
Got negative time for scope render pass bottom: -47.757ms
Got negative time for scope render pass bottom: -48.121ms
Got negative time for scope render pass bottom: -49.284ms
Got negative time for scope render pass bottom: -48.247ms
Got negative time for scope render pass bottom: -48.914ms
Got negative time for scope render pass bottom: -49.019ms
Got negative time for scope render pass bottom: -48.857ms
Got negative time for scope render pass bottom: -49.149ms
Got negative time for scope render pass bottom: -48.637ms
Got negative time for scope render pass bottom: -48.430ms
Got negative time for scope render pass bottom: -48.916ms
Got negative time for scope render pass bottom: -49.627ms
Got negative time for scope render pass bottom: -48.838ms
Got negative time for scope render pass bottom: -48.749ms
Got negative time for scope render pass bottom: -48.616ms
Got negative time for scope render pass bottom: -48.701ms
Got negative time for scope render pass bottom: -48.852ms
Got negative time for scope render pass bottom: -48.890ms
Got negative time for scope render pass bottom: -48.424ms
Got negative time for scope render pass bottom: -48.461ms
Got negative time for scope render pass bottom: -48.810ms
Got negative time for scope render pass bottom: -47.944ms
Got negative time for scope render pass bottom: -49.123ms
Got negative time for scope render pass bottom: -48.587ms
Got negative time for scope render pass bottom: -49.598ms
Got negative time for scope render pass bottom: -49.021ms
Got negative time for scope render pass bottom: -49.062ms
Got negative time for scope render pass bottom: -48.772ms
Got negative time for scope render pass bottom: -48.857ms
Got negative time for scope render pass bottom: -48.448ms
Got negative time for scope render pass bottom: -48.830ms
Got negative time for scope render pass bottom: -48.837ms
Got negative time for scope render pass bottom: -48.843ms
Got negative time for scope render pass bottom: -48.870ms
Got negative time for scope render pass bottom: -48.441ms
Got negative time for scope render pass bottom: -48.918ms
Got negative time for scope render pass bottom: -48.998ms
Got negative time for scope render pass bottom: -48.460ms
Got negative time for scope render pass bottom: -49.123ms
Got negative time for scope render pass bottom: -49.237ms
Got negative time for scope render pass bottom: -48.730ms
Got negative time for scope render pass bottom: -48.631ms
Got negative time for scope render pass bottom: -48.833ms
Got negative time for scope render pass bottom: -48.622ms
Got negative time for scope render pass bottom: -48.509ms
Got negative time for scope render pass bottom: -48.401ms
Got negative time for scope render pass bottom: -49.594ms
Got negative time for scope render pass bottom: -49.550ms
Got negative time for scope render pass bottom: -48.455ms
Got negative time for scope render pass bottom: -48.202ms
Got negative time for scope render pass bottom: -47.909ms
Got negative time for scope render pass bottom: -49.135ms
Got negative time for scope render pass bottom: -49.076ms
Got negative time for scope render pass bottom: -48.914ms
Got negative time for scope render pass bottom: -48.837ms
Got negative time for scope render pass bottom: -48.962ms
Got negative time for scope render pass bottom: -48.884ms
Got negative time for scope render pass bottom: -48.845ms
Got negative time for scope render pass bottom: -49.046ms
Got negative time for scope render pass bottom: -48.170ms
Got negative time for scope render pass bottom: -39.965ms
Got negative time for scope render pass bottom: -31.547ms
Got negative time for scope render pass bottom: -23.659ms
Got negative time for scope render pass bottom: -32.919ms
Got negative time for scope render pass bottom: -48.370ms
Got negative time for scope render pass bottom: -48.661ms
Got negative time for scope render pass bottom: -48.486ms
Got negative time for scope render pass bottom: -48.772ms
Got negative time for scope render pass bottom: -49.076ms
Got negative time for scope render pass bottom: -49.551ms
Got negative time for scope render pass bottom: -49.466ms
Got negative time for scope render pass bottom: -47.784ms
Got negative time for scope render pass bottom: -49.140ms
Got negative time for scope render pass bottom: -48.419ms
Got negative time for scope render pass bottom: -49.697ms
Got negative time for scope render pass bottom: -48.392ms
Got negative time for scope render pass bottom: -48.378ms
Got negative time for scope render pass bottom: -49.630ms
Got negative time for scope render pass bottom: -48.645ms
Got negative time for scope render pass bottom: -81.600ms
Got negative time for scope render pass bottom: -79.206ms
Got negative time for scope render pass bottom: -96.553ms
Got negative time for scope render pass bottom: -65.552ms
Got negative time for scope render pass bottom: -49.043ms
Got negative time for scope render pass bottom: -48.810ms
Got negative time for scope render pass bottom: -48.901ms
Got negative time for scope render pass bottom: -48.717ms
Got negative time for scope render pass bottom: -48.912ms
Got negative time for scope render pass bottom: -48.759ms
Got negative time for scope render pass bottom: -48.782ms
Got negative time for scope render pass bottom: -48.659ms
Got negative time for scope render pass bottom: -48.890ms
Got negative time for scope render pass bottom: -48.837ms
Got negative time for scope render pass bottom: -49.071ms
Got negative time for scope render pass bottom: -48.903ms
Got negative time for scope render pass bottom: -49.000ms
Got negative time for scope render pass bottom: -48.783ms
Got negative time for scope render pass bottom: -48.837ms
Got negative time for scope render pass bottom: -48.914ms
Got negative time for scope render pass bottom: -48.893ms
Got negative time for scope render pass bottom: -48.828ms
Got negative time for scope render pass bottom: -48.868ms
Got negative time for scope render pass bottom: -48.824ms
Got negative time for scope render pass bottom: -48.943ms
Got negative time for scope render pass bottom: -48.759ms
Got negative time for scope render pass bottom: -48.829ms
Got negative time for scope render pass bottom: -48.773ms
Got negative time for scope render pass bottom: -48.992ms
Got negative time for scope render pass bottom: -48.908ms
Got negative time for scope render pass bottom: -48.956ms
Got negative time for scope render pass bottom: -48.777ms
Got negative time for scope render pass bottom: -48.831ms
Got negative time for scope render pass bottom: -48.851ms
Got negative time for scope render pass bottom: -48.872ms
Got negative time for scope render pass bottom: -48.830ms
Got negative time for scope render pass bottom: -48.932ms
Got negative time for scope render pass bottom: -48.813ms
Got negative time for scope render pass bottom: -48.761ms
Got negative time for scope render pass bottom: -48.914ms
Got negative time for scope render pass bottom: -48.901ms
Got negative time for scope render pass bottom: -48.855ms
Got negative time for scope render pass bottom: -48.765ms
Got negative time for scope render pass bottom: -48.856ms
Got negative time for scope render pass bottom: -48.826ms
Got negative time for scope render pass bottom: -48.811ms
Got negative time for scope render pass bottom: -48.765ms
Got negative time for scope render pass bottom: -48.910ms
Got negative time for scope render pass bottom: -48.939ms
Got negative time for scope render pass bottom: -48.951ms
Got negative time for scope render pass bottom: -48.926ms
Got negative time for scope render pass bottom: -48.839ms
Got negative time for scope render pass bottom: -48.770ms
Got negative time for scope render pass bottom: -48.946ms
Got negative time for scope render pass bottom: -48.834ms
Got negative time for scope render pass bottom: -48.936ms
Got negative time for scope render pass bottom: -48.857ms
Got negative time for scope render pass bottom: -48.871ms
Got negative time for scope render pass bottom: -48.780ms
Got negative time for scope render pass bottom: -48.840ms
Got negative time for scope render pass bottom: -48.881ms
Got negative time for scope render pass bottom: -48.855ms
Got negative time for scope render pass bottom: -48.884ms
Got negative time for scope render pass bottom: -48.886ms
Got negative time for scope render pass bottom: -48.924ms
Got negative time for scope render pass bottom: -48.784ms
Got negative time for scope render pass bottom: -48.785ms
Got negative time for scope render pass bottom: -48.761ms
Got negative time for scope render pass bottom: -48.895ms
Got negative time for scope render pass bottom: -48.749ms
Got negative time for scope render pass bottom: -48.944ms
Got negative time for scope render pass bottom: -48.626ms
Got negative time for scope render pass bottom: -48.856ms
Got negative time for scope render pass bottom: -48.752ms
Got negative time for scope render pass bottom: -48.998ms
Got negative time for scope render pass bottom: -48.890ms
Got negative time for scope render pass bottom: -48.974ms
Got negative time for scope render pass bottom: -48.855ms
Got negative time for scope render pass bottom: -48.895ms
Got negative time for scope render pass bottom: -48.882ms
Got negative time for scope render pass bottom: -49.007ms
Got negative time for scope render pass bottom: -48.894ms
Got negative time for scope render pass bottom: -48.751ms
Got negative time for scope render pass bottom: -48.886ms
Got negative time for scope render pass bottom: -48.789ms
Got negative time for scope render pass bottom: -48.886ms
Got negative time for scope render pass bottom: -48.781ms
Got negative time for scope render pass bottom: -48.901ms
Got negative time for scope render pass bottom: -48.802ms
Got negative time for scope render pass bottom: -48.829ms
Got negative time for scope render pass bottom: -48.895ms
Got negative time for scope render pass bottom: -48.897ms
Got negative time for scope render pass bottom: -48.937ms
Got negative time for scope render pass bottom: -48.769ms
Got negative time for scope render pass bottom: -48.920ms
Got negative time for scope render pass bottom: -48.785ms
Got negative time for scope render pass bottom: -48.834ms
Got negative time for scope render pass bottom: -48.828ms
Got negative time for scope render pass bottom: -48.871ms
Got negative time for scope render pass bottom: -48.869ms
Got negative time for scope render pass bottom: -48.890ms
Got negative time for scope render pass bottom: -48.973ms
Got negative time for scope render pass bottom: -48.940ms
Got negative time for scope render pass bottom: -48.848ms
Got negative time for scope render pass bottom: -48.844ms
Got negative time for scope render pass bottom: -48.839ms
Got negative time for scope render pass bottom: -48.904ms
Got negative time for scope render pass bottom: -48.774ms
Got negative time for scope render pass bottom: -48.842ms
Got negative time for scope render pass bottom: -48.828ms
Got negative time for scope render pass bottom: -48.841ms
Got negative time for scope render pass bottom: -48.809ms
Got negative time for scope render pass bottom: -48.870ms
Got negative time for scope render pass bottom: -48.848ms
Got negative time for scope render pass bottom: -48.806ms
Got negative time for scope render pass bottom: -48.834ms
Got negative time for scope render pass bottom: -49.015ms
Got negative time for scope render pass bottom: -48.846ms
Got negative time for scope render pass bottom: -48.356ms
Got negative time for scope render pass bottom: -41.081ms
Got negative time for scope render pass bottom: -26.416ms
Got negative time for scope render pass bottom: -48.895ms
Got negative time for scope render pass bottom: -48.536ms
Got negative time for scope render pass bottom: -48.379ms
Got negative time for scope render pass bottom: -49.512ms
Got negative time for scope render pass bottom: -48.570ms
Got negative time for scope render pass bottom: -49.535ms
Got negative time for scope rendering: -49.873ms
Got negative time for scope render pass bottom: -48.825ms
Got negative time for scope render pass bottom: -47.930ms
Got negative time for scope render pass bottom: -48.834ms
Got negative time for scope render pass bottom: -49.154ms
Got negative time for scope render pass bottom: -48.655ms
Got negative time for scope render pass bottom: -47.362ms
Got negative time for scope render pass bottom: -48.928ms
Got negative time for scope render pass bottom: -46.955ms
Got negative time for scope render pass bottom: -49.895ms
Got negative time for scope render pass bottom: -48.919ms
Got negative time for scope render pass bottom: -49.350ms
Got negative time for scope render pass bottom: -48.334ms
Got negative time for scope render pass bottom: -49.211ms
Got negative time for scope render pass bottom: -48.310ms
Got negative time for scope render pass bottom: -48.001ms
Got negative time for scope render pass bottom: -48.159ms
Got negative time for scope render pass bottom: -49.320ms
Got negative time for scope render pass bottom: -49.060ms
Got negative time for scope render pass bottom: -49.149ms
Got negative time for scope render pass bottom: -49.148ms
Got negative time for scope render pass bottom: -49.248ms
Got negative time for scope render pass bottom: -48.211ms
Got negative time for scope render pass bottom: -48.214ms
Got negative time for scope render pass bottom: -49.055ms
Got negative time for scope render pass bottom: -48.996ms
Got negative time for scope render pass bottom: -48.217ms
Got negative time for scope render pass bottom: -48.381ms
Got negative time for scope render pass bottom: -48.685ms
Got negative time for scope render pass bottom: -49.901ms
Got negative time for scope render pass bottom: -49.192ms
Got negative time for scope render pass bottom: -49.314ms
Got negative time for scope render pass bottom: -48.994ms
Got negative time for scope render pass bottom: -49.509ms
Got negative time for scope render pass bottom: -49.351ms
Got negative time for scope render pass bottom: -49.043ms
Got negative time for scope render pass bottom: -48.702ms
Got negative time for scope render pass bottom: -49.286ms
Got negative time for scope render pass bottom: -48.788ms
Got negative time for scope render pass bottom: -48.570ms
Got negative time for scope render pass bottom: -48.519ms
Got negative time for scope render pass bottom: -48.353ms
Got negative time for scope rendering: -51.837ms
Got negative time for scope render pass bottom: -47.955ms
Got negative time for scope render pass bottom: -48.950ms
Got negative time for scope render pass bottom: -49.190ms
Got negative time for scope render pass bottom: -48.849ms
Got negative time for scope render pass bottom: -48.136ms
Got negative time for scope render pass bottom: -48.059ms
Got negative time for scope rendering: -50.926ms
Got negative time for scope render pass bottom: -49.136ms
Got negative time for scope rendering: -50.161ms
Got negative time for scope render pass bottom: -80.132ms
Got negative time for scope render pass bottom: -78.748ms
Got negative time for scope render pass bottom: -77.884ms
Got negative time for scope render pass bottom: -48.907ms
Got negative time for scope render pass bottom: -49.069ms
Got negative time for scope render pass bottom: -48.915ms
Got negative time for scope render pass bottom: -48.826ms
Got negative time for scope render pass bottom: -48.865ms
Got negative time for scope render pass bottom: -48.787ms
Got negative time for scope render pass bottom: -48.808ms
Got negative time for scope render pass bottom: -48.944ms
Got negative time for scope render pass bottom: -48.853ms
Got negative time for scope render pass bottom: -48.827ms
Got negative time for scope render pass bottom: -48.821ms
Got negative time for scope render pass bottom: -48.883ms
Got negative time for scope render pass bottom: -48.880ms
Got negative time for scope render pass bottom: -48.304ms
Got negative time for scope render pass bottom: -40.336ms
Got negative time for scope render pass bottom: -18.666ms
Got negative time for scope render pass bottom: -30.808ms
Got negative time for scope render pass bottom: -47.633ms
Got negative time for scope render pass bottom: -49.280ms
Got negative time for scope render pass bottom: -49.077ms
Got negative time for scope render pass bottom: -48.052ms
Got negative time for scope render pass bottom: -48.176ms
Got negative time for scope render pass bottom: -48.936ms
Got negative time for scope render pass bottom: -49.882ms
Got negative time for scope render pass bottom: -48.663ms
Got negative time for scope render pass bottom: -48.765ms
Got negative time for scope render pass bottom: -47.467ms
Got negative time for scope render pass bottom: -48.740ms
Got negative time for scope render pass bottom: -48.662ms
Got negative time for scope render pass bottom: -49.020ms
Got negative time for scope render pass bottom: -48.245ms
Got negative time for scope render pass bottom: -48.178ms
Got negative time for scope render pass bottom: -49.492ms
Got negative time for scope render pass bottom: -49.262ms
Got negative time for scope render pass bottom: -48.567ms
Got negative time for scope render pass bottom: -49.041ms
Got negative time for scope render pass bottom: -48.907ms
Got negative time for scope render pass bottom: -49.234ms
Got negative time for scope render pass bottom: -48.952ms
Got negative time for scope render pass bottom: -48.333ms
Got negative time for scope render pass bottom: -48.937ms
Got negative time for scope render pass bottom: -49.104ms
Got negative time for scope render pass bottom: -48.920ms
Got negative time for scope render pass bottom: -48.942ms
Got negative time for scope render pass bottom: -48.770ms
Got negative time for scope render pass bottom: -48.564ms
Got negative time for scope render pass bottom: -48.921ms
Got negative time for scope render pass bottom: -50.122ms
Got negative time for scope render pass bottom: -46.641ms
Got negative time for scope render pass bottom: -48.860ms
Got negative time for scope render pass bottom: -49.262ms
Got negative time for scope render pass bottom: -49.480ms
Got negative time for scope render pass bottom: -79.778ms
Got negative time for scope render pass bottom: -79.750ms
Got negative time for scope render pass bottom: -78.218ms
Got negative time for scope render pass bottom: -48.813ms
Got negative time for scope render pass bottom: -48.866ms
Got negative time for scope render pass bottom: -49.112ms
Got negative time for scope render pass bottom: -48.935ms
Got negative time for scope render pass bottom: -48.999ms
Got negative time for scope render pass bottom: -48.766ms
Got negative time for scope render pass bottom: -48.880ms
Got negative time for scope render pass bottom: -48.808ms
Got negative time for scope render pass bottom: -48.817ms
Got negative time for scope render pass bottom: -48.798ms
Got negative time for scope render pass bottom: -48.765ms
Got negative time for scope render pass bottom: -48.817ms
Got negative time for scope render pass bottom: -48.865ms
Got negative time for scope render pass bottom: -48.838ms
Got negative time for scope render pass bottom: -48.959ms
Got negative time for scope render pass bottom: -48.809ms
Got negative time for scope render pass bottom: -48.867ms
Got negative time for scope render pass bottom: -48.870ms
Got negative time for scope render pass bottom: -48.853ms
Got negative time for scope render pass bottom: -48.808ms
Got negative time for scope render pass bottom: -48.863ms
Got negative time for scope render pass bottom: -48.888ms
Got negative time for scope render pass bottom: -48.833ms
Got negative time for scope render pass bottom: -48.912ms
Got negative time for scope render pass bottom: -48.896ms
Got negative time for scope render pass bottom: -48.888ms
Got negative time for scope render pass bottom: -48.907ms
Got negative time for scope render pass bottom: -48.828ms
Got negative time for scope render pass bottom: -48.525ms
Got negative time for scope render pass bottom: -48.628ms
Got negative time for scope render pass bottom: -48.740ms
Got negative time for scope render pass bottom: -49.089ms
Got negative time for scope render pass bottom: -48.994ms
Got negative time for scope render pass bottom: -48.881ms
Got negative time for scope render pass bottom: -48.925ms
Got negative time for scope render pass bottom: -48.981ms
Got negative time for scope render pass bottom: -48.954ms
Got negative time for scope render pass bottom: -48.788ms
Got negative time for scope render pass bottom: -49.025ms
Got negative time for scope render pass bottom: -48.956ms
Got negative time for scope render pass bottom: -48.943ms
Got negative time for scope render pass bottom: -48.862ms
Got negative time for scope render pass bottom: -48.816ms
Got negative time for scope render pass bottom: -48.883ms


Feature plotting

Opening to get feedback as work is done here. Don't merge yet.

Moving development to this branch: https://github.com/xray/xray/tree/feature-plotting


Need a way to change marker zIndex

I tried re-ordering the markers but that didn't change the zIndex.
This gif demonstrates the problem, it doesn't actually use any code that tries to change zIndex.

Has anybody some update for this feature?

it's in the latest release

I'm having an issue, when chosen marker rendered over other elements on the map ingnoring their zIndex (for example zIndexed marker renders over your bottom vertical scrollable cards);

https://github.com/airbnb/react-native-maps/blob/master/example/examples/ZIndexMarkers.js (for those who see this issue but don't know where to go after "it's in the latest release"

The example posted above uses zIndex: 1. This did not work for me but zIndex: 1000 did.

The example posted above uses zIndex: 1. This did not work for me but zIndex: 1000 did.

Installing an index for the markers and controlling the zIndex according to that worked for me,
style={index === selectedMarkerIndex ? {zIndex: 100000, elevation: 100000}: {zIndex: index, elevation: index}}
In the above code snippet 'index' variable is derived from the loop


Character counter indicator does not change color when char limit is reached/exceeded

When using default Mastodon stylesheet, if a user writes too many characters inside the compose form, the counter becomes red by applying the character-counter--over class.

The theme right know ignores the applied class and keeps styling the counter color with --color-dim.

I don't know if it's intentional, IMHO the theme should understand the applied class and use the appropriate token to colorize the counter (perhaps --color-destructive?)

@kde3kko Thanks! Haha I have 10000 characters limit so I never encountered this. Thanks for spotting it!


EvalField is not correct

This issue is related to #84
An appropriate way to fix this is to make LengthDofTest work directly on the space and not the field or test/trial function. It is important to gather all fields that are on the same function space and do the evaluation on the quadrature points.
By doing this, we will avoid also having variables (in the printed code) such as span_F_1, test_F_p1 etc if F is a field.
So actualy, the EvalField works fine when we want to evaluate the norm, because we only have one field. We need to make it more general.

the problem with EvalField are:

it only works with one field
the fields are not grouped by space
the first problem is a bug, the second one is an optimisation.
we can probably focus on the first one first

the problem with EvalField are:

it only works with one field
the fields are not grouped by space
the first problem is a bug, the second one is an optimisation.
we can probably focus on the first one first


bev_pool_ext.cpython-38-x86_64-linux-gnu.so: undefined

use docker enviroment , but meet some error, my server has 4*2080TI GPU with driver 515.65.01
root@730873b34ac1:/projects/perception3d/bevfusion# torchpack dist-run -np 4 python tools/train.py configs/nuscenes/det/transfusion/secfpn/camera+lidar/swint_v0p075/convfuser.yaml --model.encoders.camera.backbone.init_cfg.checkpoint pretrained/swint-nuimages-pretrained.pth --load_from pretrained/lidar-only-det.pth
Traceback (most recent call last):
  File "tools/train.py", line 15, in <module>
    from mmdet3d.datasets import build_dataset
  File "/projects/perception3d/bevfusion/mmdet3d/datasets/__init__.py", line 4, in <module>
    from .custom_3d import *
  File "/projects/perception3d/bevfusion/mmdet3d/datasets/custom_3d.py", line 10, in <module>
    from ..core.bbox import get_box_type
  File "/projects/perception3d/bevfusion/mmdet3d/core/__init__.py", line 2, in <module>
    from .bbox import *  # noqa: F401, F403
  File "/projects/perception3d/bevfusion/mmdet3d/core/bbox/__init__.py", line 3, in <module>
    from .iou_calculators import (AxisAlignedBboxOverlaps3D, BboxOverlaps3D,
  File "/projects/perception3d/bevfusion/mmdet3d/core/bbox/iou_calculators/__init__.py", line 1, in <module>
    from .iou3d_calculator import (
  File "/projects/perception3d/bevfusion/mmdet3d/core/bbox/iou_calculators/iou3d_calculator.py", line 5, in
<module>
    from ..structures import get_box_type
  File "/projects/perception3d/bevfusion/mmdet3d/core/bbox/structures/__init__.py", line 1, in <module>
    from .base_box3d import BaseInstance3DBoxes
  File "/projects/perception3d/bevfusion/mmdet3d/core/bbox/structures/base_box3d.py", line 5, in <module>
    from mmdet3d.ops.iou3d import iou3d_cuda
  File "/projects/perception3d/bevfusion/mmdet3d/ops/__init__.py", line 23, in <module>
    from .bev_pool import *
  File "/projects/perception3d/bevfusion/mmdet3d/ops/bev_pool/__init__.py", line 1, in <module>
    from .bev_pool import bev_pool
  File "/projects/perception3d/bevfusion/mmdet3d/ops/bev_pool/bev_pool.py", line 3, in <module>
    from . import bev_pool_ext
ImportError: /projects/perception3d/bevfusion/mmdet3d/ops/bev_pool/bev_pool_ext.cpython-38-x86_64-linux-gnu.so: undefined symbol: _Z8bev_pooliiiiiiiPKfPKiS2_S2_Pf
--------------------------------------------------------------------------
Primary job  terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
mpirun detected that one or more processes exited with non-zero status, thus causing
the job to be terminated. The first process to do so was:

  Process name: [[53964,1],1]
  Exit code:    1
--------------------------------------------------------------------------

How do you solve this problem?


Update DQN observation space to reflect replay buffer.

This PR updates the handling to observation_space to better reflect the docstring. It also allows one to use non-square observations. This is particularly useful to handle observations that are not images but can be shaped to be (N, 1) to be compatible with dopamine (as far as I can tell).
As seen in https://github.com/google/dopamine/blob/master/dopamine/replay_memory/circular_replay_buffer.py#L142-L145

I signed it!

hey zaf, thanks for this. i believe this has just been resolved by my commit: https://github.com/google/dopamine/commit/bc66570375dd8d4ad785948e032a7662bb32e2a6
this is part of a larger refactoring that i'm working on, and which will add some extra functionality.
i should be releasing it next week. stay tuned! :)


First test for lighthouse

Fixes #318
Signed-off-by: Matt Stratton<EMAIL_ADDRESS>

this is basically working - although it only currently tests the default configuration. I need to do some more research on GH actions to figure out how to do a better matrix test (similar to what we do with circle; I don't think we have to test every color permutation, but we should check the following:

blue-grid
blue-row-jumbo-false
blue-row-jumbo-true


Changed 404 routes

Small fix to that docs :)

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Thank you for the fix @danielsinai


upgrade to support dbt-core v1.5.0

Background
The latest version of dbt Core,dbt-core==1.5.0rc1, was published on April 13, 2023 (PyPI | Github).
How to upgrade
https://github.com/dbt-labs/dbt-core/discussions/7213 is an open discussion with more detailed information. If you have questions, please put them there!
The above linked guide has more information, but below is a high-level checklist of work that would enable a successful 1.5.0 release of your adapter.

[ ] Add support Python 3.11 (if you haven't already)
[ ] Add support for relevant tests (there's a lot of new ones!)
[ ] Add support model contracts
[ ] Add support for materialized views (this likely will be bumped to 1.6.0)

the next minor release: 1.6.0
FYI, dbt-core==1.6.0 is expected to be released at the end of July, with a release cut at least two weeks prior.

Hi! I have recently installed dbt-sqlite using pip, as recommended, and it installs dbt-core=1.5.1 and dbt-sqlite=1.4.0, which are incompatible.
When running any dbt command it will throw an error. I manually downgraded core with pip install --upgrade dbt-core=1.4 and now it works.
I guess that until dbt-sqlite is not updated to work with dbt-core=1.5 it would be nice if the default pip installation automatically provided a compatible dbt-core version.

@EloiSanchez good callout! you've got two options, and both of them make use of something called the compatible release operator (~=)
force install dbt-core version 1.4 alongside dbt-sqlite
you already did this. as a one liner, this looks like this
pip install dbt-sqlite dbt-core~=1.4.0
open a PR to change dbt-sqlite's dependency from >= to ~=
the line below should be modified to use ~=
https://github.com/codeforkjeff/dbt-sqlite/blob/af6dd91b1f5bb7043f1ae5607948e79b72616da7/setup.py#L49


Project mode is default unless chdir or filename flags are being used

Question to consider: Will it be too confusing to turn on --allow-unnamed in file mode? It makes sense to me because when a file/dir is specified, the intention is to "consider all commands contained in one file". However, some folks might interpret it as an inconsistency. Wdyt @mxsdev?

Working tests.

@sourishkrout

Will it be too confusing to turn on --allow-unnamed in file mode?

I think that's fine, consistency is valuable, but I think your initial expectation on the user's instincts is accurate. Two-way door anyhow 🚪

Also, in the case where --index & --filename is being used it's actually important to consider all blocks vs just named ones.

Right, good catch!


ReFrame crashes when trying to autodetect topology and does not have write permissions in config/_meta

This is triggered when ReFrame is installed with e.g EasyBuild system-wide, since at the first execution ReFrame tries to create config/_meta if this is not already there.

I suggest always user's $HOME to store the metadata then. It's the safest way. This issue is quite important, because it can render unusable system-wide deployments of ReFrame.


Update SubmitBlockRequest for Capella

Fix typo in readme.
Update beacon-api repo so Capella types are available.
For SubmitBlockRequest allow a Bellatrix or Capella execution payload.

For some reason the example isn't rendering what I would expect. Not sure how to fix it.

lgtm, let's merge?

lgtm, let's merge?

Maybe, but there's still the issue in the example, it doesn't show a payload with oneOf.

@lightclient do you know how to fix this?

undraft?

undraft?

Marked as ready for review. Not ideal, but we'll fix it later.


Sweep: use_feedback crashes

Details
gpt-engineer --help
Usage: gpt-engineer [OPTIONS] [PROJECT_PATH] [MODEL]

Arguments:
  [PROJECT_PATH]  path  [default: projects/example]
  [MODEL]         model id string  [default: gpt-4]

Options:
  --temperature FLOAT             [default: 0.1]
  -s, --steps [default|benchmark|simple|tdd|tdd+|clarify|respec|execute_only|evaluate|use_feedback]
                                  decide which steps to run  [default:
                                  Config.DEFAULT]
  -v, --verbose
  --install-completion [bash|zsh|fish|powershell|pwsh]
                                  Install completion for the specified shell.
  --show-completion [bash|zsh|fish|powershell|pwsh]
                                  Show completion for the specified shell, to
                                  copy it or customize the installation.
  --help                          Show this message and exit.

% gpt-engineer --steps use_feedback projects/example
Traceback (most recent call last):

  File "/usr/local/bin/gpt-engineer", line 8, in <module>
    sys.exit(app())
             ^^^^^

  File "/Users/user/PhpstormProjects/gpt-engineer/gpt_engineer/main.py", line 57, in main
    messages = step(ai, dbs)
               ^^^^^^^^^^^^^

  File "/Users/user/PhpstormProjects/gpt-engineer/gpt_engineer/steps.py", line 250, in use_feedback
    ai.fassistant(dbs.workspace["all_output.txt"]),
                  ~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^

  File "/Users/user/PhpstormProjects/gpt-engineer/gpt_engineer/db.py", line 24, in __getitem__
    raise KeyError(f"File '{key}' could not be found in '{self.path}'")

KeyError: "File 'all_output.txt' could not be found in '/Users/user/PhpstormProjects/gpt-engineer/projects/example/workspace'"

Checklist

[X] gpt_engineer/steps.py

Add a check for the existence of 'all_output.txt' in the 'use_feedback' function before trying to access it. This could be done using the 'os.path.exists' function.
• If 'all_output.txt' does not exist, decide on the appropriate action. If 'all_output.txt' is necessary for the 'use_feedback' step, create it with the necessary content. If it is not necessary, skip the step that requires it.

Looks like a matching error: we'll fix this.

sweep: Retry

@NinoSkopac did you first run without --use-feedback so that the codebase, to apply the feedback to, is generated?

Yes

Housekeeping: Closing stale issues.
Feel free to open if problem persists on latest main branch.


Add support for MacOS X

We need this for gmic-py x blender :)
Failing build at: https://github.com/myselfhimself/gmic-blender/runs/513968946?check_suite_focus=true
    raise Exception(f"dmg Unsupported")

Continuing work on this today

dmglib seems to be a nice little python library to abstract dmg mounting and demounting, trying it out

@myselfhimself how do I contact you outside of issues?
my email address is douglas.kastle gmail com

My PR was merged too early, but I now have comitter access to the repository.
Look I will just work in a branch and delete my fork.
NP
:)

WIP branch is: https://github.com/douglaskastle/blender-addon-tester/tree/macosx-support

Using dmglib was fruitful, preventing my needing to work with subprocesses.
I am struggling with the case of Blender 2.78c x mac os x. Back in the 2.78c days, packaging was obviously not done as a dmg but a zipped archive of a blender.app image folder (not Blender.app), with a lowercase blender executable in it (instead of uppercase).
Hoping to fix this today. The code of getBlender is now starting to get messy with special cases.. OOP could help at some point after this..

Github Actions shows flakiness for environment variables management or maybe is it our project.
When running a 2.80 test alongside a 2.78c test, the 2.78c test switches from 2.78c to 2.80 in the middle and downloads blender 2.80.
Still troubleshooting that.

Check the files in the example/* directory, I edited one to pass version and addon
I think there are 2 others that need the same edit.
This is where having a local machine is invaluable, and the reason I didn't develop it. Time vampire is the phrase I have heard.

The 2.80 sticky variable issue was due to the rebuild_pipreinstall_and_testexamples.sh entry point not having the BLENDER_VERSION environment variable injected (I had forgotten it).
Also each test was run one time too many.
This is now solved.
Also, Blender Mac OS X releases in the 2.78c-like older zipped format (not dmg) needed a chmod +x on top of the bundled blender and python executables. This is now applied.
Now I am facing an issue of blender 2.78c's bundled Python not seeing pytest.
This can be seen in this Github Actions run.
Highlighting the suspecting log lines:
2020-03-25T18:18:18.8704570Z found bundled python: /Users/runner/runners/2.165.2/work/blender-addon-tester/blender-addon-tester/.blender_releases_cache/blender-2.78c/MacOS/../Resources/2.78/python
2020-03-25T18:18:18.8768200Z Running /Users/runner/runners/2.165.2/work/blender-addon-tester/blender-addon-tester/examples/testing-fake-addon/blender_advanced_load_pytest.py from Blender
2020-03-25T18:18:18.8768900Z No module named 'pytest'
2020-03-25T18:18:18.8979570Z Error: Not freed memory blocks: 1, total unfreed memory 0.000122 MB

Most probably, blender's python version is not the same as the OS's python or is too different from it. So possibly package directories are not shared or acknowledged the same way. Hence, sharing the location of a non-same-python-executable version of pytest inside the python path of Blender's bundled python might not help. I do not know what to do: enforce a lower python version for when macosx X blender 2.78c is run? pip install from inside blender, which would need adding pip there? @douglaskastle  This is related to the trickery you have used and makes this project neat. Would you have some resolution idea?

First are you sure you are picking up the blender python and not the system python? I can't tell from your log which you are using. In linux I would use readlink -f python to give me the full path.  If you are using the right python ...
2.78c was only put in to have an option.  I am now beginning to find it causing problems elsewhere, and since then 2.80, 2,81, 2,82 have come along and they provide options there weren't available when I started.
One of the problems I had, which may or may not be the problem, is that the current version of zipp, which is used by pytest, has deprecated support for 3.5.  Look over in lwo import project, i had to have a special requirements file for 2.78c.  I think he might have unrolled that change, because your work under ubuntu and windows on github works and there is no special requirements file for them.
Ultimately I think it is ok to remove 2.78c from the github actions flow.  I would like to know whats wrong, but unless you have a hard requirement for support, it not worth chasing too hard.
I would love to get off 2.79, as this is the last using python3.5.  There are certain language constructs on 3.7 that i would like to upgrade to. But 2,79 will be a magic build for a few years to come.
Operationally there are a lot of users stuck on 2.79 who are afraid of 2.80.  I would be surprised to find anyone stuck on 2,78.  If they are not on 2.79, then they are probably on some much older version of blender, 2.65 or something, which we are not supporting any way.

on review, i don't think you are using the blender python, just the system.  You will probably also have a problem with 2.79.  This is where the local install would be very helpful

Hello
I have changed the mechanism of custom test script evaluation by blender's bundled python.
Regarding these log lines:
2020-03-25T18:18:18.8704570Z found bundled python: /Users/runner/runners/2.165.2/work/blender-addon-tester/blender-addon-tester/.blender_releases_cache/blender-2.78c/MacOS/../Resources/2.78/python
2020-03-25T18:18:18.8768200Z Running /Users/runner/runners/2.165.2/work/blender-addon-tester/blender-addon-tester/examples/testing-fake-addon/blender_advanced_load_pytest.py from Blender
2020-03-25T18:18:18.8768900Z No module named 'pytest'
2020-03-25T18:18:18.8979570Z Error: Not freed memory blocks: 1, total unfreed memory 0.000122 MB

they stem from the blender-evaluated python file
which is injected from the config dict here.
Good point about blender 2.78c. Putting Blender 2.79 instead.

Blender 2.79's download fails, it seems that scraper cannot find the download anymore on the webpage:
https://github.com/douglaskastle/blender-addon-tester/runs/534524536?check_suite_focus=true

ok yes that look like you are calling the blender python
where is the pip install requirements happening, the failure complaint will be there by pytest is not present

Blender 2.79's download fails, it seems that scraper cannot find the download anymore on the webpage:
https://github.com/douglaskastle/blender-addon-tester/runs/534524536?check_suite_focus=true

There is always something like that, I think they have issues over on blender.org today
https://www.blendernation.com/2020/03/25/blender-org-server-issues/

oh, make sure you do a failure test at some point.  Change the rev in the test to be wrong and make sure all the passing tests fail.  Propagating the failure out of python, to blender, to travis was lengthy enough. There is a series of tests possible around those failure modes. (also if pytest fails, it needs to error as this failure happens before blender is even called)

also, there are failures sometimes due to source server problems, a sleep and retry should be implemented, actually that is its own issue

The lack of match is due to blender 2.79 not existing anymore as a .zip or .dmg, just as .tar.gz
Now only blender 2.79a and 2.79b exist as zip or dmg
Related downloads list page is here: https://download.blender.org/release/Blender2.79/

tar.gz support for macos archive added

The MacOS archives inner files layout vary too much, this is very painful to code..:

.tar.gz (extract)
.dmg (to mount)
.zip (extract)
Inside there can be a parent directory like Blender or blender-NNnNN (same name as the archive)
Then the blender.app directory can have an upper case first Blender.app
The blender executable is at blender.app/Contents/MacOS/blender
Then the python executable is python with or without numbers with m suffix or not
All executables must have +x permission added (I added x for owner, group, others for now)
In order to work once the archive is mounted or extracted, one must find the Contents directory and move to the cache dir or working directory outside any read-only macos mounting space. Then that Contents directory can be renamed to a cacheable name eg. blender-2.79b.
With macos at hand to work, in case of troubleshooting mountable dmgs on Github Actions... the easiest after a dmglib mount to os.walk or something similar into the archive and look at its contents in the logs.
MacOS blender 2.7x python executable tends to use pip 9.0.1, which has TLS issues and cannot fetch pytest from pypi.org for example, so tests will not even start. The fix is to install pip by hand as was done for Windows already (Doug, thanks for that golden piece of code!!) here.
This was very tedious!! Maybe in the future, blender's macos releases files layout could be uniformized.. we should report that blender.org if we want a solid blender package manager some day.

Linux and blender 2.79b do not get on well together:
2020-03-26T00:51:00.1362624Z /home/runner/work/blender-addon-tester/blender-addon-tester/.blender_releases_cache/blender-2.79b/blender: error while loading shared libraries: libGLU.so.1: cannot open shared object file: No such file or directory
https://github.com/douglaskastle/blender-addon-tester/runs/535156496?check_suite_focus=true
linux and 2.78c as well (bundled python permissions)

Nightlies have new compression formats:
2020-03-26T01:00:08.5386735Z Downloading https://builder.blender.org/download/blender-2.83-188ccfb0dd67-linux64.tar.xz
2020-03-26T01:00:08.5387157Z Error, unknown archive extension: {blender_zipfile}. Will not extract it.}

tar.xz support added
It seems we are now all green for all OSes, all pytest cases, all blender >=2.80 versions including nightlies, on both Travis CI and github actions

Linux and blender 2.79b do not get on well together:
2020-03-26T00:51:00.1362624Z /home/runner/work/blender-addon-tester/blender-addon-tester/.blender_releases_cache/blender-2.79b/blender: error while loading shared libraries: libGLU.so.1: cannot open shared object file: No such file or directory
https://github.com/douglaskastle/blender-addon-tester/runs/535156496?check_suite_focus=true
linux and 2.78c as well (bundled python permissions)

I had this problem on Linux too. To get around it I did an apt-get of blender, this installed blender and all its dependacies, which are what's missing.
I have no macosx experience, I don't know if there is a apt equivalent.
I would recommend getting 2.79 support, as this is a massive inflection point, there will be a group of people stuck on it for years.
However, that's up to you if you want to complete, if not, I'll take it over and try and get out working.
I would still try and keep 2.79 operational for windows and Linux and have a pass for macosx.
Thoughts?

for clarification
2.78 and 2.79 do work on mac os x as shown here
I will try to add your 2.79 technique for linux only. For 2.78 I do not know yet.
Thanks

yes remove 2.78, thats fine

Good for me


Programmatically expose all SConstruct/SConscript files used in the build.

Describe the Feature
This request is driven by work on our Ninja builder for SCons. The Ninja builder needs to declare that the generated build.ninja file have a dependency on SConstruct and all the SConscripts, so that we can detect when the build.ninja file should be regenerated, because the structure of the build as described by SCons has changed.
Currently, we do this by globbing for such files, but this is not a great long term solution. In particular, env.SConscript allows the scripts to be named something other than SConscript, so if we want our Ninja tool to be truly generic, it shouldn't rely on filenames and globbing to do this work.
There are some tricky questions with this one, specifically, with how the phases of SCons execution would populate this vs when the Ninja backend would need access to the list.
Still, if there is still general interest in moving forward with getting the MongoDB Ninja generator upstreamed into SCons, some more robust solution to identifying the SCons files in play will be needed.
Required information

Link to SCons Users thread discussing your issue.
https://pairlist4.pair.net/pipermail/scons-users/2020-April/008072.html

Does this include site_scons files as well?

It is a great question and I can see arguments both ways. For SCons builds, any site_scons changes only cause a rebuild if they actually lead to a change in what/how things should be built. Ditto any changes to SConscripts or SConstruct. For Ninja, we just hard cause a regeneration if any of these files are out of date, but if the newly generated Ninja file doesn't change how any targets would be built, Ninja will consider them up to date. So I think that it would be preferable if site_scons loaded files were considered. This would, in effect, result in all of the built-in SCons tools being considered as well, right? So it would also probably capture a SCons upgrade as triggering a rebuild, which seems desirable.

Fixed in #3670


Dashboard Chart with auto update

I made some changes to be able to search the database, due to the control of created_at and finished_at.
The Navigation Menu will now update automatically every 5 seconds.
The Dashboard chat will update according to the time chosen in the uptime dropdown menu. By default, it is also 5 seconds.
The graph will also show the last 20 records according to the dropdown, for example, last 20 seconds.
When you enter the screen, the graph will be empty and will be filled as you watch it.
Features:

Add ChartJS
Dashboard page
Chart with auto update showing Pending, Success and Error ActiveJobs (Auto update time adjustable)
Dashboard Header Boxes with Jobs count (Auto update with chart uptime)
Auto update Navigation (Auto update fixed in 5 seconds)

Preview:

https://github.com/user-attachments/assets/8910d54f-3fb7-4644-a30b-9c1984dbf94a

The navigation bar ended up scrolling in some resolutions and depending on the number of records in the queues (which are displayed in the navbar)
I intend to make more visual changes that will probably improve this.

I'm trying to see a way to make it work with resque... I've never worked with resque, I'm not sure how I'm going to do it.

@rosa I removed the WIP, I'm open to suggestions on the code.
From the tests I've done, everything seems to be working fine with solid_queue.

Hey @MacLove13, thanks for this! I like the idea but not that it's completely tied to Solid Queue, unlike the other pages in Mission Control. Abstractions like ActiveJob::Queue, ActiveJob::JobsRelation, etc.  were created precisely for this, so that they could be used from controllers without having to reach for adapters' internals, and, could work easily with Resque, Solid Queue or other adapters. This introduces functionality that only works with Solid Queue and bypasses all of those abstractions, which right now is a no-go, I'm afraid.

Hey @MacLove13, thanks for this! I like the idea but not that it's completely tied to Solid Queue, unlike the other pages in Mission Control. Abstractions like ActiveJob::Queue, ActiveJob::JobsRelation, etc. were created precisely for this, so that they could be used from controllers without having to reach for adapters' internals, and, could work easily with Resque, Solid Queue or other adapters. This introduces functionality that only works with Solid Queue and bypasses all of those abstractions, which right now is a no-go, I'm afraid.

I tried to do it using abstractions, but I couldn't do a where by dates/time in a way that doesn't impact performance. I'll try a few more things in the next few days to remove the direct use of the database and use abstractions.


UNAUTHORIZED

https://registry-1.docker.io/v2/snowdreamtech/alpine/manifests/3.20.2
{
    "errors": [
        {
            "code": "UNAUTHORIZED",
            "message": "authentication required",
            "detail": [
                {
                    "Type": "repository",
                    "Class": "",
                    "Name": "snowdreamtech/alpine",
                    "Action": "pull"
                }
            ]
        }
    ]
}

https://github.com/dokku/github-action/issues/14


Back-button widget

My home page does not have an appbar, but my "subpage" does. I'd like to have the appbar on that page to have a back-button rather than the drawer icon (the hamburger).
It would help if the back-button was a widget to handle the Android vs. iOS look & feel. I could set that as the leading widget.

Fix in https://github.com/flutter/flutter/pull/8491


Error while regenerating alignment data

Decompression of paired-ended reads is replacing the read names. This should not happen since for paired-ended data read names are already stored in the compressed files and should be picked up during decompression

For some reason, ABRIDGE is calling the decompression program for SE instead of PE. The presence of the dictionary check is failing


Possible fix for issue #100 "Set test step execution result"

Hi @all!
Please have a look at my proposed fix.
Any comments are welcome :-)

:-D No problem, as long as it's working :-) Thx a lot!

Thank you @kaiadelmann !

Released 1.9.16-2


Add new button for peak picking

Add a new button that allows to track the spectrum by place an annotation with the value of it. The goal is that there is a call back on mouse / click

done


Any documentation about the ewelink api directly(not the package) ?

Hello !
It’s maybe a bit off topic, but does someone know if any kind of documentation on the ewelink API has been made ?
I need to implement the control of ewelink connected devices from scratch and I don’t find any resources that simply explain how this API works.
Thank you in advance

https://github.com/CoolKit-Technologies/apiDocs/tree/master/en
In particular APICenterV2.md

Thanks a lot !


Added explicit machines id_rsa. #140

Being explicit into the specified machines directory to find the key.
Maintaining a backup check into the root directory temporarily.

Thanks for the PR! Just one minor comment.

Apologies for losing track of this. GitHub sends a notification when a new PR is submitted or someone comments on it, but not when you update the PR, so I lost track of this one. Looks good, thank you.

@brikis98 shouldn't we have a test for something like this:
DOCKER_HOST_SSH_KEY="$DOCKER_MACHINE_STORE_PATH/machines/$DOCKER_MACHINE_NAME/id_rsa"
?

@yoanisgil: Probably wouldn't hurt :)


Feature: seperate service for specified commands/sensors

Hi,
I have a computer that is used by more then one person.
the startup is a scheduled task at login. it would be nice if the program can run as a service.
I think the sensors as service is enough. so the administrator can setup the sensors.
the users should be able to setup the commands.
in my case the config part could be shared between users. I made a new user for every computer and used that access token.
but maybe someone else prefers it other.

Hi @miit86,
I've actually been thinking about that as well, so it's on my shortlist. And I thought about the exact same option as you did; create a service for specific sensors/commands.
I'll let you know when it's done, thanks for sharing!

Added in today's beta; https://github.com/LAB02-Research/HASS.Agent/releases/tag/b2022.3.25
Would be great if you could test :)


parsing EXPLAIN QUERY PLAN for sqlite

bug description
sqlparser is unable to part EXPLAIN QUERY PLAN for sqlite
expected behavior
EXPLAIN QUERY PLAN is displayed similar to EXPLAIN ANALYZE

might be a limitation in sqlparser, tracking in https://github.com/apache/datafusion-sqlparser-rs/issues/1455

should be fixed after upgrading sqlparser after the next release including the fix for the above issue


HBASE-25198 Remove deprecated RpcSchedulerFactory#create

Remove the deprecated RpcSchedulerFactory#create(Configuration,
PriorityFunction) method from the interface and in all implementing
classes.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 32s
Docker mode activated.


Progress bars appear to always be a fixed size (800px)

I'd like to have a 100 px wide progress bar.  The plugin seems to force the width to be 800px
https://github.com/google/automotive-design-compose/assets/64603080/eb031b24-85d7-41d1-86fb-dd858945d2c5

The parent frame of the progress bar defines the maximum size of the progress bar, so you'll need to put that rectangle into a parent frame and set the parent frame's width to be 100px. You can click on the little information icon next to "Progress bar fill" to get a little more info.

🤦


Resolving HD Video Freeze after SD License Load with DRM - Fairplay

Have you read the Tutorials?
Yes
Have you read the FAQ and checked for duplicate open issues?
Yes
If the question is related to FairPlay, have you read the tutorial?
Yes
What version of Shaka Player are you using?
4.7.7
What browser and OS are you using?
Linux + ubuntu
Please ask your question
Fairplay - I request the SD video first to load quickly with DRM settings, and it works well. However, a few seconds later, when Shaka Player attempts to request the HD video, image stalls (audio keep running) because the license from the SD version is different from the HD version and won't update. I've tried using 'player.getNetworkingEngine().registerRequestFilter' to force an update of the license auto, but it didn't work.
Does anyone have any hints?
player.getNetworkingEngine().registerRequestFilter((type, request, context) => {
  if (type != shaka.net.NetworkingEngine.RequestType.LICENSE) {
    return;
  }

  const originalPayload = new Uint8Array(request.body);
  const base64Payload =
      shaka.util.Uint8ArrayUtils.toStandardBase64(originalPayload);
  const params = 'spc=' + encodeURIComponent(base64Payload);
  request.headers['Content-Type'] = 'application/x-www-form-urlencoded';
  request.body = shaka.util.StringUtils.toUTF8(params);
});

other thing I tried as well was to send a new player.configure() without success
player_.getNetworkingEngine().registerResponseFilter((type, response) => {

if (type != shaka.net.NetworkingEngine.RequestType.MANIFEST ||
response.originalUri != player_.getAssetUri()) {
// Not the master playlist.  Ignore it.
return;
}

const text = shaka.util.StringUtils.fromUTF8(response.data);
// Do something with the text, and call player.configure() with an appropriate config.
});

[Update 1] - On the Shaka Player demo, I observed the same behavior: if it starts with an SD video and switches to an HD video after a few seconds, the video stalls (this change happens automatically). If it doesn't switch and remains in SD quality, it keeps running.


Review contribution guidelines defined in community-operators

The community-operators contribution guidelines are defined here:
https://github.com/operator-framework/community-operators/blob/master/docs/contributing.md
Specifically, we should review the description in the CSV to make sure it addresses what is required in the contribution guidelines, like the manual steps required before installing (Istio).
The package yaml should be reviewed to be sure it's correct.
Running the tools like operator-sdk and operator-courier to validate will be done in the testing issue, not here.

Is this for the Oct-7 release?

We've been carrying this forward and we'll try to get it done by Oct 7 but it probably won't be.  It's not required for Oct 7.

It's pretty clear that this operator will not be published in community-operators, due to the lack of a "one-click install experience".  There are too many manual steps required before you can install this operator... it's best served by a link to the install instructions at kabanero.io.


Update redux reducer doc noting unique key

Multiple reducers can not be applied to store key

Coverage remained the same at 100.0% when pulling f2b75544f2f1822f0de5e1234633d0b16dbf51fb on danactive:patch-2 into e39f8bdca29a35edbd7480968c9fe0b2c9438860 on react-boilerplate:master.

Sure, I start this change now


the 'prepublish' script  failed with status  code 8

How can i solve this pbm?

I am having the same problem, using Git Deploy to an Azure Web App with ASP.NET 5.

Thanks @shaunluttin, I removed prepublish script  from project.json file. Now its working fine.

@prakashkaruppiah Good stuff. :)


Epinio UI test - Execute e2e tests on the standalone UI

Once the standalone UI ready, we will need to execute our e2e tests on.
The goal is to execute same tests on both UI for checking regressions.

I was able to adapt the code but I'm now stuck because of https://github.com/epinio/ui/issues/88


subscriber list: Fix display of email addresses in subscribers list.

Original email address is shown to admin users in subscriber list when
email_address_visibilty is set to "Admins only" by passing delivery_email
at required places.  Email address are not shown to non-admin users when
visibility is set to "Admins only".
Fixes a part of #13541.

Testing Plan:
Node tests have been updated accordingly.
GIFs or Screenshots:

@sahil839 thanks for working on this!  I fixed the handful of issues mentioned above and merged this as the series ending with 6a791e19390800806d4fd22c355bc29e6e1760ae.


:white_check_mark: Test: Add common test coverage

Description
Concise description of proposed changes
Testing
Explain the quality checks that have been done on the code changes
Additional Information

[ ] I read the contributing docs (if this is your first contribution)

Your ENS/address:

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#1275  👈
#1274
#1273
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @roninjin10 and the rest of your teammates on  Graphite


Add formatting infrastructure to the project

Fixes #2507
Upgrading project wide LLVM version to 18 and add infrastructure to format c++ files with clang-format. We upgrade to llvm-18 because some of the clang-format options we're using have only been released with clang-format 18.
Added:

clang-format file matching internal one
formatting tool based on python for cross-platform
pre-commit and pre-push hooks for formatting validation
Lint CI action.

In terms of CR workflow here's what I was thinking:
Reviewing the entire CR is going to be difficult which is why it's split into 4 distinct commits:

Establish the framework for reformatting.
Actual code changes required for the reformatting to succeed.
Plain format.py run
add .git-blame-ignore-revs file with 3's commit hash.

Seeing as how this CR will probably take a while I will not try to resolve conflicts during the CR. Instead whenever we finish the CR I will revert to

commit 2
rebase from main
apply format
add .git-blame-ignore-revs
merge without further CR

At the very least should have @jp4a50 approval before merge.

In terms of CR workflow here's what I was thinking:
Reviewing the entire CR is going to be difficult which is why it's split into 4 distinct commits:

Establish the framework for reformatting.
Actual code changes required for the reformatting to succeed.
Plain format.py run
add .git-blame-ignore-revs file with 3's commit hash.

Seeing as how this CR will probably take a while I will not try to resolve conflicts during the CR. Instead whenever we finish the CR I will revert to

commit 2
rebase from main
apply format
add .git-blame-ignore-revs
merge without further CR

Thank you for this!
On updating LLVM: Leaving it at 15 for now has been a conscious choice: My philosophy has been that it should be possible to build workerd using the LLVM version available in the default APT repo in the latest stable release of Ubuntu and Debian, so that developers can build workerd without having to build LLVM themselves or install it from an alternative repository like https://apt.llvm.org/ which is used in the CI build. For Debian (bookworm) that's currently 16 (also available on the earlier Debian Bullseye), for Ubuntu 22.04 it is LLVM 15, the recently introduced Ubuntu 24.04 supports LLVM 18. If we upgrade the version we use to build on CI to 18, we can easily introduce changes that break the build with lower versions.
With the V8 12.8 update (#2441, should land pretty soon), we will have to update this to LLVM 16 anyway, which may introduce some headaches for internal developers that are on Ubuntu 22.04-based systems.
What we can do is to require LLVM 18 and document that installing it may require additional developer actions, or we can update the version we use on CI to 18, but leave the documented minimum version as is and just state that LLVM18 is recommended and add a CI job that uses LLVM16 so that it doesn't break. I would prefer to address compiler upgrades separately from this PR TBH, for now we can just say that clang-format-18 is required for linting.

Thank you for this!
On updating LLVM: Leaving it at 15 for now has been a conscious choice: My philosophy has been that it should be possible to build workerd using the LLVM version available in the default APT repo in the latest stable release of Ubuntu and Debian, so that developers can build workerd without having to build LLVM themselves or install it from an alternative repository like apt.llvm.org which is used in the CI build. For Debian (bookworm) that's currently 16 (also available on the earlier Debian Bullseye), for Ubuntu 22.04 it is LLVM 15, the recently introduced Ubuntu 24.04 supports LLVM 18. If we upgrade the version we use to build on CI to 18, we can easily introduce changes that break the build with lower versions. With the V8 12.8 update (#2441, should land pretty soon), we will have to update this to LLVM 16 anyway, which may introduce some headaches for internal developers that are on Ubuntu 22.04-based systems.
What we can do is to require LLVM 18 and document that installing it may require additional developer actions, or we can update the version we use on CI to 18, but leave the documented minimum version as is and just state that LLVM18 is recommended and add a CI job that uses LLVM16 so that it doesn't break. I would prefer to address compiler upgrades separately from this PR TBH, for now we can just say that clang-format-18 is required for linting.

Yeah sure, I thought it'd be nice to upgrade our llvm version but I don't mind reverting this change and just requiring clang-format-18 for format

Unfortunately format checking fails for me with Configuration file(s) do(es) not support Objective-C: [...]/workerd/.clang-format (macOS, clang-format 18.1.8 installed via homebrew). Looks like clang-format is mistaking some files to be Objective-C instead of C++?

Unfortunately format checking fails for me with Configuration file(s) do(es) not support Objective-C: [...]/workerd/.clang-format (macOS, clang-format 18.1.8 installed via homebrew). Looks like clang-format is mistaking some files to be Objective-C instead of C++?

Yea that warning is printed for about 5 files where we have embedded typescript in macros but macro expansion happens before syntax parsing in clang-format so it gets confused.
It's not an error but a warning.
We can make it go away by marking objective c files as "don't format" but there isn't any easy fix to make clang format be able to format these files.
It would require quite a massive change in the way it works.
We can revisit it later but I don't think it should block formatting the other hundreds of files we have.

Unfortunately format checking fails for me with Configuration file(s) do(es) not support Objective-C: [...]/workerd/.clang-format (macOS, clang-format 18.1.8 installed via homebrew). Looks like clang-format is mistaking some files to be Objective-C instead of C++?

Yea that warning is printed for about 5 files where we have embedded typescript in macros but macro expansion happens after syntax parsing and language recognition in clang-format so it gets confused. It's not an error but a warning. We can make it go away by marking objective c files as "don't format" but there isn't any easy fix to make clang format be able to format these files. It would require quite a massive change in the way it works. We can revisit it later but I don't think it should block formatting the other hundreds of files we have.

This doesn't look like warning to me, or at least I get a non-zero return code which will cause pushes to fail. Perhaps this is caused by --Werror being enabled, does running python3 tools/cross/format.py --check result in a different return code for you?

Unfortunately format checking fails for me with Configuration file(s) do(es) not support Objective-C: [...]/workerd/.clang-format (macOS, clang-format 18.1.8 installed via homebrew). Looks like clang-format is mistaking some files to be Objective-C instead of C++?

Yea that warning is printed for about 5 files where we have embedded typescript in macros but macro expansion happens after syntax parsing and language recognition in clang-format so it gets confused. It's not an error but a warning. We can make it go away by marking objective c files as "don't format" but there isn't any easy fix to make clang format be able to format these files. It would require quite a massive change in the way it works. We can revisit it later but I don't think it should block formatting the other hundreds of files we have.

This doesn't look like warning to me, or at least I get a non-zero return code which will cause pushes to fail. Perhaps this is caused by --Werror being enabled, does running python3 tools/cross/format.py --check result in a different return code for you?

I've changed quite a lot since morning, try pulling and retrying 😄

Unfortunately format checking fails for me with Configuration file(s) do(es) not support Objective-C: [...]/workerd/.clang-format (macOS, clang-format 18.1.8 installed via homebrew). Looks like clang-format is mistaking some files to be Objective-C instead of C++?

Yea that warning is printed for about 5 files where we have embedded typescript in macros but macro expansion happens after syntax parsing and language recognition in clang-format so it gets confused. It's not an error but a warning. We can make it go away by marking objective c files as "don't format" but there isn't any easy fix to make clang format be able to format these files. It would require quite a massive change in the way it works. We can revisit it later but I don't think it should block formatting the other hundreds of files we have.

This doesn't look like warning to me, or at least I get a non-zero return code which will cause pushes to fail. Perhaps this is caused by --Werror being enabled, does running python3 tools/cross/format.py --check result in a different return code for you?

I've changed quite a lot since morning, try pulling and retrying 😄

ERROR:root:clang-format version must be at least 19.0.0
LLVM 19 is scheduled to be published on September 3, but historically the new version hasn't always been available on macOS Homebrew until a few weeks afterwards. I think this will worsen DX on macOS, is supporting clang-format 18 not salvageable?

worsen DX on macOS, is supporting

Unfortunately format checking fails for me with Configuration file(s) do(es) not support Objective-C: [...]/workerd/.clang-format (macOS, clang-format 18.1.8 installed via homebrew). Looks like clang-format is mistaking some files to be Objective-C instead of C++?

Yea that warning is printed for about 5 files where we have embedded typescript in macros but macro expansion happens after syntax parsing and language recognition in clang-format so it gets confused. It's not an error but a warning. We can make it go away by marking objective c files as "don't format" but there isn't any easy fix to make clang format be able to format these files. It would require quite a massive change in the way it works. We can revisit it later but I don't think it should block formatting the other hundreds of files we have.

This doesn't look like warning to me, or at least I get a non-zero return code which will cause pushes to fail. Perhaps this is caused by --Werror being enabled, does running python3 tools/cross/format.py --check result in a different return code for you?

I've changed quite a lot since morning, try pulling and retrying 😄

ERROR:root:clang-format version must be at least 19.0.0 LLVM 19 is scheduled to be published on September 3, but historically the new version hasn't always been available on macOS Homebrew until a few weeks afterwards. I think this will worsen DX on macOS, is supporting clang-format 18 not salvageable?

Sadly it seems that clang-format-18 spews out different results in my updated linux environment on macOS and on github actions.

Sadly it seems that clang-format-18 spews out different results in my updated linux environment on macOS and on github actions.

That's unfortunate – does that only affect a few files or is it a broad issue? Perhaps we can manage this by manually excluding a few files until 19 comes out, or add
// clang-format off
// clang-format on

sections where appropriate.

Sadly it seems that clang-format-18 spews out different results in my updated linux environment on macOS and on github actions.

That's unfortunate – does that only affect a few files or is it a broad issue? Perhaps we can manage this by manually excluding a few files until 19 comes out, or add
// clang-format off
// clang-format on

sections where appropriate.

Got it sorted with clang-format-18, I edited the comment above.

Got it sorted with clang-format-18, I edited the comment above.

Running the script works on macOS now. Unfortunately, it takes 16s in total on M1 which would slow down the commit process after freezing on src/workerd/jsg/iterator.h – when excluding that file this goes down to 4s which is still quite some overhead but perhaps acceptable. Maybe we can manually exclude that file?

overhead but perhaps acceptable. Maybe

The pre-commit hook only runs on staged files, it shouldn't slow down commits at all unless you editted that specific files.
If that were a problem I would probably multithread the format.py script but on a regular commit with just a few c++ files the format is almost instant.

One thing that I did when I did the internal formatting was to go through the diff and find cases where clang-format made the code much less readable so I could selectively turn off clang-format for certain lines. I won't block on this because it was incredibly painstaking but if you fancy killing about half a day with some monotonous work then it would be an added bonus :sweat_smile:

I'm having some trouble with apply-big-move:

it calls exec ./apply-big-move.sh so if you called it via eg ./tools/unix/apply-big-move.sh then it won't work. I tried cding into tools/unix which got me a bit further.
have to install clang-format-18 and ensure that there is a symlink from clang-format to clang-format-18 on your path. It checks whether clang-format --version is 18 after starting a rebase and doesn't clean it up when it quits, so you have to git reset --hard my-branch first.
Then I see:Fetching tags...
Rewriting commit 63b43725: Add formatting infrastructure to the project.
Updated 1 path from 45fe9bd9
Applying format...
Changes applied successfully.
[detached HEAD ee5ebcdf5] Add formatting infrastructure to the project.
 Author: Dan Lapid<EMAIL_ADDRESS> Date: Fri Aug 9 15:27:49 2024 +0100
 1 file changed, 0 insertions(+), 0 deletions(-)
 mode change 100644 => 100755 tools/unix/apply-big-move.sh
Rewriting commit 37bed02d: Add Python development compatibility flag for tests
Updated 0 paths from e34e2818
Applying format...
Changes applied successfully.
fatal: empty string is not a valid pathspec. please use . instead if you meant to match all paths

And the latest commit is d916b2af Add formatting infrastructure to the project. Maybe invoking from within the tools/unix
directory isn't good?
 This fails on FileNotFoundError: [Errno 2] No such file or directory: 'node_modules/.bin/prettier'
Run npm i prettier and try again.
Now it does a lot more stuff but still fails withfatal: empty string is not a valid pathspec. please use . instead if you meant to match all paths

But now HEAD is detached on a commit that makes my changes on top of d916b2af! So all I have to do is manually update my original branch with e.g., git switch -C orig-branch and I'm good to go.


Upgrade Google Java Format 1.14.0 -> 1.15.0

See:

https://github.com/google/google-java-format/releases/tag/v1.15.0
https://github.com/google/google-java-format/compare/v1.14.0...v1.15.0

Seems this (and in particular https://github.com/google/google-java-format/pull/759) might make #140 less necessary
Great news 👍

I would say that the Add-Exports sections added to the manifest of the google-java-format does not have any effect in this plugin since we don't launch the jar.
We most likely still need to fork the plugin to be able to add the JVM args, even if we add the same args to our manifest, the plugin is run as part of the maven process and will not pick them up.

This wouldn't really have any effects for the plugin I believe? Can still merge ofc.

Yes you are right. Fine with both merging and closing the PR.

It's good to be on the latest version after all :)


Authenticate user on monitoring data request

Monitoring data requests have been open to any user who wants to request it. We need to restrict requests to the functions' owner.

Closed by #752


M3 867

Purpose
Display a tooltip when a Linode plan is disabled.
Solution
I used the existing tooltip prop of the SelectionCard and provided sensible copy.

Coverage increased (+0.03%) to 28.174% when pulling 161e85bf0477e3965f224344cb901797afd97801 on rjstires:M3-867 into 7b3af4fa268770e4b60dd73cb8c82b64a37e37c7 on linode:develop.


[WIP] Use secret resource for usename and password in Scalar DB chart

Note:

This is a PR for discussion.
If we choose this way, we need to apply this update after releasing new version Scalar DB that includes the following PR.
https://github.com/scalar-labs/scalardb/pull/590

This PR update Scalar DB Server Helm Charts to pass the username and password via Secret resource.
In this PR, we use environment variable (Secret) for username/password only.
Another values are passed as ConfigMap.
I would like to discuss which of the following two is better.

Use secret (environment variable) for username/password only (This PR).
Use environment variable for all configurations as well as Scalar DL.

As a result of discussion, we decided to implement this feature in the another way.
So, I close this PR.


PPSSPP activity still fails to launch if games are in chd format.

Daijishou was unable to launch PSP games after the emulator was updated. This was resolved here
https://github.com/TapiocaFox/Daijishou/issues/430
However this issue still exists if the users games are in chd format.  PPSSPP can load them if using the standalone emulator, but daijisho cannot.

https://github.com/TapiocaFox/Daijishou/issues/179


CALL FOR PROPOSALS: DOMAIN

The domain is renewing in May of this year at a cost of around $45. I do not plan to renew the domain next year.
According to our analytics, we get maybe 100 views a month, many of which seem to be inauthentic traffic.
Unless I receive alternate proposals, I intend to do the following before the domain renews in 2023:

Modify the github configuration to end the use of burnout.io and begin using a default github.io domain
Cease the renewal of the burnout.io domain

If we bring this to a default GitHub domain, would you consider converting this to a Material with MkDocs site?  It's easier to maintain and manage and I'd be happy to help as a maintainer.

No objections from me!

The domain renewal is coming up in May. I have disabled auto-renewal and intend to follow through with the plan described last year when it expires.

The plan has been followed, and the site is now available at burnoutio.readthedocs.io.
I completely forgot it was hosted at readthedocs. Any future work to convert it to a MkDocs site will want to take that into account. (Although I suspect that would just be a matter of pointing people at a new GitHub Pages url instead of the readthedocs url.)


Create Custom Commands To Run/Debug Files Based On Extension

Issue Type: Feature Request
Team VSCode,
I need to set a command that runs the currently active file based on it's extension... I already sent a request regarding this issue and the reply was not much helpful or satisfying. I need to make my own commands without the help of third-party extensions. Waiting for your reply.........
VS Code version: Code 1.59.1 (3866c3553be8b268c8a7f8c0482c0c0177aa8bfa, 2021-08-19T11:56:46.957Z)
OS version: Windows_NT x64 10.0.19042
Restricted Mode: No

The Code Runner extension does exactly what you are trying to do. Please read the source to learn how to do this.