Cannot export to Ruby on Rails project as default placeholders are wrong

Describe the bug
Hello, the default format: :ruby_yaml and placeholder_format: :icu does not work with a Ruby on Rails project with the default i18n setup using the rails-i18n gem.
Ruby on Rails expects placeholders to be %{my_placeholder} but this gem exports as {my_placeholder} when using type :icu.
I cannot get any combination of format/placeholder_format for the file export to work with this gem and a Ruby on Rails project. Can you confirm how to use this gem?
To Reproduce

Export a file from Lokalise with default parameters

  # Import options have the following defaults:
  # c.import_opts = {
  #   format: 'yaml',
  #   placeholder_format: :icu,
  #   yaml_include_root: true,
  #   original_filenames: true,
  #   directory_prefix: '',
  #   indentation: '2sp'
  # }

Use this file in the default config/locales folder of a Ruby on Rails project
You will see that placeholders show up as {my_placeholder} when translating a string, instead of using the replaced variable. This is due to Rails expecting %{my_placeholder}

Expected behavior
We expect that this gem should export as %{my_placeholder}, the only format supported by Ruby on Rails rails-i18n gem.
Your environment:

Ruby version  '2.7.5'
Rails version '6.0.5'

Additional context
See how placeholders work in i18n interpolation documentation
https://guides.rubyonrails.org/i18n.html#passing-variables-to-translations
Checked with your support team to log a ticket, they suggested to go ahead. Thanks!

Thank you for your feedback! I wanted to double-check, how your translations look on Lokalise? Specifically, how placeholders are represented there? Do you use universal Lokalise placeholders?

As a quick fix, you could try using Custom placeholders https://docs.lokalise.com/en/articles/5781985-custom-placeholders and Universal placeholders https://docs.lokalise.com/en/articles/1400511-lokalise-placeholders. For example, if your translation on Lokalise has the following contents:
Welcome, [%s:name]

Then you can enable Custom placeholders and provide the following data:

Starts with: %{
Ends with: }

Then use Ruby on Rails YAML format and Raw placeholder format when exporting your data.

Thanks @bodrovis ! We uploaded the YAML files from Ruby, and converted them to Universal Placeholders.
For example [%1$s:current_weather] currently. It’s [%1$s:current_temp].

How does this gem usually work with a Rails project and rails-i18n, maybe you have an example project to show me?

Unfortunately I don't have any samples at hand, but let me try to double-check everything. It's strange because everything worked for me fine

Yeah you know it's not working with the placeholder you are currently using. However this approach is working fine
[%s:current_weather] currently. It’s [%s:current_temp]

Hi @bodrovis, are you suggesting that placeholder works in an en.yml file on Rails?
Doesn't seem to work for me on rails console:
I18n.backend.store_translations :en, { test_key: 'Example %{placeholder} here' }
I18n.translate('.test_key', placeholder: 'text')
=> "Example text here"

I18n.backend.store_translations :en, { test_key: 'Example [%s:placeholder] here' }
I18n.translate('.test_key', placeholder: 'text')
=> "Example [%s:placeholder] here"

No-no, here's an example.
Translation:

Configuration:

Download config:

Preview:

So, effectively my universal placeholders are presented as ordinary RoR YAML placeholders when using "raw" format

Ah okay! There must be something wrong with how we uploaded our YAML files before, I assumed [%1$s:current_weather] was a universal placeholder processed by Lokalise.
Would you have a way to get this Rails gem working out-of-the-box with Lokalise? And without using the Custom Placeholders App so we don't need to fix all our translated strings (4k+) 😄

Actually [%1$s:current_weather should work as a universal placeholder - I'm not quite sure what's the problem, to be honest (I've asked other team members to look into it).
Also, the gem should be working out of the box with translations similar to this one:

What was the original translation you tried to export?..

I've actually added another test case https://github.com/bodrovis/lokalise_manager/commit/45ea2452571306a6f67e293bad0dadec6dd13cce#diff-ffcc6c7c9aa007b1bd12983b91222c59ddcfe6917e2fd1cf6cef519f1edc8ee6R124
So, if I have the following translation Welcome to the app, %{username} on Lokalise, it gets exported as-is

Also, the gem should be working out of the box with translations similar to this one:

Could you explain how to get translations into Lokalise with those placeholders?
If I upload like this

with Convert to universal placeholders unchecked

I still get this result in the editor

I've actually added another test case https://github.com/bodrovis/lokalise_manager/commit/45ea2452571306a6f67e293bad0dadec6dd13cce#diff-ffcc6c7c9aa007b1bd12983b91222c59ddcfe6917e2fd1cf6cef519f1edc8ee6R124

And related to this, how did you get the placeholder %{username} to output in your new test on this line?
I see the request parameters in the VCR cassette have placeholder_format: icu defined, so I would expect {username} as that's what I was receiving.

Unfortunately I don't think there's any easy solution with Custom placeholders, universal ones and Rails. If you need this feature, I'd suggest reporting it to the customer support team and they can forward it to product guys (it would be more appropriate as I'm not a member of CS). Also, I'll update the docs for Rails.
In any case, thank you for reporting this and I'm sorry it tooks us a while to sort things out!


Git cliff 2.6.0 docker image not published

Is there an existing issue for this?

[X] I have searched the existing issues

Description of the bug
https://github.com/orhun/git-cliff/actions/runs/10978847295/job/30482488830
The github action failed to build and push 2.6.0 tag to ghcr.io
The Docker job times out after 360 minutes, as described in the GitHub documentation
Steps To Reproduce
.
Expected behavior
.
Screenshots / Logs
No response
Software information
Github action
Additional context
No response

Thanks for reporting!
Yup, I tried running the workflow 2 more times, they have all failed: https://github.com/orhun/git-cliff/actions/runs/10978847295
I think it is timing out due to QEMU/AMD builds :/
According to this docs, it is not possible to increase this limit.

Job execution time - Each job in a workflow can run for up to 6 hours of execution time. If a job reaches this limit, the job is terminated and fails to complete.

Not sure what can I do expect disabling them temporarily, which I did in cde2a8e3222f5e8f8bdd9ae841fd0e5c42f68846

@orhun Looks like an issue with github action, the docker is running now ? (could you rerun the 2.6.0 docker action)

Yup, I need to create a new release soon. I don't think it is possible to trigger the pipeline again with the new changes in the workflow file :)

In the meantime you can probably use one of the latest versions.

Yup, I close this one as the issue seems resolved :)

Hi!
Sorry to re-heat this issue. I just stumbled upon this and thought that this must be doable in a way. (Building the arm64 image again I mean)
Hopefully I am not pointing to anything that is already known to you, but the docker docs mention how to achieve this again: https://docs.docker.com/build/ci/github-actions/multi-platform/ .
Basically building the images separately and then merge them together. AFAIK building the arm image could even be done on a native arm runner. I would submit a PR... But unfortunately I have no time for this at the moment:/
So hopefully I could at least help with the above link :)

I refactored the Docker builds in #888 based on these docs - it should be faster in theory but I feel like there are still some rough edges in the workflow.

It takes 6hr+ even with the build matrix: https://github.com/orhun/git-cliff/actions/runs/11053756749/job/30708900152 💀

Hey!
As i have the impression i caused some trouble with my comment (that i deleted... which might have been a mistake) i though i share my rationale why i removed that comment.
When i saw the change removing it, i thought that it was due to the fact, that building the images and publishing them was all done on the same node. But then i found the setup-buildx-action docs, which mention that this is already creating one node for each architecture. Which is basically what this suggests as well. Thus, i deleted my comment in the hope that i had not done any harm :sweat_smile: Sorry 'bout that!
Also i guess in the current state this is not yet achievable as github has not yet released its official arm64 support as of this comment.
As soon as that is available for OSS this could be used in the open PR to use a native arm64 node to build the arm64 image. (In fact this was the second reason i deleted my comment... next time i will just update it!)

From the log I'm reading, it looks like there is an issue with shellexpand, right? It takes one hour from the start to reach shellexpand, and the compilation takes at least 5 hours (it looks really long from my POV) ?
https://github.com/orhun/git-cliff/actions/runs/11053756749/job/30708900152#step:10:1072

Maybe docker buildx on macos arm runner (for arm build) are better ?
https://github.com/actions/runner-images

Just to share some insights: on my DAYJOB we recently had to switch from qemu emulation for building arm64 images as well. In our case we were only doing apt install commands, but that already increased the build time from 10 minutes for our amd64 builds to 60 minutes for our qemu emulated arm64 builds.

As i have the impression i caused some trouble with my comment (that i deleted... which might have been a mistake), i thought i share my rationale why i removed that comment.

No worries!

Also i guess in the current state this is not yet achievable as github has not yet released its official arm64 support as of this comment.

Ah, thanks for sharing the links. I subscribed to those issues and I hope it happens one day 🙏🏼

it looks like there is an issue with shellexpand, right?

I think the issue is not about a specific crate, it is related to QEMU emulated builds.

Maybe we could add more verbose to cargo build to see if we have something useful ?
Maybe docker buildx on macos arm runner (for arm build) are better ?

I tried your suggestion in #888 but I guess setup-qemu-action is not available for the macOS runner: https://github.com/orhun/git-cliff/actions/runs/11072292415/job/30766175378?pr=888

I think the issue is not about a specific crate, it is related to QEMU emulated builds.

I just find it strange at first glance that such package takes more than 5 hours to build compared to others.

I tried your suggestion in #888 but I guess setup-qemu-action is not available for the macOS runner: https://github.com/orhun/git-cliff/actions/runs/11072292415/job/30766175378?pr=888

Sad, yes I saw the same error in the discussion.

Can you send a link of that discussion?
Man... all I wanted was to build arm64 images...

I thought qemu is not needed when using the arm64 MacOs runner? The architecture is already native and afaik you should be able to do docker builds on MacOs that build a Linux image already?

Can you send a link of that discussion?
Man... all I wanted was to build arm64 images...

https://github.com/docker/setup-qemu-action/discussions/137
https://github.com/docker/setup-qemu-action/issues/24

I thought qemu is not needed when using the arm64 MacOs runner? The architecture is already native and afaik you should be able to do docker builds on MacOs that build a Linux image already?

Yes with two differents job instead of a matrix 👍

I thought qemu is not needed when using the arm64 MacOs runner? The architecture is already native and afaik you should be able to do docker builds on MacOs that build a Linux image already?

Ah damn, right...

FTR: This seems to be the way it is until GitHub launches their linux/arm64 runners.
There seems to be no way for macos runners on arm64 to get docker to build.

TL;DR: cargo chef cook does not use the rust-toolchain.toml file while cargo build does. Thus the dependencies are build twice instead of being cached. This might be the cause for the timeout. Copying the toolchain file before invoking cargo chef cook solves this issue.
I had a look again on the build logs of the failing actions and noticed something weird in the build logs: Although the cargo chef cook  already builds the dependencies, they are build again in the cargo build during the Build and push step. This made me wonder if the arguments passed to those commands maybe need to be exactly the same.
After some fiddling around with it, i did not manage to use the cached dependencies from the chef cook step.
The following build times are on my local machine. So as a benchmark the current HEAD took ~860s to docker build ..
Disclaimer: I pre-pulled the cargo-chef base image in all cases to reduce the "noise" a normal docker pull would have here.
Try 1 (Pass same arguments to cargo-chef cook)
So then I basically did the following patch to the current head to try to get caching going again:
diff --git a/Dockerfile b/Dockerfile
index 6175d23..8723799 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -5,13 +5,13 @@ WORKDIR app
 FROM chef AS planner
 COPY . .

