fix: capture config check

There are three different conditions:

Ok(true)
Ok(false)
None

And only the first condition should be take as true here.

Hi, thanks for the contribution, is_some() and unwrap_or(false) return the same thing so there is no difference here.

Hi, thanks for the contribution, is_some() and unwrap_or(false) return the same thing so there is no difference here.

They are different on the Ok(false) condition :(

Hi, thanks for the contribution, is_some() and unwrap_or(false) return the same thing so there is no difference here.

They are different on the Ok(false) condition which is_some() returns true but unwrap_or(false) returns false.

Yes but we need to apply the false value because the default value of draw border is usually true and if we ignore false the is no way we can turn it off.

Hi, thanks for the contribution, is_some() and unwrap_or(false) return the same thing so there is no difference here.

They are different on the Ok(false) condition which is_some() returns true but unwrap_or(false) returns false.

Yes but we need to apply the false value because the default value of draw border is usually true and if we ignore false the is no way we can turn it off.

Oh, I see what you mean now. To clarify:

None means default.

Is this right?
I submit this PR because I run the example:
    let settings = WindowsCaptureSettings::new(
        // Item To Captue
        foreground_window,
        // Capture Cursor
        Some(true),
        // Draw Borders
        Some(false),
        // Kind Of Pixel Format For Frame To Have
        ColorFormat::Rgba8,
        // Will Be Passed To The New Function
        "It Works".to_string(),
    )

But I encountered a BorderUnsupported error. Then I'm a little confused why I set the Draw Borders configuration to false, but I still received an BorderUnsupported error. Ah, I see now. It's more like a ConfigBorderIsUnsupported error, right?
I believe the current implementation is satisfactory, so I intend to close this PR. However, I find the error message a bit misleading (at least for me). Additionally, I think it might be better to set the border configuration to None in the example. After all, for someone has the similar environment as mine, the sequence of "clone => run => error" can be quite disappointing :\
Thanks for your replay on this PR and your work on this crate!

Hi, thanks for the contribution, is_some() and unwrap_or(false) return the same thing so there is no difference here.

They are different on the Ok(false) condition which is_some() returns true but unwrap_or(false) returns false.

Yes but we need to apply the false value because the default value of draw border is usually true and if we ignore false the is no way we can turn it off.

Oh, I see what you mean now. To clarify:

None means default.

Is this right?
I submit this PR because I run the example:
    let settings = WindowsCaptureSettings::new(
        // Item To Captue
        foreground_window,
        // Capture Cursor
        Some(true),
        // Draw Borders
        Some(false),
        // Kind Of Pixel Format For Frame To Have
        ColorFormat::Rgba8,
        // Will Be Passed To The New Function
        "It Works".to_string(),
    )

But I encountered a BorderUnsupported error. Then I'm a little confused why I set the Draw Borders configuration to false, but I still received an BorderUnsupported error. Ah, I see now. It's more like a ConfigBorderIsUnsupported error, right?
I believe the current implementation is satisfactory, so I intend to close this PR. However, I find the error message a bit misleading (at least for me). Additionally, I think it might be better to set the border configuration to None in the example. After all, for someone has the similar environment as mine, the sequence of "clone => run => error" can be quite disappointing :\
Thanks for your replay on this PR and your work on this crate!

Yes, None means default, seems like changing border config is only supported on the recent versions of Windows. I will change the example and error message.


fixes to make tiptop work on macOS

These are just some basic fixes and a WIP, not ready for merging yet.
Turns out some neat features have to be solved differently for macOS specifically, or are specifically Linux-only, which will make them either go missing or have weird values on non-Linux OSes.
Fixes #6.

The changes above result in this runtime behavior - it's definitely suboptimal because some crucial information is missing, but I believe this can be added by looking into how glances gets these values (for example). Without these changes, none of the panels are able to run, as there are exceptions thrown in _cpu.py, _mem.py, _info.py, and _proc_list.py.

I'd already merge it now because the PR adds functionality and removes nothing, but let me know when you yourself are happy with it.

Sure, maybe that's a good idea - I can't promise that I'll be able to work on any of the more extensive fixes any time soon, so it's probably better to not hold this here artificially if you're ok with the changes.

I've now merged a bunch of PRs which should fix most (?) of the issues. Could you try again with v0.0.6?

All merged changes are an improvement except for the memory change
        values = [mem.used, mem.available, mem.cached if hasattr(mem, 'cached') else 0, mem.free]

which seems to be reverted in the other PRs.

This is handled differently now.

Ah, I see what you were doing there... it's missing the values, which still break. Fix coming up, I think that should be it then.

A more fitting fix is in #18.

I think all of the issues here are fixed now.


[MRG] renamed distributions for consistency with R and statsmodels

closes #125

Coverage decreased (-0.9%) to 89.514% when pulling eb065b1976db9c0a8ea6bd77c6b51e18040fd095 on distr into 8907dfdc0435ad1e791a4c5e828d2be88a464763 on master.

Coverage decreased (-0.9%) to 89.514% when pulling ac8d1495323ab3e46405a6d8a286badce6b412ff on distr into 8907dfdc0435ad1e791a4c5e828d2be88a464763 on master.

That's it for now @pavanramkumar ! We're getting there ... :)


impl Default for PreEscaped

Tests was broken before the change, I'm not sure if I should fix them. But cargo test misc works.

Also I noticed seemingly unnecessary type restriction:
struct PreEscaped<T: AsRef<str>>(pub T). I believe removing the AsRef restriction won't change any behavior, but it won't be necessary to repeat the restriction in each implementation. I can remove it in this PR if you'd like.

Thanks!

I believe removing the AsRef restriction won't change any behavior, but it won't be necessary to repeat the restriction in each implementation. I can remove it in this PR if you'd like.

That sounds like a good change. Though I'd prefer that in a separate PR, just to keep things small.
That reminds me, I should polish up #322 again...


[Impeller] Incorrect blend mode on drawVertices.

On the macrobenchmarks app:
Skia

Impeller

We're setting the wrong paint blend mode.

No wait, this doesn't have anything to do with the paint blend mode.

I haven't had time to look at this recently so I'm unassigning, but it is fairly easy to reproduce.

This issue is only visible when wide gamut is enabled.
The app is doing a drawVertices with BlendMode.plus.
Looked at this in the Xcode debugger and noticed that the output texture for the drawVertices operation contains pixels with RGB values that sometimes exceed 1 and an alpha value of 2.
When this is blended with the content in the next layer, the results contain pixels with negative RGB values that apparently map to unintended colors in the wide gamut.
ContentContextOptions::ApplyToPipelineDescriptor maps BlendMode::kPlus to BlendOperation::kAdd with source and destination color/alpha blend factors of BlendFactor::kOne.
Is something supposed to be clamping the results of this add operation to the [0, 1] range?

Notes from chat:

Is something supposed to be clamping the results of this add operation to the [0, 1] range?

Everything is in extended srgb when wide gamut is enabled so colors with components outside of [0, 1] are valid colors.  Clipping may have been happening when the gamuts were set to srgb.

and an alpha value of 2.

That doesn't sound right, wide gamut shouldn't be effecting valid alpha values.  Maybe we need a different alpha blend function?

Naively the plus blend can give different results depending if the color is represented in DisplayP3 or extended sRGB.  For example DisplayP3(0.5, 0, 0) is sRGB(0.5490, -0.0933, -0.0529).  If it is blended with itself in displayp3 we get DisplayP3(1, 0, 0), if it is blended with itself in sRGB we get sRGB(1.098, -0.0933, -0.0529).
sRGB(1.098, -0.0933, -0.0529) = DisplayP3(1.0, 0.1977, 0.1365) != DisplayP3(1.0, 0, 0)

I wonder if that is what's happening.

Here is the texture:

here is the resolve:

Neither the source or the destination are negative numbers, but the results are.  I suspect the problem is more likely related to the alpha = 2 than anything related to wide gamut colors.  (Albeit wide gamut's float16 pixel format may be allowing us to get alpha = 2 when we couldn't before).

the gputrace:
PlusBlend.gputrace.zip

