[IO-707] Add optional postcondition checks with assert

Fixes https://issues.apache.org/jira/browse/IO-707

Hi @boris-unckel
Hm, we do not use these types of asserts anywhere, needs discussion on the mailing list, please see the thread I am about to start there...

Hi @boris-unckel
Hm, we do not use these types of asserts anywhere, needs discussion on the mailing list, please see the thread I am about to start there...

Hm... it seems to me that any file operation in an app (through Commons IO or otherwise) is always at risk of being "out-of-sync" or simply subverted by another process or user doing some operations on disk, so this is going to be confusing at best. For example, let's say I perform some Commons IO file operation, then the JVM or GC pauses my thread for a "long" time, during which something happens on disk which violates my app's expectations once it wakes up... now what?
If the pause happened before the assert, the assert catches something... if it happens after, I know nothing and my app calling Commons IO still needs to handle the situation, assert or no assert. I'm just worried that we are cherry picking a few places to add asserts that might not be useful and will cause users to ask why asserts are here but not there, and so on... looking f/w to thoughts from the community...

Hm... it seems to me that any file operation in an app (through Commons IO or otherwise) is always at risk of being "out-of-sync" or simply subverted by another process or user doing some operations on disk, so this is going to be confusing at best. For example, let's say I perform some Commons IO file operation, then the JVM or GC pauses my thread for a "long" time, during which something happens on disk which violates my app's expectations once it wakes up... now what?
If the pause happened before the assert, the assert catches something... if it happens after, I know nothing and my app calling Commons IO still needs to handle the situation, assert or no assert. I'm just worried that we are cherry picking a few places to add asserts that might not be useful and will cause users to ask why asserts are here but not there, and so on... looking f/w to thoughts from the community...

Coverage decreased (-0.1%) to 89.092% when pulling a559f8a99d97a996b9ecba48680ed04588205ce6 on boris-unckel:assert_proposal into 5f73593d999feccc93f6e8190af22d52726bba14 on apache:master.

Coverage decreased (-0.1%) to 89.092% when pulling a559f8a99d97a996b9ecba48680ed04588205ce6 on boris-unckel:assert_proposal into 5f73593d999feccc93f6e8190af22d52726bba14 on apache:master.

@garydgregory Thank you for your time to review and place it for public review.

If the pause happened before the assert, the assert catches something... if it happens after, I know nothing and my app calling Commons IO still needs to handle the situation, assert or no assert.