-RUN cargo build --release --locked --no-default-features --features github --features gitlab --features bitbucket
+RUN cargo build ${BUILD_ARGS}
 RUN rm -f target/release/deps/git_cliff*

 FROM debian:buster-slim as runner

The build with just docker build .  took 880.942s to complete.
So that did not solve it as the dependencies where build twice again. So basically i have the feeling that cargo chef cook is not doing what i`d expect from it, or i did not manage to use it correctly. But as the current state builds the dependencies twice, this might be the problem why the arm64 build times out (though i am not sure why it gets obviously stuck in the second round of compiling, as the reported numbers from the docker builds do not add up to 6h).
Try 2 (remove cargo-chef cook)
So my next idea: if the dependency caching is not actually caching anything it is better to be removed:
(patch again based on HEAD and not my previous patch)
diff --git a/Dockerfile b/Dockerfile
index 6175d23..e60a085 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -2,14 +2,8 @@
 FROM lukemathwalker/cargo-chef:0.1.63-rust-1.76-slim-buster AS chef
 WORKDIR app

-FROM chef AS planner
-COPY . .
-RUN cargo chef prepare --recipe-path recipe.json
-
 FROM chef AS builder
-COPY --from=planner /app/recipe.json recipe.json
 ENV CARGO_NET_GIT_FETCH_WITH_CLI=true
-RUN cargo chef cook --release --recipe-path recipe.json
 COPY . .
 RUN cargo build --release --locked --no-default-features --features github --features gitlab --features bitbucket
 RUN rm -f target/release/deps/git_cliff*

This build took 603.229s. So a speed-up of ~280 seconds...
Try 3 (Toolchain file)
Now i noticed, that this project is using a toolchain file... and cargo-chef added a commit emitting the toolchain file in a version not yet used... so lets try our luck by "just" bumping the cargo-chef version:
diff --git a/Dockerfile b/Dockerfile
index 6175d23..ed61a33 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -1,5 +1,5 @@
 # syntax=docker/dockerfile:1.4.3-labs
-FROM lukemathwalker/cargo-chef:0.1.63-rust-1.76-slim-buster AS chef
+FROM lukemathwalker/cargo-chef:0.1.68-rust-1.81-slim AS chef
 WORKDIR app

 FROM chef AS planner

But that yields the same result... so lets also add the arguments passed to cargo to chef like done in my First try from above. But it still did not work...
Try 4 (copy toolchain file by hand)
Then i stumbled across https://github.com/LukeMathWalker/cargo-chef/issues/271 which looks exactly like this issue. So, as cargo-chef cook does not use the toolchain file to build the dependencies, let's just copy it by hand. I applied the following patch to the unmodified head again:
diff --git a/Dockerfile b/Dockerfile
index 6175d23..abcae25 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -9,6 +9,10 @@ RUN cargo chef prepare --recipe-path recipe.json
 FROM chef AS builder
 COPY --from=planner /app/recipe.json recipe.json
 ENV CARGO_NET_GIT_FETCH_WITH_CLI=true
+# cargo-chef prepare only started to emit the toolchain file in 0.1.63, but cargo-chef cook does not use it to build the dependencies.
+# See https://github.com/LukeMathWalker/cargo-chef/issues/271.
+# So long we have to manually copy it before invoking cargo chef cook.
+COPY ./rust-toolchain.toml rust-toolchain.toml
 RUN cargo chef cook --release --recipe-path recipe.json
 COPY . .
 RUN cargo build --release --locked --no-default-features --features github --features gitlab --features bitbucket

Aaaand :drum: it reduced the build time to 576.634s and actually cached nearly all dependencies!
So this sounds like a viable work-around until cargo-chef can use the toolchain file.
Conclusion
The build times in the docker build are quite high, because cargo-chef in the current state builds the dependencies twice. By injecting the toolchain file manually the caching works again and reduces the build times. This might not be enough to no longer hit the timeout, but as the cargo chef cook step is already fast enough, this should in theory make it work again.
Building the dependencies with the nightly compiler took roughly the same time as with installed 1.76 from the image.
So i suggest just copy the toolchain file and hopefully the arm64 images can be build again.
But it is getting late... so i will not submit a PR now and i am unsure when i get the time to do that. But fell free to apply my patch from my 4st try.

FTR: i submitted a PR in cargo-chef that hopefully solves the double install of dependencies and would make my suggested work-around unnecessary.

I guess I found an easier way to solve this and opened a PR to fix this. Let me know if you agree.

Merged your PR, let's see how it'll go 🤞🏼


Introduce UI configuration for Keda CR in kyma dashboard

Description
Configure UI components for KEDA CR.
AC:

user should be able to edit keda consumed resources and log level via edit foms, not yaml editor.
user should be able to see detailed status (conditions) of the installed keda
user should be able to read deteialed error messages in order to be able to troubleshoot (for example when deletion is stuck)

Reasons
Users will see all enabled modules on the dashboard's landing page. From there user could navigate to a CR view of the given module where he can configure it.

Done with https://github.com/kyma-project/keda-manager/issues/153


HDFS-16871 DiskBalancer process may throw IllegalArgumentException when the target DataNode has capital letter in hostname

For a Datanode with lowercase letter in hostname, everyting is ok,
but for a Datanode with uppercase hostname, when Balancer process try ro migrate on it, there will be a IllegalArgumentException thrown.
For more details, Pls refer to jira HDFS-16871

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
1m  3s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

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

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
42m 36s

trunk passed

+1 :green_heart:
compile
1m 33s

trunk passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
compile
1m 25s

trunk passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
checkstyle
1m 10s

trunk passed

+1 :green_heart:
mvnsite
1m 35s

trunk passed

+1 :green_heart:
javadoc
1m 12s

trunk passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
javadoc
1m 30s

trunk passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
spotbugs
3m 48s

trunk passed

+1 :green_heart:
shadedclient
26m 30s

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

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m 26s

the patch passed

+1 :green_heart:
compile
1m 29s

the patch passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
javac
1m 29s

the patch passed

+1 :green_heart:
compile
1m 22s

the patch passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
javac
1m 22s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 56s

the patch passed

+1 :green_heart:
mvnsite
1m 26s

the patch passed

+1 :green_heart:
javadoc
0m 55s

the patch passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
javadoc
1m 20s

the patch passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
spotbugs
3m 34s

the patch passed

+1 :green_heart:
shadedclient
26m 39s

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

_ Other Tests _

-1 :x:
unit
381m  0s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
hadoop-hdfs in the patch passed.

+1 :green_heart:
asflicense
0m 42s

The patch does not generate ASF License warnings.

500m  7s

Reason
Tests

Failed junit tests
hadoop.hdfs.TestLeaseRecovery2

Subsystem
Report/Notes

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

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

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

uname
Linux 013a56b05a40 4.15.0-200-generic #211-Ubuntu SMP Thu Nov 24 18:16:04 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 56adaeb28a02bde2599da949dc69ef1f339a44c9

Default Java
Private Build-1.8.0_352-8u352-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_352-8u352-ga-1~20.04-b08

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

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

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

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

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

@slfan1989   Could you pls help to review this PR?

Could you pls help to review this PR?
LGTM +1.

We'd better trigger a compile again.


The number of resources appear unreliable

Description
After a demo today, it's been reported that the number of scanned resources after the spinner during scan is unreliable (the number is different after each run).
Environment

OS:
driftctl version: 0.7.0

How to reproduce
https://youtu.be/-BS65owCCmQ?t=826
Possible Solution
We probably need to flush the number when scan is done.

LGTM!
3 times discovered 62 resources
 LOG_LEVEL=info driftctl-0.7.1 scan --from tfstate://./vpc/terraform.tfstate  --from tfstate+s3://driftctl-tfstates/
INFO[0001] Start reading IaC
INFO[0002] Start scanning cloud provider
Scanned resources:    (62)


Line annotation when specified with borderWidth:1, the final width of line is 2px

When using line annotation with borderWidth: 1, the final width of the line is 2px.
Step to reproduce:

Open https://www.chartjs.org/chartjs-plugin-annotation/latest/samples/line/visibility.html
Screen the website using PixelZoomer
Measure the width of the line "Now"

The width is 2px even when borderWidth is set to 1px.
I would be happy to create a pull request if someone points me to the right direction.

@skopz356 thank you very much for this issue.
To support your issue: https://usefulangle.com/post/17/html5-canvas-drawing-1px-crisp-straight-lines
To fix, we should check the borderWidth if odd or not and then change the annotation element size calculation as described in the document.
All annotation element sizes are calculated in the resolveElementProperties(chart, options) method of the annotation elements (in src/types).
This will affect also the test cases which should be changed.
Let me know if more info are needed to submit a PR. Otherwise I'll have a look asap.

@skopz356 maybe it can help, you could try to set borderWidth: 0.5. It doesn't solve completely but improve.


Adding/setting rarity points after gems have been staked or moved to vault (deposited).

TL;DR: when changing the rarity points of a deposited gem a new total rarity points for the vault isn't calculated/updated. Therefore, the staking reward amount/rate isn't updated. Furthermore, it is not possible to withdraw the gem (due to certain checks for security reasons).
Does anyone know of a way to fix or get around this? (Maybe updating/refreshing the Vault struct will fix it?)
Example/issue:
Two gems, each with rarity points of 1, are moved to the vault (and may also be staked) and while they are in the vault the rarity points of one of them are set/updated to 4.
(The same things apply to a scenario with just a single gem that gets rarity points updated while in the vault)
The amount of tokens rewarded from staking remains unchanged after the update, so it seems as if the calculated total rarity points of the vault isn't updated/refreshed.
Furthermore, trying to withdraw the gem with 4 rarity points now fails with the 0x1770 error as the program tries subtracting 4 from 2 (see attached screenshot) - it appears that the calculated total rarity points of the vault is updated somewhere (but not  the place that affects staking rewards).
Question:
Is there any way of "refreshing" the total calculated rarity points of a vault after the rarity points of a gem (or several) in the vault has been changed?
(I.e. is it possible to change/update the rarities if the staking of a collection of gems is already live)

From the docs regarding rarities: "Those rarity points are summed up and stored on the Vault struct"

I assume that I need to update the Vault struct? Does anyone know how to do this? (I´m quite a rust/vue noob)

Or perhaps the Vault struct is in fact updated but the front end is not?

@torbentemp Hey seems like I'm going through this same issue. Did you ever find a fix? My current plan (I know not a great idea) is to temporarily remove the check so they can be unstaked and then add that fix back

I had this issue the other day and in order for the users to be able to unstake again, I changed back the rarity of all of the NFTs to 1
Sucks tho that there's no way for now to update the staked ones

@torbentemp Hey seems like I'm going through this same issue. Did you ever find a fix? My current plan (I know not a great idea) is to temporarily remove the check so they can be unstaked and then add that fix back

Nope.
I ended up starting a separate farm for the new collection of NFTs that I wanted to integrate - not ideal (and costs extra sol) but priority was/is UX for the users.

@nf0x Thank you for your rarity-configuration script/repo! It saved me a lot of time. Much appreciated!

@nf0x @torbentemp can you share the repo with me as well?

I have the same problems now. Updated rarities after some nfts staked. Now user can't unstake, one or more. it depends.
The problem from the error message I can infer.
There is a rairity total saved in each vault, default it's 0 or the number of total nfts.
now you set rairity for nfts
You unstkae one, then the program try to recalculate the total rarity for th vault, new total = old total - the rarity fo the one you unstake, it turned to new value = 0- xxx, that caused the error.
Soooooooooooooooooooooooo painful using this!!!!!!!!!!!!!!!!!!!!!


Get Stream of GitHub notifications by given Token

We need to get notifications data stream from GitHub by putting the token

@zoeself register

@zoeself register

@h1alexbel I've just registered this ticket as a task and will assign it to someone soon. Thanks!

@zoeself resign

@zoeself resign

@h1alexbel ok, I'll find someone else to take care of it.

@PavelRyauzov this is your task now, please go ahead. Deadline (when this ticket should be closed) is 2023-09-20T14:29:18.664984.
Estimation here is 60 minutes, that's how much you will be paid.
Remember, you don't have to solve everything in this ticket - you can solve it partially and leave todo markers in the code, which will become future tasks.
If you have any questions don't ask me, I'm not a technical person. Open new tickets instead.
If you don't have time or simply don't want to work on this, you can always resign.

@PavelRyauzov Don't forget to close this ticket before the deadline (2023-09-20T14:29:19). You are past the first half of the allowed period.

@erstediy Looks like you've missed the task deadline (2023-09-30T14:59:46). You are now resigned from this task.
Please stop working on it, you will not be paid. I will assign it to someone else soon.

@LeonovAlexProg this is your task now, please go ahead. Deadline (when this ticket should be closed) is 2023-11-19T14:32:32.786387.
Estimation here is 60 minutes, that's how much you will be paid.
Remember, you don't have to solve everything in this ticket - you can solve it partially and leave todo markers in the code, which will become future tasks.
If you have any questions don't ask me, I'm not a technical person. Open new tickets instead.
If you don't have time or simply don't want to work on this, you can always resign.

@LeonovAlexProg Don't forget to close this ticket before the deadline (2023-11-19T14:32:33). You are past the first half of the allowed period.

@LeonovAlexProg Looks like you've missed the task deadline (2023-11-19T14:32:33). You are now resigned from this task.
Please stop working on it, you will not be paid. I will assign it to someone else soon.

@lisitsaaa this is your task now, please go ahead. Deadline (when this ticket should be closed) is 2023-11-29T15:01:21.330670.
Estimation here is 60 minutes, that's how much you will be paid.
Remember, you don't have to solve everything in this ticket - you can solve it partially and leave todo markers in the code, which will become future tasks.
If you have any questions don't ask me, I'm not a technical person. Open new tickets instead.
If you don't have time or simply don't want to work on this, you can always resign.

@lisitsaaa Don't forget to close this ticket before the deadline (2023-11-29T15:01:21). You are past the first half of the allowed period.

@lisitsaaa Looks like you've missed the task deadline (2023-11-29T15:01:21). You are now resigned from this task.
Please stop working on it, you will not be paid. I will assign it to someone else soon.

@NikiTuz18 this is your task now, please go ahead. Deadline (when this ticket should be closed) is 2023-12-09T15:31:44.162904.
Estimation here is 60 minutes, that's how much you will be paid.
Remember, you don't have to solve everything in this ticket - you can solve it partially and leave todo markers in the code, which will become future tasks.
If you have any questions don't ask me, I'm not a technical person. Open new tickets instead.
If you don't have time or simply don't want to work on this, you can always resign.

@NikiTuz18 Don't forget to close this ticket before the deadline (2023-12-09T15:31:44). You are past the first half of the allowed period.

@NikiTuz18 Looks like you've missed the task deadline (2023-12-09T15:31:44). You are now resigned from this task.
Please stop working on it, you will not be paid. I will assign it to someone else soon.

@iColdLight this is your task now, please go ahead. Deadline (when this ticket should be closed) is 2023-12-19T16:01:25.540490.
Estimation here is 60 minutes, that's how much you will be paid.
Remember, you don't have to solve everything in this ticket - you can solve it partially and leave todo markers in the code, which will become future tasks.
If you have any questions don't ask me, I'm not a technical person. Open new tickets instead.
If you don't have time or simply don't want to work on this, you can always resign.

@iColdLight Don't forget to close this ticket before the deadline (2023-12-19T16:01:26). You are past the first half of the allowed period.

@iColdLight Looks like you've missed the task deadline (2023-12-19T16:01:26). You are now resigned from this task.
Please stop working on it, you will not be paid. I will assign it to someone else soon.

@l3r8yJ this is your task now, please go ahead. Deadline (when this ticket should be closed) is 2023-12-29T16:30:31.825488.
Estimation here is 60 minutes, that's how much you will be paid.
Remember, you don't have to solve everything in this ticket - you can solve it partially and leave todo markers in the code, which will become future tasks.
If you have any questions don't ask me, I'm not a technical person. Open new tickets instead.
If you don't have time or simply don't want to work on this, you can always resign.

@l3r8yJ Don't forget to close this ticket before the deadline (2023-12-29T16:30:32). You are past the first half of the allowed period.

@l3r8yJ Looks like you've missed the task deadline (2023-12-29T16:30:32). You are now resigned from this task.
Please stop working on it, you will not be paid. I will assign it to someone else soon.

@h1alexbel I couldn't find any assignee for this task. This is either because there are no contributors with role DEV available or because the project does not have enough funds.
Please, make sure there is at least one available contributor with the required role and the project can afford to pay them.


🎮 Game Request
Game logic and basic descriptionMancala is a two-player board game that has been played for centuries across various cultures. The game typically consists of a wooden board with 12 small pits or cups, arranged in two rows, with a larger scoring pit at each end called the "mancala". Each player controls the six cups on their side of the board, and the goal is to collect the most stones or seeds in your mancala by the end of the game.
Point down the features
Game points
Multiplayer modes
Engaging visuals and animations
Select program in which you are contributing
GSSoC24
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

Hey @manishh12 !
Thank you for raising an issue 💗
You can self assign the issue by commenting /assign in comment 😀
Make sure you follow CODE OF CONDUCT and CONTRIBUTING GUIDELINES 🚀
Don’t Forget to ⭐ our GameZone🎮
Make sure you join our Discord🕹

/assign

Hey @manishh12 ! Thank you so much for your raising the issue💗
It’s all yours, you can come anytime again and make some contributions! 🚀
Alone, we can do little, but together we can do so much! 😇


tensorflow: 1.9.0 -> 1.10.1

Motivation for this change
Upstream update
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build python3.pkgs.Keras python2.pkgs.Keras

Success on aarch64-linux (full log)
Attempted: python3.pkgs.Keras, python2.pkgs.Keras
Partial log (click to expand)
copying path '/nix/store/4kcc23p7axcxzq8swsgir7lzprxlnjbs-python2.7-Keras_Applications-1.0.4' from 'https://cache.nixos.org'...
copying path '/nix/store/131j7m6fgccgd32xvynnq08clpa8w3x3-python3.6-h5py-2.8.0' from 'https://cache.nixos.org'...
copying path '/nix/store/8yg7j9ydc1l2v31ysx1liycr2gcxzfj4-python3.6-scipy-1.1.0' from 'https://cache.nixos.org'...
copying path '/nix/store/425h8ngjjjrkv2pqz8ss61sqiwb1z0za-python2.7-Keras_Preprocessing-1.0.2' from 'https://cache.nixos.org'...
copying path '/nix/store/c3qxblr816af05cf9rk7wmqbffc71s2w-python3.6-Keras_Applications-1.0.4' from 'https://cache.nixos.org'...
copying path '/nix/store/sqmxyrn9nx464wlwsdzzvkralakjz8pk-python2.7-Keras-2.2.2' from 'https://cache.nixos.org'...
copying path '/nix/store/y2kzbyjdz512sa30iwbsbqcks2fjy9if-python3.6-Keras_Preprocessing-1.0.2' from 'https://cache.nixos.org'...
copying path '/nix/store/s9ncmqf7569bblwcdwdv1g5hkn500xim-python3.6-Keras-2.2.2' from 'https://cache.nixos.org'...
/nix/store/s9ncmqf7569bblwcdwdv1g5hkn500xim-python3.6-Keras-2.2.2
/nix/store/sqmxyrn9nx464wlwsdzzvkralakjz8pk-python2.7-Keras-2.2.2

Success on x86_64-linux (full log)
Attempted: python3.pkgs.Keras, python2.pkgs.Keras
Partial log (click to expand)
copying path '/nix/store/y57biarfbl988j25rkms17q7kkvlhyz1-python2.7-Keras_Applications-1.0.4' from 'https://cache.nixos.org'...
copying path '/nix/store/d03g3fr5qsg3v97rjvflm98bgyk4s5kf-python3.6-numpy-1.14.5' from 'https://cache.nixos.org'...
copying path '/nix/store/9rzy38fqnig6q8v2yl8i35xdirlwi7wa-python2.7-Keras-2.2.2' from 'https://cache.nixos.org'...
copying path '/nix/store/9gbm7c4bl2dmi4rx4183rnh838dqhhl5-python3.6-h5py-2.8.0' from 'https://cache.nixos.org'...
copying path '/nix/store/s3wjqkdi6sz8xp9cgn9mnqdjsscfknmr-python3.6-scipy-1.1.0' from 'https://cache.nixos.org'...
copying path '/nix/store/dailh3c67xbq4jc6y864wngg64q8qzvh-python3.6-Keras_Applications-1.0.4' from 'https://cache.nixos.org'...
copying path '/nix/store/xfs0ilxqwj0gky8w6zknxk227ncvhs01-python3.6-Keras_Preprocessing-1.0.2' from 'https://cache.nixos.org'...
copying path '/nix/store/4dry92hn300f1qlwykf9c4yjrlx1wvwl-python3.6-Keras-2.2.2' from 'https://cache.nixos.org'...
/nix/store/4dry92hn300f1qlwykf9c4yjrlx1wvwl-python3.6-Keras-2.2.2
/nix/store/9rzy38fqnig6q8v2yl8i35xdirlwi7wa-python2.7-Keras-2.2.2

Success on x86_64-darwin (full log)
Attempted: python3.pkgs.Keras, python2.pkgs.Keras
Partial log (click to expand)
Requirement already satisfied: six>=1.9.0 in /nix/store/xibkimbc2faad16k9rsvvssxspxajdly-python3.6-six-1.11.0/lib/python3.6/site-packages (from Keras==2.2.2) (1.11.0)
Requirement already satisfied: h5py in /nix/store/ni5bffgvfv09m248fzgadqvfrvaydyy8-python3.6-h5py-2.8.0/lib/python3.6/site-packages (from Keras==2.2.2) (2.8.0)
Requirement already satisfied: pyyaml in /nix/store/sym4r11pq4bvf4pwaj2gk1n8njisnciv-python3.6-PyYAML-3.13/lib/python3.6/site-packages (from Keras==2.2.2) (3.13)
Installing collected packages: Keras
Successfully installed Keras-2.2.2
/private/tmp/nix-build-python3.6-Keras-2.2.2.drv-0/Keras-2.2.2
post-installation fixup
strip is /nix/store/df6k4mgdjxciy0f637lryp7c9ln7n1m3-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/00pizxvsbgjz5wp79nyyyld7wqsv8vyf-python3.6-Keras-2.2.2/lib
patching script interpreter paths in /nix/store/00pizxvsbgjz5wp79nyyyld7wqsv8vyf-python3.6-Keras-2.2.2

@GrahamcOfBorg build python3.pkgs.tensorflow python2.pkgs.tensorflow

Success on x86_64-darwin (full log)
Attempted: python3.pkgs.tensorflow
The following builds were skipped because they don't evaluate on x86_64-darwin: python2.pkgs.tensorflow
Partial log (click to expand)
strip is /nix/store/df6k4mgdjxciy0f637lryp7c9ln7n1m3-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/305iabbn9da0bqkhpk4yi67xc71vh5c0-python3.6-tensorflow-1.10.1/lib  /nix/store/305iabbn9da0bqkhpk4yi67xc71vh5c0-python3.6-tensorflow-1.10.1/bin
patching script interpreter paths in /nix/store/305iabbn9da0bqkhpk4yi67xc71vh5c0-python3.6-tensorflow-1.10.1
/nix/store/305iabbn9da0bqkhpk4yi67xc71vh5c0-python3.6-tensorflow-1.10.1/lib/python3.6/site-packages/tensorflow/aux-bin/tflite_convert: interpreter directive changed from "/usr/bin/env python" to "/nix/store/dlswl7xjvh3bsfydygqzi2n0f82p5d9p-python3-3.6.6/bin/python"
wrapping `/nix/store/305iabbn9da0bqkhpk4yi67xc71vh5c0-python3.6-tensorflow-1.10.1/bin/toco_from_protos'...
wrapping `/nix/store/305iabbn9da0bqkhpk4yi67xc71vh5c0-python3.6-tensorflow-1.10.1/bin/freeze_graph'...
wrapping `/nix/store/305iabbn9da0bqkhpk4yi67xc71vh5c0-python3.6-tensorflow-1.10.1/bin/tflite_convert'...
wrapping `/nix/store/305iabbn9da0bqkhpk4yi67xc71vh5c0-python3.6-tensorflow-1.10.1/bin/saved_model_cli'...
wrapping `/nix/store/305iabbn9da0bqkhpk4yi67xc71vh5c0-python3.6-tensorflow-1.10.1/bin/toco'...
/nix/store/305iabbn9da0bqkhpk4yi67xc71vh5c0-python3.6-tensorflow-1.10.1

