Get a error date time about "created_at"

curl --header "PRIVATE-TOKEN: xxxxx"  https://xxx.xxx.com/api/v4/projects/:ID/repository/commits
func (s *CommitsService) ListCommits(pid interface{}, opt *ListCommitsOptions, options
get different  "created_at"

Can you show some output and the error you get?

sorry
No error . I made a mistake and didn't set LoadLocation


4 Band Resistance Calculator

Prerequisites

[X] I am an Open Source Contributor
[X] I checked to make sure that this issue has not already been filed

Description
Overview
The Calculator will calculate the theoritical value of Resistance of a resistor using the 4 colour bands present on it.
Interface of Calculator
The UI of Calculator will have:
a) 4 drop down sections to select the colour of the bands.
b) Submit button
Functioning of Calulator
The calculator then will return the output resistance + tolerance value of the selected colour bands of a resistor with appropriate units inside a popup box.
Please assign this issue to me to work under the program of SocialWinterofCode'24
Thank you!!
Screenshots
No response
Code of Conduct

[X] I follow Contributing Guidelines of this project.

Go ahead!! @amansgith

@Rakesh9100 will there be any problem in points calculation by quine for SWOC if you do not assign me this issue and I create the pr for it?

Assigned @amansgith


Refactor: Create Single Image Encoding Funciton

Problem
Currently only a directory of images can be encoded. Need to refactor for both single and multiple image encoding.

Implemented with: 33d7e5582f5860225dd21d8f804fb63f15c457cf


Failover in case Backplane goes down

Right now if we configure two layers of cache (Runtime Caching and Redis -- for example). If the Redis layer goes down acting as a Backplane, CacheManager start throwing exceptions as it should do. I think it will be a nice feature if we can have some sort of failover mechanism in place for those cases

I have done further investigation and I have discovered another potential problem. Basically it comes down to guarantee the sync between caches. For example in the Add operation we first add the item to the lower cache e.g Redis but if the connection fails in the middle of that operation the item gets added but it cannot publish the message into the Backplane because Redis is not available thus no sync will occur for that item (if the connection is restored for the next Add operation,it can happen again, eventually the sync will be lost). I think the solution could be allowing dynamic configuration for the cache.
For example if the Redis part fails we could reuse the SystemRuntimeCache handle thus the cache will keep functioning out of sync until the Redis connection can be restored. The problem right now with this approach is that every SystemRuntimeCache gets a GUID attached and there is no clear way of reusing an active handle in a new CacheManager. The second approach will be some deregister function so we can remove any handle from a CacheManager. This will allow us to modify a two handle cache to function like one
I would gladly accept some feedback on these ideas

to be honest, I think it is pretty normal, that, in case Redis goes down, the state of multiple CacheManager instances (with a first level cache) might run out of sync at some point.
First of all, why would Redis go down? If you use a cluster or a good failover setup, this should actually never happen, or only very very rarely...
I implemented the backplate feature with that in mind and not to make it 100% bullet proof, which is pretty much impossible.
Yeah you could store things in one instance and sync it later. But could cause corrupted state of a cache entry (think about counters for example).
So, in those scenarios, the best thing you can do is throwing exceptions and re-issue the request, if CacheManager really cannot handle it because of some environment issue...
If you rely on Redis and Redis goes down for longer than just a restart, your system is pretty much screwed anyways ;)
Does that make sense? ;)

I agree with you that it will be better to make the Redis backend bulletproof rather than the Backplane implementation on CacheManager but it has some appeal to me the idea of changing layers dynamically. When I was talking about just using one instance to store things I never intended to re-sync those items (eventually they will expire by themselves or they will be rewritten by the clients) once the Redis gets rolling again. Do you agree on the part of using an active layer to seed another CacheManager instance (in the same machine of course)?

You mentioned counters, are you referring to the stats counters

No, I meant storing a counter/increment thing in Redis. If you increment a key, while Redis is down, and then try to sync them later from two or more instances, its impossible to figure out what the new/correct number might be...
Yeah sure, CacheManager could take another cache to copy over the values, although, what exactly would be the use case for that?
Maybe it would be easier to add an API to disable (and later enable) a cache layer, so that you can continue working if you want and you know what you are doing. And at some point you switch the distributed cache back on. The cache would work as if nothing has happend...
Although the local and distributed cache layer could be highly out of sync at that point...
I'm still not sure if that's really worth the effort implementing, considering the danger of what could happen if you somewhat rely on some kind of consistency?
Again, I'd like to hear if there is really a practical use case for those things ;)

I haven't gone into the implementation detail of the Update operation (I assume we are using this to increment the counter) but from the documentation I can remember that it is guaranteed that we will be working with the last version of the counter (don't know if this change would break something there).

If you increment a key, while Redis is down, and then try to sync them later from two or more instances

I never intent to sync the two layers when the connection to Redis gets restored. Eventually they will be in sync, either by expiration or rewriting from the client

Yeah sure, CacheManager could take another cache to copy over the values

I don't want to copy the values. I intent to use the instance of the localcache that we already have into creating the new CacheManager instance (this would only work for RuntimeCaching and Dictionary)

Maybe it would be easier to add an API to disable (and later enable) a cache layer