The use case you're describing is not improved by the assert or just slightly. I'm thinking more about cases where the underlying file system in combination with the JRE does not behave as expected:
The following is a plain vanilla Fedora 33 with ext4 filesystem.  Unfortunately in German :-(
For /tmp it says "IOCTL not matching to read flags of /tmp".
sudo lsattr / [sudo] Passwort für borisunckel:  -----------I--e----- /etc lsattr: Unpassender IOCTL (I/O-Control) für das Gerät Beim Lesen der Flags von /run lsattr: Die Operation wird nicht unterstützt Beim Lesen der Flags von /lib64 --------------e----- /lost+found lsattr: Unpassender IOCTL (I/O-Control) für das Gerät Beim Lesen der Flags von /sys --------------e----- /usr lsattr: Unpassender IOCTL (I/O-Control) für das Gerät Beim Lesen der Flags von /proc --------------e----- /mnt lsattr: Die Operation wird nicht unterstützt Beim Lesen der Flags von /sbin --------------e----- /srv lsattr: Die Operation wird nicht unterstützt Beim Lesen der Flags von /lib lsattr: Unpassender IOCTL (I/O-Control) für das Gerät Beim Lesen der Flags von /tmp lsattr: Die Operation wird nicht unterstützt Beim Lesen der Flags von /bin --------------e----- /root --------------e----- /media --------------e----- /var --------------e----- /home lsattr: Unpassender IOCTL (I/O-Control) für das Gerät Beim Lesen der Flags von /dev --------------e----- /boot --------------e----- /opt
Working with commons-io 2.5 I had no trouble to build WildFly-Core, with 2.8.0 it fails. The first fixes I already provided (former PRs not this one), but it is not over.
The asserts help to find the original place of fail and not the top level one (like "delete fails due to directory is not empty").

@garydgregory Thank you for your time to review and place it for public review.

If the pause happened before the assert, the assert catches something... if it happens after, I know nothing and my app calling Commons IO still needs to handle the situation, assert or no assert.

The use case you're describing is not improved by the assert or just slightly. I'm thinking more about cases where the underlying file system in combination with the JRE does not behave as expected:
The following is a plain vanilla Fedora 33 with ext4 filesystem.  Unfortunately in German :-(
For /tmp it says "IOCTL not matching to read flags of /tmp".
sudo lsattr / [sudo] Passwort für borisunckel:  -----------I--e----- /etc lsattr: Unpassender IOCTL (I/O-Control) für das Gerät Beim Lesen der Flags von /run lsattr: Die Operation wird nicht unterstützt Beim Lesen der Flags von /lib64 --------------e----- /lost+found lsattr: Unpassender IOCTL (I/O-Control) für das Gerät Beim Lesen der Flags von /sys --------------e----- /usr lsattr: Unpassender IOCTL (I/O-Control) für das Gerät Beim Lesen der Flags von /proc --------------e----- /mnt lsattr: Die Operation wird nicht unterstützt Beim Lesen der Flags von /sbin --------------e----- /srv lsattr: Die Operation wird nicht unterstützt Beim Lesen der Flags von /lib lsattr: Unpassender IOCTL (I/O-Control) für das Gerät Beim Lesen der Flags von /tmp lsattr: Die Operation wird nicht unterstützt Beim Lesen der Flags von /bin --------------e----- /root --------------e----- /media --------------e----- /var --------------e----- /home lsattr: Unpassender IOCTL (I/O-Control) für das Gerät Beim Lesen der Flags von /dev --------------e----- /boot --------------e----- /opt
Working with commons-io 2.5 I had no trouble to build WildFly-Core, with 2.8.0 it fails. The first fixes I already provided (former PRs not this one), but it is not over.
The asserts help to find the original place of fail and not the top level one (like "delete fails due to directory is not empty").

Hi @boris-unckel and All:
A lot of time has passed since we last iterated on this issue...
May you please rebase on master if this is still relevant with master?

https://issues.apache.org/jira/browse/IO-725 is related to this. As long as only Ubuntu (with a different file system) is accepted as prove for bugs, this here is not useful.


Docs.rs API

Adds an api for shields.io to query docs.rs with.
Users can call /api/v1/badges?crate=<crate> for the latest version of a crate and /api/v1/badges?crate=<crate>&version=<version> for a specific version.
The api returns the crate name, release version, the url of the crate (e.g. https://docs.rs/crate/rcc/0.0.0) and the crate's build status, which can be one of the following:

built fully built and available
failed the build failed in some way
queued the release is in the build queue
yanked the release has been yanked
not_library the release isn't a library (Not 100% sure about this one since #238 is a thing)

The api is versioned so that we have future-compatibility. I'm not entirely sure how to handle the old badge system, ideally we'd be able to remove it entirely and forward requests, but that's not possible until shields.io has a working thing, which isn't possible until we have a working thing

It would be useful to be able to get a list of the versions available of the docs of any given crate

basically the equivalent of: https://docs.readthedocs.io/en/latest/api/v3.html#versions-listing

In general, the RTD api is probably a good starting point for what would be useful on docs.rs.

I think I've got a decent api design that should be plenty good for the foreseeable future

/-/api/v1/crates/{crate_name}/versions See all released versions of a crate, paginated with the limit and offset parameters

{
    "total": 25, // Total number of releases for this crate
    "next": "https://docs.rs/-/api/v1/crates/{crate_name}/versions/?limit=10&offset=20",     // The next page of releases or `null`
    "previous": "https://docs.rs/-/api/v1/crates/{crate_name}/versions/?limit=10&offset=10", // The previous page of releases or `null`
    "latest": "https://docs.rs/-/api/v1/crates/{crate_name}/versions/{latest_version}",      // The latest release of the crate
    "releases": [
        {
            "version": "{release_version}",
            "url": "https://docs.rs/-/api/v1/crates/{crate_name}/versions/{release_version}",
            "status": "{build_status}", // One of "built", "queued" or "failed"
            "yanked": false
        }
    ]
}

/-/api/v1/crates/{crate_name}/versions/{version} Information on one specific version of a crate

{
    "version": "{version}",
    "crate_name": "{crate_name}",
    "project_name": "{project_name}",
    "status": "{build_status}", // One of "built", "queued" or "failed"
    "yanked": false,
    "build_time": "2020-06-06T23:31:13+00:00", // RFC 3339 timestamp or `null` if the crate failed to build
    "urls": {
        "documentation": "https://docs.rs/{project_name}/{version}/{crate_name}", // Will be `null` if the crate failed to build
        "crate": "https://docs.rs/crate/{crate_name}/{version}",
        "builds_html": "https://docs.rs/crate/{crate_name}/{version}/builds",
        "builds": "https://docs.rs/crate/{crate_name}/{version}/builds.json",
        "source": "https://docs.rs/crate/{crate_name}/{version}/source" // Will be `null` if the crate failed to build
    },
    "dependencies": [
        "https://docs.rs/-/api/v1/crates/{dep_name}/versions/{dep_version}"
    ]
}

As per https://github.com/rust-lang/docs.rs/issues/170#issuecomment-764837701, I would prefer we fixed the latest bug rather than introducing a completely new API.

As per https://github.com/rust-lang/docs.rs/issues/170#issuecomment-764837701, I would prefer we fixed the latest bug rather than introducing a completely new API.


Add options for copy

Can I add an option without overwriting if the files or folders are not changed?
or does the file system work by default?

Do you mean the clobber option?


100-avoid showing repeats in add menu

See the description in https://github.com/TheDuckCow/godot-road-generator/issues/100, goal here is to avoid repeats in the add UI. It now looks like this, which is desirable:

Closes #100

Hey @TheDuckCow, I see you already merged into dev. I did a quick check since you asked and a cursory glance indicated that these changes were sound and reasonable. I also loaded the "dev" branch, opened a pre-existing scene, and checked for errors. Then, added new RoadPoints via the Edit RoadPoint panel. Did not observe any errors and all GUT tests passed.
Also, "RoadSegment" did not show up in the Add menu as a standalone object, which seemed to be the intended outcome. Good work!
"RoadSegment(road_segment.gd)" did appear in the Add menu. But, I got the impression that was okay.

After re-reading your first comment, I did a local git restore just to cleanup the directory. Then, one more git pull.
Now, "RoadSegment" no longer shows up and the "Add" list looks just like your screenshot.

Thanks for giving it a check and trying it out! Second pair of eyes is always good.


merge flume stuff

this will bring in all the changes from the flume branch.
this is a small breaking change (rebuild is removed) and the api for plugins that create database views is different (use _flumeUse instead of handling it your self)
I'll make PRs to those other things too.

So, if lots of people are gonna run this, I think I better write a thing that makes sure nothing bad happens while it's migrating from level to flume. I'm gonna do that, then this is fully ready!

Okay, now when loading a sbot instance that already has a level database, this will not allow any reads or writes until the new log is filled in, then all views will be regenerated. It will take a while to reload, actually.

okay, merged into 16.2.0


Serialisation generators for Mary/Allegra

Resolves CAD-1845

Extract EraIndepGenerators from the ShelleyEra serialisation generators so that we can re-use EraIndep as a base for ShelleyMAEra serialisation generators
Specialise Shelley Era generators to ShelleyEra (rather than just the ShelleyTest constraint) - otherwise we'd have Overlapping Instances between Shelley/MA
ShelleyMAEra generators are fixed to MaryEra C_Crypto and AllegraEra C_Crypto

Note - the following to be done in subsequent commits:

implement a non-trivial TimeLock generator
implement serialisation tests based on these generators

@uroboros Test failure:
Ledger with Delegation
  Minimal Property Tests
    Chain and Ledger traces cover the relevant cases:                                                   FAIL (10.38s)
      *** Failed! (after 16 tests):
      Exception:
        out of bounds : -15
        CallStack (from HasCallStack):
          error, called at src/Shelley/Spec/Ledger/Coin.hs:83:15 in shelley-spec-ledger-<IP_ADDRESS>-EBuMPkcZBOjV3QszYowLH:Shelley.Spec.Ledger.Coin
      Use --quickcheck-replay=644548 to reproduce.

@uroboros Test failure:
Ledger with Delegation
  Minimal Property Tests
    Chain and Ledger traces cover the relevant cases:                                                   FAIL (10.38s)
      *** Failed! (after 16 tests):
      Exception:
        out of bounds : -15
        CallStack (from HasCallStack):
          error, called at src/Shelley/Spec/Ledger/Coin.hs:83:15 in shelley-spec-ledger-<IP_ADDRESS>-EBuMPkcZBOjV3QszYowLH:Shelley.Spec.Ledger.Coin
      Use --quickcheck-replay=644548 to reproduce.

🙏

@uroboros Test failure:
Ledger with Delegation
  Minimal Property Tests
    Chain and Ledger traces cover the relevant cases:                                                   FAIL (10.38s)
      *** Failed! (after 16 tests):
      Exception:
        out of bounds : -15
        CallStack (from HasCallStack):
          error, called at src/Shelley/Spec/Ledger/Coin.hs:83:15 in shelley-spec-ledger-<IP_ADDRESS>-EBuMPkcZBOjV3QszYowLH:Shelley.Spec.Ledger.Coin
      Use --quickcheck-replay=644548 to reproduce.

pray

Hasn't this happened before?

implement PredicateFailure generators for ShelleyMAEra

FYI, consensus will remain blocked until this is done.

implement PredicateFailure generators for ShelleyMAEra

FYI, consensus will remain blocked until this is done.

👍

@uroboros Test failure:
Ledger with Delegation
  Minimal Property Tests
    Chain and Ledger traces cover the relevant cases:                                                   FAIL (10.38s)
      *** Failed! (after 16 tests):
      Exception:
        out of bounds : -15
        CallStack (from HasCallStack):
          error, called at src/Shelley/Spec/Ledger/Coin.hs:83:15 in shelley-spec-ledger-<IP_ADDRESS>-EBuMPkcZBOjV3QszYowLH:Shelley.Spec.Ledger.Coin
      Use --quickcheck-replay=644548 to reproduce.

pray

Hasn't this happened before?

still finding that out - but this PR has nothing to do with it I'm sure

@mrBliss I've made these changes

resolved the duplication (genBlock) between Shelley/ShelleyMA generators
ShelleyMA generators are now polymorphic over Crypto
Shelley generators are now fixed to ShelleyEra - this was what was giving overlapping instances with ShelleyMA (which were fixed to MaryEra/AllegraEra)

From your side you'd now have to import both

Test.Shelley.Spec.Ledger.Serialisation.Generators ()
Test.Cardano.Ledger.ShelleyMA.Serialisation.Generators ()

How does this work for you?

@mrBliss in this episode! ...

the following are now era parametrised in EraIndep.hs

Block era, Tx era instances
all PredicateFail instances (except the UTXO one, which is specialised per era)

EraIndep no longer refs (or is referenced by) Shelley.Generators and Shelley.MAGenerators - they are independent

What I could not quite get for you is the "top of the diamond" - but in effect EraIndep.hs becomes your entry point, and must be imported alongside the specialised ones:
import Test.Shelley.Spec.Ledger.Serialisation.EraIndepGenerators ()
import Test.Shelley.Spec.Ledger.Serialisation.Generators ()
import Test.Cardano.Ledger.ShelleyMA.Serialisation.Generators ()

I have just tried it out in consensus, and everything works :tada:

If you simplify these constraints (see inline comments), this is ready to merge for me. Thanks again @uroboros.

I have just tried it out in consensus, and everything works 🎉

yay!


References

Add an entry type for references.

Thanks. Could you share a screenshot of the new entry type? Does it have a look that cannot be achieved with one of the seven entry types?

Here are some screenshots from my local examples folder.


Option to change highlighting for gitDiff

For gitDiff it makes more sense to show diff color highlighting on the output (red for removed, green for added lines), rather than highlighting of the given language.
I'm happy to create PR for this. Can you show me part of the code that renders the output of gitDiff?

Thanks for your interest!
Hmmm so the suggested behavior makes sense, though I think it comes down to the formatting of the markdown/chapter.
For example, in https://github.com/chrissound/NextUpHarticle/blame/master/sections/2_Input output.md#L6
Which is live here: "Section 2 - Input output" https://trycatchchris.co.uk/post/view/Lets-build-a-command-line-To-do-application-using-Haskell
I'm doing:
```haskell
{{ gitDiff src/Main.hs }}
```

When I guess I should be doing a diff(?) syntax instead? But this comes down to the "gitchapter enabled project" itself (the templates?) rather than the project itself.

However, I think it would make sense to handle the diff formatting with gitchapter rather than relying on a user to create the appropriate formatting. In other words, to output something like:
```diff
renderedGitDiffBlaBla
```

Instead of just the
renderedGitDiffBlaBla

So feel free to make a PR for this :) I'm assuming the diff highlighting is an actual markdown/pandoc option. This does mean it'll be a breaking change but it's
Sorry quite a lengthy response! Hopefully it makes sense!
The relevant code:
https://github.com/chrissound/GitChapter/blob/56dea57a853037e7167397017c1b1e76b3ea970e/src/Render.hs#L86
https://github.com/chrissound/GitChapter/blob/881dda7566693ef84d9d39f6569c1e997cc0fe01/src/Operations.hs#L65

You are right, I was mistaken by thinking the highlight method is predefined in the tool. Here the user has freedom. I think this approach (the current one) is better (sometimes I want to render with diff highlighting, sometimes with Haskell (depending on what I want to emphasize). Thus I'm closing this ticket for now. Thank you for feedback.
By the way, I'm starting today writing my first blog post with your tool. Let's see how it goes :)


CI: repair ltp syscalls err

Codecov Report

Merging #1278 (a93c8d3) into main (4e04f51) will decrease coverage by 0.09%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1278      +/-   ##
==========================================
- Coverage   59.41%   59.32%   -0.10%
==========================================
  Files         126      126
  Lines       21462    21462
==========================================
- Hits        12752    12732      -20
- Misses       7178     7198      +20
  Partials     1532     1532

Impacted Files
Coverage Δ

pkg/chunk/cached_store.go
70.45% <0.00%> (-2.80%)
:arrow_down:

pkg/vfs/handle.go
85.71% <0.00%> (-0.85%)
:arrow_down:

pkg/chunk/disk_cache.go
80.40% <0.00%> (-0.77%)
:arrow_down:

pkg/meta/sql.go
67.81% <0.00%> (ø)

Continue to review full report at Codecov.

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


Unable to use enum as array index.

What reproduces the bug?
sudo bpftrace -e 'enum foo { BAR }; struct MyStruct { int y[4]; } BEGIN {printf("%d\n", BAR); $s = (struct MyStruct *) 0;  $s->y[BAR]; }'

Results in
stdin:1:107-117: ERROR: The array index operator [] only accepts literal integer indices.

Subsituting BAR for 0
 sudo bpftrace -e 'enum foo { BAR }; struct MyStruct { int y[4]; } BEGIN {printf("%d\n", BAR); $s = (struct MyStruct *) 0;  $s->y[0]; }'

shows the expected result:
WARNING: Addrspace is not set
Attaching 1 probe...
0

bpftrace --info
System
  OS: Linux 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08)
  Arch: x86_64

Build
  version: v0.17.0
  LLVM: 14.0.6
  unsafe uprobe: no
  bfd: no
  libdw (DWARF support): yes

Kernel helpers
  probe_read: yes
  probe_read_str: yes
  probe_read_user: yes
  probe_read_user_str: yes
  probe_read_kernel: yes
  probe_read_kernel_str: yes
  get_current_cgroup_id: yes
  send_signal: yes
  override_return: no
  get_boot_ns: yes
  dpath: yes
  skboutput: no

Kernel features
  Instruction limit: 1000000
  Loop support: yes
  btf: yes
  map batch: yes
  uprobe refcount (depends on Build:bcc bpf_attach_uprobe refcount): yes

Map types
  hash: yes
  percpu hash: yes
  array: yes
  percpu array: yes
  stack_trace: yes
  perf_event_array: yes

Probe types
  kprobe: yes
  tracepoint: yes
  perf_event: yes
  kfunc: yes
  iter:task: yes
  iter:task_file: yes
  kprobe_multi: no
  raw_tp_special: yes

Ah yeah that's cuz BAR is not an integer literal -- it's an identifier. bpftrace can/should do a better job of constant folding.

Thanks for pointing out that this should be fixed by a constant folding pass!

Thanks for pointing out that this should be fixed by a constant folding pass!

Yes, but using LLVM's constant folding is not going to work. The enum types are not a part of the LLVM program itself, we're storing them separately in BPFtrace::enums_. So, we either need to write our own constant folding pass or to resolve them directly during semantic analysis of the array accesss operator. If this problem only applies to array indexing, the latter could be sufficient (and simpler).

Maybe I can work on fix the bug?

It'd be nice to have a generic pass that could collapse const idents -> const. That way it'll be consistent across all our language constructs.
@ZelinMa557 go for it!

It'd be nice to have a generic pass that could collapse const idents -> const. That way it'll be consistent across all our language constructs.
@ZelinMa557 go for it!

Thank you. I want to know that is there any other const idents besides enums?

I think code like:
$a = 5;
@[a] = 3;

could be folded into:
@[5] = 3;

Similarly something like:
$a = 2 + 3;
@[a] = 3;

could be folded into:
@[5] = 3;

But I'm not sure we would see much advantage in doing that cuz llvm probably does it for us already. So unlikely to affect generated code.
Maybe keep it simple and start with folding enum idents first? That has clear practical benefits. The constant folding pass can always be extended to do more over time.

I think code like:
$a = 5;
@[a] = 3;

could be folded into:
@[5] = 3;

Similarly something like:
$a = 2 + 3;
@[a] = 3;

could be folded into:
@[5] = 3;

But I'm not sure we would see much advantage in doing that cuz llvm probably does it for us already. So unlikely to affect generated code.
Maybe keep it simple and start with folding enum idents first? That has clear practical benefits. The constant folding pass can always be extended to do more over time.

Thanks, I decide to start with folding enum idents & binary expressions. Also I hope this change can be limited to the scope of ast and not affect semantic analysis and code generation, so I had best modify the AST during the constant fold pass. For example, 1+2+3 will be replaced by 6 before semantic analysis & codegen. Do you think my solution is reasonable, or that AST should not be modified during constant fold pass?

Yeah, that makes sense. Constant folding should probably occur before semantic analysis, at least to solve the issue in the original post.

There is a Mutator visitor that should work for a mutating pass, but its never been really used before and might have some rough edges


Disable xdebug to speedup travis build

:+1:

Why don't you use this syntax?

Why don't you use this syntax?

I dont work on the hhvm build

@staabm That's weird. Even if you replace $PHP with $TRAVIS_PHP_VERSION?

Hhvm does not use phpenv. In case we would add it we would need 2 separate cases, one for hhvm one for php to make it not fail.

@staabm But there's no Xdebug on HHVM to disable anyway, is there?

Dont know. The PR as is - is the simplest solution I guess. No unnecessary if etc.

The comment of @lyrixx refer to the phpenv config-rm and not HHVM

Thank you @staabm.


consistent JSON return value for failed vote

Looking through the rpc interface code it looks like the code is designed to throw a JSONRPCError exception when an error occurs.  Unfortunately there are a number of places in rpcgovernance.cpp where this practice wasn't followed but I think this is the better fix, rather than returning a JSON object directly here.

I thought about that, but after looking thru the other places where it throws a JSONRPC error, it seems like that's only when a user enters the command incorrectly. In these cases it's not technically a JSONRPC error, esp. in cases where the vote is rejected because "time between votes is too soon".
But in these places the commands are entered correctly, but the vote is simply failing for some reason or other (e.g. the above example).
@UdjinM6 @schinzelh Your thoughts?

Here's one example where JSONRPCError is thrown for an error that is not an incorrect input.
I think this is bitcoin code, so probably more likely to follow the original design intent.
https://github.com/dashpay/dash/blob/v0.12.1.x/src/wallet/rpcwallet.cpp#L249

Yep, there are lots of different rpc errors, see rpcprotocol.h
I think there is a case where throwing rpc errors is useful: there are some typical errors and you need standard, deterministic way to identify them. For example you need rpc to throw some specific predefined error code if there is some additional logic in another software using this rpc and you need to notify such software what happened exactly. Throwing such errors also indicate complete termination of command execution which is also a strong signal that smth went terribly wrong.
But I think it's ok to have error strings as a regular json output and no error thrown if execution can/should continue or no further action is needed in case of such error. For example there is no reason to throw an error for "masternode start-all" if say 1 masternode out of 10 failed to start.
I have no strong opinion about this specific case but it looks like "vote-*" commands are user-only so probably ok to have json reported errors?
I don't quite understand the reason for "vote-conf" and "vote-alias" to count failures and to have "overall" though - both of them should either fail or succeed once - multiple results could only happen for "vote-many" (but we don't have such command at all?).