Found the fix, the blend mode for the alpha was wrong:
--- a/impeller/entity/contents/content_context.cc
+++ b/impeller/entity/contents/content_context.cc
@@ -124,7 +124,7 @@ void ContentContextOptions::ApplyToPipelineDescriptor(
       color0.src_color_blend_factor = BlendFactor::kOneMinusDestinationAlpha;
       break;
     case BlendMode::kPlus:
-      color0.dst_alpha_blend_factor = BlendFactor::kOne;
+      color0.dst_alpha_blend_factor = BlendFactor::kOneMinusSourceAlpha;
       color0.dst_color_blend_factor = BlendFactor::kOne;
       color0.src_alpha_blend_factor = BlendFactor::kOne;
       color0.src_color_blend_factor = BlendFactor::kOne;

Does that match the definition of this blend mode?
Skia defines SkBlendMode::kPlus as r = min(s + d, 1).  IIUC they are adding all of the source and destination components (including alpha) and then clamping to 1.
(see https://skia.googlesource.com/skia/+/refs/heads/main/include/core/SkBlendMode.h#51)
Or see the W3C spec at https://www.w3.org/TR/compositing-1/#porterduffcompositingoperators_plus, which is adding the source and destination alpha.

kOneMinusSourceAlpha is essentially a clamp to one.  There's no reason to have an alpha value over 1 (here at least, maybe never?).  The alpha math listed in W3C has an implicit clamp in it.
I don't think clamping the color components would be the right call either since it would essentially be throwing out wide gamut colors prematurely.  There is already appropriate clamping happening when displaying to the device extended colors sRGB that can't be rendered.

Consider this example:
import 'package:flutter/material.dart';
import 'dart:ui' as ui;

void main() {
  runApp(CustomPaint(
      size: const Size(300, 300),
      painter: TestPainter(),
  ));
}

class TestPainter extends CustomPainter {
  void paint(Canvas canvas, Size size) {
    canvas.drawRect(Rect.fromLTRB(0, 0, 300, 300),
                    Paint()..color = Color.fromARGB(255, 255, 0, 0));
    canvas.saveLayer(Rect.fromLTRB(0, 0, 300, 300),
                     Paint()..blendMode = BlendMode.srcOver);
    for (int i = 0; i < 20; i++) {
      canvas.drawRect(Rect.fromLTRB(0, 0, 150, 300),
                      Paint()..color = Color.fromARGB(10, 0, 0, 255)..blendMode = BlendMode.plus);
    }
    canvas.drawRect(Rect.fromLTRB(150, 0, 300, 300),
                    Paint()..color = Color.fromARGB(200, 0, 0, 255)..blendMode = BlendMode.plus);
    canvas.restore();
  }

  bool shouldRepaint(covariant CustomPainter oldDelegate) => true;
}

With Skia or dst_alpha_blend_factor = BlendFactor::kOne
With dst_alpha_blend_factor = BlendFactor::kOneMinusSourceAlpha

The 20 calls to drawRect using BlendMode.plus with alpha = 10 should repeatedly add the source alpha to the destination alpha and accumulate an alpha output that is equal to the drawRect with alpha = 200.
But if each call adds the source alpha to a destination alpha that is multiplied by (1 - src_alpha) instead of 1, then the output does not match.

Thanks Jason, so what we know now is that the cause isn't wide gamut colors per se, but the alpha blend calculation for the Plus blend when the pixel format isn't clamped to 1.  Auditing the blends, Plus is the only one that can mathematically result in alpha values greater than one.  That would also explain why no users have reported this, I suspect Plus is rarely used.
I think the easiest solution would be to convert Plus to an advanced blend so we can do:
out = color1 + color2;
out.a = min(out.a, 1.0);

I don't think the standard pipeline can do that math.
Other options

use a 32bpp offscreen buffer if we detect Plus
accepting Plus can be wrong when alpha != 1 with overlapping items

I'll see what it would take to convert it to an advanced blend.

Plus is used by the framework to do color lerps in decoration images:
https://github.com/flutter/flutter/blob/1c153c38d2fca7e9a74a02d2971feda1620dcc88/packages/flutter/lib/src/painting/decoration_image.dart#L750

Plus is used by the framework to do color lerps in decoration images:
https://github.com/flutter/flutter/blob/1c153c38d2fca7e9a74a02d2971feda1620dcc88/packages/flutter/lib/src/painting/decoration_image.dart#L750

Because the usage is blend with plus then restore I think the kOneMinusSourceAlpha would cover that usage.  The error in that blend is from the accumulation of multiple plus's where alpha < 1.0, no?  We probably still want the advanced blend.
  @override
  void paint(Canvas canvas, Rect rect, Path? clipPath, ImageConfiguration configuration, { double blend = 1.0, BlendMode blendMode = BlendMode.srcOver }) {
    canvas.saveLayer(null, Paint());
    a?.paint(canvas, rect, clipPath, configuration, blend: blend * (1.0 - t), blendMode: blendMode);
    b?.paint(canvas, rect, clipPath, configuration, blend: blend * t, blendMode: a != null ? BlendMode.plus : blendMode);
    canvas.restore();
  }

If plus is the only blend mode that is broken ... I think we're doing OK. Making plus an advanced blend is unfortunate but otherwise fixable.

So, switching plus's alpha blend function makes the results 8x more accurate and is correct for alpha = 1 or 0.  I think we should make this an advanced blend but I wonder if we should also land the change to the alpha blend since it is super low risk if we want to cherry-pick that until the advanced blend is implemented.  We need to decide if this bug raises to the bar of wanting to cherry-pick.  I'll bring it up at the next meeting.

This is fixed!


A test issue

Raising a test issue to test the greetings workflow

Its not working

@MastanSayyad, pls make sure that your repo settings are correctly configured to allow the use of workflows


IDREF Xml Schema type is not mapped to 'string'

I'm using mbknor-jackson-jsonschema_2.12 version 1.0.39 from Java with jdk-1.8.0_201
and Jackson 2.12.0-rc1.
I have the following two beans, generated from an XSD schema.
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "MerchantAccountRefType")
public class MerchantAccountRefType implements Copyable, PartialCopyable, ToString2
{

    @XmlAttribute(name = "refId", required = true)
    @XmlIDREF
    @XmlSchemaType(name = "IDREF")
    protected PlatformMerchantAccountType refId;
...
}

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "PlatformMerchantAccountType", propOrder = {
})
public class PlatformMerchantAccountType implements Copyable, PartialCopyable, ToString2
{
    @XmlAttribute(name = "id")
    @XmlJavaTypeAdapter(CollapsedStringAdapter.class)
    @XmlID
    @XmlSchemaType(name = "ID")
    protected String id;
...
}

The JSON Schema generation tool creates such fragments:
    "MerchantAccountRefType" : {
      "type" : "object",
      "additionalProperties" : false,
      "properties" : {
        "refId" : {
          "propertyOrder" : 1,
          "$ref" : "#/definitions/PlatformMerchantAccountType",
          "title" : "Ref Id"
        }
      },
      "required" : [ "refId" ]
    }

    "PlatformMerchantAccountType" : {
      "type" : "object",
      "additionalProperties" : false,
      "properties" : {
        "id" : {
          "propertyOrder" : 1,
          "type" : "string",
          "title" : "Id"
        }
     ...
   }

And I expected such definition for the first element:
"MerchantAccountRefType": {
            "type": "object",
            "required": ["refId"],
            "properties": {
                "refId": {"type": "string"}
            }
        }

Is it correct my expectation?
I used also another generation tool that does that.
See https://www.oxygenxml.com/doc/versions/22.0/ug-editor/topics/xsd-to-json-schema-converter.html

Adding the JsonSchemaInject annotation like below forces the tool to generate correctly the JSON schema.
    @JsonSchemaInject(merge = false , json = "{\"type\": \"string\"}")
    protected PlatformMerchantAccountType refId;

Would be good to  enhance he tool to rely on these annotations and generate the correct type:
@XmlIDREF
@XmlSchemaType(name = "IDREF")

Thank you


deployment how to

Amazon ec2 ubuntu setup:
connecting:

key/Authentication:

In putty:

Connection -> SSH -> Auth
Choose a file

login:

user: ubuntu

Setup

Node version 14:

curl -fsSL https://deb.nodesource.com/setup_14.x | sudo -E bash -
sudo apt-get install -y nodejs

Git:

sudo apt-get install git

port forwarding:

sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3000

Repo setup
clone repo
git clone urlgoeshere

dont forget to setup packages after cloning
npm i

File uploading:

FTP client of your choice.
You will need to add the key similar to in putty
same port 22

server running after terminal close:

https://stackoverflow.com/questions/21193988/keep-server-running-on-ec2-instance-after-ssh-is-terminated

to start:
 tmux

to disconnect:
Ctrl+B, D (ie press Ctrl+B, then release both keys, and then press d)

when logging in again:
tmux attach

if dc'd, reattach:
tmux attach -d!

Note:
if server stopped, all terminals will close as well and will not automatically reopen unless you have a start script

Wow thank you Brett!


Quantum safe filesystem v0.4

redundant ETCD backend

[x] use etcd redundant backend

time based upload

[x] timebased upload (using zero-stor) @maxux
[x] ALL storage containers (also metadata)
[x] support index dirty detection in zdb @maxux
[x] upload changed (dirty) index, use ETCD to keep required metadata @LeeSmet

backend ZDB

multi level ZDB stor so we can support millions of backend files

more information needed

restore part

[x] Make sure we can easily restore

[x]  retrieve from etcd as metadata stor, so people can easily recreate from where they were with max e.g. 15 min delay @LeeSmet

Logging

[x] logfile to show which files are deleted, modified, added with timestamp, with size @maxux
[x]  logfile for zero-stor: which shows which files uploaded, timestamp, size, destinations, ... @LeeSmet

monitoring / repair tool

[x] Need rust based monitoring/repair tool (small) @LeeSmet  https://github.com/threefoldtech/quantum-storage/issues/5

[x]  check health of backends

[x]  if missing ZDB's repair on other location

Requirements Repair Tool

need to make sure we cannot have silent data loss
when out of capacity ask for extra ZDB to evdc controller

Update status:

0-db-fs support locked namespace: https://github.com/threefoldtech/0-db-fs/issues/8
0-db supports external hook initialization status: https://github.com/threefoldtech/0-db/issues/100
0-db supports data/index path via NSINFO: https://github.com/threefoldtech/0-db/issues/102
0-db supports list of running hooks monitoring: https://github.com/threefoldtech/0-db/issues/104

Monitoring tool can now query 0-db to get instance and real-time information needed for some part.
Coming:

0-db support of time based data rotation: https://github.com/threefoldtech/0-db/issues/101
0-db support of index dirty changes tracking: https://github.com/threefoldtech/0-db/issues/103

All required features are done in zstor, except for the notification of failed uploads. Implementation of that will depend on the monitoring tool

Can we have a new release done / ready for testing.  Want to create a new video about this and share with the larger community.

I'm on it, releasing new version and populating everything together.
I'm writing auto-release script to make next release easier to publish.

Will implement zdbfs logfile tomorrow (but this is not needed)

Version 0.0.4 released: https://github.com/threefoldtech/quantum-storage/releases/tag/v0.0.4
This version include latest zstor and latest zdb/hook.
Warning: default configuration provided for backend is not valid anymore, but using a custom evdc config works.
Note: logfile is not supported for zdbfs, this require more work but this doesn't change workload and kind of log can be generated using debug binary if needed.

Will verify today.

0-db-fs logfile implemented via https://github.com/threefoldtech/0-db-fs/pull/12
Will test and release soon.

Issue verified and closed.

I'm going to release next bootstrap including zdb 2.0 which does not have files limitation.

Can I have a look at the release?   The latest published release  is still 0.4.... :-)

Will take a look with @LeeSmet to release latest version of the bootstrap


YARN-11141. Capacity Scheduler does not support ambiguous queue names…

… when moving application across queues

Description of PR
How was this patch tested?
For code changes:

[ ] Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
[ ] Object storage: have the integration tests been executed and the endpoint declared according to the connector-specific documentation?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE, LICENSE-binary, NOTICE-binary files?

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 41s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ branch-3.3 Compile Tests _

+1 :green_heart:
mvninstall
35m  8s

branch-3.3 passed

+1 :green_heart:
compile
1m 10s

branch-3.3 passed

+1 :green_heart:
checkstyle
1m  4s

branch-3.3 passed

+1 :green_heart:
mvnsite
1m 16s

branch-3.3 passed

+1 :green_heart:
javadoc
1m  6s

branch-3.3 passed

+1 :green_heart:
spotbugs
2m 19s

branch-3.3 passed

+1 :green_heart:
shadedclient
25m 46s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m  0s

the patch passed

+1 :green_heart:
compile
0m 53s

the patch passed

+1 :green_heart:
javac
0m 53s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 40s

the patch passed

+1 :green_heart:
mvnsite
0m 57s

the patch passed

+1 :green_heart:
javadoc
0m 40s

the patch passed

+1 :green_heart:
spotbugs
1m 58s

the patch passed

+1 :green_heart:
shadedclient
24m 50s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
89m 35s

hadoop-yarn-server-resourcemanager in the patch passed.

+1 :green_heart:
asflicense
0m 51s