I agree with you that this will be the perfect solution, but I don't even know where to start to accomplish it. I suppose the BaseCacheManager class will be a good starting point. I think that creating a new CacheManager instance with an active localcache is an easier solution
In the matter of the uses cases, the only one I can think of right now is resilience against failures in the distributed cache layer. I think that the ability to dynamic reconfigure the cache will give the user a lot of flexibility in a lot of scenarios (maybe I am wrong :( ) .


关于如何发送自定义的通知内容

你好，我想请教一个问题，关于如何发送通知内容。
在响应客户端的查询时，比如QUERY_USER_PROFILES_REQUEST，是设置RequestHandlerResult.response直接响应当前用户的查询;
如果我想通知自己其他端在线客户端和相关用户时，比如UPDATE_USER_REQUEST，是设置RequestHandlerResult.notifications;
Notification只能设置TurmsRequest类型作为内容；
我如何返回自定义的内容？
比如在UPDATE_USER_REQUEST中，我想将用户完整的UserInfo当做通知内容发送给recipients？

Notification只能设置TurmsRequest类型作为内容

Yes, Notification is designed to accept TurmsRequest only because all notifications are triggered by an action. In Turms, TurmsRequest can be considered the action implicitly.

如何返回自定义的内容？

There is no official way to pass custom data to notification recipients because we suggest the client application developers let the clients accept the notifications, and perform custom business logic and CRUD data based on the notifications if they don't have a plan to modify the source code of Turms servers. The solution is quite flexible and adaptive.
But if you are sure that you want to modify the logic and the source code of Turms servers for your business, I can add a new protobuf field (e.g., repeated bytes extra_attributes) in TurmsNotification so that you can use it to pass any custom data.
If you need it, please comment so I can give a support plan to you.

谢谢，不用了，我使用了turms来二次开发，其他地方改动的比较多，这里我自己加了一个TurmsNotification中加了一个，和Data类似。

@JamesChenX  I plan to add a new protobuf field ( repeated bytes extra_attributes) in TurmsNotification,But I don't know how to use this extra_attributes when creating notify. Can you help me

@zhanchen18 Use the repeated Value custom_attributes = 15 field in proto models, which should be what you want.
For details, Request and Response Model


Leave pci address enumeration to qemu for SR-IOV device

This change is

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


Fix Python SDK

Fixes #87. A couple Python examples are included. This change will break the existing examples in yaml/go though, so those still need to be updated.

Changes made on other PRs. Thanks @rawdaGastan.


Too much issues with RN versions and guideline document

Install Google SDK followed the documentation is really hard. I think many guys here found its confused to set it up.

I tried with both RN 0.47 and 0.48.2 but got the same error:

Seems like RNGoogleSignin imported from NativeModules failed somewhere :\

In an effort to clean the issues up, this is being closed. Please open a new issue with a reproduction if you're still experiencing a problem.
This is probably caused by an incorrectly linked module.


Custom prompt theme in Linux TTY

I noticed that in .zprezto/modules/prompt/init.zsh, the shell checks if it is in a dumb terminal and turns any custom prompt off.  I understand the logic in this for a serial terminal type scenario, but why also apply this to the Linux TTY?  I believe this is what is going on in #927 and #754
Bypassing this, I have had no issues running my custom prompt in the TTY.  Would it be possible to add additional options to choose whether to either enable the custom theme on the TTY, or select a second theme to use on the TTY?
This worked for me:
.zpreztorc:
...
# Set the prompt theme to load.
# Setting it to 'random' loads a random theme.
# Auto set to 'off' on dumb terminals.
zstyle ':prezto:module:prompt' theme 'powerlinerds'
zstyle ':prezto:module:prompt-linux' theme 'clint'
...

modules/prompt/init.zsh:
# Load and execute the prompt theming system.
autoload -Uz promptinit && promptinit

# Load the prompt theme.
zstyle -a ':prezto:module:prompt' theme 'prompt_argv'
zstyle -a ':prezto:module:prompt-linux' theme 'prompt_linux_argv'

if [[ "$TERM" == (dumb|*bsd*) ]] || (( $#prompt_argv < 1 )); then
  prompt 'off'
elif [[ "$TERM" == "linux" ]];then
  prompt "$prompt_linux_argv[@]"
else
  prompt "$prompt_argv[@]"
fi
unset prompt_argv
unset prompt_linux_argv

Tested on Ubuntu 14.04.3 LTS with ZSH 5.0.2 from apt-get.

 If Linux TTY supports xterm-256color, UTF-8, etc., it should not identify as dumb.

The terminal shows up as "linux".  It's not an xterm.  I got to it from Ctrl+Alt+F1.

It's disabled on purpose. Link me to the list of capabilities of the LINUX terminal emulator, and when it got them; so, I can write a better check, or you write a better check and open a pull request.

ok, will do

It's disabled on purpose the most likely answer.

Also cf: #713

@indrajitr minimal is not the only simple theme available. That's your personal preference.

Agreed, just kept a reference of similar discussion here.


[Theme Request] Minaduki Shigure

Who/What do you want to be featured?

The last addition from NekoPara, Shigure
What do they look like?

What type of theme?

[X] Light Theme

Additional Information (Optional)

Pro: Will create a Cat-Girl harem for you.
Con: Is your little sister, by blood.


Fix typo opt names in bootstrap.sh

log "INFO: --cluster-ca or --api-server-endpoint is not defined, describing cluster..."

Fixes these two opts as it doesn't exist.

Thanks @ketozhang !


make List public or a way to merge QueryEnumerators

Couchbase Lite version : 1.4.0 (Android)
I was loading around 20k+ of rows into recyclerview and iterating over QueryEnumerator to make List of queryrow is very slow, so i checked the QueryEnumerator code and there is already List field, so is it possible to get that list direct and also merging different QueryEnumerators ?
Because seriously queryrow list is already there so why create new list by iterating over QueryEnumerator.

Hi @nishantpardamwar
API change is not only for Android platform, also other platforms. Not easy for us.
Could you compile CBL Android by yourself with customizing QueryEnumerator?


High network usage?

Hi again,
Wondering if there was a change from 0.6.2 to 0.7 that led to an increase in network utilization? I actually thought there was no network needed for the xml production but when I checked my system usage there was a fairly high upload happening. Is this apart of the consolidation step? It would be great to detail this info as well as the possibility to allow this run offline.
But now I'm realizing this could be local network activity of course :upside_down_face:

Hello @jacksongoode !
Consolidation of headers is enabled by default (this is helpful for accuracy/quality).
I think 0.7.0 by default is using https://cloud.science-miner.com/glutton which was more reliable than CrossRef web API. This explains the network usage.
However this online demo is not really used in a courteous manner and now frequently overloaded so it might possibly explain your new pain for tests.
About running offline, this is documented. Simply add the consolidation parameters to 0 when calling the service as described (or if you use the command line, use the corresponding documented arguments).
Good luck !!

Hello @jacksongoode !
Consolidation of headers is enabled by default (this is helpful for accuracy/quality).
I think 0.7.0 by default is using https://cloud.science-miner.com/glutton which was more reliable than CrossRef web API. This explains the network usage.
However this online demo is not really used in a courteous manner and now frequently overloaded so it might possibly explain your new pain for tests.
About running offline, this is documented. Simply add the consolidation parameters to 0 when calling the service as described (or if you use the command line, use the corresponding documented arguments).
Good luck !!


Fixes Issue#1488

Now if a method block only adds constraints, testcases, or assertion (but not codelangs) i.e. no new executable code, then warning 49 would be suppressed.

There are some print statements in the testcases that need to be removed (print statements in testcases clutter the build transcript)


Materials and/or textures seem to be missing

I cloned the repository using git lfs and it seems like I have all the files, however when I launch any scene, I don't see any materials and the UI looks broken. Any help much appreciated, I'd love to contribute to this project!

You can see that the palm trees also don't have the materials showing up. Am I doing something wrong?

Are you able to start the sim?

same problem..

I cloned the repo and opened it with Unity version 2017.4.15f1. These issues seem to be fixed.
However, in your image, it seems like the source image somehow got disconnected. To fix this:
In the Inspector window (along the right hand side), click the little circle to the right of the box next to "Source Image". This should let you choose an image to put here.
The 1_BaseImageReference should be "drivingUI_Reference".
The 1_BaseImage should be "drivingUI_Base"


Pass Azimuth update reason to the Infra role

Pass Azimuth update reason to the Infra role to ensure rebuilds on patched appliances.

We should wait for the release of the Terraform collection that includes this and bump it in this PR.

Yeah +1 what mattp said here.


backend

@CodiumAI-Agent /review

@CodiumAI-Agent /review

PR Review

 ⏱ Estimated effort to review [1-5]
5, because the PR contains a large number of files with significant changes across multiple directories. Reviewing this PR requires a thorough understanding of the project structure, dependencies, and the impact of the changes on the overall functionality. Additionally, the PR includes changes to critical functionalities such as request parsing, response handling, and middleware configuration which require careful examination to ensure compatibility and stability.

 🧪 Relevant tests
No

 🔍 Possible issues

Possible Bug: The changes in Backend/node_modules/body-parser/lib/types/urlencoded.js might affect how URL-encoded bodies are parsed. This could potentially introduce parsing errors or inconsistencies if not properly tested with various payloads.

Performance Concern: The addition of multiple middleware and utility functions in Backend/node_modules/express/lib/router/index.js and Backend/node_modules/express/lib/application.js could impact the performance of the application. It's important to assess the performance implications of these changes, especially under high load.

Dependency Management: The PR includes changes to several dependencies and their configurations. It's crucial to ensure that these changes do not introduce compatibility issues with other parts of the application or with the Node.js runtime version being used.
 🔒 Security concerns
No

 Code feedback:
relevant fileBackend/node_modules/body-parser/lib/types/urlencoded.js
suggestion

Consider adding comprehensive tests for the URL-encoded body parser to ensure that the parser correctly handles various edge cases and payloads. This is crucial for preventing potential parsing errors that could lead to application crashes or incorrect request handling. [important]

relevant linefunction urlencoded (options) {
relevant fileBackend/node_modules/express/lib/router/index.js
suggestion

Review the changes made to the router configuration and middleware handling. Ensure that these changes do not unintentionally alter the routing logic or middleware execution order, as this could impact the application's behavior and security. [important]

relevant linevar express = require('express');
relevant fileBackend/node_modules/express/lib/application.js
suggestion

Validate the modifications in the application setup, particularly those related to middleware configurations and error handling. It's important to ensure that error handling remains robust and that middleware configurations are correctly applied to prevent security vulnerabilities. [important]

relevant lineapp.use(express.json());
relevant fileBackend/node_modules/express/lib/response.js
suggestion

Assess the changes in response handling methods to ensure they correctly set headers, status codes, and body content. Incorrect handling of responses could lead to security issues like header injection or information disclosure. [important]

relevant lineres.status = function status(code) {

 ✨ Review tool usage guide:
Overview:
The review tool scans the PR code changes, and generates a PR review which includes several types of feedbacks, such as possible PR issues, security threats and relevant test in the PR. More feedbacks can be added by configuring the tool.
The tool can be triggered automatically every time a new PR is opened, or can be invoked manually by commenting on any PR.

When commenting, to edit configurations related to the review tool (pr_reviewer section), use the following template:

/review --pr_reviewer.some_config1=... --pr_reviewer.some_config2=...

With a configuration file, use the following template:

[pr_reviewer]
some_config1=...
some_config2=...

See the review usage page for a comprehensive guide on using this tool.

Persistent review updated to latest commit https://github.com/kalviumcommunity/S53_Shubham_Kumar_Chaurasia_Fusion_Drink/commit/c51a74a2b15a852bac4f9b6199f0c1da92f4ea80


Python3

Added support for pythons 2 and 3

Have you tried running this on an IP Studio machine to check it all looks okay on there @jamesba?

For the benefit of those that may come after, could you please outline what tooling you've used to do this, and a rough outline of the changes you needed to make please?

Note to self - tested this with nmos-joint-ri. Worked okay.

I did this primarily by running the tests in python3 and seeing what exceptions where thrown.
Most places where syntax differs significantly from python2 the six library was used to provide a stable non-version specific interface.

When I build the deb for this I get this error from lintian https://lintian.debian.org/tags/build-depends-on-1-revision.html
You seem to be requiring python3-setuptools >=20.7.0-1, is there any reason it can't just be >=20.7.0?

Tested on an ipstudio machine - looks good as far as I can tell there


update "README.md" for development beginners

Hi Mirco.
When I ran the "How to use" code, I got an error.
ReferenceError: myData is not defined

Beginners may not be able to solve the error.
I would like to add a link to the complete example.

Coverage remained the same at 100.0% when pulling 6f619615302e9eac025d117ae5024c7809e48ea0 on tetsuyaohira:feature/readmechange into 53466bce5f5ac4033dbf4098d1a62288984d60f8 on zemirco:master.

thanks!

Thank you for accepting!
It's my first pull request!!!

Nice! Welcome to the world of opensource contribution!


Groups with space in name are invalid

Environment:

Currently running 20.1.3
System set-up with auth from both 'Local Database' and 'AD LDAP + TOTP' server connecting to AD
Both AD and Firewall have 'VPN Users' group; LDAP filters memberOf to 'VPN Users' group
Users created previously that are part of the 'VPN Users' group remain so

Note: AD 'VPN Users' group used to be called 'VPN Access' -- this was renamed to 'VPN Users' and LDAP filter updated; OPNsense group has always been called 'VPN Users'

To Reproduce:

'Import' a new user from LDAP

After adding, user does not have 'VPN Users' membership in OPNsense

Edit user to add 'VPN Users' membership
After some period of time (< 30 mins) the user no longer shows as a member of 'VPN Users'
This entry is shown in the system logs:

opnsense: /system_usermanager.php: The command '/usr/sbin/pw 'groupadd' 'VPN Users' -g '2000' -M '2001,2007,2006,2005,2009,2008,2010,2012'' returned exit code '65', the output was 'pw: invalid character ` ' at position 3 in userid/group name'

Renaming the group to VPN appears to have worked around the issue -- I'm not sure if the AD LDAP linking is related or if this is just spaces in group names are not handled well

groups with spaces aren't allowed, when trying to add one in the UI it will signal an error like:

The group was created a long time ago -- although odd that it worked as long as it did.
Nothing to be done then, other than possibly correcting old group names?


[YUNIKORN-1293] Revert the customized redirects

Since https://issues.apache.org/jira/browse/SPARK-40187 now has been solved, there is no reference to the 1.0 version doc. This customized redirect is no longer needed.

@wilfred-s , @craigcondit
could u pls help to review this? this reverts the unneeded changes


Cannot extract .wld files

Description

Go to your backup folder and try to copy files from the backup folder to the main "Worlds" folder

[First Step]
[Second Step]
[And so on...]

Expected behavior

I think that the file should be extracted from the zipped folder and fully copied to the Worlds folder.
Actual behavior

I get the error posted above.
Reproduction frequency

100% of the time
Versions

currently, I am using tModLoader v0.11 Beta 5
Mods

(I don't think that the mods matter)
Elements Awoken Music
Fargo's Mutant Mod
Magic Storage
OmniSwing
VeinMiner
Recipe Browser
Calamity Mod Extra Music
Cheat Sheet
Calamity Mod Music
Calamity Mod (No Calamity Music)
Fargo's Soul Mod
Elements Awoken
Boss Checklist
AFK's PETS and more
Additional Information

Yesterday, when I last played, I hard shut down my computer without fully exiting Terraria, I exited and saved my world, but I stopped my computer when Terraria was in the main menu.
2019-06-12-Modpack_Neat.zip

I'm not sure about this issue, you're a bit vague. What exactly are you trying to extract? Is this about a bug in tModLoader?

I think this is an actual bug. I think the issue might be with the zip file. I can extract the contents fine with 7zip, but with the windows explorer unzip I too get an error:

Players also suffer from this problem. Log backups extract without issue.

We used BZIP compression, but explorer only supports DEFLATE for some reason....

So how would I extract files using BZIP compression?

Thank you!


python310Packages.klein: don't test on multiple cores

Tests time out otherwise. See e.g. https://hydra.nixos.org/build/211736636.
Description of changes

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

1 package failed to build:

python311Packages.buildbot-full

5 packages built:

buildbot-full (python310Packages.buildbot-full)
python310Packages.buildbot-plugins.badges
python310Packages.klein
python311Packages.buildbot-plugins.badges
python311Packages.klein


Fails to build @cloudflare/wrangler@beta (due to NPM workspaces?)

NPM now has a "workspace" concept, where multiple packages reside in the same repository, and share the same package-lock.json. Wrangler2 (the rewrite that is known by NPM as @cloudflare/wrangler@beta, hosted in a different repository from the stable version) fails to build, and.. maybe it's because it's using a workspace?
Here's a couple of attempts to build wrangler2 using npmlock2nix:
$ nix build .#theSubDir
error: [npmlock2nix] A valid dependency consists of at least the resolved and integrity field. Missing one or both of them for `@ampproject/remapping`. The object I got looks like this: {"requires":{"@jridgewell/trace-mapping":"^0.2.2","sourcemap-codec":"1.4.8"},"version":"2.0.2"}
(use '--show-trace' to show detailed location information)

$ nix build .#hybrid
error: [npmlock2nix] A valid dependency consists of at least the resolved and integrity field. Missing one or both of them for `@ampproject/remapping`. The object I got looks like this: {"requires":{"@jridgewell/trace-mapping":"^0.2.2","sourcemap-codec":"1.4.8"},"version":"2.0.2"}
(use '--show-trace' to show detailed location information)

$ nix build .#theRoot
error: [npmlock2nix] A valid dependency consists of at least the resolved and integrity field. Missing one or both of them for `@ampproject/remapping`. The object I got looks like this: {"requires":{"@jridgewell/trace-mapping":"^0.2.2","sourcemap-codec":"1.4.8"},"version":"2.0.2"}
(use '--show-trace' to show detailed location information)

flake.nix:
{
  description = "Wrangler2";

  inputs = {
    nixpkgs.url = github:nixos/nixpkgs;
    flake-utils.url = github:numtide/flake-utils;
    npmlock2nix = {
      url = github:nix-community/npmlock2nix;
      flake = false;
    };
    wrangler2 = {
      # this is tag<EMAIL_ADDRESS>which is rejected by Nix likely due to the at sign
      url = "github:cloudflare/wrangler2/3789b164ec5f56e59545bb7059e20e8543e0d95b";
      flake = false;
    };
  };

  outputs = { self, nixpkgs, flake-utils, ... }@inputs:
    flake-utils.lib.eachDefaultSystem (system:
      let
        pkgs = import nixpkgs {
          system = "x86_64-linux";
        };
        npmlock2nix = import inputs.npmlock2nix.outPath {
          pkgs = pkgs;
        };
      in
      {

        packages.theRoot = npmlock2nix.build {
          src = inputs.wrangler2.outPath;
          buildCommands = [ "cd packages/wrangler && npm run build" ];
          installPhase = "cp -r dist $out";
        };

        packages.hybrid = npmlock2nix.build {
          src = inputs.wrangler2.outPath;
          packageJson = "${inputs.wrangler2.outPath}/packages/wrangler/package.json";
          packageLockJson = "${inputs.wrangler2.outPath}/package-lock.json";
          buildCommands = [ "cd packages/wrangler && npm run build" ];
          installPhase = "cp -r dist $out";
        };

        packages.theSubDir = npmlock2nix.build {
          src = "${inputs.wrangler2.outPath}/packages/wrangler";
          packageJson = "${inputs.wrangler2.outPath}/packages/wrangler/package.json";
          packageLockJson = "${inputs.wrangler2.outPath}/package-lock.json";
          buildCommands = [ "npm run build" ];
          installPhase = "cp -r dist $out";
        };
      }
    );
}

Oh the "integrity" field issue might be due to changes in npm? See https://github.com/svanderburg/node2nix/issues/238#issuecomment-942838431

another example in the wild: portiaui/package-lock.json
{
  "name": "portia-ui",
  "version": "2.0.0-alpha",
  "lockfileVersion": 1,
  "requires": true,
  "dependencies": {

    "npm": {

      "dependencies": {

        "async-some": {
          "version": "1.0.2",
          "integrity": "sha1-TYqBYg1ZWHkbW5j4AtMgd3bpVQk=",
          "dev": true,
          "requires": {
            "dezalgo": "^1.0.2"
          }
        },

error: [npmlock2nix] A valid dependency consists of at least the resolved and integrity field. Missing one or both of them for `async-some`. The object I got looks like this: {"dev":true,"integrity":"sha1-TYqBYg1ZWHkbW5j4AtMgd3bpVQk=","requires":{"dezalgo":"^1.0.2"},"version":"1.0.2"}


rc4 Contract issues

Context
1.10.0 rc 4
Summary
The Redistribution contract seems to be updated in rc4, but the ABI is not (yet) available at goerli.etherscan.io.?
And my first Claim transaction logged the following:
"time"="2022-11-11 12:20:07.983724" "level"="error" "logger"="node/storageincentives" "msg"="claim" "error"="expired batches exist: execution reverted"

According to pkg/chain/chain.go, the postage stamp contract address has not changed, but that contract does not seem to have an expiredBatchesExist method which is being called before a claim transaction is even submitted.
Expected behavior
I thought rc4 would continue to play the Schelling Game successfully.
Actual behavior
Fails before submitting the claim transaction.
Steps to reproduce
Fire up a node that thinks it can play the storage incentives Schelling game.  It will commit, reveal, and then fail before claiming.
Possible solution
Update pkg/chain/chain.go for the new PostageStamp contract and upload the ABI and source to be visible at goerli.etherscan.io.

From rc4's pkg/chain/chain.go
Redistribution contract: https://goerli.etherscan.io/address/0x7d5ff32e744340ab26873d05e019a0d27fe4716f
PostageStamp contract: https://goerli.etherscan.io/address/0x7aac0f092f7b961145900839ed6d54b1980f200c

this issue will be resolved by changing contract addresses and abi in bee, if we are ready to do it. @mrekucci @notanatol , maybe if Esad is ok with changing it.


Move dispatcher response creation to a new ResponseFactory

This moves all of the response creation stuff from the dispatcher and adds some extra helpful functions to a new ResponseFactory class.
One can get an instance of it by doing $app->make(ResponseFactoryInterface::class)

This improves #1644 cookie functionality

This has conflicts now. I'm not familiar enough with the code in question – can you remake this pull request?


Proof the strings in en.ts and create specific rules how to generate key names

This issue deals with two tasks:

proof the strings in en.ts:

this was the original issue;

define how the key names are generated:

for the specific rules, see this comment below.

Original issue description:
In liturgy, the Church usually translate the first name (sometimes even the surname) into vernacular, e.g. in English, we use Mary instead of Maria or John instead of Giovanni.
Now in romcal in en.js, some of the keys (those not in the general nor any of the particular calendars of countries with English as official language; in general: those not in any official liturgical book written in English), we use foreign (non-English) names.
I know that some of those names are not translatable or they are used untranslated—those might need to be left untranslated. But I think that most of those names should be localised.

Actually, I think we might create a list of first names of saints/blesseds used in romcal and translate that separately from saints/blesseds. When a person is defined, we would then use a name from the list of names.
@pejulian, @emagnier, what do you think?

@pejulian, @emagnier, I am about to tend to this issue after I finish the Latin localisation.
My plan is to deal with multiple issues with the English locale(s) and the US particular calendar (which with serve as the base for the en.ts locale) and all the particular calendars of the British Isles (Enland & Wales, Irish) calendars (which if differ in terms of celebration names from en.ts, the differences will be put into either en-GB.ts or en-IE.ts).
These are the tasks I want to deal with in particular:

fix 26+ localisation issues which I have found since merging #202 (duplicates, typos, missing titles, etc; I am quite sure I’ll find some more);
check celebration names (l10n), as well as celebration definitions (in src/calendars/*.ts) of the following particular calendars:

US;
UK (England & Wales, Scotland, Northern Ireland);
Ireland.

Now, @emagnier recently said I he would like to keep the key names constant (i.e. once set, they won’t change) and also that the key names should be stripped down to bare minimum, therefore I’d like to do that to, but I need some feedback on this (i.e. some kind of approval that I may proceed).
My proposal is as follows:

from the key names, remove canonisation level (saint/blessed);
from the key names, remove all the titles (like priest or religious) except for the titles necessary to make a distinction between two or more persons:

e.g. we venerate St Kieran, bishop, who is sometimes called Ciaran, and we also venerate St Ciaran, abbot, therefore the keys of both saints would retain the titles: ciaranAbbot and kieranBishop:
note that not all titles would be kept, but only one that is the most important, i.e. titles like pope, bishop, priest, abbot, or abbess would be kept if one of those titles would be accompanied with one the following: religious, virgin, religious, missionary; e.g. saintGabrieltaurinDufresseBishopAndMartyr would become gabrieltaurinDufresseBishop if we need to differentiate him from another person;

we would keep AndCompanions as sometimes we celebrate a saint separately and sometimes collectively with their companions;
untill #201 is implemented, we would keep PatronOfCountry titles in the key names (when #201 is implemented, we would either delete these keys or create a new key without the PatronOfCountry suffix);
in English locales (src/locales/en*.ts), we would write the canonisation level (unless at the beginning) and all the titles (unless Patroness is used for Our Lady) with lowercase letters, i.e. priest instead of Priest;
we would remove all unused keys (i.e. blessedIstvanSandorMartyr, shroveMonday, and shroveTuesday);
we would localise all first names into English unless their original form is in use in English.

During this work, I’ll create a table with first names localised into all supported languages (something like this, but more thorough). As the table will be quite big (wide and long), I think that Google Sheets will be a better tool for this that a Markdown table in the romcal Wiki. I’ll be useful for l10n. For now, I’ll only use those names which we already have in the codebase and thus:

I won’t add new names; and
if a name is currently not localised in a particular/non-English locale, I won’t look it up online.

However, when/while #208 would be implemented, it would be filled with all the names from the Martyrology (the Latin names), as well as their localised counterparts.

from the key names, remove canonisation level (saint/blessed; #174);

👍 yes

from the key names, remove all the titles (like priest or religious) except for the titles necessary to make a distinction between two or more persons:

😕 I'm not sure of that. On my side projects depending on Romcal, I always find useful to have theses titles when I have to deal with the keys. Except for titles that can change or be added in the futur (like patron, doctors...) I will recommend instead to keep them.

we would keep AndCompanions as sometimes we celebrate a saint separately and sometimes collectively with their companions;
untill #201 is implemented, we would keep PatronOfCountry titles in the key names (when #201 is implemented, we would either delete these keys or create a new key without the PatronOfCountry suffix);
in English locales (src/locales/en*.ts), we would write the canonisation level (unless at the beginning) and all the titles (unless Patroness is used for Our Lady) with lowercase letters, i.e. priest instead of Priest;
we would remove all unused keys (i.e. blessedIstvanSandorMartyr, shroveMonday, and shroveTuesday);
we would localise all first names into English unless their original form is in use in English.

👍 ok

On a side note, what do you think to use kebab-case for the keys (instead of camelCase). On some of my side projects using Romcal, I've already converted all the saint/blessed/celebrations keys to kebab-case and found them a lot more readable. I think the camelCase usage is directly coming from JavaScript (variable names), but here it should be agnostic from the language, and a bit more human readable. I still have the plan to move the current calendars from js/json to something more modular and human readable (like yaml) to simplify contributions and editions for everyone. And using kebab-case for keys could be an area of improvement.
All constant keys (colors, ranks, seasons...) should remain in UPPER_UNDERSCORE_CASE. Because this convention is quite common for constants in all coding languages.
As long as the new TypeScript codebase is not released in production, it is the time to work and improve the keys. After that, we will avoid as much as possible to modify them.

:confused: I'm not sure of that. On my side projects depending on Romcal, I always find useful to have theses titles when I have to deal with the keys. Except for titles that can change or be added in the futur (like patron, doctors...) I will recommend instead to keep them.

How do you find these titles within the key name usuful? Well, I think that we might (after fixing #154) provide additional object for each celebration with the celebration metadata (like: start_date since it is celebrated, end_date until when it is celebrated, titles array for the list of the titles if any, etc) and this might be (from my point of view) much more useful than relying on the key name what titles are used.

On a side note, what do you think to use kebab-case for the keys (instead of camelCase). On some of my side projects using Romcal, I've already converted all the saint/blessed/celebrations keys to kebab-case and found them a lot more readable. I think the camelCase usage is directly coming from JavaScript (variable names), but here it should be agnostic from the language, and a bit more human readable. I still have the plan to move the current calendars from js/json to something more modular and human readable (like yaml) to simplify contributions and editions for everyone. And using kebab-case for keys could be an area of improvement.

To be honest, I have no preference on this field, though I personally prefer to use either camelCase or snake_case. And I have no problems with the readability of any type of the cases (even camelCase is readable to me). Therefore, as you are the romcal programmer, I leave the decision to you (and probably @pejulian).

As long as the new TypeScript codebase is not released in production, it is the time to work and improve the keys. After that, we will avoid as much as possible to modify them.

That is why I want to deal with this issue as have pointed out in this comment.

@emagnier, I have two suggestions about the French locale which are somewhat connected with this issue. I’d to fix them as well.

Change all titles to lowercase:

I have found this French Ordo 2020, which looks to be the latest one. In this Ordo, all titles are written in lowercase. Of cource, the titles can be written with uppercase first letter (just like in English, Latin or Slovak), but they are not proper names, therefore I suggest to change them to lowercase.

Change the value of saintThereseOfTheChildJesusVirginSecondaryPatronessOfFrance to Sainte Thérèse de l’Enfant-Jésus, Vierge, Docteur de l’Église et Seconde Patronne de la France (✝ 1897):

The original value (Sainte Thérèse de l’Enfant-Jésus, Docteur de l’Église, Seconde Patronne de la France (✝ 1897)) is missing the virgin (vierge) title and an et (it might not be required, but I think that there should be and/et before the final title of a person). Of course, if you agree to change the uppercase first letters of the titles to lowercase (see the first suggestion), those changes would apply here too.

@emagnier, while looking deeper at English locales (namely: the US and UK locales), I have found out that Americans use Christmas Season, while the British use Christmastide. Now I’d like to know I can simply redefine christmastide.season as shown below, however, I am not sure if other keys under christmastide (namely day, octave, and sunday) will overwritten in the process (i.e. removed) or if they still be sourced from en.ts if they are not defined in en-GB.ts.
christmastide: {
    season: 'Christmastide',
}

Thanks in advance!

Another thing: Should we not change the case of localised colour names to lowercase? Currently, we have for example RED: 'Red', I suggest to use RED: 'red', as the colour names are not proper names. What do you think?

After some thinking, I think that we should think about the celebration names (as we currently use the keys) should be in title case (not sentence case, as I have thought until now), because they will be used usually as the titles.
It might be a good idea, though, to implement a romcal general option, using which the user might be able to choose if the celebration name should be in title case (specific to the locale, because e.g. in Slovak, the title case is same as the sentence case) or sentence case. For now, the casing will be hard-coded (as it always was).

Therefore, the titles will be written with uppercase first letter in English locales. @emagnier, you need to think about the French locales, because I can’t really speak French. :smiley:
And same is true about other words in the English locales: Companions, Basilicas, Principal/Secondari/Celestial Patron/Patroness.

How do you find these titles within the key name usuful?

For all the reasons I already gave 😄 . For several projects like mine, we only deal with the keys to build something on top of romcal (like building a tool to generate the content of monastic offices), and do not especially use other available metadata.

To be honest, I have no preference on this field, though I personally prefer to use either camelCase or snake_case

This is something that bothers me since a long time 😄 . The next major release might be a good window to do it.
I'll keep the snake_case convention (in uppercase) for the constant keys, and might propose to rename all date-item or celebration keys to snake-case (after the big work on key names is done).

I have two suggestions about the French locale which are somewhat connected with this issue. I’d to fix them as well: Change all titles to lowercase.

👍 yes for the first letter and all proper names. And I might have a better source than this ordo you found. I can share you the index table of the French Sanctoral lectionary, so you will have the official list of all common saint/blessed people in French and French-speaking countries (with titles, date of death...). This lectionary has been edited in 2016, so the list is quite recent.

I have found out that Americans use Christmas Season, while the British use Christmastide.

I'm not sure where you found that, we often see both in same documents. However in liturgical books in English, I've often seen the name of "Christmas time" and "Easter time" ("time" instead of "season"). Maybe that could be a consensus?
Also are you speaking about renaming the key or the localized name?

Should we not change the case of localised colour names to lowercase?

Yes 👍

your last comment

I'm not sure to understand entirely your comment. I know that  capitalizing more words on titles (except the articles) is a common convention, at least in English and French. But we could simply capitalize only the first letter and the proper name only (since it's another common practice), for any celebration/saint/blessed name (with their titles in the same sentence).

How do you find these titles within the key name usuful?

For all the reasons I already gave smile . For several projects like mine, we only deal with the keys to build something on top of romcal (like building a tool to generate the content of monastic offices), and do not especially use other available metadata.

I see that you don’t (wan to) use other available metadata, but I can’t see the why. If I were you and wanted to accomplish want you are after, I certainly would at least try to use all the available metadata. Anyway, from my point of view, romcal still misses great amount of metadata. :smiley:

This is something that bothers me since a long time smile . The next major release might be a good window to do it.
I'll keep the snake_case convention (in uppercase) for the constant keys, and might propose to rename all date-item or celebration keys to snake-case (after the big work on key names is done).

Well, then we will convert the keys into snake-case. :smiley:

+1 yes for the first letter and all proper names. And I might have a better source than this ordo you found. I can share you the index table of the French Sanctoral lectionary, so you will have the official list of all common saint/blessed people in French and French-speaking countries (with titles, date of death...). This lectionary has been edited in 2016, so the list is quite recent.

When will you give me access the the index table of the French Sanctoral lectionary? I think you mean the General Calendar with all the persons from the French Proper, which is usually at the beginning of the Roman Missal and the Liturgy of the Hours. You can do that in your next comment (as an attachment). :smiley:

I have found out that Americans use Christmas Season, while the British use Christmastide.

I'm not sure where you found that, we often see both in same documents. However in liturgical books in English, I've often seen the name of "Christmas time" and "Easter time" ("time" instead of "season"). Maybe that could be a consensus?
Also are you speaking about renaming the key or the localized name?

I own The Divine Office (the British, three-volume version of the Liturgy of the Hours) published by Collins from 2006 and there I can find it. However, I might be wrong the Christmastide/Eastertide because of the latest English edition (and translation) of the Roman Missal, which might have changed their names used in the official books in the UK. The Liturgy Office of England and Wales is using Easter Season, Christmas Season (and weekday instead of feria), but Lent (or Season of Lent) instead of the US Lenten Season. Yes, I am nitpicking, but I wanna be as thorough as possible with the limited resources I/we have. :smiley:

your last comment

I'm not sure to understand entirely your comment. I know that capitalizing more words on titles (except the articles) is a common convention, at least in English and French. But we could simply capitalize only the first letter and the proper name only (since it's another common practice), for any celebration/saint/blessed name (with their titles in the same sentence).

I can’t comment on the French usage, but in English, there are two (main) title cases used for headings/titles:

sentence case:

this is the one where you capitalise the first letter of the first word and the proper names only;

(true) title case:

generally, there are many rules and each style guides (e.g. Chicago Manual of Style) have there own preferences;
in the US, I’ve seen most articles/books use First Letter case (i.e. first letter of all words are capitalised), but it greatly depends on the style guide used;
in the UK, I’ve seen most articles/books use the (true) title case like it is defined in the Chicago Manual of Style, but there are differences (some capitalise all words that have four or more letters, some all nouns, adjectives, pronouns, adberbs, numbers). Again, it greatly depends on the style guide used.

(Just a sidenote: In Slovak, we use sentence case only for all titles.)
Now, the celebration names are mostly used as titles, but that depends on the usage and the title case (version) used.
For example, see the US Liturgical Calendar 2020 or Liturgical Calendar 2021. There you can find this: Saints Joachim and Anne, Parents of the Blessed Virgin Mary, while the British prefer Ss Joachim and Ann, parents of the Blessed Virgin Mary. For now, I don’t want to change all the keys for en-GB.ts locale just because of the casing (it might be a good idea to provide romcal global settings for the casing [sentence_case or title_case] and for the canonisation level format [short or full] in the future), therefore I’d like to use one type of case per locale (not counting the regional locales).
Is that more clear now?

Key name generation for personal celebrations: I think you will agree with this, but I want it to be confirmed by you before I make the changes:

The key name is composed of the following:

for celebration of events:

usually the full name of the celebration is included, however it should be shortened somewhat (like corpusChristi for the Most Holy Body and Blood of Christ or heartOfJesus for the Most Sacred Heart of Jesus);

for personal celebrations:

not included:

canonisation level;
most of the titles;

included:

first names, middle names, last names, patronyms, places of origin/work (e.g. of Cordoba):

even if the person is venerated without a last name or patronym or place of origin, but they have one in use otherwise, the key name will include it (e.g. St Anselm → anselmOfCanterburyBishop);

in case of religious persons, usually the religious name and their last names only are used;
only one title is included, one of the following (first one from the list below is used; for Saint Joseph, we always use theWorker or Spouse respectively):

apostle;
evangelist;
pope;
bishop;
priest;
deacon;
abbot;
religious;
hermit;
virgin;
doctor of the Church;
archangel;
martyr;
missionary;
prophet;
confessor.

Perfect 👍

@emagnier, what would you say if I suggested to change easter key name to easterSunday in celebrations? I think easter is quite ambiguous key name for the First Sunday of Easter (full celebration name in English is Easter Sunday of the Resurrection of the Lord). If you agree, I’d change it. AFAIK, it is only used in the l10n files and src/lib/Celebrations.ts.

@emagnier, you want to change the key names format from camelCase to kebab-case, therefore we need to quote all key names (see this), right? As I want to make it right, I need to know this. Thanks. :smiley:

Another question: if the celebration name contains a weekday name (like ashWednesday or divineMercySunday), could/should we reverse the word order in the key name (like wednesdayAsh or sundayDivineMercy)?

what would you say if I suggested to change easter key name to easterSunday

On a first through, I was not very enthusiast to make this change, especially that this celebration is the more important Christian celebration, so everyone knows what Easter is (I hope!). However I can note that a few other celebrations are written with the same pattern: palmSunday, trinitySunday, pentecostSunday. So I agree to change it to easterSunday.

could/should we reverse the word order in the key name (like wednesdayAsh or sundayDivineMercy)?

No. And I think it changes the meaning with this reversed order.

I personally prefer to use either camelCase or snake_case

you want to change the key names format from camelCase to kebab-case, therefore we need to quote all key names right?

After several days of thinking, I think I really prefer your suggestion to snake_case. It's even more readable than kebab-case, and I notice that a few other applications are also following this convention, like Firefox (in the about:config page)
And you are completely right, if we use kebab-case we will have to add quotes everywhere, while this is not necessary with snake_case. So let's go for snake_case (all lowercase), and thank you for your feedback about that!

And also in the tests, e.g. expect(Dates.allSaints(i).date()).toEqual(1); → expect(Dates.'all-saints'(i).date()).toEqual(1);

It only concerns keys (which are data), not JavaScript methods.

A partially connected proposal: key names for celebrations of Our Lady (incl Mary, the Holy Mother of God) would start with ourLady, which also replaces Mary or Blessed Virgin Mary if it is part of the celebration name (e.g. maryMotherOfGod → ourLadyMotherOfGod).  This way all keys of Her celebrations would be next to each other. I would even go futher and change assumption to ourLadyAssumption and also the (personal) celebrations of Jesus (like ascension, but not holyFamily) to have a prefix jesus (e.g. jesusAscension.

I'm not very up for that. I still believe that a key should reflect its liturgical day name. We never say "our Lady of Assumption" when it's about August 15 (and the same thing with the other examples). Furthermore it will be ugly for developers dealing with these keys in their code/apps.
If we need a convenient way to sort / group keys by criteria, it's another story.
To continue on this topic, I don't really understand what was the motivations to change the ordinal numbers in weekday keys to their worded equivalent (3rdSundayofEaster -> thirdSundayofEaster). Because of that, keys are becoming less readable. Especially with keys like: wednesdayOfTheTwentySeventhWeekOfOrdinaryTime instead of wednesdayOfThe27thWeekOfOrdinaryTime.

Okay. I either agree with you or don’t mind your (counter-)proposals.
Just a small note on sundayTrinity, wednesdayAsh and ourLady*: the reason behind this proposal is to group the celebration keys together. You said, We never say "our Lady of Assumption", which was not exactly what I have suggested. I suggested to name the key of Assumption of the Blessed Virgin Mary as ourLadyAssumption, which should not be regarded as a phrase (just like your feriaCycle vs my ferialCycle).

To continue on this topic, I don't really understand what was the motivations to change the ordinal numbers in weekday keys to their worded equivalent (3rdSundayofEaster -> thirdSundayofEaster). Because of that, keys are becoming less readable. Especially with keys like: wednesdayOfTheTwentySeventhWeekOfOrdinaryTime instead of wednesdayOfThe27thWeekOfOrdinaryTime.

I agree with you. Since then my opinion changed on this. Now I would suggest to use something like this: ordinaryTime07Wednesday or eastertide04Sunday.

just like your feriaCycle vs my ferialCycle

I moved on that one too 😄! I tried to use both on my private fork of romcal, and finally have adopted the ferialCycle. But anyway it's now weekdayCycle 😉. Finding the right naming is a difficult exercice!

ordinaryTime07Wednesday or eastertide04Sunday

Your suggestion is a lot better! It keep the meaning while being shorter and a lot more readable! Should we always pad numbers with a 0 to have always them in 2 chars?

On weekdayCycle: just to keep your thinking: what about cycleWeekday and cycleSunday? :smiley: That is: the most general term is on the left and the the most specific term on the right (same as in ordinaryTime07Wednesday).
On ordinaryTime07Wednesday and the number padding: Well, I think yes, because number 34 (the highest number of weeks in the Ordinary Time) is a two-digit number. Of course, for other seasons it is not neccessary to pad the week numbers, but I suggest to pad all the week numbers just because of uniformity/consistency.

And also in the tests, e.g. expect(Dates.allSaints(i).date()).toEqual(1); → expect(Dates.'all-saints'(i).date()).toEqual(1);

It only concerns keys (which are data), not JavaScript methods.

@emagnier, does this comment of yours mean that the JS methods should be kepts in camelCase?
For example, when I grep all files in src/ folder (and all its subfolders) to match allSaints pattern, I get the following output (of course there some other keys matched, like allSaintsOfWales, which I simply skip):
lib/Dates.test.ts:          expect(Dates.allSaints(i).date()).toEqual(1);
lib/Dates.test.ts:          expect(Dates.allSaints(i).month()).toEqual(10);
lib/Locales.test.ts:    expect(await Locales.localize({ key: 'celebrations.allSaints' })).toBe('Tous les Saints');
lib/Locales.test.ts:    const localizedText = await Locales.localize({ key: 'celebrations.allSaints' });
lib/Locales.test.ts:    expect(await Locales.localize({ key: 'celebrations.allSaints' })).toBe('Tous les Saints');
lib/Locales.test.ts:    expect(await Locales.localize({ key: 'celebrations.allSaints' })).toBe('All Saints');
lib/Locales.test.ts:    expect(await Locales.localize({ key: 'celebrations.allSaints' })).toBe('All Saints');
lib/Locales.test.ts:    expect(await Locales.localize({ key: 'celebrations.allSaints' })).toBe('All Saints');
lib/Celebrations.ts:      key: 'allSaints',
lib/Celebrations.ts:      date: Dates.allSaints(year),
lib/Dates.ts:const allSaints = (year: number): dayjs.Dayjs => dayjs.utc(`${year}-11-1`);
lib/Dates.ts:  allSaints,
calendars/ireland.ts:      key: 'allSaintsOfIreland',
calendars/england.ts:      key: 'allSaints',
calendars/wales.ts:      key: 'allSaints',
calendars/wales.ts:      key: 'allSaintsOfWales',
index.ts:  allSaints,
index.ts:  allSaints,
locales/pt-BR.ts:    allSaints: 'Todos os Santos',
locales/fr.ts:    allSaints: 'Tous les Saints',
locales/it.ts:    allSaints: 'Tutti i Santi',
locales/pl.ts:    allSaints: 'Wszystkich Świętych',
locales/la.ts:    allSaints: 'Omnium Sanctorum',
locales/la.ts:    allSaintsOfIreland: 'Omnium Sanctorum Hiberniæ',
locales/la.ts:    allSaintsOfWales: 'Omnium Sanctorum Cambriæ',
locales/sk.ts:    allSaints: 'Všetkých svätých',
locales/sk.ts:    allSaintsOfIreland: 'Všetkých svätých Írska',
locales/sk.ts:    allSaintsOfWales: 'Všetkých svätých Walesu',

Does your comment mean that, for example, expect(Dates.allSaints(i).date()).toEqual(1); from lib/Dates.test.ts should not be changed to expect(Dates.all_saints(i).date()).toEqual(1);? Or should I simply replace all instances of allSaints with all_saints?

does this comment of yours mean that the JS methods should be kepts in camelCase?

Yes, methods like Dates.allSaints(i) should not be renamed. Only keys.

On weekdayCycle: just to keep your thinking: what about cycleWeekday and cycleSunday?

No, after a lot of testing and experimentation, I'm sure that it should keep a natural naming, as much as we can, to keep things human readable for developers (and raw data consumers). Although we could have exceptions, especially when keys are becoming very long (like a few keys for weekday). But here I prefer to keep weekdayCycle for theses reasons.

of course there some other keys matched, like allSaintsOfWales, which I simply skip

It should become all_saints_of_wales as well. Maybe it's what you are saying.

I suggest to pad all the week numbers just because of uniformity/consistency

I see you like to have everything well prefixed, uniform, consistent 😄, thank you for your feedback! At the moment I do not see the padding very important. These keys are not listed together in a localization file for exemple. And I am more in favor of the simplest possible naming for these keys, as we often see them alone as a developper.

I’m okay or simply agree with everything.
Just to be sure: the change of allSaints to allsaints should be made only in celebrations.allSaints (the parent element must be kept), right?

@emagnier, another thing that came to my mind: I suggest that for keys with patron titles, we could name the key using the country/calendar name only instead of PatronOfXxx.
For example, Saint Joseph, Spouse of the Blessed Virgin Mary and Principal Patron of Canada could have josephSpouseOfMaryCanada (note that the celebration name was shortened too, but here I talk about PrincipalPatronOfCanada vs Canada key name suffix).
Do you agree?

Just to be sure: the change of allSaints to allsaints should be made only in celebrations.allSaints (the parent element must be kept), right?

Yes, the namespace celebrations should be kept in celebrations.all_saints.

another thing that came to my mind: I suggest that for keys with patron titles, we could name the key using the country/calendar name only instead of PatronOfXxx.

Instead of removing it, wouldn't it be better to use an abbreviation instead? to keep the meaning? Or only first letters, something like joseph_spouse_of_mary_ppo_canada. All these redundant part that became abbreviated could be documented in the localization section in the doc (there shouldn't be that many).

another thing that came to my mind: I suggest that for keys with patron titles, we could name the key using the country/calendar name only instead of PatronOfXxx.

Instead of removing it, wouldn't it be better to use an abbreviation instead? to keep the meaning? Or only first letters, something like joseph_spouse_of_mary_ppo_canada. All these redundant part that became abbreviated could be documented in the localization section in the doc (there shouldn't be that many).

Well, from my point of view, the meaning of Canada in the key name is that that particular key (i.e. alternate version of the generally used key in the most cases) is only used in the canada.ts calendar, therefore from my point of view the meaning is kept, however, I know you mean the meaning of PatronOf (etc). I believe that again we are talking about your quite intensive use of the key name for anything else but the celebration identification (from my point of view, key name is simply just a celebration ID). I still think that the metadata (like the titles, incl patronage titles) should be acquired from another object within the JSON output by romcal. For example, we could have an object like I suggest below in each and every celebration (of course, it is partially already implemented, but not the patronage object; see also #201 and #154):
metadata: {
  titles: [
    martyr,
  ],
  patronage: {
    territory: 'Canada',
    level: 'principal`,  // principal | secondary; It might be omited: then there would be no level of patronage; `level` might be renamed if you find a better key name
  }
}

Just to directly answer your question/suggestion of ppo abbreviation: I am not exactly for adding abbreviations into the key names (although I am for shortening the key names by omiting some not important words). Another reason is that we already agreen to remove all titles but the most important one from the list I posted above.

The metadata patronage is an excellent idea. So in the meantime we could kept the "patron of..." before this possibilities would be added into romcal.

I think we (both) forget some of the suggestions / feature requests I suggest some (long) time ago. I’d suggest you to read all open issues from time to time, esp #201 and #154). I have already proposed the feature (e.g. here), however, back then you suggested to list of the patronage titles separately, which I think is not a great idea (it would require 1. changes if a patronage title would created; 2. we would need, as we still need, two l10n keys is most of the cases, which should be fixed by #201). Also, when dealing with the titles themselves, some are not used usually (e.g. St Francis of Assisi is a deacon, but most of the calendars don’t use that title; or most calendars don’t use the missionary title, but in ireland.ts they use it quite a lot). We need to be able to add, remove or even replace the titles of celebrations. But that is another, but connected issue.

The metadata patronage is an excellent idea. So in the meantime we could kept the "patron of..." before this possibilities would be added into romcal.

Well, the thing is that you said you don’t want change the key names after the next release (because it would break the API), therefore if we introduce the ppo kind of abbreviations, it would stay until we deem it right to break the API (v3.0.0). Therefore, IMO it might be better to resolve this before v2.0.0 release.

There is plenty suggestions and GH issues about sanctorale metadata, a few are very similar or close, and I recognise I still didn't had time yet to dive across all of that (to organize, prioritize them and see how to convert some ideas to code logic).
Please re-read my comment, about patronage title, I'm just suggesting to eventually move to your idea (I'm not proposing a new one), and keep joseph_spouse_of_mary_principal_patron_of_canada in the meantime. In other words, to be iterative. And I'm not speaking about release here.

Another note on the patronage titles in metadata implementation: some titles contain additional adjectives before the Patron(ness) word, e.g. Celestial Patroness of the Philippines, which is quite non-standard as I have no idea if adjectives like this should be kept or not.
On your latest comment: okay, then I’d write those titles in full and thus (for now) we might have two titles in the key names.

Also I don't know if you already started or not all this renaming work (this could be part or after my PR against dev). Before, I would like to cherry pick the es translation work from the PR against master. Because after that it will be harder to include it.

Also I don't know if you already started or not all this renaming work […]

I already work on this (change of camelCase to snake_case, remove canonisation level and most titles from the key names, rename some celebrations in order to use the most used celebration/personal names in English, …), that’s why this PR will be quite big, however, I think it must be dealt in one PR.

Before, I would like to cherry pick the es translation work from the PR against master. Because after that it will be harder to include it.

You can do it even now if you wish. I need to rebase this PR (its final or pre-final version) on top the latest commit of the TS branch, therefore it won’t add too much burden on me. :smiley:

Ok, I'll do it this afternoon.

Spanish locale added.

Some Spanish keys might need to be reviewed, since you already made some work, like splitting keys (multiple celebration on 1 day). But this could be done little by little after the next big release on dev. We will take the time on dev to do the fine tuning, and reviewing and testing everything, until a future release on master.

Yes, I have already found mostHolyNameOfJesusOrOurLadyOfBethlehem, which is not part of romcal anymore. :smiley:

And about specific celebration name on some countries (like "...Patron of Country"), beyond all the possible metadata we could add, I really think of adding a way to specify a custom name for a specific calendar, without having to redefine all the celebration (because she/he is the Patron of a Country or whatever). Name of these celebrations should be closed as much as possible as how they are named in the missal or lectionary (if we have access to these books).
Currently, keys of celebrations are deeply wired to their localized name. A new customLocaleKey could be added when we need to change only the celebration name for a specific country (i.e. a calendar).
For example in philippines.ts, the definition below will extend the one defined in it's parent calendar (general.ts), but redefine the rank, and add a custom name. No need to redefine the date (it remain the same).
{
  key: 'saintRoseOfLima',
  extend: true,
  customLocaleKey: 'saintRoseOfLimaSecondaryPatronessOfThePhilippines',
  rank: Ranks.MEMORIAL,
},

The extend feature is related to #206.

And about specific celebration name on some countries (like "...Patron of Country"), beyond all the possible metadata we could add, I really think of adding a way to specify a custom name for a specific calendar, without having to redefine all the celebration (because she/he is the Patron of a Country or whatever). Name of these celebrations should be closed as much as possible as how they are named in the missal or lectionary (if we have access to these books).

I am not sure if I understand you correctly. Are you suggesting to create a list of countries/territories used in the patronage titles or not?
I have already suggested that the patronage titles should be defined within the celebration definition (see #201). It would be even better if the calendarists (those who define the celebrations within romcal) could change the titles of any person in any celebration if the particular calendar uses different titles than another calendar).
I don’t think that it is a good idea to create a static list of patronage title countries/territories. I think that the implementation should be something like this:

in the celebration definition, we would add something like this for principal patron of Canada:

patronage: {
  territory: 'Canada',
  level: 'principal',  // principal | secondary; It might be omited: then there would be no level of patronage; `level` might be renamed if you find a better key name
  sex: 'male',
  number: 'singular',
  capitalize: false,  // `true` should be used for Our Lady or Jesus only
}

based on level, it would use either principal or secondary or nothing (empty string);

based on the sex and number, it would use patron, patrons, patroness or patronesses;

based on the capitalize, it would change the letter of the patron (either sex and either number) to Patron;

based on the territory, it would add of {territory}.

Is that a complicated algorithm?

Currently, keys of celebrations are deeply wired to their localized name. A new customLocaleKey could be added when we need to change only the celebration name for a specific country (i.e. a calendar).

I know that they are deeply wired, however, I think that the transition can be made in little steps.
As for customLocaleKey: I am not quite sure if I understand you right. If you mean we could/should add a new/different key when a celebration name differs from a current celebration name, then that is what we currently do (e.g. ourLadyOfGuadalupe and ourLadyOfGuadalupeCelestialPatronessOfThePhilippines) and that is what I suggest to change in #201 and #154. When we have single one definition per a person (not even a celebration, but a person) and/or an event, only then we we can be sure that a celebration does not have two different keys (because some celebrations, or more often persons, have different names, but they are the very same celebration).

For example in philippines.ts, the definition below will extend the one defined in it's parent calendar (general.ts), but redefine the rank, and add a custom name. No need to redefine the date (it remain the same).
{
  key: 'saintRoseOfLima',
  extend: true,
  customLocaleKey: 'saintRoseOfLimaSecondaryPatronessOfThePhilippines',
  rank: Ranks.MEMORIAL,
},

The extend feature is related to #206.

From my point of view, the customLocaleKey is quite good from celebration definition point of view, but not that much from the l10n point of view, because there would be still two different keys for the very same celebration name (they differ in just a single attribute). I wish we would have only one definition of each and every celebration metadata. We already do this for the celebration ranks or liturgical colours—we localise them once and define them once per celebration; the same we should do with the titles, canonisation level (etc), however the calendarists should be able to change the titles as in some calendars they use different titles for a particular person (from my point of view, the titles should be viewed as part of a particular calendar [or a celebration definition in a calendar], not a celebration).

I am not sure if I understand you correctly. Are you suggesting to create a list of countries/territories used in the patronage titles or not?

No

As for customLocaleKey: I am not quite sure if I understand you right. If you mean we could/should add a new/different key when a celebration name differs from a current celebration name, then that is what we currently do

Not exactly, when we need something different for specific calendar, currently we have to recreate a whole new celebration, that completely overwrite the previous defined one.
I made a basic example but it was not enough 😛

Instead of redefining a new celebration completely, be able to extend it only with the properties that differ. This is where I was speaking about the extend property and feature (#206). By default, a celebration will continue to overwrites the previous one (that has the same key), except if it has the extend: true property.

Because we can't overwrite the celebration key property (the only property we can't change), and because the celebration names are deeply wired to the celebration keys, we need to add a customLocaleKey property for this specific need, when the celebration is the same as defined in general, but the name content differs. This allows keeping only one main definition, and only introduce a variation on a specific calendar to change its name (to make a title that would contain for example, "Secondary Patron of a Country").

I think this is the simple and the cleanest way to meet this need. And be able to offer celebration names closest to the celebration name in the missal, without having to redefine a lot of celebrations. In my example above, we keep the celebration definition for saintRoseOfLima (same date, the same color...), but we only change its name and its rank. I hope my explanations are clearer now 😄

Just to be clear: the celebration metadata inheritance part was clear to me. You still talk about this from calendar (or celebration definition) point of view. I look at this problem from both calendar and localisation point of view. As I understand it, we still would have two l10n keys: one for the general celebration name and the other for the slightly changed celebration name. I wanna get rid of the other, slightly changed celebration key altogether by moving the patronage titles (and possibly even all other titles too) definition into the calendars (specificly: into the celebration definition).

Is the easter in easter2020 = calendar2020.find((item) => item.key === 'easter') on lines 300-302 a l10n key? I have changed the easter key to easter_sunday, therefore if it is a key name, I need to change it, right?

In l10n files, should I change the casing of the object names (e.g. holyWeek or paschalTriduum) to snake_case? And even their elements (e.g. dayAfterAshWed)? I think I should do it, but I need confirmation. Thanks.

Have all metadata you want, with any tools to build a celebration name, doesn't prevent the benefit of having a way to customize the name of a very specific celebration. I don't believe in perfect rules that match all the cases, and it's important to allow flexibility to meet all possible needs (especially for religious and monastic communities that have a strong liturgical tradition and a lot of special cases). Romcal should always aim to be compliant with the missal, with a streamlined data architecture (especially when calendar definitions come from external endpoints), while giving flexibility to address all specific usages.
To continue on my last proposition, I would like to propose an improved approach: instead of adding a new customLocaleKey, I would like to allow using the name property in celebration definitions.
By default romcal still continue to use the celebration key to find the matching localization key. And when we need a customized name, a name property could be added in the definition, containing a different locale key, e.g.:
{
  key: 'saintRoseOfLima',
  extend: true,
  name: '{{saintRoseOfLimaSecondaryPatronessOfThePhilippines}}',
  rank: Ranks.MEMORIAL,
},

I really like this approach, it's clearer, simple, and offer even more modularity.

Is the easter in easter2020 = calendar2020.find((item) => item.key === 'easter') on lines 300-302 a l10n key? I have changed the easter key to easter_sunday, therefore if it is a key name, I need to change it, right?

Yes

In l10n files, should I change the casing of the object names (e.g. holyWeek or paschalTriduum) to snake_case? And even their elements (e.g. dayAfterAshWed)? I think I should do it, but I need confirmation. Thanks.

Yes. You might have a look then on lib/seasons.ts where these keys are mostly used to generate the base weekday/Sundays.

Indeed, your latest proposition is better, but still I am not happy with it. (I like it if I look at it from celebration metadata inheriting point of view).
Right now, if a celebration name differs from the general celebration name, we (can) use the regional locales, e.g. in en.ts we have celebrations.holy_thursday: 'Holy Thursday', however, in the UK, they use Maundy Thursday, therefore I have put it into en-gb.ts: celebrations.holy_thursday: 'Maundy Thursday' and I’m fine with this. (Note: I am not exactly sure if they still use Maundy Thursday in the UK after the editio typica tertia English translation is released, however, the Liturgy Office of England and Wales still use that name.)
Now a problem might come when a religious (and _monastic) calendars continue a different celebration name: a country name abbreviation is used as the regional locale; what is the regional locale for a religious calendar? Is it en-dominican? However, this (potential) issue is not being address right now.
All I want and am talking about (esp in #201) that the titles should not be part of the l10n key values, but they should be separately localised (like we do with the ranks and colours) and separately added to each celebration within the celebration definition (like we do with the ranks and colours). Because from my point of view, our_lady_of_guadalupe and our_lady_of_guadalupe_patroness_of_the_philippines celebrations are one and the very same celebration, but they differ in the titles only.

Thanks for the answers!

In therm of data architecture (and computing architecture), you need to think that calendars (including celebration or liturgical day definitions) to be a completely separated module than the localization module, and a potential future Martyrology/Sanctorale module (that will contain all the metadata you are thinking about since a long time, for all the saint/blessed people). Today this is still not the case (things are still too wired together), but we must aim to that, for many good reasons (code quality and maintenance, simplify future codebase evolutions and contributions, data and module extensibility and usability...). So be able to have a custom name for a celebration isn't an option.
And calendars for a specific region are not the same things as locales for a specific region. So your example with Holy Thursday and Maundy Thursday doesn't apply here. From your example, if you are using the england calendar, it should always display Maundy Thursday as much with en than en-gb.
With an improved tool to manage localized data, and leaning on a future Martyrology/Sanctorale module, we will be able then to compute names automatically. So the need to manage manually a custom name for a specific calendar will be less necessary. But that will be still useful to manage exceptions (by specifying the specific locale pattern or locale key in the name property). However this tool and future module will not be part of the next major release since it's a lot of work.

Okay.
Just one thing:

From your example, if you are using the england calendar, it should always display Maundy Thursday as much with en than en-gb.

Not exactly. Maundy Thursday should be used only when en-gb locale is specified by the user. It should not matter what calendar is output, e.g. en + france.ts → Holy Thursday, but en-gb + slovakia.ts → Maundy Thursday. As the calendars should be locales agnostic, so the locales should be calendar/celebrations agnostic.

Anyway, implement it as you wish. From my point of view, at least the patronage titles could be possible to append the celebration title (one way or another), but I’ll leave up to you.

+1 yes for the first letter and all proper names. And I might have a better source than this ordo you found. I can share you the index table of the French Sanctoral lectionary, so you will have the official list of all common saint/blessed people in French and French-speaking countries (with titles, date of death...). This lectionary has been edited in 2016, so the list is quite recent.

When will you give me access the the index table of the French Sanctoral lectionary? I think you mean the General Calendar with all the persons from the French Proper, which is usually at the beginning of the Roman Missal and the Liturgy of the Hours. You can do that in your next comment (as an attachment). 😃

@emagnier: ping 😃

I have found out that Americans use Christmas Season, while the British use Christmastide.

I'm not sure where you found that, we often see both in same documents. However in liturgical books in English, I've often seen the name of "Christmas time" and "Easter time" ("time" instead of "season"). Maybe that could be a consensus?
Also are you speaking about renaming the key or the localized name?

I own The Divine Office (the British, three-volume version of the Liturgy of the Hours) published by Collins from 2006 and there I can find it. However, I might be wrong the Christmastide/Eastertide because of the latest English edition (and translation) of the Roman Missal, which might have changed their names used in the official books in the UK. The Liturgy Office of England and Wales is using Easter Season, Christmas Season (and weekday instead of feria), but Lent (or Season of Lent) instead of the US Lenten Season. Yes, I am nitpicking, but I wanna be as thorough as possible with the limited resources I/we have. 😃

Anyway, I have found out that the missing temporal l10n keys in the regional locales (e.g. en-gb) are not replaced by those in the main locale (e.g. en) like the sanctoral keys are (romcal won’t build unless I copy-paste the missing keys). I think this is a bug and we might need to create a separate issue for it, but I’d like to hear your opinion first.

Addressed on https://github.com/romcal/romcal/pull/250.


MoM Fire

Currently we don't support the spread of fire.

flag support added, need to add standard event.


panel.png problem

hey the positions in panel.png are wrong how i fix that?

Panels can be adjusted by editing config.json file.

Panels can be adjusted by editing config.json file.

How

How will I find that numbers to fit there?

How will I find that numbers to fit there?

Change the value in config file
Check if panels.png shows correct position or not.
If position is not corrects, then repeat step 1

How will I find that numbers to fit there?

Change the value in config file
Check if panels.png shows correct position or not.
If position is not corrects, then repeat step 1

Asking that how will I know the exact value of that place

How will I find that numbers to fit there?

Change the value in config file
Check if panels.png shows correct position or not.
If position is not corrects, then repeat step 1

Asking that how will I know the exact value of that place

Have you tried running this command and check the images?
python main.py --run --output_panels panels.png --output_color_panel color_panel.png

How will I find that numbers to fit there?

Change the value in config file
Check if panels.png shows correct position or not.
If position is not corrects, then repeat step 1

Asking that how will I know the exact value of that place

Have you tried running this command and check the images?
python main.py --run --output_panels panels.png --output_color_panel color_panel.png

i have tried the box was in wrong position for catching

i have tried the box was in wrong position for catching

Change the value In config file, and check the box position again.
How to get correct value? Trial and error, change the value and see how it affects the box coordinates position.

is there any video demonstrating how input_panel and color work tried changing value but never landing in the spot and after 1st execution my cursor goes to search bar not staying in discord..

What should I modify? input_panel or color_panel?

What should I modify? input_panel or color_panel?

Both.

input_panel determine text box to input command

color_panel determine area to check pokemon color

What should I modify? input_panel or color_panel?

Both.

input_panel determine text box to input command
color_panel determine area to check pokemon color

I managed to position the color well, but now based on what should I position the input_panel?
Thanks anyway for the prompt response.

Put the input_panel at text area

Metti l' input_panelarea di testo

I think I got it. Now, to make them use the Pokéballs, do I need to place the frame of each ball on its respective button?

Now, to make them use the Pokéballs, do I need to place the frame of each ball on its respective button?

Yes

Now, to make them use the Pokéballs, do I need to place the frame of each ball on its respective button?

Yes
I did it, thank you very much for your patience and for the tips.

Now, to make them use the Pokéballs, do I need to place the frame of each ball on its respective button?

Yes
I did it, thank you very much for your patience and for the tips.

Everything working now? Happy grinding 👍

Now, to make them use the Pokéballs, do I need to place the frame of each ball on its respective button?

Yes
I did it, thank you very much for your patience and for the tips.

Everything working now? Happy grinding 👍

yes, kts

Now, to make them use the Pokéballs, do I need to place the frame of each ball on its respective button?

Yes
I did it, thank you very much for your patience and for the tips.

Everything working now? Happy grinding 👍

yes, kts

hi marco i im on the same problems as u and i need to adjust the config i dont know how to see the bbox i am knew to this thing and i dont know if u could help me with it


How do I check if the current platform is supported?

I want to enable compression if the current platform is supported by zstd-jni. How can I check?

You can try com.github.luben.zstd.util.Native.load() and catch exceptions: if it throws, the platform is not supported.

I can't import the Zstd class without throwing exceptions on unsupported platforms, so detecting support this way doesn't really do anything (i.e. I still have to import the Zstd class to use it). I ended up using reflections to solve this issue...
package org.hydev.mcpm.utils;

import org.jetbrains.annotations.Nullable;

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;

/**
 * Utility for Zstd-jni
 *
 * @author Azalea (https://github.com/hykilpikonna)
 * @since 2022-11-22
 */
public class ZstdUtils
{
    public static final ReflectedZstd zstd;

    /**
     * Reflected zstd class
     *
     * @param cl Class object
     * @param decompress decompress(byte[], int) method
     * @param decompressedSize decompressedSize(byte[]) method
     * @param compress compress(byte[]) method
     */
    public record ReflectedZstd(Class<?> cl, Method decompress, Method decompressedSize, Method compress) { }

    /**
     * Get zstd class
     *
     * @return Zstd class if usable, null otherwise
     */
    private static @Nullable ReflectedZstd getZstdClass()
    {
        try
        {
            var cl = Class.forName("com.github.luben.zstd.Zstd");
            var decompress = cl.getMethod("decompress", byte[].class, int.class);
            var decompressedSize = cl.getMethod("decompressedSize", byte[].class);
            var compress = cl.getMethod("compress", byte[].class);
            return new ReflectedZstd(cl, decompress, decompressedSize, compress);
        }
        catch (Throwable e)
        {
            // Any exception here would mean that it isn't supported
            return null;
        }
    }

    static
    {
        zstd = getZstdClass();
    }

    /**
     * Check if zstd is supported on the current platform
     *
     * @return true if supported
     */
    public static boolean isSupported()
    {
        return zstd != null;
    }

    /**
     * Compress zstd using reflection
     *
     * @param content Plain text content
     * @return Zstd compressed content
     */
    public static byte[] compress(byte[] content) throws ZstdException
    {
        if (!isSupported()) throw new ZstdNotSupported();
        try
        {
            return (byte[]) zstd.compress.invoke(null, (Object) content);
        }
        catch (IllegalAccessException e)
        {
            // This would never happen
            throw new RuntimeException(e);
        }
        catch (InvocationTargetException e)
        {
            // This would be when zstd has some errors
            throw new ZstdException(e);
        }
    }

    /**
     * Decompress zstd using reflection
     *
     * @param zst Zstd compressed content
     * @return Plain text content
     */
    public static byte[] decompress(byte[] zst) throws ZstdException
    {
        if (!isSupported()) throw new ZstdNotSupported();
        try
        {
            return (byte[]) zstd.decompress.invoke(null, zst,
                ((Long) zstd.decompressedSize.invoke(null, (Object) zst)).intValue());
        }
        catch (IllegalAccessException e)
        {
            // This would never happen
            throw new RuntimeException(e);
        }
        catch (InvocationTargetException e)
        {
            // This would be when zstd has some errors
            throw new ZstdException(e);
        }
    }
}

You should be able to use the zstd.utit.Native.load() - it should be lighter weight, but your approach will also work.


Update the VS 2015 RTC

Updated project files according to this page
https://msdn.microsoft.com/library/mt148501(v=vs.140).aspx
Added the nuget dependencies so they become part of the project.json
files
Couldn't get the SDKTest project running. It is missing a pfx file and
it is saying something about the .net framework dependency not existing.

this has been resolved in the develop branch. it will soon be merged.


How do I add custom recipes?

It's not immediately clear what - if any - file I should modify in order to add custom recipes. Currently, it seems as though you can only maintain homebrew casks and formula with the project.
I needed to customize my pantry bin to specify a custom role to run, which isn't ideal :(

One thing I was thinking is to switch to a role matching the user's name if it exists. Thoughts on that? I think you can grab that from SUDO_USER or something similar.

Have a look at https://github.com/chef/pantry-chef-repo/pull/18.


CVEs / Vulnarabilities

Hallo,
According to the owasp Vulnarability scan, there are CVEs in the fat-jar due to outdated libs

[ERROR] keycloakmigration-0.2.47-fat.jar\META-INF/maven/com.fasterxml.jackson.core/jackson-databind/pom.xml: CVE-2020-36518(7.5), CVE-2022-42003(7.5), CVE-2022-42004(7.5)
[ERROR] keycloakmigration-0.2.47-fat.jar\META-INF/maven/org.apache.commons/commons-text/pom.xml: CVE-2022-42889(9.8)
[ERROR] keycloakmigration-0.2.47-fat.jar\META-INF/maven/org.yaml/snakeyaml/pom.xml: CVE-2022-38752(6.5), CVE-2022-38751(6.5), CVE-2022-38750(5.5), CVE-2022-41854(6.5), CVE-2022-25857(7.5), CVE-2022-38749(6.5), CVE-2022-1471(9.8)
This is a blocking issue, while we are not allowed to deploy artifacts with security issues

Hey @fadiaismael thanks for providing the pull request for this issue 👍 Your changes are release with version 0.2.48 (https://github.com/mayope/keycloakmigration/releases/tag/0.2.48). Could you verify this on your side?

Tested successfully, thanks :)


removed a misplaced r (planned failover)

Hi @metzGi, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no contribution license agreement is required at this point. Real humans will now evaluate your PR.

TTYL, AZPRBOT;

@metzGi : Thanks for your contribution to the Azure documentation! The author, @stevestein, has been notified to review your proposed change.

@metzGi - good catch, thanks for the fix!
@tysonn - this PR is ok to merge.
#sign-off


Update cookie name

Standardizing cookie names https://github.com/aspnet/Coherence-Signed/issues/166.
cc @Tratcher @rynowak

:watch:

:up::date:

:shipit: with one small adjustment

:shipit: from me as well!


Messages being broadcast to consumers in same group

I have two consumers in the same group and both are receiving each message that I push up into the queue. I am consuming the message on consumer 1 and committing the consumption to Kafka, then checking pending messages and verifying that it is at 0. Consumer 2 is constantly checking pending messages, and never goes down after a message has been pushed, despite appropriate message consumption from consumer 1.
Restarting consumer 2 resets pending message counter back to 0, which validates that the commit logic is working appropriately.
Kafka v <IP_ADDRESS>
kafka-python release 0.9.x

Can confirm, I'm seeing the same thing on the same server version. Auto-commiting or commiting each message after print(), makes no difference. Both consumers get all messages.

This is expected -- consumer coordination is not natively supported by kafka-python. See #455 and #38 .


factory_girl renamed to factory_bot

Clean up deprecation warnings resulting from Thoughtbot's decision to rename factory_girl.

Wow, was not watching #378. Thanks!