I don't really like the idea of constructing ad hoc error objects like this though.  It seems error prone (ie. easy to accidentally construct a malformed object that clients won't see as an error, and I think this kind of bug may be relatively hard to spot in code review)  and the client has to do more work to determine if an error occurred.
I think calling JSONRPCError ensures that the standard error information is returned but it has the disadvantage of not allowing the code to include additional details that may be useful to the caller (more likely for human debugging purposes than for automated action).
Maybe we should add an optional JSON parameter to JSONRPCError so that additional information can be easily returned.
A simpler option would be call write() on some JSON object to produce a string and pack that into the string parameter of the exception, but I don't much like that either, especially if there is any possibility the client may need to parse the additional information (as opposed to just displaying it for debugging purposes).

I'll merge this for now as it actually does fix inconsistency. We can come up with better system for rpc calls in general (if needed) in another PR.

oot@iZ2zeeeup1v8x4tt6rzmr6Z:/var/www/html/mpos/cronjobs# ./findblock.php -f
PHP Fatal error: Uncaught Exception: RPC call did not return 200: HTTP error: 500 - JSON Response: [-8] Invalid blockhash in /var/www/html/mpos/include/lib/jsonRPCClient.php:120
Stack trace:
#0 /var/www/html/mpos/cronjobs/findblock.php(35): jsonRPCClient->__call('listsinceblock', Array)
#1 {main}
thrown in /var/www/html/mpos/include/lib/jsonRPCClient.php on line 120
root@iZ2zeeeup1v8x4tt6rzmr6Z:~# dash-cli getblockhash
error code: -1
error message:
getblockhash index
Returns hash of block in best-block-chain at index provided.
Arguments:
index (numeric, required) The block index
Result:
"hash" (string) The block hash
Examples:
dash-cli getblockhash 1000
curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getblockhash", "params": [1000] }' -H 'content-type: text/plain;' http://<IP_ADDRESS>:9998/
I used the old version of the wallet link, not wrong
But the new version of the wallet link is wrong


Add a way to debounce .touched

I would like to have a way to debounce .touched so that 500 milliseconds after the user finishes typing their current input all the validation fires.
This will allow me to do username checks while the user keeps their cursor in the username field.

Presumably you would need to call asyncValidate() somewhere, but if all you want is for a field to be marked touched 500ms after the first change, this should do it (handwritten untested code):
class MyForm extends Component {
  debounceTouch(field) {
    const { touch } = this.props
    if (this.debounceTimeout) {
      clearTimeout(this.debounceTimeout)
    }
    this.debounceTimeout = setTimeout(() => touch(field), 500)
  }

  render() {
    const { fields: { username }, touch, handleSubmit } = this.props
    return (
      <form onSubmit={handleSubmit}>
        <input type="text" {...username} onChange={event => {
            username.onChange(event)
            this.debounceTouch('username')
          }}/>
      </form>
    )
  }
}
export default reduxForm({
  form: 'myForm'
})(MyForm)

Can I call asyncValidate when the setTimeout fires? Or is there a better place to do so?
That solution looks like it could definitely work!


Remove hardcoded status in log