The patch does not generate ASF License warnings.

189m  2s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4312/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4312

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell

uname
Linux d3750acd6c70 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
branch-3.3 / 188356fe5e62b696a486cd1b9c567793d1e82056

Default Java
Private Build-1.8.0_312-8u312-b07-0ubuntu1~18.04-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4312/1/testReport/

Max. process+thread count
864 (vs. ulimit of 5500)

modules
C: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager U: hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4312/1/console

versions
git=2.17.1 maven=3.6.0 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

Thanks @9uapaw ,
Patch LGTM, merged to branch-3.3


[Request] Retroactive Critical Damage Rolls

Because retroactive advantage can turn an attack into a critical hit, it would be great to be able to retroactively increase the damage to critical hit range.

This is firmly out of the scope for this module.
The logic for handling anything other than the d20 roll itself is an order of magnitude more complex.


Updates to tagged version handling

Loosen version tag found in Makefile: --exact-match failed when not on a version tag showing v0.0.0, without it we get the most recent version tag followed by a commit-ish to indicate a modified build but also its base version
Show version from command line with --version
Eliminate the dependency on github.com/earthboundkid/versioninfo and get the vcs.revision value directly since the minimum go version is 1.21.

I'll re-work this to have a second version that gets printed with --version so it is simpler to work backwards to what commit was used for the build.

I've moved the version string assembly into its own function workers.VersionStr() and pulled getting the info from the go binary inline.  The Makefile defines VERSION now with '-dev' appended to the most recent tag so it is apparent that this is not a release build.


Allow controller syntax

This creates an array named "servicos.produtos":
<div server-repeat="produto as servicos.produtos">
// ...

since I'm using ui-router and controllerAs, I don't use the raw scope and namespacing to servicos controller. It's not a case of "deep level" properties

this seem to suffice:
var collection           = $scope.$parent.$eval(collectionIdentifier) || $scope.$parent[collectionIdentifier] || [];

but on an SPA, this directive is leaking memory like crazy, when using ui-router or preloading views. the data doesn't get freed when switching between them, expect perfomance penalties


Kanban Board Setup

Project link
There are 3 people on our team.

Team Member 1: Dire Akanbi
Team Member 2: Awais Amjed
Team Member 3: Dagmawi zewdu

Thanks for the feedback, We updated the project with points.

Hi @awais-amjed,
Congratulations! 🎉
Your project is complete!  There is nothing else to say other than... it's time to merge it 🚀 :
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, remember to tag me in your question so I can receive the notification.

As described in the Code reviews limits policy  you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.


Add Bholdus network SS58 Address

Hi, This is registration for SS58.
prefix 2207 for Bholdus network (https://bholdus.com)

@bkchr and @BenWhiteJam could you please give a moment to review?

@BenWhiteJam could you please check?

@naviocean could you please reach out on Element?

Please move the pr over to: https://github.com/paritytech/ss58-registry


Security alert: upgrade node-forge to 0.10.0

I had this popping up in my repo a few days ago, just wanted to let you know

Can we update node-forge or is that breaking ? I have no idea if you guys already know or if someone is already on it ? Just let me know :)

I'm having the same issue, NPM is calling it a high severity vulnerability.
Will APN work with Node-Forge > 0.7.6? Or will we just have to have the vulnerability?

I'm having the same issue, NPM is calling it a high severity vulnerability.
Will APN work with Node-Forge > 0.7.6? Or will we just have to have the vulnerability?

There seems to be an open PR already. Has been open since September though.

There seems to be an open PR already. Has been open since September though.

https://github.com/danthegoodman1/node-apn if anyone wants to use an updated fork


query connection given connection_id

Given a connection id, query the connection.
Should be able to run this from the relayer CLI.

Proto definitions for connection queries and responses (see ConnectionEnd, Counterparty, etc) are here:
https://github.com/cosmos/cosmos-sdk/tree/master/proto/ibc/connection

As per our discussion today, I'll create a proto folder and store the proto files in there following the same structure as the  cosmos sdk proto folder.

BTW, something I forgot to mention but you've probably seen already is that if you want to generate the rust types during build time, you also need a dependency on prost-build:
[build-dependencies]
prost-build = "0.6"

and a build.rs file. In tendermint-rs we never used that because we never generated the types (this might change in the near future too). Here is an example:
https://github.com/libp2p/rust-libp2p/blob/master/core/build.rs
https://github.com/libp2p/rust-libp2p/blob/master/core/src/keys.proto
https://github.com/libp2p/rust-libp2p/blob/6ad05b0ff1cb11ceec37cb191adb0d13feaceeb4/core/src/lib.rs#L38-L40

Added a new branch andy/proto
Implemented the initial proto files required for the connection.
The proto files are in the modules folder.
Copied proto files from cosmos-sdk and tendermint repos, but it seems they are not in sync, e.g. a cosmos proto file reference an import from tendermint that was not valid. Noticed the tendermint proto files just had a refactoring a few hours ago. Looks like this proto work on the crates are pretty much in flux for now.
There's a new build.rs in there that generate the files in the output folder (e.g. /target/debug/build/relayer-modules-[HASH]/ibc.connection.rs).
Then tried to replace the connections mod (modules/src/ics03_connection/mod.rs) with generated file as per prost_build instructions but got bunch of failures probably because there are dependencies that the original Rust connection had and it's not in the generated proto files.

Next steps are trying to make it compile again using the new proto generated file. We might need to chat about this. Seems to me that a lot of logic in the proto files are somewhat duplicate with things already implemented in the Rust code.

Just a note for now let's try to use the minimal amount of proto to get this working. Since this is just the ConnectionEnd we should probably copy over just the pieces we need to query just a ConnectionEnd - I don't think that should have any dependency on Tendermint. If we copy over the full dir we'll have lots of deps but let's try to simplify first to get it working.

Just a note for now let's try to use the minimal amount of proto to get this working. Since this is just the ConnectionEnd we should probably copy over just the pieces we need to query just a ConnectionEnd - I don't think that should have any dependency on Tendermint. If we copy over the full dir we'll have lots of deps but let's try to simplify first to get it working.

I’ve tried to use the minimal as far as I know. There might be more ways to trim possibly. The dependency on tendermint proto is from the cosmos proto, there’s an import for tendermint.crypto.Proof (which the cosmos proto had what it seems an old reference tendermint.crypto.merkle.Proof and I changed to match the new tendermint reorged protos). We should have some discussions on how we want to handle proto files on our side. Thought the idea of using proto in the end was that all implementations used the same interface to prevent mismatches and deserialization issues. But if we’re going to implement our own protos then we can structure for now in a more simplistic way.

Regarding the dependency on the Go proto definitions & compiling them:
It seems that the problem with using the Go-based .proto files is that there are some Go-specific declarations in there. The gogo extension is problematic:
message ConnectionEnd {
  option (gogoproto.goproto_getters) = false;
  // connection identifier.
  string id = 1 [(gogoproto.customname) = "ID", (gogoproto.moretags) = "yaml:\"id\""];
  // client associated with this connection.
  string client_id = 2 [(gogoproto.customname) = "ClientID", (gogoproto.moretags) = "yaml:\"client_id\""];
  // opaque string which can be utilised to determine encodings or protocols for
  // channels or packets utilising this connection
  repeated string versions = 3;
  // current state of the connection end.
  State state = 4;
  // counterparty chain associated with this connection.
  Counterparty counterparty = 5 [(gogoproto.nullable) = false];
}

Trying to trim out the gogo part and see where that leads.

While writing the above ^ comment I remembered that there are more "canonical" proto definitions here:
https://github.com/cosmos/ics/blob/master/spec/ics-003-connection-semantics/data-structures.proto

It seems that the problem with using the Go-based .proto files is that there are some Go-specific declarations in there. The gogo extension is problematic:

Out of curiosity do they err if build with prost? It would be good to give that as feedback to the tendermint/sdk team.

Implemented logic that the response can be decode using prost.
Error handling is not the best for now, just added something so it could compile need to understand how to do it properly
There are a few classes that have todo!() that we might need to implement later now that we are deserializing things (e.g. CommitmentPath)

If you want to run this

You have to use the andy/proto branch.
Get the simapp folder from bucky's branch (https://github.com/informalsystems/ibc-rs/tree/bucky/genesis-data/relayer/tests/support/ibc-test)
Run simd --home simapp start
On another terminal window got to the ibc-rs folder and run ./target/debug/relayer -c ./relayer/relay/tests/config/fixtures/relayer_conf_example.toml query connection end chain_A connectionidone

Out of curiosity do they err if build with prost? It would be good to give that as feedback to the tendermint/sdk team.

No, they don't error, surprisingly. But note we had to manually copy/paste the gogo.proto from github into our repo..
It seems that only the prefix needs fixing. And we need to also define pub struct CommitmentPrefix which is empty. I'm now overhauling the code and will push an update soon with a simplified .proto versions. @andynog  please let me keep the token on your branch for a bit longer.

This is the output for the command above. Need someone (maybe @ancazamfir) to validate if it makes sense

Looks good! I made some comments in the PR wrt error handling. The command takes some other parameters, -h <height> for example queries at the specified height. I had simd running for longer and because of pruning the query at low heights fails with pages of traces. Same with non-existing connection.

Worked on the issue that an exception was thrown if height parameter was specified. Now it shows an error message (but not sure if the error makes sense, need @ancazamfir to validate message)
For example specifying height 4:
./target/debug/relayer -c ./relayer/relay/tests/config/fixtures/relayer_conf_example.toml query connection end chain_A connectionidone -h 4
     Options QueryConnectionOptions { connection_id: ConnectionId("connectionidone"), height: 4, proof: true }
connection query error RPC error: proof is unexpectedly empty; ensure height has not been pruned: invalid request


Make BehaviorVersion as future-proof as the documentation specifies

Fixes #1111
This is technically a breaking change but since this was released recently and it's documented that this API shouldn't be used, better now than later.

Closing because this PR should be opened to https://github.com/smithy-lang/smithy-rs


packages.config must be in the project directory

my testing found that this file must be in the project root next to the .vcxproj file. attempts to share this file between multiple projects, putting it above (e.g. ..\packages.config) and referencing it from the .vcxproj file, does not work.

Docs Build status updates of commit 8e52d7e:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/reference/packages-config.md
:white_check_mark:Succeeded
View

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

Does the ..\ reference work in other languages? I assume not. My understanding is other languages don't need to use packages.config as this information is stored in  .*proj files. So, this is issue is more related to C++ and it seems appropriate here.

Docs Build status updates of commit 5adde09:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/reference/packages-config.md
:white_check_mark:Succeeded
View

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

It's true for any proj files.
I've removed the C++ reference.