Failure on aarch64-linux (full log)
Attempted: python3.pkgs.tensorflow, python2.pkgs.tensorflow
Partial log (click to expand)
unpacking sources
patching sources
updateAutotoolsGnuConfigScriptsPhase
configuring
building
installing
/build/dist /build
tensorflow-1.10.1-cp36-cp36m-linux_x86_64.whl is not a supported wheel on this platform.
builder for '/nix/store/z5gvmddm4zgq3h8snad3dhmfdagq7ycy-python3.6-tensorflow-1.10.1.drv' failed with exit code 1
error: build of '/nix/store/ycsnndig14bqx42cn9rm8jlqhicm7w6y-python2.7-tensorflow-1.10.1.drv', '/nix/store/z5gvmddm4zgq3h8snad3dhmfdagq7ycy-python3.6-tensorflow-1.10.1.drv' failed

Success on x86_64-linux (full log)
Attempted: python3.pkgs.tensorflow, python2.pkgs.tensorflow
Partial log (click to expand)
patching script interpreter paths in /nix/store/li1j6jpgin0h8x9w34nxcc3p3d3vncyq-python3.6-tensorflow-1.10.1
/nix/store/li1j6jpgin0h8x9w34nxcc3p3d3vncyq-python3.6-tensorflow-1.10.1/lib/python3.6/site-packages/tensorflow/aux-bin/tflite_convert: interpreter directive changed from "/usr/bin/env python" to "/nix/store/hy65mn4wjswqih75gfr6g4q3xgqdm325-python3-3.6.6/bin/python"
checking for references to /build in /nix/store/li1j6jpgin0h8x9w34nxcc3p3d3vncyq-python3.6-tensorflow-1.10.1...
wrapping `/nix/store/li1j6jpgin0h8x9w34nxcc3p3d3vncyq-python3.6-tensorflow-1.10.1/bin/toco'...
wrapping `/nix/store/li1j6jpgin0h8x9w34nxcc3p3d3vncyq-python3.6-tensorflow-1.10.1/bin/saved_model_cli'...
wrapping `/nix/store/li1j6jpgin0h8x9w34nxcc3p3d3vncyq-python3.6-tensorflow-1.10.1/bin/tflite_convert'...
wrapping `/nix/store/li1j6jpgin0h8x9w34nxcc3p3d3vncyq-python3.6-tensorflow-1.10.1/bin/toco_from_protos'...
wrapping `/nix/store/li1j6jpgin0h8x9w34nxcc3p3d3vncyq-python3.6-tensorflow-1.10.1/bin/freeze_graph'...
/nix/store/li1j6jpgin0h8x9w34nxcc3p3d3vncyq-python3.6-tensorflow-1.10.1
/nix/store/85m63m4f503xfdb73ana1napizsz83zd-python2.7-tensorflow-1.10.1

@GrahamcOfBorg build protobuf3_6 python3.pkgs.tensorflow python2.pkgs.tensorflow python3.pkgs.tensorflow-tensorboard python2.pkgs.tensorflow-tensorboard

Success on x86_64-darwin (full log)
Attempted: protobuf3_6, python3.pkgs.tensorflow, python3.pkgs.tensorflow-tensorboard, python2.pkgs.tensorflow-tensorboard
The following builds were skipped because they don't evaluate on x86_64-darwin: python2.pkgs.tensorflow
Partial log (click to expand)
/private/tmp/nix-build-python2.7-tensorflow-tensorboard-1.10.0.drv-0
post-installation fixup
strip is /nix/store/df6k4mgdjxciy0f637lryp7c9ln7n1m3-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/k6ydn3vk0i07f2im7jips21fwfr40xak-python2.7-tensorflow-tensorboard-1.10.0/lib  /nix/store/k6ydn3vk0i07f2im7jips21fwfr40xak-python2.7-tensorflow-tensorboard-1.10.0/bin
patching script interpreter paths in /nix/store/k6ydn3vk0i07f2im7jips21fwfr40xak-python2.7-tensorflow-tensorboard-1.10.0
wrapping `/nix/store/k6ydn3vk0i07f2im7jips21fwfr40xak-python2.7-tensorflow-tensorboard-1.10.0/bin/tensorboard'...
/nix/store/kpawns8pc8n7l9bm1bampkgbdzxkln49-protobuf-3.6.1
/nix/store/305iabbn9da0bqkhpk4yi67xc71vh5c0-python3.6-tensorflow-1.10.1
/nix/store/avrvprkxba6s3pwwygqqp8gf0xr20190-python3.6-tensorflow-tensorboard-1.10.0
/nix/store/k6ydn3vk0i07f2im7jips21fwfr40xak-python2.7-tensorflow-tensorboard-1.10.0