Problem
When testing our CloudWatch logging, we noticed an invalid url will still log a "Broker component loaded" string along with a 200, and send a 404 metric to CloudWatch.
This seems inconsistent, and a mixed response, of a success and a non-success.
WARN [Election2016Broker] - Broker.ComponentFactory.create: Exception raised (ContentNotFound) for foo/7e0c33c476b1089500d5f172102ec03e
W, [2016-02-26T19:09:45.853000 #1261]  WARN -- : Broker.ComponentFactory.create: Exception raised (ContentNotFound) for foo/7e0c33c476b1089500d5f172102ec03e
INFO [Election2016Broker] - Broker: Component loaded! foo/{}/{"Content-Type"=>"text/plain"}  {} (200)
I, [2016-02-26T19:09:45.980000 #1261]  INFO -- : Broker: Component loaded! foo/{}/{"Content-Type"=>"text/plain"}  {} (200)

Solution
I have changed the 200 to #{status}, but I am not sure the message makes sense. The ComponentMeta object has been loaded, but the Component wasn't found. I could only log that line if the code is a 200, or change the message.

@BBCMarkMcDonnell, any thought on this? Are you happy with a dynamic status in the log, or I could remove the log line, change the message, or only log if it's a 200.

Hi @samfrench, we shouldn't make the log call dynamic, because if you're right and a status of 404 is returned then that's a mixed message (e.g. "component loaded: 404" makes no sense).
We should identify the cause of the error instead (e.g. why do we get a type of Component back when no content was found). Once we do that we can choose an appropriate solution such as only calling the log function if indeed the component is successfully loaded

@BBCMarkMcDonnell, the mixed status looks to be caused by a few things:

An asset response is always returned, as the request factory checks the type of request, and a single component request is an asset type.
The same type is then used in the response factory, so an asset response is created.
The issue here, is the asset response, says to log if the component is_a Component. This does not log, as the component is type ErrorComponent, so that is correct.
The mixed logging is coming from the response asset base class, which calls log in the add_no_cache_headers method. This calls log, but would trigger the parent class (asset), as log is defined in both asset and base.
Originally, base was used for a non-200 response, and then asset was hardcoded to 200. I don't see how the base would get used for a non-asset response, as it is of type asset. This is why @zygotic99 had an issue with his metrics and changed BrokerResponse to BrokerNon200Response in the base class. https://github.com/BBC-News/alephant-broker/pull/56/files

I would propose removing the status from the "Broker component loaded" line. The same thing happens in the batch response, but rather than a component(s) loaded, it seems to mean response component parse complete, as it could be a component, or an error component.
Alternative we could use the log method in the base class only, and remove the others, as the asset class overrides and has an issue when components are not found. Then checking if it's a 200 before logging the "Broker component loaded" line. The rest would be fine as it's dynamic, but we have BrokerResponse and BrokerNon200Response which mean the opposite.
The response could be changed to check either in asset if the component has a 200 status or not, or we serve an error response to handle this.

Hi @samfrench this is a bit of a confusing set-up. I'd probably just remove the log method from the Asset class and rely on the log from within the base class. But I'd also modify that Base log to be more generic. So instead of BrokerNon200Response#{status} I'd change it to BrokerResponseStatus#{status} so it doesn't make any assumptions.


Question about the code

Hi, authors
Thx for this incredible work! I have a question about the code implementation of this line in Real_FITS.py. I can not figure out why use the real+ imag / real-imag to generate the results. Why not directly generate the real or image with the corresponding layer? I would appreciate if you could explain this.
Thx ;D

Thanks for being interested in our work! XD
FITS fundamentally works as multiplying a complex vector $X$ by a complex weight matrix $W$.
$$
Y=X*W
$$
However, if we break it down to real number computation, it should be:
$$
Y_real = X_realW_real - X_imagW_imag
Y_imag = X_realW_imag + X_imagW_real
$$
That is exactly what we do in the FITS_real, simulating this break down.
Hope this can help you.

I have added a comment in real_FITS.py for this! :D

Thx for your detailed explanation!


Numbers in font name

Original issue on project git: https://github.com/codeman38/PressStart2P/issues/2
I know numbers are not good in font names, but Press Start 2P is an active GF font, and it validates fine in font book.
I think font-bakery has some bug in reading the name. Compare this output to the name table:
fontbakery-check-ttf.py error output:
ERROR    [FONT_FAMILY_NAME(1):MACINTOSH(1)] entry: expected 'Press Start2 P' but got 'Press Start 2P'
ERROR    [FULL_FONT_NAME(4):MACINTOSH(1)] entry: expected 'Press Start2 P Regular' but got 'Press Start 2P Regular'
ERROR    [FONT_FAMILY_NAME(1):WINDOWS(3)] entry: expected 'Press Start2 P' but got 'Press Start 2P'
ERROR    [FULL_FONT_NAME(4):WINDOWS(3)] entry: expected 'Press Start2 P Regular' but got 'Press Start 2P Regular'

name table:
<namerecord nameID="1" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Press Start 2P
    </namerecord>
    <namerecord nameID="2" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Regular
    </namerecord>
    <namerecord nameID="3" platformID="1" platEncID="0" langID="0x0" unicode="True">
      3.000;CYRE;PressStart2P-Regular
    </namerecord>
    <namerecord nameID="4" platformID="1" platEncID="0" langID="0x0" unicode="True">
      Press Start 2P Regular
    </namerecord>
    <namerecord nameID="6" platformID="1" platEncID="0" langID="0x0" unicode="True">
      PressStart2P-Regular
    </namerecord>
    <namerecord nameID="1" platformID="3" platEncID="1" langID="0x409">
      Press Start 2P
    </namerecord>
    <namerecord nameID="2" platformID="3" platEncID="1" langID="0x409">
      Regular
    </namerecord>
    <namerecord nameID="3" platformID="3" platEncID="1" langID="0x409">
      3.000;CYRE;PressStart2P-Regular
    </namerecord>
    <namerecord nameID="4" platformID="3" platEncID="1" langID="0x409">
      Press Start 2P Regular
    </namerecord>
    <namerecord nameID="6" platformID="3" platEncID="1" langID="0x409">
      PressStart2P-Regular
    </namerecord>

or is  PressStart2P-Regular  > Press Start2 P perfectly logical?
How should I proceed with the original font naming?

Hey Alexei,
I reported this the other day #1120. Same Issue.

also related: #1075

@m4rc1e and @graphicore is this a duplicated issue?

@vmesel as long the policy is to add exceptions into fontbakery, I would argue that this is not a duplicate. The solution is probably to add an exception for Press Start 2Pas well. See #1075 and the PR #1084
For the record, I'm not too happy with the exception thing, but it seems to be hard to define a universal scheme for allowed names.

I'm not too happy about it as well. As a programmer I'd expect a clear-cut algorithmic definition of what's allowed and what's unacceptable. But this universal rule seems a bit hard to come up with, as @graphicore pointed out, so that's how we're working at the moment, adding exceptions. Maybe after we gather a slightly larger set of exceptions we'll gradually grasp a reasonable algorithmic expression of our criteria and then get rid of the exceptions. Maybe not. :-P

No. This was not a good fix, sorry.

alright :-)


Slide

layout: slide
title: "Welcome to our second slide!"
Your text
Use the left arrow to go back!

layout: slide
title: "Welcome to our second slide!"
Your text
Use the left arrow to go back!

Add 12S21051Martha's file

Add 12S21051Martha's file


Searchable classes in the display tree

Searchable classes in the tree
The addition of a search bar to filter out classes that don't match the text would allow users to quickly find classes by typing their names. This would be useful especially if it is buried deep in a large package sequence.

Originally from: #131

Preview


Reviewed PRs from Sam, with fixes to last.

Current coverage is 59.77% (diff: 78.57%)

Merging #231 into master will increase coverage by 0.05%

@@             master       #231   diff @@
==========================================
  Files           128        128
  Lines          6766       6795    +29
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           4041       4062    +21
- Misses         2363       2371     +8
  Partials        362        362

Powered by Codecov. Last update 80a600e...03a3377


[Bug] Blink

Read the docs
You might find a solution to your problem in the docs -- consider using the search function there.
Describe the bug
Blink style does not work in PyCharm IDE or Python 3.9 terminal
To Reproduce

console.print("Danger, Will Robinson!", style="blink bold red underline on white")
Danger, Will Robinson!
console.print("Danger, Will Robinson!", style="blink2 bold red")
Danger, Will Robinson!
console.print("Danger, Will Robinson!", style="blink bold red")
Danger, Will Robinson!
from rich.style import Style
danger_style = Style(color="red", blink=True, bold=True)
console.print("Danger, Will Robinson!", style=danger_style)
Danger, Will Robinson!

All of the commands above did not produce blink text
Platform
Python 3.9.1 (64-bit) and PyCharm 2020.3.3
Rich 9.51
Windows 10 (64-bit)
Diagnose
I may ask you to cut and paste the output of the following commands. It may save some time if you do it now.
python -m rich.diagnose
python -m rich._windows
pip freeze | grep rich

Did I help?

Not all terminals support blink. Often it’s a conscious choice, because some find it an irritating feature. Windows doesn’t support it.

Ok fair play.
Computer joke: You mean to tell me my intel i7-7700HQ 7th gen 64 bit processor with 32gb ddr4 ram cannot manufacture or process the bits required to display blinking text in my terminal?


Add "East Coast Greenway / Overseas Heritage Trail" to popup for that lane

[ ] Also add "Promenade/Overseas Heritage Trail" to the northern part of it


Small Readme typo and arrangement cleanup.

Just a quick cleanup proposition.

yayks, had a typo in the commit message 😓 .

Next time I'll triple check before hitting that PR button. Here it is: https://github.com/intendednull/yewdux/pull/15


Import doesn't parse all externals in svn

When using dfetch -v import following svn output is shown, but the Core\FileSystem\Resources are not in the manifest.
Core\FileSystem\Resources - ^/DATA-MYPROJECT-SOME-FILES SomeFiles
^/DATA-MYPROJECT-SOME-OTHER-FILES/Processed SomeOtherFiles

Core\Legacy\Info - ^/DOCS-MYPROJECT/Build/trunk/Build.md@6128 Build.md

Core\Legacy\Info\guides - ^/DOCS-MYPROJECT/Filesystem/trunk@6128 Filesystem
^/DOCS-MYPROJECT/SomeOtherFiles/trunk@6128 SomeOtherFiles

Quality - http://svn.mycompany.com/MYCOMPANY/Jenkins/Project/Resources/tags/0.1.0@592 Resources

Tests\functional - http://svn.mycompany.com/MYCOMPANY/SomeFramework/tags/v0.1.15/PythonPackage/dist@597 SomeFramework

manifest:
  version: '0.0'

  remotes:
  - name: svn-mycompany-com-PD28-DOCS-SOMEPROJECT
    url-base: http://svn.mycompany.com/PD28/DOCS-SOMEPROJECT

  - name: svn-mycompany-com-MYCOMPANY-Jenkins-Project
    url-base: http://svn.mycompany.com/MYCOMPANY/Jenkins/Project

  - name: svn-mycompany-com-MYCOMPANY
    url-base: http://svn.mycompany.com/MYCOMPANY

  projects:
  - name: Build.md
    revision: '6128'
    remote: svn-mycompany-com-PD28-DOCS-SOMEPROJECT
    src: Build.md
    dst: Core/Legacy/Info/Build.md
    repo-path: Build

  - name: Filesystem
    revision: '6128'
    remote: svn-mycompany-com-PD28-DOCS-SOMEPROJECT
    dst: Core/Legacy/Info/guides/Filesystem
    repo-path: Filesystem

  - name: SomeOtherFiles
    revision: '6128'
    remote: svn-mycompany-com-PD28-DOCS-SOMEPROJECT
    dst: Core/Legacy/Info/guides/SomeOtherFiles
    repo-path: SomeOtherFiles

  - name: Resources
    revision: '592'
    remote: svn-mycompany-com-MYCOMPANY-Jenkins-Project
    dst: Quality/Resources
    tag: 0.1.0
    repo-path: Resources

  - name: SomeFramework
    revision: '597'
    remote: svn-mycompany-com-MYCOMPANY
    src: PythonPackage/dist
    dst: Tests/functional/SomeFramework
    tag: v0.1.15
    repo-path: SomeFramework

This is due to the first two externals are svn repositories with a non-standard layout. Since dfetch cannot check/update these currently (see #135), it is not usefull to import these. However, it might be usefull to notify the user that some externals couldn't be imported.

The second problem is that they are unpinned (no @1234 behind).


#yourfirstpr - Update our template and remove thousands of warnings from our build logs.

Instead of fixing this issue immediately, we are leaving this issue open and up for grabs for someone who has never contributed to open source before. We will not accept solutions to this issue from non-first-timers to this project or open-source, we will check.
Problem
We lack XML documentation on our ReactiveUI-Events package which results in an excessive amount of warnings when building ReactiveUI on our continuous integration environment.
It really doesn't make sense to go back and add the missing XML documentation as these projects are automatically generated by a moustache template and a console application.
Additionally it does not make sense to add dummy XML documentation so the approach we are proposing is update the template that generates the projects to supress the compiler warning.
Suggested Resolution
On https://github.com/reactiveui/ReactiveUI/blob/master/ReactiveUI.Events/Events.mustache#L14
At the top of the file you will find the following section
{{#Namespaces}}
namespace {{Name}}

Change it to be
#pragma warning disable 1591
{{#Namespaces}}
namespace {{Name}}

At the bottom of the file you will find the following section
{{/Types}}
}
{{/DelegateNamespaces}}

Change it to be
{{/Types}}
}
#pragma warning restore 1591
{{/DelegateNamespaces}}

Submit your first pull-request and when it gets merged, we will send a tweet to  @yourfirstpr in celebration :)
What you'll be fixing
In our build logs #1006 we have thousands of these annoying and erroneous warning messages:
Events.cs(2506,16): warning CS1591: Missing XML comment for publicly visible type or member 'TimelineEvents.TimelineEvents(Timeline)' [C:\projects\reactiveui\ReactiveUI.Events\ReactiveUI.Events_Net45.csproj]
Events.cs(2512,46): warning CS1591: Missing XML comment for publicly visible type or member 'TimelineEvents.CurrentStateInvalidated' [C:\projects\reactiveui\ReactiveUI.Events\ReactiveUI.Events_Net45.csproj]
Events.cs(2516,46): warning CS1591: Missing XML comment for publicly visible type or member 'TimelineEvents.CurrentTimeInvalidated' [C:\projects\reactiveui\ReactiveUI.Events\ReactiveUI.Events_Net45.csproj]
Events.cs(2520,46): warning CS1591: Missing XML comment for publicly visible type or member 'TimelineEvents.CurrentGlobalSpeedInvalidated' [C:\projects\reactiveui\ReactiveUI.Events\ReactiveUI.Events_Net45.csproj]
Events.cs(2524,46): warning CS1591: Missing XML comment for publicly visible type or member 'TimelineEvents.Completed' [C:\projects\reactiveui\ReactiveUI.Events\ReactiveUI.Events_Net45.csproj]
Events.cs(2528,46): warning CS1591: Missing XML comment for publicly visible type or member 'TimelineEvents.RemoveRequested' [C:\projects\reactiveui\ReactiveUI.Events\ReactiveUI.Events_Net45.csproj]
Events.cs(2536,25): warning CS1591: Missing XML comment for publicly visible type or member 'EventsMixin' [C:\projects\reactiveui\ReactiveUI.Events\ReactiveUI.Events_Net45.csproj]
Events.cs(2538,43): warning CS1591: Missing XML comment for publicly visible type or member 'EventsMixin.Events(BitmapDecoder)' [C:\projects\reactiveui\ReactiveUI.Events\ReactiveUI.Events_Net45.csproj]
Events.cs(2542,42): warning CS1591: Missing XML comment for publicly visible type or member 'EventsMixin.Events(BitmapSource)' [C:\projects\reactiveui\ReactiveUI.Events\ReactiveUI.Events_Net45.csproj]
Events.cs(2548,18): warning CS1591: Missing XML comment for publicly visible type or member 'BitmapDecoderEvents' [C:\projects\reactiveui\ReactiveUI.Events\ReactiveUI.Events_Net45.csproj]
Events.cs(2552,16): warning CS1591: Missing XML comment for publicly visible type or member 'BitmapDecoderEvents.BitmapDecoderEvents(BitmapDecoder)'

Thanks for this great issue! Putting it up on the @yourfirstpr account tomorrow at 1pm (GMT). :sparkles:

@Charlotteis this PR has been resolved by @Avrozavr!
See https://github.com/reactiveui/ReactiveUI/pull/1010
This has been a pleasure, look forward to working with you again in the future.

Nicely done :)


Installation error

I am going through the installation step, can't understand the following error. Can anyone help me to resolve this.

@TIYASARIT Hi, it seems that you have not installed git on your system. Besides, we do not suggest running this project on the Windows system. Please use Linux system like Ubuntu instead.

@MasterBin-IIAU  Thanks, I do have Git installed.... Is there any path dependency?
I will try to switch to Ubuntu. Tell me one thing, do I need GPU along with Ubuntu to execute this?


get_followers() returns Unauthorized: You're not authorized to use this route regardless of twitch scopes

Describe the bug
get_followers() returns Unauthorized: You're not authorized to use this route regardless of twitch scopes
Are you using TwitchIO within a Discord Bot?
No
What commit of TwitchIO are you using?
1.1.0
To Reproduce
try and run get_followers() on either the initial_channel userid or the authorized bots userid
Expected behaviour
It should send me back a list of followers
(please complete the following information):

OS: Windows

update your twitchio

update your twitchio

Thanks but 1.2.1 did not fix it

Thanks but 1.2.1 did not fix it

join the pythonista discord for support in that case

join the pythonista discord for support in that case

Thanks I will

Thanks I will

Where did you get your Token. Are you sure it is a User and Bearer Token? Try using https://twitchtokengenerator.com/ to generate it, helped me.
If you want an example look in https://dev.twitch.tv/docs/api/reference#get-users-follows .

Where did you get your Token. Are you sure it is a User and Bearer Token? Try using https://twitchtokengenerator.com/ to generate it, helped me.
If you want an example look in https://dev.twitch.tv/docs/api/reference#get-users-follows .


Show valid auth type in lower cases

Show valid auth type in lower cases

Codecov Report

Merging #982 into develop will decrease coverage by 0.02%.
The diff coverage is 0%.

@@              Coverage Diff              @@
##             develop     #982      +/-   ##
=============================================
- Coverage      41.25%   41.23%   -0.03%
  Complexity       781      781
=============================================
  Files            156      156
  Lines           5633     5636       +3
  Branches         787      787
=============================================
  Hits            2324     2324
- Misses          3140     3143       +3
  Partials         169      169

Impacted Files
Coverage Δ
Complexity Δ

...a/com/microsoft/azure/maven/AbstractAzureMojo.java
34.3% <0%> (-0.61%)
0 <0> (ø)

Continue to review full report at Codecov.

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


Add Accesss Key to Properties

When pairing with an Android device, the user must input their access key. This is currently only available by inspecting the "Pairing URL" property and extracting from the final query param. Better to have it's own field.

@gStart9 is taking over this service.  Happy to help you get familiarized with packaging when you are ready

Fixed up in #17


🔄 Regression on importing from subdirectory of a package in node_modules

Prerequisites

[X] I've read the relevant documentation
[X] I've searched for existing issues
[X] I've read the issue reproduction guide

Reproduction url
https://github.com/stephenwade/knip-issue-repro-crispy-broccoli
Reproduction access

[X] I've made sure the reproduction is publicly accessible

Good version
5.27.3
Bad version
5.27.4
Description of the regression
In my project, I import a type from 'node_modules/react-toastify/dist/components' because 'react-toastify' doesn't export it. To get around Knip reporting it as an unlisted dependency, I added this to my config file:
"ignoreDependencies": ["node_modules/react-toastify/dist/components"]

In version 5.27.3, Knip reports no issues. In version 5.27.4 and later, I get this report:
Unlisted dependencies (1)
node_modules/react-toastify/dist/components  app/ToastContainer.tsx
Configuration issues (1)
Unused item in ignoreDependencies: node_modules/react-toastify/dist/components

I haven't found a configuration that works for my project since the update.
I think the issue is likely caused by 89780376.
(ref: https://github.com/stephenwade/festival/pull/1693)

Regardless of whether this is a bug or not, this seems to work the same for a while:
npx<EMAIL_ADDRESS>Unlisted dependencies (1)
node_modules/react-toastify/dist/components  app/ToastContainer.tsx

The values in ignoreDependencies are package names so either "name" or "@scope/name" - so in this case the odd "node_modules" would do.
Will investigate some more later on.

The issue is not that it appears as an unlisted dependency. The issue is that I can no longer ignore that report with "ignoreDependencies".

You can use literally "ignoreDependencies": ["node_modules"]

That works, thank you!
I'll leave the issue open for the underlying issue that Knip should detect this import as react-toastify and not need any "ignoreDependencies" config.

:rocket: This issue has been resolved in v5.30.2. See Release 5.30.2 for release notes.
Using Knip in a commercial project? Please consider becoming a sponsor.


[taskcat-ci] Updating submodules

Can I get someone familiar with the util to resolve the conflicts please? @sjacoby-godaddy @sfeltner-godaddy

@sjacoby-godaddy @sfeltner-godaddy  Can you resolve the conflict please?


Allow users to request role assignment

Is your feature request related to a problem? Please describe.
Corvesta has said that in some cases, users need to get access to multiple resources at once. Requesting access one at a time is tiresome, even with auto-approval. They ask if we can allow users to request Role assignment, i.e. assign me to role OnCall2021
Describe the solution you'd like
Add a new command, e.g. assign me to role
Describe alternatives you've considered
Dynamic Grants might be an alternative, after they are GA.

For simplicity sake, as we do with the access command, I'll follow the pattern: assign role Xxx

By default, I'll use a manual approval flow and then we can add a flag for auto-approve

Changing the semantics of the command to: access to role RoleName because in reality we'll grant temporary access to all resources listed in a role

I have added a show available roles command. It just lists all roles, in the future we might want to add more information (e.g. resources) or support a hide-roles flag

Besides, because some clients might want to disable access to role role-name or show available roles I added a new variable: SDM_COMMANDS_ENABLED. See docs/CONFIGURE_ACCESSBOT.md


Add Avax subnet support for DFK

Ha @ernestognw, right on the money - I just put this up: https://github.com/OpenZeppelin/defender-client/pull/119
It seems like until something like it gets merged, the integration tests are broken because there's a type mismatch between Network in defender and Network here...
Technically only sentinels can use Hedera at this time. The rest are hidden in the UI, wondering if I should also put up a "Not supported" error in the API? But that ends up being a lot of endpoints...what do you guys think?

LGTM, just two concerns:

I know backend will reject requests from users trying to access DFK subnet, but at least having a note in the code that these are private will be great for me. Perhaps we make type Network = PublicNetwork | PrivateNetwork where PublicNetwork is what we already have and PrivateNetwork is DFK's
I do like the idea of keeping a single source for Network, but @mok0230 is working on Hedera's sentinels, this may get back to have them separated or at least making SentinelNetwork = Network | 'hedera'

Thanks for the feedback! I think you're right in separating the public and private networks for clarity. We should probably apply the same separation in the defender codebase. As for @mok0230, I don't believe
SentinelNetwork = Network | 'hedera' will do the trick as the tests read from base-client -> Network. Alternatively, Dan, you could add Hedera as part of public network, or create a new type SentinelNetwork = 'hedera' and have export type Network = PublicNetwork | PrivateNetwork | SentinelNetwork if that's cleaner? Not sure what your thoughts are?

FWIW I don't think it makes sense to have a separate SentinelNetwork at the models level, since we'll eventually add Hedera support all across the board.

Maybe we can combine this validation with the one that takes care of checking if the tenant has access to the network, if it's a custom network?

@spalladino I created this issue to capture the work, but it can't be completed until after Hedera Sentinels gets approved because that's where those properties get added. Or, if we want to up the priority, I could include with my Hedera PR.
https://github.com/OpenZeppelin/defender/issues/2701


Proposal for better gatekeeping: stick to masterpiece materials

Description
Can we please refrain from adding things if content isn’t unique?

Why
I’ve been following the changes happening lately and I’m concerned making changes to this repo is turning into a popularity contest. Below are a few reasons why.
Possible Implementations
I propose contributors ask themselves these questions before opening a PR:

Does the writing follow a unique pedagogy?
Does the writing put you outside your comfort zone by taking an unfamiliar and scary topic and making you happy, instead of overwhelmed?
Is the writing from a portal, aggregator or a commercial site (constains ads, etc)? That should be a yellow flag as these places favor breath over depth.

A few other random points:

I would prefer that topics endure test of time and that they stay away from frameworks. Thoughts here?
If we link to an aggregator site, we defeat the point of being curators here.

Is this something you're interested in working on?

[x] YES
[ ] NO

I agree with your points. I'll admit that I haven't been able to pay enough attention to this project. I'll plan on purging some of the redundant tutorials. What do you think about putting them into a separate file like "Some other tutorials" which acts as a link aggregator, nothing more and nothing less?

we can begin tagging tutorials that stand the test of time like classic


[HUDI-485]: corrected the check for incremental sql

Tips

Thank you very much for contributing to Apache Hudi.
Please review https://hudi.apache.org/contributing.html before opening a pull request.

What is the purpose of the pull request
Corrected the check for incremental SQL in HiveIncrementalPuller.java class.
Brief change log
(for example:)

Modify AnnotationLocation checkstyle rule in checkstyle.xml

Verify this pull request
(Please pick either of the following options)
This pull request is a trivial rework / code cleanup without any test coverage.
(or)
This pull request is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)

Added integration tests for end-to-end.
Added HoodieClientWriteTest to verify the change.
Manually verified the change by running a job locally.

Committer checklist

[ ] Has a corresponding JIRA in PR title & commit

[ ] Commit message is descriptive of the change

[ ] CI is green

[ ] Necessary doc changes done or have another open PR

[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

Codecov Report

Merging #2768 (5d32a15) into master (e970e1f) will increase coverage by 0.09%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #2768      +/-   ##
============================================
+ Coverage     52.32%   52.42%   +0.09%
+ Complexity     3689     3499     -190
============================================
  Files           483      461      -22
  Lines         23095    21487    -1608
  Branches       2460     2305     -155
============================================
- Hits          12084    11264     -820
+ Misses         9942     9229     -713
+ Partials       1069      994      -75

Flag
Coverage Δ
Complexity Δ

hudicli
37.01% <ø> (ø)
0.00 <ø> (ø)

hudiclient
∅ <ø> (∅)
0.00 <ø> (ø)

hudicommon
50.78% <ø> (-0.05%)
0.00 <ø> (ø)

hudiflink
56.71% <ø> (ø)
0.00 <ø> (ø)

hudihadoopmr
33.44% <ø> (ø)
0.00 <ø> (ø)

hudisparkdatasource
71.33% <ø> (ø)
0.00 <ø> (ø)

hudisync
?
?

huditimelineservice
?
?

hudiutilities
69.74% <ø> (+0.05%)
0.00 <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ
Complexity Δ

...ache/hudi/common/fs/inline/InMemoryFileSystem.java
79.31% <0.00%> (-10.35%)
15.00% <0.00%> (-1.00%)

...e/hudi/common/table/log/HoodieLogFormatWriter.java
78.12% <0.00%> (-1.57%)
26.00% <0.00%> (ø%)

...main/java/org/apache/hudi/dla/HoodieDLAClient.java

...g/apache/hudi/timeline/service/RequestHandler.java

...in/java/org/apache/hudi/hive/HoodieHiveClient.java

...apache/hudi/timeline/service/handlers/Handler.java

...udi/timeline/service/handlers/TimelineHandler.java

...i/hive/SlashEncodedDayPartitionValueExtractor.java

...src/main/java/org/apache/hudi/dla/DLASyncTool.java

...main/java/org/apache/hudi/hive/HiveSyncConfig.java

... and 15 more

@vingov for an extra pair of eyes.
@pratyakshsharma can you please provide more context into what the fix is? any tests?

lgtm, we should use '%s' to replace the from commit time in the line no. 197 with the string format function:
incrementalPullSQLtemplate.add("incrementalSQL", String.format(incrementalSQL, config.fromCommitTime));

@pratyakshsharma : can you please respond to vinoth's feedback when you get a chance.

@vingov for an extra pair of eyes. @pratyakshsharma any testing done for the PR? any way to add a test for the tool?

No I have not done any testing. Currently there is no test coverage for this tool. The lines of code that this PR is touching do not need any test case I believe. We can try to cover the entire tool in general with unit tests though. Do you want me to do that as part of this PR itself? @vinothchandar

yes, please.

I see L197 is not yet fixed. @vingov given you use this or a similar tool daily. Do you want to upstream a patch for this?

the code looks good, my last comment was confirming that we should use '%s' so that the String.format function in the L197 will replace it correctly.
No further changes are required by @pratyakshsharma!

@codope I need to add few test cases for this PR. Will do that soon!

@pratyakshsharma : Can you please follow up on this and address the feedback.

@pratyakshsharma can we please see this PR through? are you still interested in driving this forward?

Ack. Let me close this in a day or two.

@nsivabalan @vinothchandar please take a pass. We can include this in 0.10.1 release as well.

@codope please take a pass, I have added the happy flow test case now.


The 'Canceled' activities shows when canceling the setting of Access Tier

Storage Explorer Version:1.7.0_20190312.3
Platform/OS: _Linux Ubuntu/macOS High Sierra/Windows 10
Architecture: _i86
Regression From: Not a regression
Steps to Reproduce

Right click one non-adls gen2 account -> Select 'Set Default Access Tier'.
Click 'Cancel/Close' on the dialog -> Check whether the canceled activities shows or not.

Expected Experience
No canceled activities shows.
Actual Experience
The canceled activities shows.

Fix merged into master.


[bug] chainid is not injected eosjs

When calling scatter.eos() you need to set the chainId as eosOptions like this:
const eosOptions = {
    chainId: 'aca376f206b8fc25a6ed44dbdc66547c36c6c33e3a119ffbeaef943642f0e906'
};
const eos     = scatter.eos( network, Eos, eosOptions, 'http' );
const backend = eos.contract('eosforumtest');

If you don't you get the following error message:
chainId mismatch, signatures will not match transaction authority. expected
cf057bbfb72640471fd910bcb67639c22df9f92470936cddc1ade0e2f2e7dc4f
!== actual
aca376f206b8fc25a6ed44dbdc66547c36c6c33e3a119ffbeaef943642f0e906

@ eos.min.js:1:7998

Yes, the Developer documentation should be updated accordingly.

Fixed on both Scatter Classic and Scatter Desktop.

OK, I double checked in Chrome and there it works now without the chainID, even without the authorization param. W00T!!
... but only for Chrome. Is Firefox still going to be supported, or what's the future for that plugin?


Multiple effects in one token

It doesnt look like its possible to define multiple effects such as shadow with a toke and the current behaviour overrides one shadow with another.
If im to replicate the shadow styles of android material i need layered shadows, can this be added ?

Unfortunately for now there's only one fill (for all tokens), this includes boxShadow tokens. I do understand we definitely need multiples, which is especially true for shadows.
I'd like to merge this issue with #152 so we can track progress there.

Closing this in favor of #152


Unable to Join World due to Incompatible Packs after Encrypting Custom Resource Pack

After encrypting my custom resource pack, I encounter the following error message when attempting to join a Minecraft world: "You are unable to join the world because you have the following incompatible packs." This issue began only after encrypting the resource pack; the same pack worked fine on both client and server in its unencrypted form.
The attached screenshot is provided solely as an example of the error message in English. The screenshot shows a different server (from Zeka) because I found it online with the exact error text in English (my own game's language is set to [RU], so I opted not to upload my own screenshot). The error message is, however, identical to the one I receive with my own encrypted resource pack.

I just got that error :/


Cart not available

why in demo version and localhost ,iam failed to click button cart and refresh in same page ,thanks

Hi @masdinan I am unable to understand your issue please mention some reproduction steps so that I can figure out what help you need


Search nodes in graph with highlighting?

Is it possible to search nodes in the graph based on attributes and then highlighting them?

react-d3-graph works in a way that allows you to implement all that lookup logic on the client side. You have methods to highlight the nodes but the logic to look for them and in what attributes that lookup is based on is totally up to you, you can put whatever data you want on the node as long as you follow the base contract


Add way to find out what went wrong when sendTransaction fails

BlockChainContext.sendTransaction returns null or an empty string if no transaction could be made. However, it would be good to let the calling application know what went wrong. This could be done by throwing an error containing Retrofit's call object with more information.

The transaction is made before calling this method. The method just sends the transaction to the node. If the sending fails, the exception is raised.  Or am I missing something?

Closed because I am using BoxOperations.send now without problems


TuyaWebPlatform Error: connect ETIMEDOUT

Hi,
I have been using this plugin for atleast 6 months or more without any problems.
But since a week ago, i am unable to use Homekit without connectivity issues.
Everything from Homebridge to the plugin is up to date. I even did a full re-install of homebridge + plugin.
My config follows as:
},
"accessories": [],
"platforms": [
{
"name": "Config",
"port": 8581,
"platform": "config"
},
{
"name": "TuyaWebPlatform",
"options": {
"username"<EMAIL_ADDRESS>"password": "password",
"countryCode": "31",
"platform": "tuya",
"pollingInterval": 700
I tried a different account that i added to Tuya, with different login.
I changed my password, still no luck.
Is it just me?
The error is get:
Starting to advertise 'Homebridge AD8F 5777' using bonjour-hap backend!
[5/16/2021, 4:20:10 PM] Homebridge v1.3.4 (Homebridge AD8F) is running on port 53114.
[5/16/2021, 4:20:10 PM] [TuyaWebPlatform] Sending HTTP GET request to /homeassistant/skill - Header: {"name":"Discovery","namespace":"discovery","payloadVersion":1}.
[5/16/2021, 4:20:42 PM] [TuyaWebPlatform] connect ETIMEDOUT <IP_ADDRESS>:443
[5/16/2021, 4:20:42 PM] [TuyaWebPlatform] Error: connect ETIMEDOUT <IP_ADDRESS>:443
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1146:16) {
errno: -110,
code: 'ETIMEDOUT',
syscall: 'connect',
address: '<IP_ADDRESS>',
port: 443,
config: {
url: '/homeassistant/skill',
method: 'get',
data: '{"header":{"name":"Discovery","namespace":"discovery","payloadVersion":1},"payload":{"accessToken":"EUheu15925146217965ECxCShSbSWKPM3"}}',
headers: {
Accept: 'application/json, text/plain, /',
'Content-Type': 'application/json;charset=utf-8',
'User-Agent': 'axios/0.21.1',
'Content-Length': 136
},
baseURL: 'https://px1.tuyaeu.com',
transformRequest: [ [Function: transformRequest] ],
transformResponse: [ [Function: transformResponse] ],
timeout: 0,
adapter: [Function: httpAdapter],
xsrfCookieName: 'XSRF-TOKEN',
xsrfHeaderName: 'X-XSRF-TOKEN',
maxContentLength: -1,
maxBodyLength: -1,
validateStatus: [Function: validateStatus]
},
request: <ref *1> Writable {
_writableState: WritableState {
objectMode: false,
highWaterMark: 16384,
finalCalled: false,
needDrain: false,
ending: false,
ended: false,
finished: false,
destroyed: false,
decodeStrings: true,
defaultEncoding: 'utf8',
length: 0,
writing: false,
corked: 0,
sync: true,
bufferProcessing: false,
onwrite: [Function: bound onwrite],
writecb: null,
writelen: 0,
afterWriteTickInfo: null,
buffered: [],
bufferedIndex: 0,
allBuffers: true,
allNoop: true,
pendingcb: 0,
prefinished: false,
errorEmitted: false,
emitClose: true,
autoDestroy: true,
errored: null,
closed: false
},
_events: [Object: null prototype] {
response: [Function: handleResponse],
error: [Function: handleRequestError]
},
_eventsCount: 2,
_maxListeners: undefined,
_options: {
maxRedirects: 21,
maxBodyLength: 10485760,
protocol: 'https:',
path: '/homeassistant/skill',
method: 'GET',
headers: [Object],
agent: undefined,
agents: [Object],
auth: undefined,
hostname: 'px1.tuyaeu.com',
port: null,
nativeProtocols: [Object],
pathname: '/homeassistant/skill'
},
_ended: false,
_ending: true,
_redirectCount: 0,
_redirects: [],
_requestBodyLength: 136,
_requestBodyBuffers: [ [Object] ],
_onNativeResponse: [Function (anonymous)],
_currentRequest: ClientRequest {
_events: [Object: null prototype],
_eventsCount: 7,
_maxListeners: undefined,
outputData: [],
outputSize: 0,
writable: true,
destroyed: false,
_last: true,
chunkedEncoding: false,
shouldKeepAlive: false,
_defaultKeepAlive: true,
useChunkedEncodingByDefault: false,
sendDate: false,
_removedConnection: false,
_removedContLen: false,
_removedTE: false,
_contentLength: null,
_hasBody: true,
_trailer: '',
finished: false,
_headerSent: true,
socket: [TLSSocket],
_header: 'GET /homeassistant/skill HTTP/1.1\r\n' +
'Accept: application/json, text/plain, /\r\n' +
'Content-Type: application/json;charset=utf-8\r\n' +
'User-Agent: axios/0.21.1\r\n' +
'Content-Length: 136\r\n' +
'Host: px1.tuyaeu.com\r\n' +
'Connection: close\r\n' +
'\r\n',
_keepAliveTimeout: 0,
_onPendingData: [Function: noopPendingOutput],
agent: [Agent],
socketPath: undefined,
method: 'GET',
maxHeaderSize: undefined,
insecureHTTPParser: undefined,
path: '/homeassistant/skill',
_ended: false,
res: null,
aborted: false,
timeoutCb: null,
upgradeOrConnect: false,
parser: null,
maxHeadersCount: null,
reusedSocket: false,
host: 'px1.tuyaeu.com',
protocol: 'https:',
_redirectable: [Circular *1],
[Symbol(kCapture)]: false,
[Symbol(kNeedDrain)]: false,
[Symbol(corked)]: 0,
[Symbol(kOutHeaders)]: [Object: null prototype]
},
_currentUrl: 'https://px1.tuyaeu.com/homeassistant/skill',
[Symbol(kCapture)]: false
},
response: undefined,
isAxiosError: true,
toJSON: [Function: toJSON]
Any help is appreciated. Thanks in advance!

I have not received any other complaints regarding this and I assume that, if the plugin broke, I would have received complaints.
For now, I assume that either your network connection or the tuya servers had a hick-up.
Please see how it continues to function.

Hi,
It was Tuya related, might have been server issues on their end.
Previously, i did a fresh install of both homebridge + plugin and that didn't fix it.
This week it started to work again like normal.
Thanks again!


[Bug]: Add logger and redirect logs to a file

Your current environment

VLLM 0.3.0
ray 2.9.2

🐛 Describe the bug
If I used serve ray to run the chat completion entrypoint with VLLM. I can't use my logger to redirect logs into a file. even if I used it without redirection to a file it didn't output anything!

NOTE

Plus if I have multiple replicas how it handle writing to the logger file from many workers?
from ray import serve
from fastapi import FastAPI, Request
from fastapi.responses import StreamingResponse
from fastapi.responses import JSONResponse, StreamingResponse
from vllm import AsyncEngineArgs, AsyncLLMEngine

from protocol import ChatCompletionRequest, ErrorResponse
from serving_chat import OpenAIServingChat

## logger
import logging
logger = logging.getLogger(__name__)
logger.setLevel(logging.INFO)
handler = logging.StreamHandler()
logger.addHandler(handler)
save_logs_path = Path("logs")
file_handler = logging.FileHandler(str("logs" / "run.log"))
logger.addHandler(file_handler)

app = FastAPI()

@serve.deployment(
    ray_actor_options={"num_gpus": 1},

)
@serve.ingress(app)
class OpenLLMDeployment:
    def __init__(self) -> None:

        ENGINE_ARGS = AsyncEngineArgs(
            gpu_memory_utilization= 0.95,
            model="path/to/model",
            max_model_len=4096,
        )
        self.engine = AsyncLLMEngine.from_engine_args(ENGINE_ARGS)
        logger.info("Initilize LLM")

    @app.post("/v1/chat/completions")
    async def create_chat_completion(request: ChatCompletionRequest,
                                 raw_request: Request):

       logger.inf(f" input: {request}")

       generator = await OpenAIServingChat.create_chat_completion(
            request, raw_request)
        if isinstance(generator, ErrorResponse):
            return JSONResponse(content=generator.model_dump(),
                            status_code=generator.code)
        if request.stream:
            return StreamingResponse(content=generator,
                                 media_type="text/event-stream")
        else:
            return JSONResponse(content=generator.model_dump())

service = OpenLLMDeployment.bind()

@hahmad2008 did you find a way to solve this behavior ? vllm seems to enforces its logging above everything else..

same request, I also hope to add log to file for vllm.

same request, I also hope to add log to file for vllm.

I found that vllm logger can be customized with a JSON file. Check more detail in https://github.com/vllm-project/vllm/blob/main/examples/logging_configuration.md


Expose more llama.cpp options

I've been testing https://huggingface.co/TheBloke/wizardLM-7B-GGML , and the example code is:
./main -t 10 -ngl 32 -m wizardLM-7B.ggmlv3.q5_0.bin --color -c 2048 --temp 0.7 --repeat_penalty 1.1 -n -1 -p "### Instruction: Write a story about llamas\n### Response:"

A few of these options (and others) would be useful to expose:

temp
repeat_penalty
top-k
top-n

@technicalpickles
Thank you for your interesting proposal. In version 0.3.2, I made the sampling options the arguments of the generate module function in LLaMACpp.
https://yoshoku.github.io/llama_cpp.rb/doc/LLaMACpp.html#generate-class_method
https://github.com/yoshoku/llama_cpp.rb/blob/main/CHANGELOG.md#032---2023-07-08

Thank you!


Timers: Incorrect freeze time for Tormented Demons

Type
Incorrect behavior
Operating System
None
OS Version
No response
Bug description
Tormented demons have a special attack which roots the player for a few frames.
The timer displays the freeze time for entangle.
When casting, the message The demon's spell binds you! appears in the chatbox.
Screenshots or videos
No response
RuneLite version
Runelite version 1.10.34
Launcher version 2.7.1
Logs
No response

If you want to, you can check if it works correctly on EHC. If so, it'll likely be fixed in my next buff bar PR.

Seems okay in EHC, I can check again after your PR is merged. Mind linking it here?
I'll see if I can gather any other info on them later as well.

Apologies, I should have been more clear on Discord. I haven't checked out the bound vars yet. I do not know if it's transmitted, and if so, how it behaves. I might be able to take a look in a couple of hours. Feel free to @ me on Discord for further follow-up.

I don't think we can fix this easily as they use a shared animation (entangle), and the client doesn't have information about the length of a player's freeze timer.

Could the chat message be used? Seems something similar is done with ice barrage.

Determine player is bound from the chat message.
Use a newly defined timer here after getting the number of ticks the player is bound manually.
Ignore creating the entangle timer if this one is active (better way to do this?)

Partially resolved with 1b0b2d9 but maybe good enough to close this?
The timer still stays if you don't move and tank the special attack, but doubt people are going to be doing that


[BP-1.13][FLINK-22704][tests] Harden ZooKeeperHaServicesTest.testCleanupJobData

Backport of #15954 to release-1.13.

Thanks for the review @XComp. Merging this PR now.


Live updates infinite loops refreshing?

I've had a lot of trouble with live updates. It failed previously, now it continuously refreshes. Something seems broken. Is anyone else having this issue?
Chrome 84.0.4147.135

I'm having this same issue. Firefox 82.0

Same issue. Chrome 86.0

I think what might be happening is that the check for if the current SHA is the same as the latest SHA is triggering an infinite loop before the page build can complete. That might be causing a race condition– and even if it's not the primary cause here I'd consider it a risk.
Doing a full page refresh like this is kind of dangerous to begin with, and can cause some really expensive loading. In the interest of suggesting something useful: Maybe output the SHA of the latest build to a file and then check the latest commit in fetchLatestCommit against that instead. That way you can be sure the page was built before kicking off a refresh. It'll be better, but you might still have caching issues.
You almost might as well force that commit check to be some offset from the last build time so you can be sure the build completed before checking and refreshing.

If you open the page in a new tab, does it still get in an infinite loop? If so, mind pasting what your console logs look like?

errors on the sha check like so https://i.imgur.com/l1JVYNs.png until rate limiter hit

was working until a sec ago this: https://i.imgur.com/QXUksBk.png https://i.imgur.com/a0bujqe.png

Hey @helix4u
Your network log shows requests to the github API which we're not longer leaning on for updates. So if you hard refresh I think the issue you're hitting should go away.
Please let us know if it doesn't :D

yeah, I think it was just a momentary thing... possibly related to revert-262-feature/gh-page-polling if it went live for a second before it was paused.


Fix expectedAction for DELETE method

Fix expectedAction to be write for DELETE method as well

@JSAssassin does this look good to you? @dmitrizagidulin?

@dlongley yup. LGTM! Will this still be a patch release though?


Commutative equality

While we're talking about strictness of the eq expectation in #13389, I'd like to push some other though that has bugged me for a while.
Equality is usually expected to be commutative (i.e. from a == b follows b == a). That's a practical assumption, but not necessarily the case. If a and b have different types (say A and B), it might be that only one leg, A#==(B) or B#==(A) is implemented and the inverse would fall back to the default implementation which always returns false (ref #10277).
In stdlib there are a couple of cases where this applies. They're related to types that imitate a wrapped type, namely YAML::Any and Log::Metadata::Value.
require "log"

a = Log::Metadata::Value.new("foo")
b = "foo"

a == b # => true
b == a # => false

I think that these types that implement custom equality methods should do the same on the types they define equality with.
Having specs ensure equality in both directions should go a long way to provide sanity on this topic.
If type strictness gets implemented as proposed in #13389, this will also cover specs for all such cases because a eq b requires both operands to have the same type. Otherwise, it would be good for eq to test reverse equality.

Patch
--- i/src/spec/expectations.cr
+++ w/src/spec/expectations.cr
@@ -16,7 +16,7 @@ module Spec
           actual_value.bytesize == expected_value.bytesize &&
           actual_value.size == expected_value.size
       else
-        actual_value == @expected_value
+        (actual_value == @expected_value) && (@expected_value == actual_value)
       end
     end

Failing examples with this patch:
  1) YAML::Schema::Core parses "!!set { 1, 2, 3 }"
     Failure/Error: YAML::Schema::Core.parse(string).should eq(expected)

       Expected: Set{1, 2, 3} : Set(Int32)
            got: Set{1, 2, 3} : YAML::Any

     # spec/std/yaml/schema/core_spec.cr:6

  2) YAML::Schema::Core parses "!!binary aGVsbG8="
     Failure/Error: YAML::Schema::Core.parse(string).should eq(expected)

       Expected: Bytes[104, 101, 108, 108, 111] : Slice(UInt8)
            got: Bytes[104, 101, 108, 108, 111] : YAML::Any

     # spec/std/yaml/schema/core_spec.cr:6

  3) YAML::Schema::Core parses "!!timestamp 2010-01-02"
     Failure/Error: YAML::Schema::Core.parse(string).should eq(expected)

       Expected: 2010-01-02 00:00:00.0 UTC : Time
            got: 2010-01-02 00:00:00.0 UTC : YAML::Any

     # spec/std/yaml/schema/core_spec.cr:6

  4) Log::Metadata []?
     Failure/Error: md[:a]?.should eq(3)

       Expected: 3 : Int32
            got: 3 : Log::Metadata::Value

     # spec/std/log/metadata_spec.cr:89
  5) Log::Metadata []
     Failure/Error: md[:a].should eq(3)

       Expected: 3 : Int32
            got: 3 : Log::Metadata::Value

     # spec/std/log/metadata_spec.cr:81

  6) HTTP::Server::RequestProcessor does not bleed Log::Context between requests
     Failure/Error: logs.entry.context[:foo].should eq "bar"

       Expected: "bar" : String
            got: "bar" : Log::Metadata::Value

     # spec/std/http/server/request_processor_spec.cr:345

  7) HTTP::Server::RequestProcessor catches raised error on handler and retains context from handler
     Failure/Error: logs.entry.context[:foo].should eq "bar"

       Expected: "bar" : String
            got: "bar" : Log::Metadata::Value

     # spec/std/http/server/request_processor_spec.cr:289

  8) HTTP::Client logging emit logs
     Failure/Error: logs.entry.data[:method].should eq("GET")

       Expected: "GET" : String
            got: "GET" : Log::Metadata::Value

     # spec/std/http/client/client_spec.cr:445

  9) HTTP::Client logging emit logs with block
     Failure/Error: logs.entry.data[:method].should eq("GET")

       Expected: "GET" : String
            got: "GET" : Log::Metadata::Value

     # spec/std/http/client/client_spec.cr:459