Wiki translation into Romanian

Are you going to translate the description fields?

I didn't think that it was necessary to translate that, but I will

Ok, I just changed thew description

I just noticed, you moved the files inside docs/ to the root of this project, I'll have to clean that up later.
Regarding description, yeah, it is needed for metadata tags as well as opengraph image generation, while you probably can skip doing this for now if you're busy.
I'll prepare the lunaria configuration files and related later today in your PR.

I just noticed, you moved the files inside docs/ to the root of this project, I'll have to clean that up later.
Regarding description, yeah, it is needed for metadata tags as well as opengraph image generation, while you probably can skip doing this for now if you're busy.
I'll prepare the lunaria configuration files and related later today in your PR.

Ok, also thanks for the notice about the description

You're now only left witb translating the sidebar.

You're now only left witb translating the sidebar.

Where is the sidebar text?

docs/.vitepress/locales/ro.ts

Nope, https://github.com/Douper2/wiki/blob/master/docs/.vitepress/locales/ro.ts, I committed the file myself for you.

Nope, https://github.com/Douper2/wiki/blob/master/docs/.vitepress/locales/ro.ts, I committed the file myself for you.

Most likely I forgot to upload the file containing the sidebar but now it's fixed

Thanks, I also now noticed that some pages still have their english fields (title, description), will you translate them?

Thanks, I also now noticed that some pages still have their english fields (title, description), will you translate them?

No problem, I just finished translating the description

I fixed another translation, could you merge it?

Make a new PR.


Beta: Mutations are creating invalid code