Success on x86_64-linux (full log)
Attempted: protobuf3_6, python3.pkgs.tensorflow, python2.pkgs.tensorflow, python3.pkgs.tensorflow-tensorboard, python2.pkgs.tensorflow-tensorboard
Partial log (click to expand)
wrapping `/nix/store/li1j6jpgin0h8x9w34nxcc3p3d3vncyq-python3.6-tensorflow-1.10.1/bin/freeze_graph'...
wrapping `/nix/store/li1j6jpgin0h8x9w34nxcc3p3d3vncyq-python3.6-tensorflow-1.10.1/bin/toco'...
wrapping `/nix/store/li1j6jpgin0h8x9w34nxcc3p3d3vncyq-python3.6-tensorflow-1.10.1/bin/saved_model_cli'...
wrapping `/nix/store/li1j6jpgin0h8x9w34nxcc3p3d3vncyq-python3.6-tensorflow-1.10.1/bin/toco_from_protos'...
wrapping `/nix/store/li1j6jpgin0h8x9w34nxcc3p3d3vncyq-python3.6-tensorflow-1.10.1/bin/tflite_convert'...
/nix/store/1krnj68gh7b5cg3qpcf291k9g5gy1ky7-protobuf-3.6.1
/nix/store/li1j6jpgin0h8x9w34nxcc3p3d3vncyq-python3.6-tensorflow-1.10.1
/nix/store/85m63m4f503xfdb73ana1napizsz83zd-python2.7-tensorflow-1.10.1
/nix/store/033z8afzig8h59r3bn2c0rn878jpg92z-python3.6-tensorflow-tensorboard-1.10.0
/nix/store/hczcsrmqhvaqd5ccc882sp78fw2z501d-python2.7-tensorflow-tensorboard-1.10.0

@xeji note that tensorboard is a dependency of tensorflow (weird I know).
@FRidh right, please let me know if I'm not doing things as they should be done.

@jyp Could you rebase onto the current master? Since #47353 Protobuf 3.6 is the default.

@orivej Done, thanks for the heads up.
@FRidh Please re-consider merging this :)

Could you remove the old hashes file, otherwise looks fine.

@globin I have removed the old hashes. Also, tensorflow 1.11 was released, so I have updated to that.

@GrahamcOfBorg build python3.pkgs.tensorflow python2.pkgs.tensorflow

Failure on aarch64-linux (full log)
Attempted: python3.pkgs.tensorflow, python2.pkgs.tensorflow
Partial log (click to expand)
unpacking sources
patching sources
updateAutotoolsGnuConfigScriptsPhase
configuring
building
installing
/build/dist /build
tensorflow-1.11.0-cp36-cp36m-linux_x86_64.whl is not a supported wheel on this platform.
builder for '/nix/store/cijd4yqir9n8v9rl4vlc6j8jyj6nz6pm-python3.6-tensorflow-1.11.0.drv' failed with exit code 1
error: build of '/nix/store/cijd4yqir9n8v9rl4vlc6j8jyj6nz6pm-python3.6-tensorflow-1.11.0.drv', '/nix/store/sdwzgiz6zyfxrs2i6pqaghzp2hwd8r1w-python2.7-tensorflow-1.11.0.drv' failed

Success on x86_64-darwin (full log)
Attempted: python3.pkgs.tensorflow
The following builds were skipped because they don't evaluate on x86_64-darwin: python2.pkgs.tensorflow
Partial log (click to expand)
strip is /nix/store/53nysl8bqwxihwzs1pgwka20nf8mbvlp-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/0mhr5rrfa8n3kan0san1crjr3ijj7jmg-python3.6-tensorflow-1.11.0/lib  /nix/store/0mhr5rrfa8n3kan0san1crjr3ijj7jmg-python3.6-tensorflow-1.11.0/bin
patching script interpreter paths in /nix/store/0mhr5rrfa8n3kan0san1crjr3ijj7jmg-python3.6-tensorflow-1.11.0
/nix/store/0mhr5rrfa8n3kan0san1crjr3ijj7jmg-python3.6-tensorflow-1.11.0/lib/python3.6/site-packages/tensorflow/aux-bin/tflite_convert: interpreter directive changed from "/usr/bin/env python" to "/nix/store/8rw1vq2k50g7jgniskzs51qjb47w8nhz-python3-3.6.6/bin/python"
wrapping `/nix/store/0mhr5rrfa8n3kan0san1crjr3ijj7jmg-python3.6-tensorflow-1.11.0/bin/freeze_graph'...
wrapping `/nix/store/0mhr5rrfa8n3kan0san1crjr3ijj7jmg-python3.6-tensorflow-1.11.0/bin/saved_model_cli'...
wrapping `/nix/store/0mhr5rrfa8n3kan0san1crjr3ijj7jmg-python3.6-tensorflow-1.11.0/bin/tflite_convert'...
wrapping `/nix/store/0mhr5rrfa8n3kan0san1crjr3ijj7jmg-python3.6-tensorflow-1.11.0/bin/toco'...
wrapping `/nix/store/0mhr5rrfa8n3kan0san1crjr3ijj7jmg-python3.6-tensorflow-1.11.0/bin/toco_from_protos'...
/nix/store/0mhr5rrfa8n3kan0san1crjr3ijj7jmg-python3.6-tensorflow-1.11.0