Finished in 1:31 minutes
15327 examples, 9 failures, 0 errors, 20 pending

Failed examples:

crystal spec spec/std/yaml/schema/core_spec.cr:184 # YAML::Schema::Core parses "!!set { 1, 2, 3 }"
crystal spec spec/std/yaml/schema/core_spec.cr:192 # YAML::Schema::Core parses "!!binary aGVsbG8="
crystal spec spec/std/yaml/schema/core_spec.cr:235 # YAML::Schema::Core parses "!!timestamp 2010-01-02"
crystal spec spec/std/log/metadata_spec.cr:86 # Log::Metadata []?
crystal spec spec/std/log/metadata_spec.cr:78 # Log::Metadata []
crystal spec spec/std/http/server/request_processor_spec.cr:325 # HTTP::Server::RequestProcessor does not bleed Log::Context between requests
crystal spec spec/std/http/server/request_processor_spec.cr:271 # HTTP::Server::RequestProcessor catches raised error on handler and retains context from handler
crystal spec spec/std/http/client/client_spec.cr:438 # HTTP::Client logging emit logs
crystal spec spec/std/http/client/client_spec.cr:453 # HTTP::Client logging emit logs with block

Additionally, there would also be a technical option to ensure commutativity of #== by the compiler. For example. If there is no specific implementation for b == a and the call would resolve to the default implementation, the compiler could theoretically reverse the operands and transform b == a into a == b.
But this would likely still be brittle. Specific implementations could still revert to the default implementation for some cases. Or even if there are specific implementations for both directions, does not necessarily mean they are required to agree 😆
So I don't think this would lead anywhere (nor would making everything more strict). At least it's always necessary having tests to ensure expected behaviour. Doing some compiler magic won't help about that, it's just more effort and more complex behaviour for developers to understand.