Summary
The mutations that are being created have strange errors in them.
Unterminated Template Literals
Below is the tail end of a file are being mutated:
          const url = __global_69fa48.__activeMutant__ === 706 ? `` : (__global_69fa48.__coverMutant__(706), `https:
          this.browserService.launch(url);
        }
        break;
    }
  }

}

Note that the \https:` template is unterminated, so when this is compiled by TypeScript compiler you get the error:
error TS1160: Unterminated template literal.

Unterminated String Literal
Tail end of another file:
  protected getExcludedFiles(): string[] {
    switch (__global_69fa48.__activeMutant__) {
      case 1086:
        {}
        break;

      default:
        __global_69fa48.__coverMutant__(1086);
        {
          const list: string[] = __global_69fa48.__activeMutant__ === 1087 ? [] : (__global_69fa48.__coverMutant__(1087), [__global_69fa48.__activeMutant__ === 1088 ? "" : (__global_69fa48.__coverMutant__(1088), '**/Libsite-packages

It's just truncated at that point, and so the compiler error is:
error TS1002: Unterminated string literal.

Original unmutated code:
   protected getExcludedFiles(): string[] {
        const list: string[] = ['**/Lib/**', '**/site-packages/**'];
        this.getVsCodeExcludeSection('search.exclude', list);
        this.getVsCodeExcludeSection('files.exclude', list);
        this.getVsCodeExcludeSection('files.watcherExclude', list);
        this.getPythonExcludeSection(list);
        return list;
    }

(There's another 60 lines of code after that I left out that was just dropped from the mutated file).
')' Expected
Another tail end:
  private openPythonExtensionPage() {
    switch (__global_69fa48.__activeMutant__) {
      case 11468:
        {}
        break;

      default:
        __global_69fa48.__coverMutant__(11468);
        {
          env.openExternal(Uri.parse(__global_69fa48.__activeMutant__ === 11469 ? `` : (__global_69fa48.__coverMutant__(11469), `https:
        }
        break;
    }
  }

}

Again, the \https` is unterminated, but that leads to the parentheses being unmatched too, which is the compiler error reported here.
Original unmutated code:
    private openPythonExtensionPage() {
        env.openExternal(Uri.parse(`https://marketplace.visualstudio.com/items?itemName=ms-python.python`));
    }
}

There's a bunch more of these but the above are illustrative.

Stryker config

{
  "$schema"<EMAIL_ADDRESS>  "packageManager": "npm",
  "reporters": [
    "html",
    "clear-text",
    "progress"
  ],
  "testRunner": "mocha",
  "buildCommand": "npx gulp prePublishNonBundle",
  "mutate": ["src/client/**/*.ts"],
  "coverageAnalysis": "perTest"
}

Test runner config

Stryker environment

➜  vscode-python-me git:(stryker) ✗ npm ls | grep stryker
├─┬ UNMET PEER DEPENDENCY<EMAIL_ADDRESS>│ ├─┬<EMAIL_ADDRESS>│ ├─┬<EMAIL_ADDRESS>│ │ ├─┬<EMAIL_ADDRESS>│ │ ├──<EMAIL_ADDRESS>deduped
│ ├─┬<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├─┬<EMAIL_ADDRESS>│ ├─┬<EMAIL_ADDRESS>│ └──<EMAIL_ADDRESS>deduped
├─┬<EMAIL_ADDRESS>│ ├─┬<EMAIL_ADDRESS>│ ├──<EMAIL_ADDRESS>deduped
├──<EMAIL_ADDRESS>├─┬<EMAIL_ADDRESS>│ ├─┬<EMAIL_ADDRESS>│ ├──<EMAIL_ADDRESS>deduped
├─┬<EMAIL_ADDRESS>│ ├─┬<EMAIL_ADDRESS>

+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>+--<EMAIL_ADDRESS>
Test runner environment

# Test command

Your Environment

software
version(s)

node
12.18.0

npm
6.14.4

Operating System
MacOS Catalina

Add stryker.log

Thanks a lot @gramster ! Will have a look tomorrow

Update: I just read #2466 and that triggered me. I think this issue is already fixed, but we didn't release a new beta version. I just released  v4.0.0-beta.5. Could you please try it again?
Sorry for the work you put in, we should be better about updating our beta's 😢
It was fixed with #2438

No worries, I am very excited about getting this to work as it solves a big problem for me around measuring the effectiveness of our test suites :-), and you have been very responsive. I'll update and try again.

Looks like I am now past the build step! The next thing I need to figure out is how to customize the mocha command.

I got somewhat further. I had to remove a bunch of tests that failed in the initial test run, but now I get:
20:56:48 (72658) ERROR DryRunExecutor Initial test run timed out!
20:56:48 (72658) ERROR Stryker an error occurred Error: Something went wrong in the initial test run
    at DryRunExecutor.validateResultCompleted (/Users/grwheele/repos/vscode-python-me/node_modules/@stryker-mutator/core/src/process/3-DryRunExecutor.js:67:15)
    at DryRunExecutor.execute (/Users/grwheele/repos/vscode-python-me/node_modules/@stryker-mutator/core/src/process/3-DryRunExecutor.js:39:14)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
    at async Stryker.runMutationTest (/Users/grwheele/repos/vscode-python-me/node_modules/@stryker-mutator/core/src/Stryker.js:35:49)

and I have no idea what tests I should remove to get past this (there are several thousand tests).

Well... the initial test run should pass if your normal test run also passes. Instrumented code without an activated mutant should of course run the same way as non-instrumented code would.
There can be a number of things that are problematic. The best way to debug this is to kill the process during the initial test run, cd into the sandbox directory cd .stryker-tmp/sandbox1234 and then run the tests yourself.
I can also give it a try. Is this the repo? https://github.com/Microsoft/vscode-python

Alternatively, you can run with --logLevel trace or --fileLogLevel trace to see the stdout output from the child process (the test runner process).

I've taken a look. Nice bug! 🐛
This:
switch (item.severity) {
    case DiagnosticSeverity.Error: {
        traceError(message);
        this.outputChannel.appendLine(message);
        break;
    }
    // ...
    default: {
        traceInfo(message);
    }
}

Is instrumented as this:
switch (item.severity) {
    case DiagnosticSeverity.Error:
    {
        switch (__global_69fa48.__activeMutant__) {
        case 1775:
            {}
            break;

        default:
            __global_69fa48.__coverMutant__(1775);
            {
            traceError(message);
            this.outputChannel.appendLine(message);
            break;
            }
            break;
        }
    }

    // ...

    default:
    {
        switch (__global_69fa48.__activeMutant__) {
        case 1779:
            {}
            break;

        default:
            __global_69fa48.__coverMutant__(1779);
            {
            traceInfo(message);
            }
            break;
        }
    }
}

Which... is obviously wrong. The inner break won't break out of the case it was designed to break out of.
@hugo-vrijswijk I know you use the same case statement syntax in Stryker4s. How do you handle these kinds of mutant placements?

Thanks for diving into this, Nico! Really appreciate it. Just BTW, I am wanting to use Stryker because I think our test suite has a lot of anti-patterns in it, especially over-use of mocking, and want to come up with metrics for a baseline that we can improve. I'd be interested in knowing of over metrics you may be aware of. Right now, I am thinking of these:

code coverage (obviously not very useful just on its own)
the mutation index score from Stryker (I'm thinking of this as "test effectiveness")
time taken to run the tests (this is one where mocking can improve the score, so I want metrics in tension with that)
"test efficiency" - I'm kind of inventing here, but was thinking of looking at the ratio of lines of real code covered by a test to lines of test code covered by a test. Are we able to write concise tests that cover a good amount of real code? This is one where I expect the overuse of mocking will hurt the metric. This seems like something Stryker could compute too if it was useful.

@hugo-vrijswijk thanks for pitching in. So scala doesn't have a break statement, this is interesting... and such a good idea! 👍
Since JS does have a break statement, I think the easiest thing to do is to use an if-statement instead of a switch ... case. This is quite a big change, so it might cost me a day or 2 to implement.

BTW, I am wanting to use Stryker because I think our test suite has a lot of anti-patterns in it [...]

Yeah, I saw some of them already at a first glance (for example Math.random() in tests. Made me scratch my head 😉) .

the mutation index score from Stryker (I'm thinking of this as "test effectiveness")

Yep. Definitely "test effectiveness", that's what I call it as well. It might be difficult to get Stryker running on the entire test suite since it takes a very long time.
Worst case scenario:  Tmutation-testing = Ttest run * n.
Where n = number of mutants. Per test coverage analysis + running in parallel will speed that up considerably, but still a big time. You might want to think about sharting your mutation runs. This is what we do for Stryker, see for example https://github.com/stryker-mutator/stryker/actions/runs/228545052
Why don't you join our slack, so we can discuss the other points further? Always nice to talk about tests 😍 join slack

@gramster the issue with case switch statements is fixed. However, I still run into an issue during the dry run of the vscode-python, this is because #2474, I'll be fixing that next

Ok after I fixed #2474, I ran into #2485 . After I fixed that I managed to start a run properly:
nicojs@nicoj03 ~/vscode-python (main)$ npx stryker run
14:48:35 (8032) INFO ConfigReader Using stryker.conf.json
14:48:36 (8032) INFO InputFileResolver Found 1041 of 2380 file(s) to be mutated.
14:49:04 (8032) INFO Instrumenter Instrumented 1041 source file(s) with 72054 mutant(s)
14:49:05 (8032) INFO ConcurrencyTokenProvider Creating 7 test runner process(es).
14:49:06 (8032) INFO Sandbox Running build command "tsc -b" in the sandbox at "/home/nicojs/vscode-python/.stryker-tmp/sandbox9640422".
14:50:50 (8032) INFO DryRunExecutor Starting initial test run. This may take a while.
14:52:41 (8032) INFO DryRunExecutor Initial test run succeeded. Ran 8441 tests in 4 minutes 6 seconds (net 84892 ms, overhead 8504 ms).
Mutation testing  [                                                  ] 0% (elapsed: ~1m, remaining: ~5h 14m) 92/24878 tested (7 survived, 8 timed out)

Hope you have some decent hardware to run this on since it will take a couple of hours. Or run mutation testing on a part of the code.
I will release a new version of the beta and report back here.

Just released 4.0.0-beta.7. Happy mutation testing @gramster  😁

Awesome, thanks Nico!
On Thu, Sep 17, 2020 at 6:06 AM Nico Jansen<EMAIL_ADDRESS>wrote:

Just released 4.0.0-beta.7. Happy mutation testing @gramster
https://github.com/gramster 😁
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/stryker-mutator/stryker/issues/2469#issuecomment-694219113,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAVCPCDMLR7BVM6T26MW3ZTSGICWXANCNFSM4RDEHLNA
.

And thank you for the bug reports. 🐛


[BEAM-1251] Unskip passing Python 3 tests

This is is part of a series of PRs with goal to make Apache Beam PY3 compatible. The proposal with the outlined approach has been documented here: https://s.apache.org/beam-python-3.
This PR removes the skip condition for some tests which were indirectly fixed for Python 3.
Post-Commit Tests Status (on master branch)

Lang
SDK
Apex
Dataflow
Flink
Gearpump
Samza
Spark

Go

---
---
---
---
---
---

Java

Python

---

---
---
---

retest this please

(just to take another look on the failure we see).

These tests pass on 3.3. I suggest we skip the passing tests only if Python interpreter version is less than 3.5.3, then we will keep the tests for 3.6, and devs running 3.5.3 or higher on their workstations will still exercise the tests.

Ok, thank you. Sounds good.
Should we also throw a warning when using the failing functionality on versions <3.5.3?

No, instead of warnings I think we will have to set python_requires to >= 3.5.3 for Python 3 versions.

@aaltay @charlesccychen to help with the merge, thank you!


Recommend a global installation of the npm package

Since the package is a tool, it should be installed globally so it can be reused across projects. The same approach can be leveraged in automated build. It may be obvious to some, but from personal experience it's better when clearly stated (and the syntax spelled out).

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

@sign-off

#sign-off

@mamccrea: I'm sorry - only the author of this article, @su-jie, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.


Use Next Image on Home Page

References #136
📝 Description
The Chakra UI website had poor performance due to images not being served at the correct size and next-gen formats.
⛳ Current behavior (updates)
Use of chakra.img and Img tags which don't do resizing of images or serve them in next-gen formats
🚀 New behavior
Use of ChakraNextImage tag for better performance
💣 Is this a breaking change (Yes/No):
No

📝 Additional Information
Change in lighthouse scores (left is chakra UI on prod and right is the preview deployment for this pr) -

@AnishDe12020 looks good. Make sure you resolve the conflicts, then we can merge this.

@AnishDe12020 looks good. Make sure you resolve the conflicts, then we can merge this.

Done, I have fixed the merge conflicts in https://github.com/chakra-ui/chakra-ui-docs/pull/137/commits/5bea83011b29011e68ffd079134d7176a3326c57. Do let me know if anything is wrong

@allcontributors please add @AnishDe12020 for code.


ResolvedLicense: fix toResolvedCopyrights to identify the same copyri…

…ght in multiple files.
Fix a regression when a copyright is present in multiple files in the same repository.
The expected behavior is that the all findings of the copyright are returned, if they have different paths.
The previous behavior was that only the last finding was kept, as 'statementToFinding' is built using 'associateBy' which "If any two elements would have the same key returned by keySelector the last one gets added to the map."
Signed-off-by: Stefano Bennati<EMAIL_ADDRESS>Please ensure that your pull request adheres to our contribution guidelines. Thank you!

We identified this regression in one of our scans where resolvedLicense.getResolvedCopyrights() returned
[[[ResolvedCopyrightFinding(statement=Copyright (c) 2021-2022 HERE Global B.V. and its affiliate(s), location=TextLocation(path=src/index.html, startLine=4, endLine=4), matchingPathExcludes=[])]]]

instead of
[[[ResolvedCopyrightFinding(statement=Copyright (c) 2021-2022 HERE Global B.V. and its affiliate(s), location=TextLocation(path=LICENSE, startLine=1, endLine=1), matchingPathExcludes=[]),
ResolvedCopyrightFinding(statement=Copyright (c) 2021-2022 HERE Global B.V. and its affiliate(s), location=TextLocation(path=src/assets/LICENSE, startLine=1, endLine=1), matchingPathExcludes=[]),
ResolvedCopyrightFinding(statement=Copyright (c) 2021-2022 HERE Global B.V. and its affiliate(s), location=TextLocation(path=src/index.html, startLine=4, endLine=4), matchingPathExcludes=[])]]]

Let me come up with a test for this first...

Let me come up with a test for this first...

@bennati and @zhernovs, I'm having trouble reproducing your issue. Do you agree that the test add in https://github.com/oss-review-toolkit/ort/pull/6109/commits/dea34c2db58ccb9b2a1cfa0db442ff0e75d1e473 should reveal is there was any issue?
Also, which version of ORT are you using? Can it be that you're using a version that lacks https://github.com/oss-review-toolkit/ort/pull/6016?

In our case the issue were caused on a project that has the same license (same statement and years) in root of the project and in subdirectories (src, src/assets). So perhaps you can't reproduce the issue because there are different years in https://github.com/oss-review-toolkit/ort/commit/dea34c2db58ccb9b2a1cfa0db442ff0e75d1e473?
We facing this issue on every version newer than https://github.com/oss-review-toolkit/ort/commit/3e9d11d83626c7886f2706d72ce05dddd40937cc including https://github.com/oss-review-toolkit/ort/commit/03bea2277177284e2a504b1a90f7b8c90a2f8622
Please @bennati correct me if I'm wrong.

Correct, we applied the fix https://github.com/oss-review-toolkit/ort/pull/6016 (which this fix reverts because the values in statementToFinding are now processed statements).
Try setting the year of both copyrights to be the same.

Try setting the year of both copyrights to be the same.

Thanks, that way I can reproduce the issue. I've added a test and am proposing a more minimal fix in https://github.com/oss-review-toolkit/ort/pull/6113. Would you mind testing it?

Thanks @sschuberth, the test was successful!

Thanks @sschuberth , the test was successful!

Great, then let me close this in favor of the other PR. Many thanks for the report and initiative to fix it!


Transparently handles rate controlled file systems when proxying as a…

…nother user.

@ydailinkedin can you review?

Talked to @ibuenros . LGTM!


Coding error in counter track hue selection

Came across this while studying the code. Obviously, not a bug since color is subjective. If you don't want to change behavior (i.e., fix the typo), I suppose you can correct the comment so that it syncs with what the code is doing.
I believe the Math.max() call in this line accidentally has a minus character instead of a comma. It wouldn't make much sense to use that function on a single argument. I believe the code wants to use an exponent range of 3 through 9, but didn't get there.
So, the colors being used are not what's described in the comment. Do with this information what you wish :-)

Hey, thanks for letting us know 👍
I think the intention was probably something like this:
const expCapped = Math.min(Math.max(exp, 3), 9) - 3;

I've put a patch together and notified the person responsible for the code to see if it matches their expectations.

Ah, yes.  That makes more sense. A net exponent range of 0 through 6 (not 3 through 9 as I stated) would give the color sequence described in the comment.

@stevegolton I don't know if you meant to mark this closed or whether that was accidental. I looked for the PR/commit with the adjustment and didn't find it.

Sorry, yes the patch is still in review. I was too trigger-happy with the close button. Reopening.
Here's the link to the patch.
https://android-review.googlesource.com/c/platform/external/perfetto/+/3027711

It turns out the functionality of the code was the correct and the comment was wrong. Besides, color scheme changes are difficult as folks get used to the way things look and it's jarring when things change.
I've removed the comment (and the superfluous Math.max()) under the assertion that no comment is better than a wrong comment.

Sounds good to me. I suspect changing the color algorithm at this point would probably be seen as undesirable for that very reason. So, removing the comment is very much a suitable resolution, IMO. Thanks!


Improved Post Paste Behaviors

This exposes behaviors for all of iD's operations so we can support them in more places other than select mode.  Being able to perform operations while moving and rotating shapes (e.g. post-paste) is super useful.
This will close #3656

You can now use many of the operations from Select mode in Move and Rotate modes, and can seamlessly switch between the modes with the M and R hotkeys.  Also many things that previously did not work with multiselections (like reflect or rotate around centroid) do work now.
I have a few more checks to add before merging, but this is feeling 👌


Add tests

Hi, this question is quite selfish, I'd like to use this repo among others for smoke testing new pydantic releases, see https://github.com/pydantic/pydantic/discussions/4359. According to this this repo has the most pydantic imports, hence why I came here.
It would be great if we could add tests to this repo, I guess either (or both of):

add tests for a few specific examples
automate the build of models for all types (perhaps using hypothesis?) and compare to stored JSON schemas - this wouldn't immediately catch bugs, but it would catch changes, e.g. in new pydantic releases

WDYT?

Hi @samuelcolvin. Great to hear from you, i have been using pydantic in so many projects :+1:
In this repo there is already one test script that creates the extended BaseModel classes for all all schema.org examples located at (https://schema.org/version/latest/schemaorg-all-examples.txt). This script effectively checks if the examples provided by schema.org can be loaded into the Pydantic models. The script can be found here: https://github.com/lexiq-legal/pydantic_schemaorg/blob/main/src/test_classes.py.
All the models in this repo are already automatically build according to the Schema.org model definitions. Please do note that these Schema.org models use mostly primitive types and will not cover all of Pydantic's field types.
TL;DR: With a modifications on the existing code I can produce the tests you describe. Maybe you can provide me with a list of Pydantic features/mechanisms you would like to test first? I would be happy to contribute to Pydantic.
Cheers

Thanks so much would be great if you could test against pydantic v1.10.0b1, more information at https://github.com/pydantic/pydantic/discussions/4419.
Ice now tested that release against quite a lot of libraries, so I doubt there will be a problem, but still busy to check.
Also as per the linked discussion, I'd like to build up a list of libraries I can easily test future pydantic releases against to avoid breaking changes.

Might I suggest @pytest.mark.parametrize (and pytest-cov) or better?

https://docs.pytest.org/en/6.2.x/parametrize.html
https://pytest-cov.readthedocs.io/en/latest/reporting.html


Helm-deployed Airflow does not have access to Airflow config file

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/3346
Originally created by @kgpayne on 2022-03-23 12:22:04

Problem to solve
When deploying Airflow using deployment tools such as Helm, configuration artefacts are needed at the time of deploy (e.g. .env files and config.py). These are generated by meltano invoke but are not accessible to users directly.
Meltano makes it easy to centralised configuration and to inject config artefacts (env vars and files) into a plugins context during execution with meltano invoke, but these generated files are cleaned up after the invoked process exits (to prevent secrets leaking). In order to provide the same benefits to plugins (services) that require config at deployment time (e.g. Airflow, Superset) we could provide a mechanism to export these config artefacts to a user-specified location on disk for use in deployment scripts and Helm inputs as part of a CI/CD pipeline.
Target audience
Anyone using Meltano with service-based plugins that need deployment in production (e.g. Airflow, Superset).
Further details
As part of setup for services like Airflow during meltano invoke, Meltano generates/populates Airflow-specific config files and environment variables from the Projects top-level meltano.yml. This is useful for local development and execution, however production deployment tools such as Helm require these artefacts at the point of deployment (usually at the end of an automated CI/CD pipeline). As meltano invoke does clean-up after any spawned processes terminate, these files (and the logic that generates them) cannot easily be accessed for use in production deployments. Exposing them via the CLI would allow users to benefit from Meltanos centralised config features even when using external deployment tools.
What does success look like, and how can we measure that?
Meltano can be used to centralise config at all stages of development and deployment (not just locally via invoke).

View 4 previous comments from the original issue on GitLab

This came up again recently and I wanted to circle back.
The proposed solution is to move the config file to files-airflow, where the dag generator meltano.py already exists.
Then Airflows config can take input from callers' environment variables rather than storing them in cleartext.
cc @DouweM, @kgpayne
This also has the benefit of unwinding the 'special' relationship that Meltano has with Airflow, but without any compromise in user functionality.


Blog issues - dead links for some posts

e.g. http://contentmine.org/api/catalogue/378812d761564a828db7750780e7f329

This is a link to an API document, not a blog post. Are there any dead links on the actual blog that need fixed?

http://contentmine.org/blog/Chicago_workshop & http://contentmine.org/blog/ami

Ah, they are not actually failing, just the authors had not made them public and as you are not logged in you get the 404. I have changed the AMI one, you should be able to view it now, although it also seems to be unfinished. However for the chicago one there is an actual error in trying to save the settings of the post. I will look into that.

Cool, thanks.


Placement of dataset

Hello,
I managed to run training with train.article.txt and train.title.txt but now I'm confused about how to get the test data sets setup properly.
The paths are shown below, but how am I supposed to convert these into  a data/test.duc2004.txt  which is being loaded by the test script?  What exactly is supposed to be in this single file?
data/DUC2004/task1_ref0.txt
data/DUC2004/task1_ref1.txt
data/DUC2004/task1_ref3.txt
data/DUC2004/task1_ref2.txt
data/DUC2004/input.txt

test.duc2004.txt is actually data/DUC2004/input.txt. Other files in data/DUC2004 are annotated summaries for ROUGE evaluation.


❓ Is it possible to render the camera partially

Question
We would like to render camera just partially inside view however camera is rendering 100% device width/height behind the scenes and is overlapping over the Status Bar as can be seen in screenshot. Is there a way to write in such a way that we only take the displayed segment into consideration only?

What I tried
We tried style and format props and changing these but could not quite get it to work.
Relevant Library Versions:
react-native - 0.70.3
react-native-vision-camera: 2.15.2
react - 18.1.0
react-native-reanimated - 2.12.0
VisionCamera Version
2.15.2
Additional information

[ ] I am using Expo
[X] I have read the Troubleshooting Guide
[X] I agree to follow this project's Code of Conduct
[X] I searched for similar questions in the issues page as well as in the discussions page and found none.

Why would you do such a thing 🥴

Closing as this is a stale issue - this might have been fixed with the full rewrite in VisionCamera V3 (🥳) - if not, please create a new issue.
If your issue has been fixed, consider sponsoring me on GitHub to say thanks 💖
Preview now has a resizeMode btw


tests: added more test coverage for diagonal win components

added tests for diagonal win method and component methods -- WILL NEED TO FIX TO PASS WITH CONCURRENT CHANGES TO LIB

Looks great, thank you!


Run rename-unsafe-lifecycles on v6 branch

I'm not sure I can do this without doing a major semver release. This would break a lot of people as a minor or patch release

No worries, as v6 won't be receiving any large changes in anticipation of v7, I will import it from my repo until we upgrade.

Sounds good. I think that's the best solution for now. Thanks!

Are you going to do a 6.11 version with this ? If so when is it planned ?
Thanks

This fix has broken compatibility with Preact, as they are not supporting the UNSAFE* methods preactjs/preact#1047. I have fixed my react-table version to 6.10.0 as this version still works with Preact.

There is a now a bug for Preact tracking the broken compatibility issue https://github.com/preactjs/preact/issues/1941.

Seems like the preact issue is resolved now, could this PR be opened up again and released as a new major version?


HW 17.10.2016

https://github.com/Maksimik/HW-10.10.2016-UnitTests/commit/61b03131cb35aa06ccfd764cc090823b840ce44e

debug/release type add to BuildConfig by default.
You should do write additional logic for that.
What about renaming apk?


FYI: Annotation processing with Gradle 3.4.1 and "Use separate module per source set"

Hello - I know in other issues you have mentioned that IntelliJ support is just best effort and your recommended configuration is to uncheck "use separate modules". With newer gradles, I've found that unchecking this causes other problems and that for future-proofness it's probably good to support it.
I dug though and came up with a configuration that seems to work with separate modules, and also uses gradle's built in apt support as of 3.4 - IntelliJ build (not delegate to gradle) works great with no user configuration at all. I'm just pasting it here in case it's useful information for you in a future version of this plugin. I'd be happy to switch back to the plugin :) This issue is just to document it, feel free to close right away.
To sum, I think the key changes are

Modern gradle idea plugin seems to allow adding subdirectories of build/ without any exclusion weirdness
Gradle's idea.module.scopes seems to be sort of broken. But using compileOnly is actually simpler and works perfectly - the processors are added as PROVIDED, but any dependencies that are also used by the project are added as COMPILED.
Annotation processing output directories in the project are set to current directory '.'. I'm not sure why this works, but it does seem to have intellij put the files into the generated sources directory (maybe it finds the first generated sources directory and dumps into them).

All projects
[sourceSets.main, sourceSets.test].each { sourceSet ->
            // HACK: Configurations usually use the same naming logic/scheme as for tasks
            def aptConfiguration = configurations.create(sourceSet.getTaskName('', 'apt'))
            // Makes sure IDEs can find the annotation processor on the compile classpath.
            // Since it's compileOnly, it doesn't affect the result.
            configurations.getByName(sourceSet.getTaskName('', 'compileOnly'))
                    .extendsFrom(aptConfiguration)

            def outputDir = "$buildDir/generated/source/apt/${sourceSet.name}"
            tasks.getByName(sourceSet.compileJavaTaskName) {
                project.mkdir(outputDir)
                options.annotationProcessorPath = aptConfiguration
                options.compilerArgs += ['-s', outputDir]
            }

            project.plugins.withType(IdeaPlugin) {
                project.idea.module {
                    if (sourceSet == sourceSets.main) {
                        sourceDirs += file(outputDir)
                    } else {
                        testSourceDirs += file(outputDir)
                    }
                    generatedSourceDirs += file(outputDir)
                }
            }
        }
}

Root project
idea.project.ipr.withXml {
    def compilerConfiguration = it.node.component.find { it.@name == 'CompilerConfiguration' }
    compilerConfiguration.remove(compilerConfiguration.annotationProcessing)
    compilerConfiguration.append(new groovy.util.NodeBuilder().annotationProcessing() {
        profile(name: 'Default', enabled: true, default: true) {
            outputRelativeToContentRoot(value: true)
            processorPath(useClasspath: true)
            sourceOutputDir(name: '.')
            sourceTestOutputDir(name: '.')
        }
    })
}

// Since it's compileOnly, it doesn't affect the result.

This is unfortunately wrong: dependencies from the apt configuration will leak into the compilation classpath, which changes the resolution rules and might break the build (apt brings newer dependency with breaking change so code no longer compiles) or break at runtime (apt brings newer dependency with new API or breaking change, and you mistakenly code against it; compilation is OK but the older dependency is used at runtime; this should break tests too, but makes it difficult –more than necessary– to pinpoint the actual issue).
Those issues are the main reason for using a processor path separate from the compilation classpath (other reason is to avoid annotation processors from compilation classpath "leaking" into the processor path; this could also be solved in most cases by explicitly listing the processors to run, but not always; only other reason would be feeding custom checks to the Error Prone compiler); otherwise you'd just put your annotation processors into compileOnly.
Thanks for the suggestion though.

Thanks for the explanation - you're right the comment is wrong. But I wonder if it would still make sense as behavior guarded behind a enableIdeaProcessors config option. I agree that separating the annotation processor and compile classpath is ideal, but for convenience IntelliJ supports picking processors up from the compile classpath so I guess combining them is also sort of standard. It's why this plugin currently adds to scopes.COMPILE - I think the main difference with using compileOnly instead of scopes.COMPILE is that both ./gradlew and IntelliJ would have similar dependency hell behavior, while only touching scopes could cause confusing situations where the IntelliJ build fails but gradle succeeds.
FWIW, with this proposal, processors from the compilation classpath won't leak into the processor path since we're setting options.annotationProcessorPath = aptConfiguration - this disables gradle's default behavior of running processors found on the compile classpath. So the only problem seems to be the dependency hell possibility you described, but I guess that could already happen in an IntelliJ build, though not ./gradlew.
Anyways, I can see the issue with this proposal too, so it makes sense wanting to push the "delegate build to gradle" option instead :)

FWIW, the main reason this plugin puts annotation processor dependencies into IntelliJ's compile classpath is because the IDE integration won't use the idea.project.ipr configuration so manual configuration in IDEA has to remain easy. I really wish annotation processors are first-class citizens in Gradle so they could be expose through the tooling API and IDEs can simply pick them up and configure things cleanly (.factorypath in Eclipse, and processor dependencies in IDEA).
In the current state, I think the discrepancy is acceptable as long as the Gradle build is OK; the build is the source of truth, IDEs are just tools to help you be productive (otherwise we'd all just use nano or the notebook).


Added 3 new settings in supportbot.yml for more customization

Added the following settings to supportbot.yml for further customization 😊
AllowThanksForReachingOutMessage Allows the user to disable the "Thanks for reaching out..." message that is sent when a ticket is created.
DisableSuggestionsChannel Allows the user to disable the requirement of having a "suggestions" channel as well as disabling the relevant command.
DisableTicketLogChannel Allows the user to disable the requirement of having a "ticket-logs" channel. (This is due to the messages also being sent in the "Transcripts" channel).
I also added code in client.js for further commands to be disabled in the future!
I just wanted to say thank you for viewing this pull request (as it is my first ever) so hopefully everything is up to standard. 💙
Thanks
RandomTomato 🍅

Hello.
Thank you for your suggestion. We will definitely look into adding this an option.
Feel free to join our discord server for faster support or review on suggestions: https://discord.gg/jspKFcE

Hello!
Thank you for adding your suggestion.
If you need any assistance then feel free to contact us through Discord


Get comments endpoint doesn't filter by author

Summary
I expect get comments endpoint to be able to filter author or author.id property according to Strapi Docs. However, it throws an error.
Steps to reproduce

Make a comment
Send GET request to "/api/comments/{collection}:{id}/flat?pagination[pageSize]=5&pagination[page]=1&pagination[withCount]=true&filters[author][$eq]=58&sort=createdAt:desc"

Expected results
Return comments sent by the author specified (58).
Actual results
{
  "data": null,
  "error": {
    "status": 500,
    "name": "InternalServerError",
    "message": "Internal Server Error"
  }
}

I have tried other filter queries as well with no luck.

&filters[author][$eq]=58
&filters[author.id][$eq]=58
&filters[author_id][$eq]=58 <- returns a regular response with blank array, not error
&filters[user_id][$eq]=58

Hello @ubaranzorlu,
as the plugin support both non-Strapi + Strapi users the filtering should be done like below.
non-Strapi users:

/api/comments/api::page.page:1/flat?filters[authorId]=123456
<EMAIL_ADDRESS>/api/comments/api::page.page:1/flat?filters[authorName]=Joe

Strapi users:

/api/comments/api::page.page:1/flat?filters[authorUser]=1

Thanks for your response, it worked. Adding this info to the Readme might be helpful for others.


Update released

OK, the history did matter. Well learned something new. Merged with the unsigned commit....


[RESOLVED] High ICMP ping response time

Problem started at 10:39:33 on 2023.05.15
Problem name: High ICMP ping response time
Host: S100-Santiago
Severity: Warning
Operational data: Value: 877ms
Original problem ID: 20619
Event details in Zabbix: http://<IP_ADDRESS>/tr_events.php?triggerid=23518&eventid=20619

Problem has been resolved in 5m 0s at 10:44:33 on 2023.05.15
Problem name: High ICMP ping response time
Host: S100-Santiago
Severity: Warning
Original problem ID: 20619


Test Issue for Boris

What type of help do you need?
Test issue only.

[ ] Question
[ ] New Repo
[ ] Delete Repo
[ ] User Membership (please make sure new members are familiar with the CDC open practices and set up their profile with name and org info to help people collaborate with them)
[ ] Other

Please describe how you'd like us to help.

Closing, no longer needed.


Remove timing feature

We have timing feature, but it is not work in async rule.
$ TIMING=1 textlint README.md
Rule                            | Time (ms) | Relative
:-------------------------------|----------:|--------:
spellcheck-tech-word            |   124.277 |    70.7%
prh                             |    18.419 |    10.5%
no-mix-dearu-desumasu           |    13.965 |     7.9%
max-ten                         |    13.246 |     7.5%
no-start-duplicated-conjunction |     5.911 |     3.4%

https://github.com/textlint/textlint/blob/master/docs/rule.md#performance
We want to remove it for a temporary period of time.
Make textlint core #286 simple.

I'm error.
It work fine.


ContainsFile API

When asking if a folder contains a file, the API is currently
let folder = try Folder(named: "Foo")
let contains: Bool = folder.containsFile(named: "NameOfFile")

Could we extend this to handle an actual file variable instead?
let file: File = ...
let folder = try Folder(named: "Foo")
let contains: Bool = folder.containsFile(file)

An interesting point to add: I was getting a false result when using name instead of nameExcludingExtension.
let name = file.nameExcludingExtension
let doesContain = folder.containsFile(named: name) // true

let name = file.name
let doesContain = folder.containsFile(named: name) // false

I can understand why this happens, but it was unexpected at first.

In order to stay in line with the Foundation APIs, let's change the method signature from containsFile(_ file: File) to contains(_ file: File) (folder.contains(file)).

@rob-nash Are you working on a PR or is this open to anyone for implementation?

Sounds like a great addition 👍 Agree with @clayellis that the new method should be called contains(_ file: File), and we could (not necessarily now) also add a contains(_ folder: Folder) overload as well.

@clayellis No, this is open for implementation. 👍🏼

Starting an PR for this


upgrade deps and migrate to ask-sdk(-core)

It would seem that ask-sdk-model is a peer dependency, as it won't run correctly on AWS lambda without it.


Demo Refresh Requirements

Description

[ ] Configurable service endpoints
[ ] Add a component that calls outside the mesh (to demo / exercise external services)
[ ] Ensure e2e tracing is implemented in all components to show off tracing
[ ] Add metrics to some components to demonstrate metric aggregation
[ ] Admin Panel

[ ] Simulate failures
[ ] Switch backends?
[ ] Toggle debug view (show where traffic is coming from, pod metadata, headers, latency, number of retries, error codes etc...)

Triage: it would be nice to have "a thing" to simulate constant traffic just like we have with counter demo


Ability to return the formatted value as an option

I would like to send back the formatted value to the server. Can we do this with ui-mask? Thank you for any input on this!

Use the model-view-value attribute as described in the readme.


Create function for deleting extended query tag

Description

Created new durable function to delete extended query tag
Split up all calls - get tag, update status, delete index per batch, delete error per batch, delete tag itself
created new stored procedures
incremented sql schema version
updated delete API to create operation and then wait on operation status to be in a terminal state

Todo:

full delete e2e test

Related issues
Addresses [issue #].
Testing
Manually ran function / API with various test data. Ensured existing e2e and integration tests for delete ran

I'm aware there's already a v57 of the schema now - will update that to 58 after a round of reviews. Want to avoid having to update it multiple times in case of another change coming in before this is merged


Warn on test class files prefixed with test-

Following on from #882, I propose a WordPress-Extra check that would look at files with test classes for the presence of a filename prefix of test-, and throw a warning if found.
WP Core doesn't use prefixes, and PHPUnit doesn't appear to have ever support a <directory prefix="..."> attribute either (so was never using the value anyway).
There should be an option to turn this check off, for those that really don't want to comply.

There should be an option to turn this check off, for those that really don't want to comply.

Like <exclude name="sniffname" />?

Yes. I realise my request for an option was redundant, but wanted to emphasis that there was a way for people to opt out of this check, and that the could continue using the test- if they wish :-)

If I'm honest, I don't see this as a sniff for WPCS. The handbook doesn't have any rules about naming test files, so until it does, I don't think WPCS should enforce anything related to this.
Suggest: close

The handbook doesn't have any rules about naming test files, so until it does, I don't think WPCS should enforce anything related to this.

It kinda does be example, a bit further down:

Test class names should reflect the filepath, with underscores replacing directory separators and TitleCase replacing camelCase. Thus, the class Tests_Comment_GetCommentClass(), which contains tests for the get_comment_class() function, is located in tests/comment/getCommentClass.php.

An unscientific skimming of https://core.trac.wordpress.org/browser/trunk/tests/phpunit/tests suggests no test class files start with test-, so while this is probably one of those to get added to the handbook first, the follow-up sniff idea could probably still stand.

I don't think we should add a negative rule - "don't prefix with test-", I think we'd rather want it to be a positive rule like "Test file names should match the name of the class therein".
I also seem to remember PHPUnit actually enforcing this as of 9.?, but can't find the reference to it at this moment.
Similarly, I think there is at least one Trac ticket open in which this is being discussed, but I can't seem to find it...

https://core.trac.wordpress.org/ticket/53010#comment:5 and #1995.

Ha! Your search-fu is clearly better than mine. Thanks for those links.
Would it make sense to close this ticket in favour of #1995 ?

Agreed.


⚠ Bofrost.at has degraded performance

In abd81ed, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1196 ms

Resolved: Bofrost.at performance has improved in 90801f0 after 20 minutes.


move Toolbox under Get Docker, init cap Get Started

@mstanleyjones @johndmulhausen
In docs left-side nav menu:

moved Docker Toolbox topics under Get Started
added (Legacy) label to Docker Toolbox
Init capped Get Started top level menu label

Signed-off-by: Victoria Bialas<EMAIL_ADDRESS>

LGTM, merging


Tutorial Testing

### Tasks
- [x] Quick start
- [ ] Quick start custom (docker, flags, etc)
- [ ] Docker compose local services
- [ ] https://github.com/rollkit/rollkit/pull/1929
- [ ] Update Dockerfile entrypoint rollkit CMD start

Status Update
Experimenting with the ignite how to guide to add these steps into CLI so that we have confidence that the ignite flow always works.
This would then allow us to add the DA and Sequencing to this testing.
Currently running into issues with install ignite in the ci because of the telemetry prompt


Fix choice lock for the combined Pledge move

The original problem with choice lock was that it locked you in to a move that your Magic Bounce bounced. This was hacked around in 08792b1 by checking whether the move had a source effect. (Pursuit has a source effect when it triggers on the foe switching, so an additional hack was added to cope with that case.) Pledge moves also get a source effect when they combine, so this is why they currently don't get choice locked. Instead, we can just directly check whether the move has bounced in the first place.

Wait, wait!

Most moves with source effects should not be locked, right? Like Sleep Talk calling Calm Mind should lock you into Sleep Talk, not into Calm Mind, right?

Most moves with source effects should not be locked, right? Like Sleep Talk calling Calm Mind should lock you into Sleep Talk, not into Calm Mind, right?

Right, but choice lock sees Sleep Talk first, and locks that, rather than the move it calls. The exceptions are Magic Bounce moves (which don't lock you) and Dancer moves (which do).

Huh, well someone just reported a Metronome Solar Blade locked them into Solar Blade...

Except in the sun (or if you hold a Power Herb, which doesn't apply here) Solar Blade is a multi-turn move. The way those moves (as opposed to choice-locked moves) work is that next turn the move is the only move on the move selection screen. In previous generations, the move then executed as normal. However, in Gen 7, the choice item prevents the move from executing, as if it had been Disabled.
Note: I just tested this again to check that the mechanics were correct. Luckily for me, Metronome called Bide fairly quickly. The next turn, I was forced to select Bide, but, due to my Choice item, it failed to execute. On subsequent turns I was able to resume using Metronome normally.


Test Mergebot (ignore this PR)

High-level description
What features does this change enable? What bugs does this change fix?
Corresponding DC/OS tickets (required)

D2IQ-ID JIRA title / short description.

Related tickets (optional)

D2IQ-ID JIRA title / short description.

@mesosphere-mergebot test teamcity/dcos/test/terraform/aws/onprem/static/group3

@mesosphere-mergebot test wrong_check_1 wrong_check_2

@mesosphere-mergebot test all


adds travis and tests

Now I remember why I stalled on this PR, there's a private NPM module (mapbox-assembly). Looking into it!

🤦♂ apparently the private module @mapbox/mapbox-assembly is only used to run the test cases app. I moved the module as an optional dependencies so that Travis can run the tests.


paragraph \P character

I would like to use but disabled.

The MathJax web fonts don't include this character.  You can use \unicode{xB6} to request it, but that relies on the user having a font that includes it.  It is very common, but it is not a guarantee.  You can use \unicode[fontname]{xB6} to suggest a font (or a list of fonts) if you want.


Add contributing.md

Coverage remained the same at 60.064% when pulling 3f2f46ad52cbd89a6267c71778921986d12b16e3 on add-contributing into 35511d188a06ec65e805b50cf267ae94ec6cafee on master.


Refactor: softDispatch doesn't return null

Built on #181887
cc @roblourens @lramos15

Seems fine, I think the only change that impacts me is that null is now { kind: ResultKind.NoMatchingKb }


Crash when resizing to less than one tile size

If the view is resized to less than 256px in either dimension, a zero "split" is passed into Isect2D::resize here: https://github.com/tangrams/tangram-es/blob/master/core/src/labels/labels.cpp#L74, which subsequently causes an uncaught divide-by-zero here: https://github.com/tangrams/isect2d/blob/master/include/isect2d.h#L64

@hjanetzek == :zap:


[Feature Request]:Add an API call example.

Is there an existing issue for the same feature request?

[X] I have checked the existing issues.

Is your feature request related to a problem?
No response
Describe the feature you'd like
Add invocation examples to facilitate usage for newcomers, similar to those provided by chatglm or chatgpt.
Describe implementation you've considered
No response
Documentation, adoption, use case
No response
Additional information
No response

I second this motion


AppMixin plugin requires a Meta class with app_label

Please verify that this bug has NOT been raised before.

[X] I checked and didn't find similar issue

Describe the bug*
After the changes from #3535, my plugin doesn't load anymore, but instead with the following error in the plugin error stack:
discovery | django | Model class inventree_bulk.models.BulkCreationTemplate doesn't declare an explicit app_label and isn't in an application in INSTALLED_APPS.

I guess this has something todo with a wrong configuration, but I cannot see where. This is my plugin repo.
If I add a Meta class with an app label, this error is gone and the plugin loads without issues, but how do I get it working without that extra meta class like it was working before these changes?
originally commented at https://github.com/inventree/InvenTree/pull/3535#issuecomment-1220751210, but this was the wrong place, as this is a real new issue, not just a simple further question
Steps to Reproduce

Create an AppMixin plugin
Add a model without a Meta class
Load the plugin to inventree
Goto Settings > plugins
See error stack

Expected behavior
Plugin should load correctly without a Meta class like it was before #3535
Deployment Method

[X] Docker
[X] Bare metal

Version Information
# Version Information:
InvenTree-Version: 0.9.0 dev
Django Version: 3.2.15
Commit Hash: b886e5470
Commit Date: 2022-08-19
Database: sqlite3
Debug-Mode: True
Deployed using Docker: False
Active plugins: [{'name': 'CupsLabels', 'slug': 'cups', 'version': '0.1.0'}]

Relevant log output
No response

@matmair do you have any insights here? What did you change in #3535 in particular which may have caused such issues?

@SchrodingersGat it fixed the way App names are computed, before there could be a missmatch between the packagename and appeared - that lead to collisions with 3rd party modules. The PR changed it to follow Django standards as I understand them.
Adding a Meta class to them model should fix this issue.

@wolflu05 is it an acceptable solution to simply add a metaclass to your plugin? I think this would be the simplest way to move forward here.

@SchrodingersGat Yeah that is also fine if this is now the intended way of doing it. Thank you very much for resolving those two issues. No I can continue develop my plugin if I had some more time. We can close this from my side.


operator project-quay (3.9.0-nightly.20230531)

Add 3.9.0-nightly.20230531 to community operators

/merge possible

/merge possible


How to map disqus comments according to different posts?

Hi,
I'm using your vue-disqus on my social network kind of project. When a user comments in a post, the comments are replicated to wherever the disqus is embedded in the project. How to map the comments set to different posts in a unique manner?

Are you inserting a unique identifier and unique url for each vue-disqus instance?

Nope so far.
@ktquez If you can help me on how to do that, would be really great.

Could you show me a piece of code? Of how you're doing it.


Built version of these packages can cause unit tests run in node to fail

The build process for this project exports code that uses ESM imports without file extensions. This can cause issues when running the code in node such as via vitest. For example:

Here's an issue where the history can be viewed. It doesn't appear that Typescript or Node seem willing to fix the issue. I'm also not totally sure that it's not an issue with the Esri modules since there are other imports.
The workaround for vitest is to inline the packages from this repo:
import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    server: {
      deps: {
        inline: ['@ugrc/utah-design-system'],
      },
    },
  },
});

The esri docs do show imports esm with the .js extension. Is that a change we should make to solve the problem?

I have some things to update in kitchen sink. I'll give it a try and we can test it in your project.

This has been resolved by adding ".js" to the import paths.


Bugfix: honor the -v commandline flag

Proposed Changes
Set log level in logrus according to the commandline parameter.
Types of Changes
Bugfix.
Verification

Install k3s (tested with v1.24.6+k3s1)
Run k3s with  the -v=6 option

Testing
Only tested manually, only really relevant for developers. Please advise if any kind of automated test is required to get the PR merged.
Linked Issues
Fixes https://github.com/k3s-io/k3s/issues/6656
User-Facing Change
NONE

--debug sets the level for k3s components that use logrus. -v sets the verbosity for klog-based components, such as the various Kubernetes controllers. Do you see a meaningful difference in output with this change?

--debug sets the level for k3s components that use logrus. -v sets the verbosity for klog-based components, such as the various Kubernetes controllers. Do you see a meaningful difference in output with this change?

Thanks for explaining, I did not even understand well the context TBH.
My use case is: as a k3s user, I would like to set arbitrary log level for the whole k3s - my current problem is getting trace log lines from kine.
I am open to any suggestions as to change/add commandline flags if this is too hacky.

In general trace is too high a level for kine to run at for any significant period of time. If we need trace-level logs from kine for troubleshooting, we usually just run a standalone instance of kine via the binary or docker image, and point K3s at its http endpoint. That also has the benefit of giving us the kine logs separate from the rest of the k3s and kubernetes component logs.

I am fine closing this if the flag's intent is different and this solution does not align with the intended use case.


MultiStream scenario problem:ERROR:Attempted to complete a sample twice

when finished test of MultiStream scenario, there ara errors in mlperf_log_detail.txt： ERROR:Attempted to complete a sample twice，what's wrong in the test?

First of all, what is your test?

do you mean what's the mode i test? i test performance mode.
I found the error is coused by two times call mlperf::QuerySamplesComplete() function.
thank you anyway.

It sounds that the issue was with your implementation. Glad to hear you've solved it. Please resolve the issue then.


Add Bazel support

(Re-opened due to CLA issue)
Implements option 2 stated in: https://github.com/vmware-tanzu/carvel-kbld/issues/128.
The implementation is similar to the other builders. bazel run <label> is used for the sub process command as it outputs the image digest if container_image(...) is used.
One thing to note about bazel run <label> is that it isn't limited to just image building, but can also run tests and binaries (depending on how its configured). Thus it is recommended that the label used for label has container_image(...) as the last step in the BUILD.bazel.

(failure unrelated to this PR, @jtigger is chasing it down)
getting really close!

(failure unrelated to this PR, @jtigger is chasing it down)
getting really close!

Yup yup; we recently added a step in the workflow to authenticate to DockerHub to avoid rate limiting.  GitHub (appropriately) prevents Actions running off a fork of the repo from accessing the secrets context.  We didn't account for that fact in the script: the secret is empty, the script attempts to login with an empty input to stdin, and docker gripes and errors because the only alternative would be for the tty to be interactive (which it is not).
For now, I'll short-circuit that authentication if secrets are not provided. Pull requests from forks will run unauthenticated.
Tracking a longer-term solution here: vmware-tanzu/carvel-kbld#159

Pedantically, fixing the build for this PR would require a rebase.
Practically, I pulled and ran the tests locally (including https://github.com/vmware-tanzu/carvel-kbld/pull/149/commits/e4c5ee8b760b9a37fc45ca68121556f3ecfd2c0e); all ran green. 👍🏻
@cliuj — would you do me a favor and review the "Bazel" section of the proposed docs?

Preview -- https://deploy-preview-234--carvel.netlify.app/kbld/docs/latest/config/#bazel
PR -- https://github.com/vmware-tanzu/carvel/pull/234/files#diff-a942671466ca8d61b968f6cc660959f1f6fcdd5468b940c224e5f12a438c537bR415


add serde helpers crates

related : https://github.com/alloy-rs/alloy/issues/123

we now want this in all the other rpc crates so we can get rid of the serde_helpers.mod file

do you agree if this can be in separate pr ?

hey @DoTheBestToGetTheBest sorry for the late response
we want this as separate crate yes and then replace the current serde_helpers file in the rpc types crate
currently this duplicates the stuff, let's do it in one go

hey @DoTheBestToGetTheBest sorry for the late response

no problem (:

we want this as separate crate yes and then replace the current serde_helpers file in the rpc types crate
currently this duplicates the stuff, let's do it in one go

okey will finish this

@mattsse does it look great to you ? i don't know how can i run test here

hey boss @mattsse does this looks great to you?

@mattsse hey can you take look here pls