Success on x86_64-linux (full log)
Attempted: python3.pkgs.tensorflow, python2.pkgs.tensorflow
Partial log (click to expand)
patching script interpreter paths in /nix/store/6ckfdl9l0vny7mnsq6my57dp0i0pkclr-python3.6-tensorflow-1.11.0
/nix/store/6ckfdl9l0vny7mnsq6my57dp0i0pkclr-python3.6-tensorflow-1.11.0/lib/python3.6/site-packages/tensorflow/aux-bin/tflite_convert: interpreter directive changed from "/usr/bin/env python" to "/nix/store/nrl0l79a48924xb0897ap572xf29ciir-python3-3.6.6/bin/python"
checking for references to /build in /nix/store/6ckfdl9l0vny7mnsq6my57dp0i0pkclr-python3.6-tensorflow-1.11.0...
wrapping `/nix/store/6ckfdl9l0vny7mnsq6my57dp0i0pkclr-python3.6-tensorflow-1.11.0/bin/freeze_graph'...
wrapping `/nix/store/6ckfdl9l0vny7mnsq6my57dp0i0pkclr-python3.6-tensorflow-1.11.0/bin/toco'...
wrapping `/nix/store/6ckfdl9l0vny7mnsq6my57dp0i0pkclr-python3.6-tensorflow-1.11.0/bin/saved_model_cli'...
wrapping `/nix/store/6ckfdl9l0vny7mnsq6my57dp0i0pkclr-python3.6-tensorflow-1.11.0/bin/tflite_convert'...
wrapping `/nix/store/6ckfdl9l0vny7mnsq6my57dp0i0pkclr-python3.6-tensorflow-1.11.0/bin/toco_from_protos'...
/nix/store/6ckfdl9l0vny7mnsq6my57dp0i0pkclr-python3.6-tensorflow-1.11.0
/nix/store/3n27wdjsqiaj26n340acm55zykf55pz5-python2.7-tensorflow-1.11.0


doesn't respect WCAG contrast recommendations

https://webaim.org/resources/contrastchecker/?fcolor=C3C3C3&bcolor=FFFFFF

https://webaim.org/resources/contrastchecker/?fcolor=E0E0E0&bcolor=FFFFFF

It looks like we use the default placeholder styles nowadays which is #757575 on #ffffff in Chrome for example which passes all of the WCAG checks.

And that screen after doesn't look relevant anymore.


Some places missing error handlings of pthread_mutex_lock

Hi, there are some places missing handling the possible errors that return from pthread_mutex_lock that are not consistent.
unhandled
https://github.com/Linaro/uadk_engine/blob/8f9bf25903a019fde04761a0c1dd2757cd680a16/src/v1/utils/engine_log.c#L98-L100
https://github.com/Linaro/uadk_engine/blob/8f9bf25903a019fde04761a0c1dd2757cd680a16/src/v1/utils/engine_log.c#L115-L117
handled
https://github.com/Linaro/uadk_engine/blob/8f9bf25903a019fde04761a0c1dd2757cd680a16/src/v1/wdmngr/wd_queue_memory.c#L391-L393
https://github.com/Linaro/uadk_engine/blob/8f9bf25903a019fde04761a0c1dd2757cd680a16/src/v1/wdmngr/wd_queue_memory.c#L397-L400

could you send pr, thanks

OK.
I have a question. Could all these cases be safely handled by checking the return values and directly returning to the callers?

The code is directly copy from kae, which is used in product.
I think in normal case we can simply ignore the return value.
https://www.man7.org/linux/man-pages/man3/pthread_mutex_lock.3p.html
The mutex object referenced by mutex shall be locked by a call to
pthread_mutex_lock() that returns zero or [EOWNERDEAD].  If the
mutex is already locked by another thread, the calling thread
shall block until the mutex becomes available.


Feature/button styling 280

Copied hover, active, focus button pseudo states from official GDS button at: https://govuk-elements.herokuapp.com/buttons/
':hover': {
   backgroundColor: '#00692f',
   color: WHITE,
 },
 ':focus': {
   color: WHITE,
   backgroundColor: '#00692f',
   outline: `3px solid ${YELLOW}`,
 },
 ':active': {
   position: 'relative',
   top: '2px',
   boxShadow: `0 0 0 ${BUTTON_COLOUR}`,
   WebkitBoxShadow: `0 0 0 ${BUTTON_COLOUR}`,
   MozBoxShadow: `0 0 0 ${BUTTON_COLOUR}`,
 },

Checklist:

[x] Documentation
[x] Tests
[x] Ready to be merged

closes #280

Codecov Report

Merging #292 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master   #292   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files          69     69
  Lines         373    373
  Branches       10     10
=====================================
  Hits          373    373

Impacted Files
Coverage Δ

components/button/src/index.js
100% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Enemies can hit player through doors

Summary
An enemy with a melee weapon can hit the player through a closed door.

Created an issue on the Delver side of things.


Define input format for production data

I QA'd it, it's the REST API wiki page. It looks pretty alright.


Event Bus

Pub/Sub pattern is great for decoupling different modules of the application. In large it allows to separate big engines like Worksheet and Calendar, but you can use it in small for decoupling different objects, for example Controller from the UseCase or different parts of same engine
We could use wisper for general Pub/Sub implementation (for "in small" decoupling but also for synchronous events) and wisper-sidekiq for async events.

[ ] wisper-sidekiq vs wisper-celluloid (used by sidekiq under the hood) vs wisper-activejob (which abstracts all job frameworks like sidekiq)
[ ] or maybe we go with something full-blown like message_bus which allows to also communicate with the client app (frontend app, mobile app etc.)
[ ] or... something like RabbitMQ for reliability and high availability. although sidekiq works for us so far so why should it fail us now?

https://github.com/nedap/railjet-bus 🤷♂ 😉


Lone Question Mark in Regex in Sublime Syntax File

Is the lone question mark in line 28 of the sublime syntax file intentional?
https://github.com/kurokirasama/nushell_sublime_syntax/blob/395c382aa2aa3d3ae4cfb701086af905eeaba2b4/nushell.sublime-syntax#L28C1-L28C2429
Trying to use it as syntax for bat raises an error as the regex is not valid.
Escaping the question mark as \? fixes this issue.

hey, sorry for the delay.
Yes, I just took the a sublime template syntax file and modified it for nushell


License button missing, why ?

Licensing.
Before their was a button to add a license file to the repository into the repository interface, which has disappear.
Is it because the License file into the repository has prior and it make messing the repository and so it is intentional.
Adding tags is a good idea for github.

@mrcyberfighter there's a button on the new repository page, see https://help.github.com/articles/licensing-a-repository/#applying-a-license-to-a-repository-with-an-existing-license and for existing repositories see https://help.github.com/articles/adding-a-license-to-a-repository/
Regarding tags, check out https://help.github.com/articles/classifying-your-repository-with-topics/
If you have other questions or suggestions I suggest contacting support at https://github.com/contact
Closing this as it isn't directly pertinent to GitHub's site policies.


access to repo

@diasdavid I was trying to create a branch windows-interop and I was denied access.

@richardschneider just invited you to the JS team in this org as well :)


DNS error check only MX Record ?

Wouldn't it be a viable case for a valid email with a correct MX record, but no A-record? Email will be received that way.
It's an edge case, but wouldn't it be more correct to change
return !\checkdnsrr($domain . '.', 'MX') || !\checkdnsrr($domain, 'A');
to
return !\checkdnsrr($domain . '.', 'MX');
in the code here ?

Thanks for the bug-report ... and yep, I think you are right and it's fixed in version 3.0.1 -> see https://github.com/voku/email-check/commit/2acff4fcffe0bd49de8d55a414c3dc6f7498fcb9#diff-9bf7e6c7e7ec373eb21aeb4f55a2a020R254


Update list and review commands in the user guide

Codecov Report

Merging #45 (bd18c0f) into master (5906c25) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #45   +/-   ##
=========================================
  Coverage     70.36%   70.36%
  Complexity      376      376
=========================================
  Files            70       70
  Lines          1208     1208
  Branches        113      113
=========================================
  Hits            850      850
  Misses          319      319
  Partials         39       39

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Browser Support: does it support all the major browsers

Hi ,greetings. Just a plain simple browser question : Does this test framework support all major browsers.
Thx
K.thulsi doss

Hi @kthulsidoss. Yes, all major browsers are supported (Chrome, Firefox, Edge, IE, Safari, Opera).


Multipart Request Body Support

Added support for multipart/form-data request body content. The support is a thin layer over the client-specific implementations which means that, for now at least, the core Java implementation does not support mutlipart requests.
There is some transitional work in here pending more detailed refactoring of the parsers and encoders.
This fixes #1

BTW, this branch and cookie-fixes should both merge cleanly into development, I just did a test merge locally and git had no issues.

Yeah, I actually had support for making a file entry with an InputStream but I got lazy. :-) I will add that back in and finish it. Also, I may have simple minimal mutlipart support for the Java client too - I will make these changes and then merge.

I was just thinking this morning that most of the parser/encoder infrastructure we have built up could be re-used for multipart support. After all multipart is just a series of content parts with associated content types.
So something like:
multipart {
    part 'application/json', pogo1
    part 'application/xml', pogo2
}

would make multipart basically identical to defining the request body. We would just have to pass the current encoder/parser configuration to the multipart and it could use all of the encoders/parsers for that request.

Hmm. I like that idea. I should be able to roll that in with what I have.

@dwclark Conceptually your suggestion works; however, the encoders are a bit coupled to the builders themselves - it is difficult to get the part content since the encoders generally translate the entire body content. Also, writing out the resulting data to the ToServer would have to be adapted to allow the part collection before writing to the overall message ToServer instance. This seems like a cleaner approach from a user perspective (and even code reuse) but we would need to refactor the encoders to be less dependent on their calling environment - something more like:
Function<Object,byte[]> encoder = new Function<Object,byte[]>(){
    byte[] apply(Object input){
        // transform the input to the encoded output...
    }
}

We could include other arguments if needed, but something like this would allow for them to be used in the multipart encoding.

I think what we have now coverts the cases. In fact if Multipart implements ToServer and InputStream it becomes really simple. For example if we have this:
request.contentType = 'multipart/form-data'
request.body = multipart {
  file 'image/jpeg', 'icon','user-icon.jpg', imageFile
  part 'application/json', pogo1
  part 'text/xml', pogo2
}

And we also have configuration that is the equivalent of this:
HttpBuilder.configure {
  request.encoder 'multipart/form-data', Multipart.&encoder
  response.parser 'multipart/form-data', Multipart.&parser
}

Then since Multipart implements InputStream the encoder method is as simple as this:
void encoder(final ChainedHttpConfig config, final ToServer ts) {
  final ChainedHttpConfig.ChainedRequest request = config.getChainedRequest();
  Multipart mp = (Multipart) request.actualBody();
  mp.setConfig(config);
  ts.toServer((Multipart) request.actualBody(), request.actualCharset());
}

since Multipart implements InputStream that works. Now that Multipart has the entire configuration for the request we can do the stream part of the data transfer lazily and however we want. Essentially we only encode data as needed and we use all of the encoders to write their content to the input stream we are working with. In pseudo-code the read() operations just become:

//somewhere in multipart

private InputStream currentStream;

public void toStream(InputStream stream) {
  this.currentStream = stream;
}

private void putPartHeader(byte[] b, Part p) {
  //do the right thing
}

private void putStreamToBytes(byte[] b) {
  //do something intelligent with currentStream
}

int read(byte[] bytes) {
  for(Part p : multipart.parts) {
    putPartHeader(bytes, p);
    BiFunction f = config.actualEncoder(p.contentType);
    f.apply(config, multipart); //works since Multipart implements ToServer
    putStreamToBytes(bytes)
  }

  return bytes.length;
}

Interesting idea... I will take a look at this over the weekend.

The nested ToStream approach you mentioned won't work. The encoders all assume that the body content is the thing they are encoding - this goes back to potentially needing a different encoder interface. I am going to try it with a wrapper around the ChainedHttpConfig but the code is getting close to the approach I mentioned earlier. I'll let you know what I end up with, but looking at something like:
final NestedToServer toServer = new NestedToServer();
BiConsumer<ChainedHttpConfig,ToServer> encoder = config.findEncoder(part.getContentType());
encoder.accept(new PartConfig(config), toServer);
buffer.write(toServer.getBytes());

you can't write directly to the InputStream since its read only (hence the byte-gathering adapter).

Would it clean things up to push some of the code to the ChainedRequestConfig? Internally it would have to track whether it is working with a single request or multi-part. It would then provide the correct body and content type for each stage of the multi-part encoding. Just thinking out loud.
If we provide a generic multipart implementation, we can get rid of the client specific ones, I don't think we need to provide a way to use either, that sounds like it's more trouble than it's worth.

I think I have a good working solution based on the above... I am refactoring the client-specific multipart encoders to behave in a similar manner; however, I would like to keep them around as client-specific alternatives since our implementation is not full-featured. It looks like I can pull out a helper method for doing "embedded encoding" in the multipart cases. I am cleaning up and trying to get the dust to settle with what I have done.

I am closing this PR and will open a new one once the new code is ready... enough changes that it should have its own PR.


[move-prover] Introduce choice operator for spec language.

Often times in the Diem specs we need to choose a value from a collection of values (typically a vector) which satisfies a certain predicate. Sometimes we also need to choose the smallest index into a vector s.t. a predicate is fullfilled. This PR introduces two choice operators which supports this.
For example, to choose a value in a vector we use this syntax:
choose v in vec where v.addr == validator_addr

To choose the smallest index we use:
choose min  i in 0..len(vec) where vec[i].addr == validator_addr

In general, the some/min keyword is followed by a single variable declaration which supports the same features as in quantifiers (x in v or x: T), followed by a where and a predicate.
Choices can use memory and refer to aribtrary variables in the context, including old(..) expressions. They can also be used in spec functions.
Semantically a choice is translated into an axiom of the following form:
axiom (forall CTX :: (exists X :: pred(X, CTX)) ==> pred(choice_fun(CTX), CTX))

Here, CTX represents variables captured from the context of the choice, X the variable of the choice, pred a predicate incorporating all constraints from the variable declaration and the condition after the where, and choice_fun an uninterpreted function which is introduced for the choice expressions. Notice that we need the premise with the existential quantifier because pred(X, CTX) might not be satisfiable, and we would introduce an inconsistency without this check. For specifications this means that if the choice's predicate is not satisfiable, the result of the choice operator is undetermined.
New test cases have been introduced in choice.move which illustrate usage.

Motivation
Nicer specs.
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
Added new test.
Related PRs
NA

I greatly prefer "choose" over "some" as the operator name because I'm used to "some" being used as a synonym for "there exists" in math.
Perhaps we should also have a "max" operator?

Naming this now choose. Also using choose min to not confuse this with a general min/max over a collection. I don't see a need for choose max but we can add it once we come along a need.

/land


Thoughts on serialize/deserialize?

Thinking about serialization to support persistence in a key/value store or transferring/synchronizing state over the wire.
Serialize:
JSON.stringify(f.hexastore.queryXXX(null, null, null))

Deserialize:
var f = new Factis();
var list = JSON.parse('[["Factis","is","nice",true],["Factis","is","fast",true]]');

var facts = list.map(function(i) {
  this.f.fact.apply(f, i);
});

f.add(facts);

Should these be a part of the standard API?
Where would you like them?
Can you think of a more performant or optimal way to do this, or does this seem nice?

Happy to submit a pull request.

Done,
You should now be able to import and export to strings as explained on http://factis.io:
var myExportString = f.hexastore.exportString();
f.hexastore.importString(myExportString);

There are also methods to export to files of different formats when used within node.js. These functions are not yet documented because i did not test them properly yet. Here they are:
exportJSON and importJSON for json files
exportZip and importZip for json files compressed in a zip file
exportNt and importNt for NT files (basic support)
Let me know if there are any problems.

Interesting solution!  I like it.  I didn't at first glance realize that you already have all the data you need to regenerate all indexes from just the SPO property.  Neat!


do_not_synchronize doesn't work

I believe this should stop the websocket server pushes for this and all inheriting models, but doesn't seem to. Pushes still happen, can be seen in server logs / browser.
class ApplicationRecord < ActiveRecord::Base
  do_not_synchronize
end

its because the internal instance data is not being inherited correctly

I have started selectively putting do_not_synchronise in models that don't need to update live, to reduce broadcast traffic. It works fine like that.
Before I was trying to use it in ApplicationRecord to have it inherited but that didn't work. I guess it would be useful to have it be inherited, though it's also easy to patch with included. In fact sticking it in a Concern might work too.

probably need a way to turn it on and off then
i.e. turn it off in ApplicationRecord, but then turn it back in specific modules.


Update devContainer schema - Adds overrideFeatureInstallOrder

Reported in https://github.com/devcontainers/spec/issues/175
Update the schema to avoid the incorrect prompt of VS Code hints!

Doc - https://containers.dev/implementors/features/#overrideFeatureInstallOrder

Fixing with https://github.com/devcontainers/spec/issues/93 by referencing the schema in the spec repository. Thanks!


Deprecated functions

The uniDecode and uniEncode functions were deprecated in LC 7.0 around 2014. I suggest replacing them with the equivalent textEncode and textDecode. Only a suggestion, thanks!
https://github.com/Ferruslogic/PhotonJSON/blob/3751420e316e4cef829276ddb90e5f0a2e216487/PhotonJSON.livecodescript#L565-L580

Thanks @Monox18, those functions have already been changed to their textDecode or textEncode equivalent. That made me think that you also don't have to do a check to see if the text is UTF-8. Since in the help it is specified that this library receives and returns a UTF-8 string.

Thanks! Yah it makes sense to keep it UTF-8 on the developer side. I have also tested on my application and replaced fastJSON with this improved PhotonJSON which I believe is more future proof now.


User and Item features?

Hi! Is there a way to add user and item features to the model just like LightFM?

Oh! I am so glad to hear that!
Here are some quick guidelines for you!
Please feel free to comment if you have any questions.


Replay saving function needs rewriting

This is all retarded, but couldn't make my brain work while writing it and thinking in all the promise layers. Should be a way to not have duplicated code here.

Fixed by 920dfac


[BUG] erratic application of Suddden Death modifier

Sometimes the Sudden Death game modifier is not applied as expected from the system preview.
Sometimes the Sudden Death game modifier is applied contrary to the system preview.
The Sudden Death Tech Card has NOT been selected.
In this most recent occurrence, the Sudden Death modifier was applied to the Legonis Machina faction on the Hatuamoto system contrary to the system preview as shown in the supplied screen shot.
The Cluster faction was still active when this occurred, so I immediately closed the game to save the files.
I was able to replay that system and duplicate the results. (and immediately close game with Cluster faction still active)
You might be able to restart that match from the supplied files?
Supporting files available at https://drive.google.com/drive/folders/1mqy2zY9MlGc_WivkKmmEk766zmJs-gfc
If needed, I can duplicate the results but complete the match and submit a new set of files.

Looking closer at the server file, the starting planet reads

"land_anywhere":true,"bounty_mode":true,"bounty_value":0.2,"sudden_death_mode":true

Whereas the preview mentions only Bounties.
This might be a broader issue than I initially thought.
There is typically only one game modifier applied per system, yes?

I have since seen where all 3 game modes were listed in the system preview

I don't have access to the linked file.

Here is an example of the reverse. The preview for Naubakht system indicates Sudden Death mode but the server file has > "sudden_death_mode":false
Appropriate files located at https://drive.google.com/drive/folders/1qYCgf1YY8qsj5yQ-zhLHzvLAooJbCo4q


Using search with ui-dropdown causes action to be fired twice

{{#ui-dropdown class="ui fluid search selection" selected=selected_type onChange=(action 'myEvent') as |execute mapper|}}
myEvent gets fired twice
This can be repeated with the example app

using selected together with onChange causes this, not search class, at least in my case.

Tested and not the case in example app.
This can be closed


Remove IE-only types from lib.d.ts

The various MS* interfaces and vars don't exist except in IE, and their extra properties are added to the standard properties. Eg: HTMLElement.style is of type MSStyleCSSProperties instead of CSSStyleDeclaration, which allows element.style.pixelWidth to compile but be undefined at runtime.

@zhengbli has a change to update lib.d.ts to remove them. see PR #2645

That PR gets rid of pixelWidth and style is now CSSStyleDeclaration, but I see it's added ms- and webkit-prefixed properties and functions. That would lead to the same problem.
But I can see the usefulness of wanting to support code like var animation = style.animation || style.webkitAnimation; Should it also include moz-prefixed stuff then?

These are auto generated; @zhengbli has a script that allows creating the lib file from webidl definitions. we can augment the script to add these definitions as well, assuming we have a webidl for them.

Yeah the new spec got ride of many of those interfaces but some still remain. I guess after publishing the script it is possible to create a customized version that removes all IE-only content.

Can we remove the ones that are not needed from extensions.d.ts, specifically Map, Set and the typed arrays?

Yeah I'm working on that too. Thanks!

I ran a little analysis of the extension interfaces, and found out the use count of each one:
ArrayBuffer: 5
ArrayBufferView: 17
Int8Array: 0
Uint8Array: 7
Int16Array: 0
Uint16Array: 0
Int32Array: 4
Uint32Array: 0
Float32Array: 21
Float64Array: 0
DataView: 0
Map: 0
WeakMap: 0
Set: 0
I plan to remove the unused ones and keep the others if that looks good.

Here is what i propose:
From extenstions.d.ts remove:
DataView: 0
Map: 0
WeakMap: 0
Set: 0
Update types in extentions.d.ts to use the same typings in es.d.ts
ArrayBuffer: 5
ArrayBufferView: 17
Int8Array: 0
Uint8Array: 7
Int16Array: 0
Uint16Array: 0
Int32Array: 4
Uint32Array: 0
Float32Array: 21
Float64Array: 0

should be fixed by #2739


How I can have a server purchase verification?

A simple answer is

add a verification code connecting to your server side in in-app purchase callbacks
if the server says ok, give the purchase to the client consuming it or not depending of the type


Consistent naming for Docker images built

I was having problems building the Docker image.
Here is how I tried:
$ git clone git@github.com:openshift/jenkins.git openshift-jenkins
    Cloning into 'openshift-jenkins'...
    .......
    Resolving deltas: 100% (786/786), done.

$ cd openshift-jenkins

$ docker images
    <NOTHING>

$ make build TARGET=centos7 VERSION=2
    .......
    .......
    Successfully built 22ba8f27048c

$ docker images
    openshift/openshift-2-centos7      latest              22ba8f27048c        24 seconds ago      1.25 GB

build.sh script is doing some magic based on the directory name. However, the target image will have a weird name if the sources are checked out in a directory named differently.
Following works (when I don't specify the clone target dir):
$ git clone git@github.com:openshift/jenkins.git
    Cloning into 'jenkins'...
    .......
    Resolving deltas: 100% (786/786), done.

$ cd jenkins

$ docker images
    <NOTHING>

$ make build TARGET=centos7 VERSION=2
    .......
    .......
    Successfully built 85adbe9718ae

$ docker images
    openshift/jenkins-2-centos7        latest              85adbe9718ae        43 seconds ago      1.25 GB

With the PR, I got rid of the part where build.sh is trying to do the magic and building the image name based on that.
I can see that build.sh is only used in Makefile and my change will result in consistency.
With the PR, doing the first operation above will result in openshift/jenkins-2-centos7 no matter what the directory is.
I was trying to understand why there is such a logic, but I couldn't.

i think this was because we originally shared this build script between different repos, so it was kept generic, but the simplification seems reasonable at this point.
[test]

Ok, seems understandable.


[WGScan] Hidden files in PC...

After testing on Non-Steam I deleted it from the computer and after a couple of days when I ran WGScan on my Steam account, WG Scan marked me as "Found Oxware Data", which means that somewhere this program recorded some registry. Big zero for this cheat even though I just downloaded it to test it on my server. Next time make the installation so that clients can run Uninstall.exe to delete all files and registries.

amx

https://www.wargods.ro/wcd/report.php?id=2885037

Yes, I was planning to implement a feature that would mitigate that findage.
BTW: there's a section for uninstalling in the README section.


Group related lines together by printed headers

"Installing Homebrew packages ..."
"Restarting services ..."
"Relinking OpenSSL ..."
"Configuring Ruby ..."
"Running your customizations from ~/.laptop.local ..."
"Cleaning up old Homebrew formulas ..."

To make that work in the desired way,
print less noise in the custom functions.

I like the printed headers but not sure "Homebrew" is descriptive enough. Could take the comment idea from https://github.com/thoughtbot/laptop/pull/392/files and use the printed header idea here.

Made the middle section more specific:
Updating Homebrew formulae ...
Already up-to-date.

Updating Unix tools ...
Warning: thoughtbot/formulae/rcm-1.3.0 already installed

Updating Heroku tools ...
Warning: thoughtbot/formulae/parity-<IP_ADDRESS> already installed

Updating GitHub tools ...

Updating image tools ...

Updating testing tools ...

Updating programming languages ...

Updating databases ...
/Users/croaky/Library/LaunchAgents/homebrew.mxcl.postgresql.plist -> /usr/local/opt/postgresql/homebrew.mxcl.postgresql.plist
/Users/croaky/Library/LaunchAgents/homebrew.mxcl.redis.plist -> /usr/local/opt/redis/homebrew.mxcl.redis.plist

Updating OpenSSL ...
Unlinking /usr/local/Cellar/openssl/1.0.2e... 1556 symlinks removed
Linking /usr/local/Cellar/openssl/1.0.2e... 1556 symlinks created

Cool, looks good.


docs(readme): clean up documentation

Codecov Report
Base: 90.52% // Head: 90.52% // No change to project coverage :thumbsup:

Coverage data is based on head (c006093) compared to base (ce9fb75).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##           master      #31   +/-   ##
=======================================
  Coverage   90.52%   90.52%
=======================================
  Files          33       33
  Lines        2449     2449
=======================================
  Hits         2217     2217
  Misses        158      158
  Partials       74       74

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Project Report Paper 1.1 - 2.2

SeniorDesignFinalReportFall.docx
Please complete sections 1.1 - 2.2 of the project report paper. We have enough progress to be able to write up to that point. You can either divide the work into three or come together and work on each section as a collective. Its up to you on how to tackle the collaboration aspect of this.

Got it. I'll work on that between work and class. Meaning I'll probably skip the lecture to make sure it's good to go


yml first step

A quick note for authorize filter failed test, the cause for null expectation in src/Serilog.Ui.Web/SerilogUiMiddleware.cs and line
var htmlStringBuilder = new StringBuilder(await new StreamReader(stream).ReadToEndAsync()); is the index.html file does not exist and the command npm run build is not executed.

@mo-esmp yep, thanks, you're right! I'll take the chance on this branch to also fix these tests 😊
I'll probably wait to pr-it until there's the new repo 😊

A couple of days ago I requested to transfer the repo and waiting to be processed.

That's an awesome news, thanks for the update! 😊

Nice job, all green checks!

Yes! Still need to tweak and fix the c# part though 😂
Maybe after that I'll give a try to Nuke as a Build tool 😊


test: build error on master

https://travis-ci.org/inveniosoftware/invenio-records-files/jobs/530783782

Closed by https://github.com/inveniosoftware/invenio-records-files/pull/75.


initial consul leader implementation

Leader election via consul.
Follows the leader election guide. Uses the session http api .
See session internals for more information.
/cc @pperalta @dsyer @jvalkeal @mstine

A few of my initial thoughts include the following scenarios:
Lease non-renewal

Process starts up and acquires lock
Background thread renews lease (via ConsulLeaderRenewer)
Exception is thrown in ClusterLeaderInitiator.renew()

Is the lock released? Is candidate.onRevoked() invoked?
Lock already held

Process starts up
It tries to acquire lock but lock is already held

Will the process continue attempting to acquire the lock, or will it give up?
Session TTL
Is TTL mandatory? What happens if no TTL is in use and the lock holder dies?

Any idea when this get merged?

When all of the suggestions get implemented.

Will the consul leadership election be implemented on Spring Integration? Since the branch was closed I cannot see any branch on SI with this initiative. Thank you!

I don't see any activity there either. If I were you I'd talk to the Spring Integration team. There might be an extension project?


[Question][Deployment] Webhook:  is allowed for required?

Question
I am referencing https://devlake.apache.org/docs/Plugins/webhook/#deployment and noticed that pipeline_id, repo_url, and commit_sha allowed <no value> or null ...even though they are required...is this expected?
Using version: 1.0.0-beta9
Screenshots

Additional context
SELECT cicd_scope_id, commit_sha, repo_url, result
FROM cicd_deployment_commits

edit: or could it be that it is inserting the literal <no value> into the DB? I am dynamically grabbing these values via annotations

nevermind..seems that it is inserting the literal  into the DB I am dynamically grabbing these values via annotations ...and not doing it correctly..but instead of passing "" or null ..it is passing in the literal value <no value>


Add ingressClassName as an optional chart value

Issue: https://github.com/rancher/rancher/issues/37971
This exposes ingress.ingressClassName as a value in the main chart.
For Rancher setups using RKE-provisioned Kubernetes clusters, this changes nothing because RKE ensures an Nginx Ingress controller watches for ingress rules without an ingressClassName specified and sets it.
But for cases where Rancher is installed on non-RKE clusters, this change enables users to specify the class name for the relevant ingress controller (Nginx, Traefik) on the command line to Helm. This will set the value of ingressClassName to the name of the ingress controller on the rancher ingress resource.
By default, the value is an empty string because we cannot make assumptions about the exact ingress controller that people might want to use with a non-RKE cluster for Rancher.
I have document the new value in the chart's README and will also add a separate non-urgent docs issue where we need
to update the instructions for EKS and GKE. We just want to link to the ingress-nginx documentation, which has more details on updates to ingress-nginx here: https://kubernetes.github.io/ingress-nginx/#faq-migration-to-apiversion-networkingk8siov1
We already have this link for AKS.

@MbolotSuse, yes, I did test this scenario before opening the PR.
I provisioned an EKS cluster and installed ingress-nginx 4.0.18.
With it, Rancher v2.6.5 is not accessible because the ingress controller rejects Rancher's ingress. When I simply upgrade the Rancher release to the custom chart with a newer image and do not specify the ingress.ingressClassName value at all, the ingress still does not have the class name, so the controller rejects it again. Only when I upgrade and DO specify the class name, the controller accepts Rancher's ingress definition, and Rancher can be accessed.
So this works as we want. One interesting little detail is that the Rancher image version does not matter, when I upgrade to a different image, helm spins down existing Rancher pods and gradually deploys new ones. But the ingress change is visible immediately, the ingress controller properly receives the request even while the old pod is still available.

QA Testing
Root cause
Rancher may be unavailable to external requesters if the ingress controller
does not validate Rancher's ingress resource when it does not define ingressClassName in its definition.
This has been detected with the nginx ingress controller of a version greater than 4.x.
Users whose Rancher instances are backed by RKE clusters do not face this issue because
RKE, when setting up the local cluster, takes care to instruct the nginx ingress controller
to automatically insert the ingressClassName with a value of nginx if it's missing.
This does not happen with EKS or GKE clusters, so Rancher instances backed by those providers, and taking
advantage of the nginx ingress controller, may face this issue.
What was fixed, or what changes have occurred
We expose the ingress.ingressClassName chart value. By default, its value is an empty string because
we do not make assumptions about the type of an ingress controller that runs in Rancher (nginx, traefik, etc.).
Areas or cases that should be tested

Rancher instance backed by an RKE K8s cluster.
Rancher instance backed by a non-RKE K8s cluster, like EKS or GKE, for example.
Both cases need upgrade tests.

What areas could experience regressions?
Are the repro steps accurate/minimal?
RKE-based Rancher

Deploy an HA Rancher instance backed by RKE. Use Helm and choose a non-latest version of Rancher's image.
Inspect the Rancher ingress and ensure it does include the ingressClassName in its spec definition.
kubectl get ingress -o yaml -n cattle-system rancher | grep ingressClassName
Ensure that you can access the cluster on its hostname URL.
Use Helm to upgrade the Rancher release. Do not specify the ingressClassName value to Helm.
Ensure the ingress resource still has the class name, and Rancher is still accessible.

EKS-based Rancher

Provision an EKS Kubernetes cluster.
Deploy an ingress-nginx release.

helm upgrade --install \
  ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --set controller.service.type=LoadBalancer \
  --version 4.0.18 \
  --create-namespace

Deploy Rancher. Use Helm and choose a non-latest version of Rancher's image.
Inspect the Rancher ingress and ensure it does NOT include the ingressClassName in its spec definition.
Ensure that you cannot access the cluster on its hostname URL.
Inspect the logs of the ingress-nginx controller pod. Search for errors and find the one that says the controller
refused to allow the ingress resource defined by Rancher, because it does not have the ingressClassName defined.
Upgrade the Rancher release, make sure the chart is of the version that includes this issue's change. Specify
the ingress.ingressClassName as nginx on the command line to Helm.
Ensure the ingress resource still now the class name, and Rancher is accessible.


[FEATURE REQ] Raspibolt+ArchLinux

I tried installing raspibolt adapting the guide to an arch install, but as I am not very technical I found some problems with the first config files as the differ a lot. But I think it would be of great beneficial for those who like arch, because as debian it's backed by a huge comunity of very talented people that very often did not understand bitcoin yet.
So if anyone has the knowledge and the will to do so, I am glad to test and try.

Almost every guide uses apt, which is Debian specific package manager, also Debian style configs, as you mentioned. For distributions not based on Debian, you would need to rewrite most of the stuff. It makes more sense to fork this guide, modify for Arch and then keep it up to date separately.


improve request type definition

Example:
export interface GetRequest {
  body: {
    'id': string;
  }
  query: {
    'id': string;
  }
  headers: {
    'id': string;
  }
}

Draft because I'm pretty sure some cases are not covered
cc @rozzilla
Fixes: #1435

Can you add a fullRequest option too? Also a full alias for fullRequest and fullResponse.

Since this PR needed to be landed, I also added. the code (in 559c496) to Fix: #1450


Methd update

Description
Related Issue
Issue: https://github.com/dragonflyoss/Dragonfly2/issues/532
Motivation and Context
Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to change)
[x] Documentation Update (if none of the other choices apply)

Checklist:

[x] Code compiles correctly.
[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Codecov Report

Merging #534 (3a5e423) into main (c1c3d65) will increase coverage by 0.04%.
The diff coverage is 0.00%.

:exclamation: Current head 3a5e423 differs from pull request most recent head 758ede1. Consider uploading reports for the commit 758ede1 to get more accurate results

@@            Coverage Diff             @@
##             main     #534      +/-   ##
==========================================
+ Coverage   39.47%   39.51%   +0.04%
==========================================
  Files          86       86
  Lines        6529     6529
==========================================
+ Hits         2577     2580       +3
+ Misses       3581     3578       -3
  Partials      371      371

Flag
Coverage Δ

e2etests
∅ <ø> (∅)

unittests
39.51% <0.00%> (+0.04%)
:arrow_up:

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

Impacted Files
Coverage Δ

cdnsystem/storedriver/driver.go
16.66% <0.00%> (ø)

cdnsystem/storedriver/local/local_driver.go
51.89% <ø> (ø)

cdnsystem/storedriver/mock_driver.go
0.00% <0.00%> (ø)

client/daemon/peer/peertask_base.go
35.62% <0.00%> (+0.64%)
:arrow_up:


dev: use constants for precompiles addresses range

use constants instead of inlined numbers for the precompiles address range.
https://github.com/kkrt-labs/kakarot-ssj/blob/041acc93944cd2fa2b24f6f00a45c91d83414d46/crates/evm/src/model.cairo#L138-L143
reference:
https://github.com/kkrt-labs/kakarot/blob/65e333a0d3475e81b0a6367b0f00561c763da0a0/src/kakarot/precompiles/precompiles_helpers.cairo#L1-L37

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
Hello, my name is Luca! I have been a backend software engineer for over 8 years. It would be a pleasure to collaborate with you, especially on this issue. I started studying Web3 development a few months ago and would like to contribute.
Thank you for considering me.
How I plan on tackling this issue
I will analyze the project and take the reference to be able to solve the problem.

#868


Add DoxygenLayout.xml to customize our pages

First change is to put the detailed description of every class at the very top.

This PR can be closed I think?


Prettytensor library doesn't include customs_fully_connected/custom_conv2d

the part of the code in StageI/model.py as followed:
node1_0 =
(pt.wrap(z_var).
flatten().
custom_fully_connected(self.s16 * self.s16 * self.gf_dim * 8).
fc_batch_norm().
reshape([-1, self.s16, self.s16, self.gf_dim * 8]))
node1_1 =
(node1_0.
custom_conv2d(self.gf_dim * 2, k_h=1, k_w=1, d_h=1, d_w=1).
conv_batch_norm().
apply(tf.nn.relu).
custom_conv2d(self.gf_dim * 2, k_h=3, k_w=3, d_h=1, d_w=1).
conv_batch_norm().
apply(tf.nn.relu).
custom_conv2d(self.gf_dim * 8, k_h=3, k_w=3, d_h=1, d_w=1).
conv_batch_norm())
I'm trying to running the experiments with the data.However, it gives me the error:
NO module "custom_fully_connected"
It might be caused by the fact that I use recent version of Tensorflow or PrettyTensor master branch . I wonder which modification make running this code on current settings.
谢谢你的解答，在线急。

If you TensorFlow version is > 1.0, then yes the  custom_fully_connected will not work with PrettyTensor. If you are trying to run this code the way it is, I would suggest either downgrading your TensorFlow or use my code for TensorFlow > 1.0


Conditional breakpoints should have a different color

Hello,
It would be good to make conditional breakpoints look different than the normal red-colored breakpoints. This is a feature that is implemented in almost all Chromium-based browsers and Firefox, for examples.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 0a900399-43f6-f787-17b1-426e26eec4a1
Version Independent ID: 97d60945-0048-78f6-cc47-0e4202c9817d
Content: Pause code with breakpoints - Microsoft Edge Development
Content Source: microsoft-edge/devtools-guide-chromium/javascript/breakpoints.md
Product: microsoft-edge
Technology: devtools
GitHub Login: @MSEdgeTeam
Microsoft Alias: msedgedevrel

Thanks for reaching out about this.
I think this is a great feature request, but unfortunately it's not on the right repository. This repository here is for tracking documentation issues, not product issues.
Could you please create a new issue for this over on the DevTools repo instead? Here is the address: https://github.com/MicrosoftEdge/DevTools
Thanks for your understanding!

Whoops! Thanks for pointing that out.
I've opened the a new issue on the DevTools repo :)


Wildcard support

Hi, the article mentions that "For Restrict-Access-To-Tenants, a value of , which is a comma-separated list of tenants you want to allow users to access.". It does not say if we can use wildcards. For example, to allow access to all tenants ending with *.company domain name, can I specify *.company in "Restrict-Access-To-Tenants"?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 89ea5c2d-4602-25b8-3cdd-60cfb5c31895
Version Independent ID: 35d4af7e-72e4-7c40-9dd6-b8490ee73f0d
Content: Manage access to cloud apps by restricting tenants - Azure
Content Source: articles/active-directory/manage-apps/tenant-restrictions.md
Service: active-directory
GitHub Login: @barbkess
Microsoft Alias: barbkess

@vsathiamoo  Thanks for the feedback! We are currently investigating and will update you shortly.

@vsathiamoo We will now proceed to close this thread. If there are further questions regarding this matter, please open a new issue and we will gladly continue the discussion.


⚠ Roblox Devforum has degraded performance

In f7edec7, Roblox Devforum (https://devforum.roblox.com) experienced degraded performance:

HTTP code: 200
Response time: 1165 ms

Resolved: Roblox Devforum performance has improved in ff82b41.


Add support for InfiniBand

The Prometheus node exporter collects metrics for the InfiniBand network protocol including the amount of packets sent and received, the number of times the link has been downed and how many times the link has recovered from an error state.
Reading all those information from sysfs is better placed in the procfs library. Also collect the state, physical state, and the rate.

Thanks for the review. I will address those points. @mdlayher, do you really prefer to have a switch statement for the 16 different values? This list might grow. If the counter fields are regular values, what should I do if the system does not have this counter?

I looked at https://github.com/prometheus/node_exporter/blob/master/collector/infiniband_linux.go and borrowed the workarounds and the legacy counters.

I changed the two parse functions to take a string as parameter (instead of a path to the file).

Tend to agree with @mdlayher. What about using a temporary map to iterate over instead of using reflect to iterate over the map?

sysfs/class_power_supply.go and sysfs/net_class.go uses reflect. Can you point me to a component that uses a temporary map to iterate over?

@mdlayher I saw your recent commits on master and adapted this pull request to the logic used for PowerSupply. Therefore reflect is not used any more. Additional changes:

Introduce InfiniBandDevice type
also collect board_id, fw_ver, and hca_type (in InfiniBandDevice)

All remarks are addressed and this pull request is ready for an in depth review.

Merged, thanks!


can't parse shadowroot  element

for example the github commit relative-time element  is a shdowroot  ,document.querySelector("#repo-content-pjax-container > div > div > div.Layout.Layout--flowRow-until-md.Layout--sidebarPosition-end.Layout--sidebarPosition-flowRow-end > div.Layout-main > div.Box.mb-3 > div.js-details-container.Details > div.Details-content--hidden-not-important.js-navigation-container.js-active-navigation-container.d-md-block > div.Box-row.Box-row--focus-gray.py-2.d-flex.position-relative.js-navigation-item.navigation-focus > div.color-fg-muted.text-right > relative-time").shadowRoot.textContent  the selector can't find out

Yeah, what you describe depends on two things: custom elements and shadowroots. For the shadow roots to exist you must first register the custom element Javascript classes to add the shadowroots. Just parsing the HTML won't yield you shadowroot nodes, you must also run the Javascript on the page in addition parsing the HTML.
Deno DOM is not meant to be a substitute for a browser and by extension will never execute the Javascript on a page. What I do plan on doing, however, is implementing both the custom element API and the shadow root API in Deno DOM. It's just if you parse the HTML from Github for example you won't get any shadow roots created because that's strictly a Javascript feature and can't be expressed in HTML.