Any comparison operator can be concerned by such inconsistencies, like ===, >=, <=, < and >.

Good point. However comparison operates are typically implemented via the Comparable interface based on <=> which ensures consistency to a high degree. There would only be a chance for error when implementing the comparison operators manually, or when A includes Comparable(B) but B does not include Comparable(A).
The case equality operator === though is explicitly directional:
(1..2) === 1 # => true
1 === (1..2) # => false

So I'd argue it's not actually an equality, it's more pattern matching. But that's a different story.
There's also the pattern match operator =~ which I guess is symmetric in practice, because in stdlib it's only defined between String and Regexp in both directions. But I'm not sure it's required to be that. Actually, I'm not even sure about the semantic difference between === and =~ except that the former usually expands on == and its return value is usually Bool.
Anyway, I those would be excluded here because they're either explicitly not symmetric or not necessarily so.

For standard library specs we could consider using something like this in as many places as possible:
https://github.com/crystal-lang/crystal/blob/98c091ee9dd5a0e75b3dd47b642bd170b4c84a39/spec/std/big/big_rational_spec.cr#L8-L23


[bug] state management of more stories.

go to newscout app
open any news article detail page
click on more stories
it will suddenly close and open on its own.

Issue fixed in release 1.0.1
release link https://play.google.com/apps/testing/com.fafadiatech.newscout


Raise overall test timeout while running with clustered test cases

Clustered test cases brings in additional delay while waiting for pods to be ready. This contributes to increased overall test time which is not guaranteed to finish within default 10m timeout. Therefore raising the time limit for clustered test cases.

/retest centos-ci/sink-clustered/mini-k8s-1.22


"Group by" functionality

Currently, codec-compare allows matching attributes between different batches for individual source images. This is useful for those cases where you want to compare each image at the same bpp, or encode/decode time.
However, encoders are usually used by setting the same quality level for the entire batch, then figuring out if the resulting bpp or encode/decode time is acceptable for the use case.
Having a way for codec-compare to "group" batches by certain criteria (e.g. quality level), then perform per-file matching between groups based on aggregated stats of the groups (sum is good enough for most cases) would capture the aforementioned use case scenario. Performing the comparison in this way would also reward encoders that are better at consistency per quality level.

Thank you for your interest in codec-compare.
Could you share a simple but detailed example, to be sure I correctly understand your request?
The point of codec-compare is to make sure the comparison makes sense. This is why it only compares pairs of the same image, and by default at the same distortion. I feel like aggregating results across different source images and then comparing the averaged results can introduce bias, because one may end up comparing encoded images that are unrelated (low vs high visual quality, different pixel count etc.).
Of course, the codec-compare pairing method introduces other kinds of bias (ignoring unmatched data points) and maintains some inherent drawbacks (objective distortion function inaccuracies). But I still believe it gives a fairer visualization of relative compression performances.
One can preprocess the JSON input of codec-compare to merge multiple rows into single entries which can then be matched by codec-compare. I would not recommend that as it would shrink the number of points to match.
I do not think this is exactly what you had in mind but assuming the intent is to display uncorrelated results side-by-side on the same plot, such as traditional RD-curves, other tools already exist for that.
Also I would like to mention that one can use the arithmetic mean setting, to first aggregate the matched points and then compute its ratio of the aggregated result of the other batch. This is still based on pair-matching first so probably not what you asked.
I suggest keeping the default geometric mean aggregation method anyway, to keep the same weight for each asset.
(I am only talking about lossy compression here.)

Hi @y-guyon, sure thing. I can give you a practical example (one that I actually ran into recently):
Let's say that I want to convert 100, 8 MP pictures for an album gallery, and I have a total file size budget of about 200 MB. I don't care about the size of each individual image, but rather have them all be at a roughly constant perceptual quality. I also don't want to explicitly search for a particular metric score, but instead trust that a given distance/CRF/QP will be a good-enough proxy.
Each album image can be considerably different in what they feature. One image might have a lot of green, bushy trees, so it'll need relatively more bits to encode. Another image might be a macro shot of a flower against a blurry background, so it'll need relatively fewer bits.
I want to know which image format is best for the task. To do this, I'd just encode the entire album at an initial distance/CRF/QP value, then binary-search a value that fits the file size budget. I'd do this procedure for the all the image formats I want to analyze.
Doing this will result in several sets of 100 images, by image format. In this case, I'm interested into knowing a few things:

Which image format has the best overall quality?
Which image format is the most consistent at hitting a certain quality level?
Are there certain images that one format excels/struggles compressing at a quality level? Is there a pattern between them (smooth vs complex textures, having a lot of edges vs. few edges)?

In this case, having the ability for codec-compare to group by quality, then match groups by total file size, then pair images within those matched groups would be helpful at answering questions 2) and 3).
Hope this explains the scenario!

In this case, I'm interested into knowing a few things

Here is an example comparison. Consider there are two codecs encoding 101 images each at the quality closest to the overall size budget (not the case on the screenshot but let's say it is):

How to reproduce
git clone https://github.com/webmproject/codec-compare-gen.git
# Follow build instructions at https://github.com/webmproject/codec-compare-gen?tab=readme-ov-file#cmake-build

mkdir -p output
codec-compare-gen/build/ccgen \
--codec webp 420 4 \
--codec avif 420 6 \
--quality 75 \
--threads $(($(nproc) - 1)) \
--progress_file output/progress.csv \
--results_folder output/ \
--metric_binary_folder codec-compare-gen/third_party \
-- images

git clone https://github.com/webmproject/codec-compare.git
cp output/*.json codec-compare/assets/
cd codec-compare
echo '[["avif_420_6.json"],["webp_420_4.json"]]' > assets/demo_batches.json
npm i
npm run dev
# Go to http://localhost:5173/#matcher_psnr=off&matcher_ssim=off&metric_encoding_time=off&metric_decoding_time=off&metric_ssim=on&y_scale=lin&metrics=abs

We can see AVIF has the best overall quality
AVIF has a somewhat flatter point cloud so one could consider it is "the most consistent at hitting a certain quality level"*
One can look for outsiders in the point clouds to see if there are patterns compared to the images in the middle of the point cloud

So I would say the current framework implementation can help answering 1,2,3 for given quality settings.
Now if you are asking that for the whole quality range, the framework basically needs another dimension, and that is what you are requesting with the "grouping" feature, right? But then only one quality setting fits your given overall budget, so I probably missed something.

Each album image can be considerably different in what they feature. One image might have a lot of green, bushy trees, so it'll need relatively more bits to encode. Another image might be a macro shot of a flower against a blurry background, so it'll need relatively fewer bits.

*Indeed, but each image will also answer differently to distortion metrics, and this is here where the question "Which image format is the most consistent at hitting a certain quality level?" may not be well-defined.

Hope this explains the scenario!

It did, thank you for all the details! There are still some blurry areas though, see above.
Overall it feels like your request is more about advanced data science, so I am not so sure it would hit the same objective as the current user-friendly visual framework for comparing codecs.


[modify] Display of year and month

Coverage increased (+1.7%) to 80.343% when pulling 3f4bbccfeb0892ba13f07ab1cd722f97c75d0786 on fix/display_month_for_archive_list into 387418b93ed406f6446e1f05bce7e89f85fcb048 on master.

Coverage increased (+1.7%) to 80.343% when pulling 3f4bbccfeb0892ba13f07ab1cd722f97c75d0786 on fix/display_month_for_archive_list into 387418b93ed406f6446e1f05bce7e89f85fcb048 on master.

Coverage increased (+1.7%) to 80.343% when pulling 3f4bbccfeb0892ba13f07ab1cd722f97c75d0786 on fix/display_month_for_archive_list into 387418b93ed406f6446e1f05bce7e89f85fcb048 on master.

Coverage increased (+1.7%) to 80.343% when pulling 3f4bbccfeb0892ba13f07ab1cd722f97c75d0786 on fix/display_month_for_archive_list into 387418b93ed406f6446e1f05bce7e89f85fcb048 on master.

Coverage increased (+1.7%) to 80.343% when pulling 3f4bbccfeb0892ba13f07ab1cd722f97c75d0786 on fix/display_month_for_archive_list into 387418b93ed406f6446e1f05bce7e89f85fcb048 on master.


Enforce account RPC limits by account objects traversed

High Level Overview of Change
Modifies account RPCs to enforce limits by number of account objects traversed.
Context of Change
Previously, we limited account RPCs by the number of objects returned, not the number of objects traversed. This can get expensive when traversing accounts with a lot of owned objects. This PR modifies this behavior to enforce limits based on number of objects traversed. It also slightly changes how we do markers, including the marker startHint in the marker, similar to how account_objects works.
Type of Change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] Refactor (non-breaking change that only restructures code)
[ ] Tests (You added tests for code that already exists, or your new feature included in this PR)
[ ] Documentation Updates
[ ] Release

Test Plan
If helpful, please describe the tests that you ran to verify your changes and provide instructions so that others can reproduce.
This section may not be needed if your change includes thoroughly commented unit tests.
Some tests had to be modified, including increasing limits and changing markers.

Just want to point out this change actually changes the behavior of the RPCs from a client perspective. The call will return less objects than what is specified in limit. It could even return no objects, but a marker, in which case a user should continue paging. None of this is actually API breaking, as the server is not required to honor the limit. I think these changes are appropriate and beneficial, but just wanted to make sure everyone is aware. @mDuo13 chime in if you object to these changes.

@cjcobb23, I'm okay to wait on this PR until 1.8.3, its already running in reporting mode, which is where it is most important.

@natenichols I would like to ship it now, because we are trying to make it easy for others to run reporting mode. I think this will also benefit regular rippled.

@natenichols, the latest changes look good to me.
Thanks for adding the unit test, however I don't think it is testing as much as you hope for.   When I check code coverage I see that, even with the added test, none of the non-manual unit tests exercise the ltSIGNER_LIST branch of isOwnedByAccount().
I'll poke at a way to fix the new unit test so it exercises that branch.  But in the mean time, know that we haven't verified that part of the code.

Are the markers portable across servers, or not?
No, they are not portable across servers. There is not a scenarios where these changes could actually make markers portable, since now the marker can be the index of a non-RippleState SLE, which is not allowed pre 1.8.2.

If you do a request and get a marker back, but then your follow-up request using the marker goes to a different machine, will pagination continue smoothly?
Yes, as long as all servers in the same cluster are running 1.8.2. If there are different versions of rippled running in the same cluster, then no, because markers are not portable.