Modifying weave pod template results in brief networking connectivity issues for pods on the same node as the weave daemonset being restarted

What you expected to happen?
Modifying weave daemonset podtemplate should not result in traffic loss for pods on the host Nodes.
What happened?
Any change to the weave pod template that causes weave to download the docker image results in the network connectivity problems for all the pods running on the host node.
We observed the below iptables rules were being deleted:
-A WEAVE-IPSEC-IN -s <IP_ADDRESS>/32 -d <IP_ADDRESS>/32 -p udp -m udp --dport 6784 -m mark ! --mark 0x20000/0x20000 -j DROP
-A WEAVE-IPSEC-IN -s <IP_ADDRESS>/32 -d <IP_ADDRESS>/32 -p esp -m esp --espspi<PHONE_NUMBER> -j WEAVE-IPSEC-IN-MARK
-A WEAVE-IPSEC-OUT -s <IP_ADDRESS>/32 -d <IP_ADDRESS>/32 -p udp -m udp --dport 6784 -j WEAVE-IPSEC-OUT-MARK

How to reproduce it?
Delete weave docker image on a k8s node, update the pod template section of a weave yaml and kubectl apply the file
Anything else we need to know?
Running Kubernetes
Versions:
$ weave version
1.9.4 (tried 1.9.5 and 1.9.6)
$ docker version
Client:
 Version:      1.13.0
 API version:  1.25
 Go version:   go1.7.3
 Git commit:   49bf474
 Built:        Tue Jan 17 09:44:08 2017
 OS/Arch:      linux/amd64

Server:
 Version:      1.13.0
 API version:  1.25 (minimum version 1.12)
 Go version:   go1.7.3
 Git commit:   49bf474
 Built:        Tue Jan 17 09:44:08 2017
 OS/Arch:      linux/amd64
 Experimental: false
$ uname -a
Linux kube-worker04.qa.braintreepayments.com 4.4.0-1-amd64 #1 SMP Debian 4.4.43-1 (2017-01-30) x86_64 GNU/Linux
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.0", GitCommit:"d3ada0119e776222f11ec7945e6d860061339aad", GitTreeState:"clean", BuildDate:"2017-06-29T23:15:59Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.0", GitCommit:"d3ada0119e776222f11ec7945e6d860061339aad", GitTreeState:"clean", BuildDate:"2017-06-29T22:55:19Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}

I spoke to @bboreham on k8s #sig-network slack and he asked me to open this issue

I also forgot to mention we have WEAVE_PASSWORD and IP_ALLOC set, but I assume both of those should be obvious from the iptables rules

Did the connectivity disruption happen between the pods running on the same host, or running on different hosts?
If the latter case, then it can happen due to the following:

https://github.com/weaveworks/weave/blob/v2.0.1/net/ipsec/ipsec.go#L252 (with destroy=true) gets called when the weaver process terminates which is due to the upgrade. The Flush method removes XFRM policies and states first, and then the related iptables rules and chains. So, in-between the XFRM and iptables removals no traffic is allowed between the hosts. (I'm starting to think maybe we should call Flush only upon weave reset, however it does not help in the k8s case.)
fastdp flows are removed when either host detects that the other host went down.

Did the connectivity disruption happen between the pods running on the same host, or running on different hosts?

I can try investigating and report back, I do think it's different hosts but I'll verify.
If it's the latter case what do you advice we do in this regards?
We are considering running as a systemd daemon on every of our worker nodes instead of being a daemonset in k8s, that way we can cordon off the worker before conducting an upgrade of weave

@brb I am yet to investigate, but I think this:
https://twitter.com/mikemetral/status/889551203977187328
especially this:

-New DS strategy: start new instance before Pod termination

should help with this problem, can you think of possible problems that can be introduced with running multiple instances of weave on the same host

@bjhaid Weave Net is not engineered to run multiple instances on one host; there can be only one.
However I am interested to drill further into the disruption you reported - we expect traffic to stop for a few seconds and then resume, but I think on Slack you were saying you got more noticeable failures.

@bboreham the failures where mostly due to dns lookups failing and the containers rely heavily on DNS resolution, hence the significant disruption whenever we need to pull the image

Do you know how long the gap is in traffic, and how the DNS clients retry?

Do you know how long the gap is in traffic

No exactly but things go back to normal once weave is completely rolled out.

how the DNS clients retry?

I really don't know but I can dig around, this is all probably wrapped in some library that times out on calls to glibc's getaddrinfo but can also vary from the language/stack to stack

glibc default is to retry twice with 5-second gaps, so total 15 seconds.  If the time Weave Net is down is more than a fraction of that then I'd say find out why.

things go back to normal once weave is completely rolled out.

wait, you are saying the disruption lasts until it finishes across the whole cluster, not just one host at a time?

wait, you are saying the disruption lasts until it finishes across the whole cluster, not just one host at a time?

Roughly yes, things crashing on different hosts for network reasons

OK, we need to drill into "for network reasons".  I expect some packet loss, maybe for 1-2 seconds, on one node at a time as it restarts, with all of that being hidden by retries at a higher level.
Can you give any detail on the timing - start of update on cluster, start of update on one node, end of update on that node, and how that relates to errors raised on that node or other nodes, and what exactly those errors are?

@bboreham I'll ensure gathering all of these data is prioritize and get back to you asap. thanks for helping look

I have some data points for you,
Failures from tcpdump, note <IP_ADDRESS> is the service ip for kube-dns
21:55:24.518135 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 92
21:55:24.518142 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 92
21:55:24.538127 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 92
21:55:24.538134 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 92
21:55:24.538148 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 92
21:55:24.538152 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 92
21:55:24.538158 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 92

21:55:28.630247 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 92
21:55:28.630251 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 92
21:55:29.467461 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
21:55:29.542136 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 92
21:55:29.542143 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 92
21:55:29.542149 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 92
21:55:29.542153 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 92
21:55:29.542158 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 92

21:55:32.466173 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 68

21:55:34.526160 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 68
21:55:34.526168 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 68
21:55:34.526174 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 68
21:55:34.526178 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 68
21:55:34.526184 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 68
21:55:34.526188 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 68

21:55:37.626163 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 86
21:55:37.626168 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 86
21:55:37.917620 ARP, Request who-has <IP_ADDRESS> tell <IP_ADDRESS>, length 28
21:55:38.586150 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 86
21:55:38.586156 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 86
21:55:38.586162 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 86
21:55:38.586166 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 86
21:55:38.586170 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 86
21:55:38.586174 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 86

21:55:40.914160 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 86
21:55:40.914164 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 86
21:55:40.914169 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 112
21:55:40.914173 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 112
21:55:40.914179 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 102
21:55:40.914182 IP <IP_ADDRESS> > <IP_ADDRESS>: ICMP host <IP_ADDRESS> unreachable, length 102

From start to end of downloading the image took at best 35 seconds, I have other iterations, we might be able to improve this on our end by pre-fetching the images with docker pull
Thu Jul 27 21:55:02 UTC 2017
Thu Jul 27 21:55:37 UTC 2017

Let me know if you find this useful? Thanks!

My testing technique is to run apache bench against of one our services (to generate enough traffic to detect errors) then kick off a weave upgrade. On the host where the service pod is running I run:
watch -g 'docker ps --format "table {{.Image}}" | grep weave-' && echo $(date) >> foo1.txt
once that exits(means the weave container just got stopped on that host) I start a tcpdump in the container running the service and also rerun the command, when it exits again means the container has been started. So that gives me approximate start and stop time of the weave containers.
From the tcpdump it seems ICMP host unreach (which maps to errno EHOSTUNREACH) was returned about 3 seconds even after the container was started, is this expected?

I want to also point out that in between the EHOSTUNREACH there were successful request to external service IPs, so I think it's only pods running on a different host that connectivity failed to

I also just verified that requests to pod on the same host goes fine in this period

@bboreham ping

From the tcpdump it seems ICMP host unreach (which maps to errno EHOSTUNREACH) was returned about 3 seconds even after the container was started, is this expected?

I'd say this is expected, as It takes some time for weave to start and to connect to remote peers. Do you have docker logs of the latest weave-net container?
Also, would you mind pre-fetching the weave image before running the upgrade on each host and re-running your tests? Thanks.

Do you have docker logs of the latest weave-net container?

I can try to get the logs for the containers that were created during the experiments, do you have anything specific you want me to look for in the logs?

Also, would you mind pre-fetching the weave image before running the upgrade on each host and re-running your tests?

This is an additional operational overhead but it's a worthy compromise.
Thanks!

I can try to get the logs for the containers that were created during the experiments, do you have anything specific you want me to look for in the logs?

I just want to see timings of weave bootstrapping steps. So, providing the whole log would be the best.

We seem to have reached a dead end in the investigation here. -> closing


Ninja abilities don't work

Description

When trying to use ninja abilities that cost power they do not work, instead a popup appears saying that the ninja suit does not have enough energy, this occurs at any charge rate from 0% to 100%
Ninja gloves still work.
Reproduction

Spawn in as a ninja
Attempt to use cloak/throwing star/katana teleport
Get trolled and go murderboning instead.

Screenshots

none
Additional context

First reproduced on wizden leviathan at round #43231, the ninja was mostly active on the northern side of the station starting from 40(?) minutes.
I was not playing since roundstart or latejoined, I started as an observer.

recent trolling idk it worked a week ago

The issue seems to be caused the delay component that was added in #22502 in NinjaSuitSystem.cs.
TryComp doesn't find the component and returns false.
Also, power from the battery still gets used even if the delay check fails so I think that the charge check should be last or have these two checks be separate.
Having them separate might be preferable to also get a different message when the reason you can't use the ability is the cooldown.


support command ps -q

Support ps command with only display IDs.
Signed-off-by: Bo Hai<EMAIL_ADDRESS>

@bohai Thanks for this PR. An integration test would be really cool, but other than that, looks good :wink:

@vdemeester OK. I will add an integration test later.

@bohai ah, needs a rebase :sweat:


Questions

I added some more questions. I separated them into single commits, so let me know if you don't like one and I will just drop the commit ...

@digitaltom @cornelius


Update snap value for precision in small scale models.

Subtracting two CSG box nodes from a box can generate a floating triangle.
Not sure if this is the proper fix, so putting it out for testing.
Seems to resolve:

https://github.com/godotengine/godot/issues/58637
https://github.com/godotengine/godot/issues/41140
https://github.com/godotengine/godot/issues/86567

godot-csg-mesh-repro.zip

How well does this behave when a few thousand units away from the world origin? I believe this is why the default is 0.001.

@Calinou can send me a test case where this errors. I am not sure if it exists.
As far as I know this snapping value was because of bug that used to cause an infinite loop.
https://github.com/godotengine/godot/pull/76521

@Calinou I made a video of the double precision test with https://github.com/V-Sekai/godot-double-precision-test. How did you expect it to break because it doesn't seem to be breaking on a CSG box subtractions at the top left.
https://youtu.be/VD0_45cvXaU

This change is going to make CSG appear to have a precision issue without an obvious explanation why.
I would rather keep the current behavior which is obviously incorrect for some uses and have users change snap to a value appropriate for their application, than have a non obviously bad default that users won't notice or understand

I disagree because ordinary csg cases will be broken as in the bug report.

Closing due lack of agreement on this method.

https://github.com/godotengine/godot/pull/91748 is a better theoretical fix for this.


update service-host package

update gRPC and other dependencies

Pull Request Test Coverage Report for Build<PHONE_NUMBER>2
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 0.0%

Totals

Change from base Build<PHONE_NUMBER>5:
0.0%

Covered Lines:
0

Relevant Lines:
365

💛  - Coveralls


creating UI folder for sharing UI components in Package folder leads to error , how we can achieve that

it is private code , i am sorry for that , but it is running on next 12.1.4 not next 13 , if that does not related to the problem can you share the repo

it is private code , i am sorry for that , but it is running on next 12.1.4 not next 13 , if that does not related to the problem can you share the repo

mine's private too - but there was an issue a while back with a public repo: https://github.com/t3-oss/create-t3-turbo/issues/71

Did you get this working?


Fixes Syntax error in example code

Fixes Syntax error in example code

Coverage remained the same at 100.0% when pulling 6ef982809d9b4edd6c6d1001a476299e675825fb on chilian:master into 6e207c9e5502823a583bd9297b1dc216a498ef62 on aditya7iyengar:master.

👍 Thanks for the contribution!


Incompatibilities with django 1.10

Hi guys, now i update django to 1.10 version and i have this problem:
 salahaddin@TulipanROG  ~/Proyectos/demo-oscar/ecommerce   master ● ?  (demo-oscar)  ./manage.py runserver                                                                                 ✓  1685  18:14:32
Unhandled exception in thread started by <function check_errors.<locals>.wrapper at 0x7f7ed4947730>
Traceback (most recent call last):
  File "/home/salahaddin/Proyectos/demo-oscar/lib/python3.5/site-packages/django/utils/autoreload.py", line 226, in wrapper
    fn(*args, **kwargs)
  File "/home/salahaddin/Proyectos/demo-oscar/lib/python3.5/site-packages/django/core/management/commands/runserver.py", line 113, in inner_run
    autoreload.raise_last_exception()
  File "/home/salahaddin/Proyectos/demo-oscar/lib/python3.5/site-packages/django/utils/autoreload.py", line 249, in raise_last_exception
    six.reraise(*_exception)
  File "/home/salahaddin/Proyectos/demo-oscar/lib/python3.5/site-packages/django/utils/six.py", line 685, in reraise
    raise value.with_traceback(tb)
  File "/home/salahaddin/Proyectos/demo-oscar/lib/python3.5/site-packages/django/utils/autoreload.py", line 226, in wrapper
    fn(*args, **kwargs)
  File "/home/salahaddin/Proyectos/demo-oscar/lib/python3.5/site-packages/django/__init__.py", line 27, in setup
    apps.populate(settings.INSTALLED_APPS)
  File "/home/salahaddin/Proyectos/demo-oscar/lib/python3.5/site-packages/django/apps/registry.py", line 108, in populate
    app_config.import_models(all_models)
  File "/home/salahaddin/Proyectos/demo-oscar/lib/python3.5/site-packages/django/apps/config.py", line 199, in import_models
    self.models_module = import_module(models_module_name)
  File "/home/salahaddin/Proyectos/demo-oscar/lib/python3.5/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 986, in _gcd_import
  File "<frozen importlib._bootstrap>", line 969, in _find_and_load
  File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 673, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 665, in exec_module
  File "<frozen importlib._bootstrap>", line 222, in _call_with_frames_removed
  File "/home/salahaddin/Proyectos/demo-oscar/lib/python3.5/site-packages/oscar/apps/address/models.py", line 1, in <module>
    from oscar.apps.address.abstract_models import (
  File "/home/salahaddin/Proyectos/demo-oscar/lib/python3.5/site-packages/oscar/apps/address/abstract_models.py", line 13, in <module>
    from oscar.models.fields import PhoneNumberField, UppercaseCharField
  File "/home/salahaddin/Proyectos/demo-oscar/lib/python3.5/site-packages/oscar/models/fields/__init__.py", line 3, in <module>
    from django.db.models import SubfieldBase
ImportError: cannot import name 'SubfieldBase'

Here  are a solution for this problem.
I'll report some problems with django 1.10.
Thanks you!

Thanks, we are aware of this and it is currently worked on by @pxg

hi SalahAdDin ,
I am facing same problem , I tried to understand the solution . but couldn't.
File "/home/ubuntu/workspace/zabrabox/production/local/lib/python2.7/site-packages/oscar/models/fields/init.py", line 3, in
from django.db.models import SubfieldBase
ImportError: cannot import name SubfieldBase
. please suggest me which file cone i need to change .
thanks you soo much in advance .

@prabhatpankaj I have a branch in my fork where I'm working on Django 1.10 compatibility https://github.com/pxg/django-oscar/tree/feature/django-110 however not all test are passing so this work should definitely be considered unstable. The SubfieldBase issue isn't the only one with upgrading to Django 1.10.

@mvantellingen Where django-oscar going to support django 1.10 ?

Hello,
I wanted to use django-oscar for a prototype website with Django 1.10, so I made some changes to make it work:
https://github.com/pxg/django-oscar/pull/1
I haven't checked the test, I just wanted to have a quick look (so it's a quick&dirty change).
Hope that may help.

@saintger thanks for this, will be useful for you to confirm that this works for your prototype. I think the main thing blocking us on this is getting the tests passing.

@pxg I just ran the test and I have only 6 failed tests.
However with Django 1.9.10, I have 2 failed tests as well.
I'll try to have a look at these 4 failed tests within 1-2 weeks.

Ok great, let me know if you need a hand. I have an Oscar site I want to update to Django 1.10 so keen to get this working.

@pxg Perhaps I need indeed you help to start debugging.

With all this subclassing and mixing, I'm a bit lost.
Perhaps you can point me to the right direction ?
Thanks

Any news on this topic?

@CoffiDev I should have time to work on this in Q1 of 2017, but I have another project which needs to be finished first. The code appears to be stable, but we need to dig into why the tests are failing.

hi guys!
I am new to django-oscar. Is there any solution for this issue or can you suggest any other django e-commerce framework?
thanks!

@rohit135 we have Django 1.10 compatibility in version 1.4 which will be officially released soon, we just need to fix a couple of tests, some of us are using the beta. The work for this is in the master branch if you'd like to help us test it.

Thanks! Is there a release date scheduled? Also is there any issue with python3.6 and django1.9? I am thinking of using them for the moment..

There isn't an official release date, but I expect it will be released in the next couple of weeks. The test suite runs on Travis with Python 3.6 so this should be fine, Django 1.9 is fine too.


Feature Request: need  Support Chinese

When I use Chinese symbols in the flowchart, the flowchart cannot be parsed. I hope the plugin can support Chinese.
The following code can be rendered:
   A[cmmitOA] --> B{Is it?}     B -->|Yes| C[OK]     C --> D[Rethink]     D --> B     B ---->|No| E[End]
The following code cannot render the flowchart after replacing the module name:
    A[提交OA] --> B{Is it?}     B -->|Yes| C[OK]     C --> D[Rethink]     D --> B     B ---->|No| E[End]

Fixed in the latest version.


How to color the BottomBar even if there are only three tabs

Could you provide any example or a snippet?

Use mBottomBar.setMaxFixedTabs.
Its on the main page

What Gallevy said.
Also, this is more easy in the version 2.0 and later.


Update link to Exponention operator

Exponention operator has a link that doesn't go to the proper row, the link is now: http://kangax.github.io/compat-table/es7/#test-Exponentiation_operator
which should be: http://kangax.github.io/compat-table/es2016plus/#test-exponentiation_(**)_operator

As https://caniuse.com/?search=Exponentiation now only shows two entries from MDN and a search result for ES2016

https://caniuse.com/mdn-javascript_operators_exponentiation
https://caniuse.com/mdn-javascript_operators_exponentiation_assignment
https://caniuse.com/sr_es7

i.e. the link isn't present anymore, I believe this issue can be closed :P

I see, the current links all look good, closed :smile:


Full JaCoCo support for JVM test suites

In a Groovy project of mine, I tried to migrate from the org.unbroken-dome.test-sets plugin to the JVM Test Suite Plugin. And here is my current way of doing it:
https://github.com/rkrisztian/search/commit/a62afd9f364a7902029c6451612e0c24c508ef78
As you can see, it's not perfect yet:

No JacocoReport task is created for each test task. The test-sets plugin does it (see source).
It has always been a manual effort to also aggregate the coverage results, but even if I don't create a JacocoReport task for each test task and just make the jacocoTestReport task do the aggregation as the ticket suggested, setting jacocoTestReport.reports.executionData testing.suites.integrationTest won't work because it's not a supported syntax); and jacocoTestReport.reports.executionData 'integrationTest' results in a failure Unable to read execution data file /home/rkrisztian/projects/search/build/test-results/integrationTest/binary.
I shouldn't be needed to add implementation configurations.testCompileClasspath to the integrationTest suite, but if I don't do, then Gradle won't be able to find XmlSlurper, which is part of the groovy-xml jar, which is a transitive dependency of groovy-all, which is a project dependency, which I already included into the suite.

So what I'm asking is:

for the linked user guide to include examples for the use of the Jacoco plugin as well.
examples for inheriting dependencies from the test suite, just as how the test-sets plugin did.
So far I never needed to use jacocoTestCoverageVerification, but we should probably document how it can work together with the test suites plugin...

Have a look at 7.4 nightlies - improved support for Jacoco aggregation, combined with test suites, is coming. However looks like the docs still need to be done. #19068 should give you some ideas on APIs.

Closing as duplicate of #18914

@ljacomet , I've tested Gradle release 7.4 and the jacoco-report-aggregation plugin, but it solved nothing for me, is it possible to reopen this issue?
The problem is that I don't have multiple subprojects to work with, I just have multiple test suites in the same project, and the JaCoCo reports of those are not aggregated at all.
According to the documentation:

The JaCoCo Report Aggregation plugin (plugin id: jacoco-report-aggregation) provides the ability to aggregate the results of multiple JaCoCo code coverage reports (potentially spanning multiple Gradle projects) into a single HTML report.

Despite that, I can't configure a report task that combines all test types. The API simply does not allow such a thing.
=> It would help if the aggregation plugin could support both dimensions (multiple projects × multiple tasks per project).

@ljacomet, would it be possible to support JaCoCo aggregation for each test task in the same subproject too?

@ljacomet , I've tested Gradle release 7.4 and the jacoco-report-aggregation plugin, but it solved nothing for me (except: "No JacocoReport task is created for each test task."), is it possible to reopen this issue?
The problem is that I don't have multiple subprojects to work with, I just have multiple test suites in the same project, and the JaCoCo reports of those are not aggregated at all.
According to the documentation:

The JaCoCo Report Aggregation plugin (plugin id: jacoco-report-aggregation) provides the ability to aggregate the results of multiple JaCoCo code coverage reports (potentially spanning multiple Gradle projects) into a single HTML report.

Despite that, I can't configure a report task that combines all test types. The API simply does not allow such a thing.
=> It would help if the aggregation plugin could support both dimensions (multiple projects × multiple test suites per project).
Edit: So all I could do was: rkrisztian/search@ec93a56

@rkrisztian , I am trying to do the same thing (i.e., multiple test suites per project) but no luck so far. just wondering if you managed to get this working?

@gradle/bt-core Can you talk a look and answer / re-open?

This is not something we currently support.  Each aggregation is for a specific test type, and you cannot have more than one test suite of a given type in the same project.
Why do you want to do this, vs. splitting the test suites with the same type amongst multiple sub-projects?  Why have 2 different groups of say, integration tests?  What would distinguish them programmatically?  Any information you can give us about your use case can help inform our discussions.

Example project structure:
fullStackAppProject
|- microservice1Subproject
|  |- unit tests
|  `- integration tests
|- microservice2Subproject
|  |- unit tests
|  `- integration tests
`- frontendSubproject
    |- unit tests
    |- integration tests
    `- end-to-end tests

Questions I might ask:

What is the total whitebox coverage for the whole project? (Do we test enough?)
What is the total whitebox coverage for the whole project per test type (unit, integration)? (Does our testing pyramid look like a pyramid or an ice-cream cone?)
What is the total whitebox coverage for each subproject? (E.g., in which subproject should we need to focus on writing more/better tests?)

Something like that.
Additionally, on the root level I prefer seeing the test results of all modules for each test type. This allows easy reporting in CI tools that consume HTML reports.

So by now it should be clear that when I talk about testing.suites, I just take over Gradle's terminology for different test types like unit, integration... It looks like the Gradle API is confusing in this regard, and "suites" is probably not the right term. Or I completely misunderstood what it should be about. Regardless, I've been looking for an option to replace the Gradle test-sets plugin. Was I looking at the wrong direction?

@rkrisztian - The JVM Test Suite Plugin is definitely what you should be looking at to replace the test-sets plugin.  It's not a complete replacement for the functionality offered there (yet), but is still under active development and we have a lot of ideas for interesting things we want to do with it soon.  It is our goal to make the test suites plugin the idiomatic solution for most use cases involving dividing a projects' tests into different groups.
I think aggregating across multiple test suite types within the same project is something we want to support, and the discussions we've been having are more about how we want to implement this.  As a temporary workaround, you could always customize the report task used by the JacocoReportAggregationPlugin to add additional execution data from other test types to the collection in a doFirst block, so that the report would run using all of them.  The plugin does this using dependency resolution, but ultimately all that matters is that the *.exec files make it into that collection prior to the report running (and make sure all the classes/source are in the other task collections, but it seems like they already would be, most of the time).
Thank you for the example.  One more question: Why do this the Gradle API, or the term "suites" is confusing here?

@big-guy - Do you have anything to add?

@tresat , good question, it's just that recently I recognized that meanings of the following terms get confusing to me when it comes to understanding the JVM Test Suites plugin:

Test types: what are our goals? (smoke, regression, performance, functional, etc.), or in what kind of granularity do we want to test the SUT (functional testing pyramid levels). (In detail: https://www.applause.com/blog/functional-testing-types-examples)
Test suites: a collection of test cases, used to group similar test cases together (smoke tests, or testing specific features of the system, etc.), and they can be of any type. (In detail: https://www.tutorialspoint.com/software_testing_dictionary/test_suite.htm)

Although there is some intersection where the two may be interchangeable for the same set of tests, I wouldn't go there, because I lost it already when I read:

you cannot have more than one test suite of a given type in the same project


Failing Azure specs on master - GEM=pending

Current master's spec are failing, the failures come from gems/pending/spec/miq_vm/miq_azure_vm_instance_spec.rb, with VCR::Errors::UnhandledHTTPRequestError or nil.unmount.
It says
ffi-vix_disk_lib: failed to load 6.0.0 version with error: Could not open library 'vixDiskLib.so.6.0.0': vixDiskLib.so.6.0.0: cannot open shared object file: No such file or directory.

(and a bunch more versions) which may be related...
example job: https://travis-ci.org/ManageIQ/manageiq/jobs/119483063#L405

@agrare, I thought @roliveri already fixed this.

@djberg96 he did. https://github.com/ManageIQ/manageiq/pull/7599

Alrighty, thanks Adam.
@himdel or @blomquisg, please close.

OK, closing, since #7599 got merged.. :)

@agrare and @djberg96 thanks for following up on that .. I saw "azure" and jumped to the wrong conclusion ... sorry about that :/

@blomquisg haha poor @djberg96 I did the same thing to him on gitter an hour ago.


Cannot hit any mob/player after trying to punch a luggage.

Forge or Fabric
Fabric
Mod Version
v1.5.1
Client Log
https://gist.github.com/StargazingKitsune/9eb968455bc328cf5d941a35074dca39
Crash Report (if applicable)
No response
Bug Description
Unable to hit mobs and other players with fists/physical attacks but can still use ranged weaponry.
Steps to Reproduce
I punched a luggage from the luggage mod that belonged to someone else and I cannot hit mobs physically except with ranged weapons.
I picked up the luggage and own it now, I'm not sure if that also contributes anything, but my companions have also been affected by the mob by being unable to hit mobs with physical weaponry/their fists.
Please Read and Confirm The Following

[X] I have confirmed the details provided in this report are concise as possible and does not contained vague information (ie. Versions are properly recorded, answers to questions are clear).
[X] I have confirmed this issue is unique and has not been reported already.

Yeah its made the game unplayable, it happens after I dropped my sword into luggage, put it back into my inventory. Only happened when I was around people

https://github.com/GizmoTheMoonPig/luggage/blob/fabric/1.19.x/src/main/java/com/gizmo/luggage/mixin/client/MinecraftMixin.java#L50
Shouldn't we add shouldCancel.remove() in an else statement to reassign the boolean to it's default value, for now it seem to toggle to true thus ignoring all mob after trying to hit luggage

Fixed in latest release

Fixed in latest release


Develop -> Main

Codecov Report

Merging #30 (6a33da7) into main (a858d21) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main       #30   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            1         1
  Lines            5         5
=========================================
  Hits             5         5

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 a858d21...6a33da7. Read the comment docs.


Linux Simulation Support

I am able to build this library on my linux machine and produce linuxx86-64 maven zips.
Would it be possible to publish equivalents of this to maven so that Linux Simulation is possible?
I'd be happy to test it to see if there are any other issues.

It's possible, will start looking into what's involved.  Don't have a good way to test it, so will need your help w/that.  Will update on this issue as things progress.

Okay, thanks.
I believe all that's needed is a Linux machine for building and testing.

It's a drag the cross-compiling isn't supported, and it requires setting up a different machine for this to manage the linux simulation build process.
Are you aware of anyone else who might be wanting linux simulation capabilities?  We must trade off the effort to do this versus developing our next-generation sensors.  You're the only one who has asked, so if this is a one-off effort I'm not sure it's worth it from our side.

Would "skipInvalidPlatforms": false do the trick? (Disclaimer: I have little idea how GradleRIO works.)

I shouldn't think so - this issue that there are no platform builds for desktop on Linux.

@kauailabs RobotPy compiles navx for Linux/Windows/OSX all using github actions -- I've been pretty happy with it compared to other CI solutions I've used in the past. Since you're completely open source (unlike CTRE, for example), using github actions might make sense for you and you'd be able to support all the simulation platforms, unlike most vendors.

Just came to say that I'm interested in this feature as well. (FRC2021 kickoff)
> Task :linkFrcUserProgramLinuxx86-64ReleaseExecutable
/usr/bin/ld: /home/dereck/frc/SimDemo/build/objs/frcUserProgram/linuxx86-64/release/frcUserProgramCpp/cpxox320jmytzosewdh0ktd87/Drivetrain.o: in function `Drivetrain::GetYaw()':
Drivetrain.cpp:(.text+0x10): undefined reference to `AHRS::GetYaw()'
/usr/bin/ld: /home/dereck/frc/SimDemo/build/objs/frcUserProgram/linuxx86-64/release/frcUserProgramCpp/9760xtgdau9jsoxxi90ozrpww/Robot.o: in function `Drivetrain::Drivetrain()':
Robot.cpp:(.text._ZN10DrivetrainC2Ev[_ZN10DrivetrainC5Ev]+0x17a): undefined reference to `AHRS::AHRS(frc::SPI::Port)'
/usr/bin/ld: Robot.cpp:(.text._ZN10DrivetrainC2Ev[_ZN10DrivetrainC5Ev]+0x4dc): undefined reference to `AHRS::ZeroYaw()'
collect2: error: ld returned 1 exit status

Just came to say that I'm interested in this feature as well. (FRC2021 kickoff)
> Task :linkFrcUserProgramLinuxx86-64ReleaseExecutable
/usr/bin/ld: /home/dereck/frc/SimDemo/build/objs/frcUserProgram/linuxx86-64/release/frcUserProgramCpp/cpxox320jmytzosewdh0ktd87/Drivetrain.o: in function `Drivetrain::GetYaw()':
Drivetrain.cpp:(.text+0x10): undefined reference to `AHRS::GetYaw()'
/usr/bin/ld: /home/dereck/frc/SimDemo/build/objs/frcUserProgram/linuxx86-64/release/frcUserProgramCpp/9760xtgdau9jsoxxi90ozrpww/Robot.o: in function `Drivetrain::Drivetrain()':
Robot.cpp:(.text._ZN10DrivetrainC2Ev[_ZN10DrivetrainC5Ev]+0x17a): undefined reference to `AHRS::AHRS(frc::SPI::Port)'
/usr/bin/ld: Robot.cpp:(.text._ZN10DrivetrainC2Ev[_ZN10DrivetrainC5Ev]+0x4dc): undefined reference to `AHRS::ZeroYaw()'
collect2: error: ld returned 1 exit status

I would also like to see this, especially considering that it doesn't seem like you're open sourcing your newer code anymore.


Centers the screen on MacOS

Before:

After:

Any chance we could get this merged?

I was wondering the same thing, but wanted the window to start filling the screen, then save and restore the user's custom size and position. I was able to get that working with the following calls:
id screen = objc_msgSend("NSScreen"_cls, "mainScreen"_sel);
auto frame = ((CGRect(*)(id, SEL))objc_msgSend_stret)(screen, "visibleFrame"_sel);
objc_msgSend(m_window, "setFrame:display:animate:"_sel, frame, 1, 0);
objc_msgSend(m_window, "setFrameAutosaveName:"_sel, "Main"_str);

The string "Main" is an arbitrary identifier that is used to save the frame's position in the os's defaults system https://developer.apple.com/documentation/appkit/nswindow/1419362-frameautosavename?language=objc
I'm not sure if I'm simply lucky that the second call doesn't conflict with the first. Perhaps the frame's size should be queried first to check for it being zero, and only use the default size in that case. Then, the default can be an optional parameter, allowing the starting state to be filling the screen, centered, or an absolute size.

Any reason we're not merging this yet ?

Any reason we're not merging this yet ?

webview.h
line:738,add this
((void (*)(id, SEL))objc_msgSend)(m_window, "center"_sel);

webview.h
line:738,add this
((void (*)(id, SEL))objc_msgSend)(m_window, "center"_sel);

Sorry guys I couldn't push the commit directly. So I open another one hope we can merge today.

Closing as this was resolved in #531


Rounding issue on USD maybe on my nodes dashboard?

If it's not rounding issues it could be caching causing the problem (ticker info and API responses are both cached for performance)

I can't reproduce this anymore, likely it's been fixed.


Added selectors for #171

This implements the required selectors for #171
The related PR on xi-editor is:
https://github.com/xi-editor/xi-editor/pull/892

Works for me, thanks!


Creating Interactive Apps Challenge

Here we didn't have a single challenge, but a set of little ones. So, going one by one:
1. Set the project icon as the two letters of the name
Great! The project icon is taking the first two letters of the name. I like the simplicity of just slicing the name.
https://github.com/bimineco/ifcviewer/blob/8d7f32e14c4c216d7402bf96574fc7e15a846c65/src/classes/Project.ts#L79
If you want another challenge in this same line, try to take the first two letters only if the name contains one word. But if it has two or more words, take the first letter of the first two words.
2. Set a random color to the icon background
Awesome! The background colors for the project initials are changing randomly. One benefit of having a fixed set of colors is you can choose them to match the overall style of the app.
https://github.com/bimineco/ifcviewer/blob/8d7f32e14c4c216d7402bf96574fc7e15a846c65/src/classes/Project.ts#L80
3. Don’t create the project if the name is less than 5 characters long
Great! The project is throwing an error if the name contains less than 5 characters long.
https://github.com/bimineco/ifcviewer/blob/8d7f32e14c4c216d7402bf96574fc7e15a846c65/src/classes/Project.ts#L46
However, I would tell you is better not to throw the error in the setUI function. The reason is because you depend on the project to have a UI in order to verify if the name complies with the requirements or not. Let's say, for example, that you change the project name after it has been created, and the new name is less than 5 characters. My suggestion is to create accessors for the name property, so anytime the name changes the verification is done. Accessors are basically getters/setters. So, in the project class, you can write something as the following:
class Project {
  private _name: string = ""

  get name() {
    return this._name
  }

  set name(value: string) {
    if (this.name.length < 5) {
      throw new Error(`${value} is less than five characters long.`)
    }
    this._name = value
  }
}

So, any time the project name is set (like project.name = "New Name" the setter will check if it fulfills the requirements before setting the name.
PD: Cool error modal!
4. Give the project a default date if the user don’t specify one
Great! I see the project taking a default date in case no one is specified.
https://github.com/bimineco/ifcviewer/blob/8d7f32e14c4c216d7402bf96574fc7e15a846c65/src/classes/Project.ts#L53
I've noticed you set the date property as string. While that's ok the UI, I suggest you keep it as a Date object because you can do math between dates in JavaScript (subtracting dates to get a timespan for example). Instead of storing the date as a string, make a helper method (or getter if you want to get it as a property) to give you the date in the string format you need. Something like this will help you with that:
class Project {
  date: Date = new Date() // this sets the default date as the current date

  get formattedDate() {
    const currentYear = this.date.getFullYear();
    const currentMonth = String(this.date.getMonth() + 1).padStart(2, '0');
    const currentDay = String(this.date.getDate()).padStart(2, '0');
    const startDate = `${currentDay}/${currentMonth}/${currentYear}`;
    return startDate
  }
}

So, if you write something like project.formattedDate then you will get in the display format you need for the UI while also keeping the date as a Date object.
5. Make a form to update the project information from the details page
Great! The modal is visible with the corresponding form when I try to edit the information of an existing project. If I accept the form, it gets updated!
6. Let the user create ToDos and store the data in the project
It seems you not only let the user create ToDos, but also to remove them! Nice one. I really liked you have created a custom class that represents the ToDo and also a ToDo Manager for them. The only thing I would like to have is a property in the ToDo with the ID of the project it belongs to. This makes possible to know the project a ToDo belongs to really easy. Also, I really liked the design when the ToDo is opened.
7. Make sure ToDos are exported along the project
Great! The ToDos are exported along the project.
8. Update the project information from JSON if the project already existed
I have made some tests with this one. It seems the project information is updated, but not the UI.

This is very likely due to some missing matching between the project data and the UI it belongs to, maybe?
9. Allow to specify a status for each ToDo. Change the background color based on the state.
Great! I see you are changing the icon color background based on the state and the ToDo color it-self based on the priority. Well done 💪
Just as a general suggestion here, try to not call some functions in English while others in Spanish 😅
Wonderful work Julián! You're going really great 🚀 I would only need to see the project details updating in the UI to give you the corresponding badge for this module.

Code Update in the branch


spotifyd: 0.3.4 -> 0.3.5

Description of changes
https://github.com/Spotifyd/spotifyd/releases/tag/v0.3.5

Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

Slightly off-topic, but is there a reason we don't enable withMpris by default? It's a very useful feature.
(Embarrassingly, I don't even know how to override it.)

Sorry for the delay, I totally forgot about this PR

but is there a reason we don't enable withMpris by default?

I think there is none. I've enabled mpris by default.

Builds on Mac OS, but I get the following error:

I tested it on Darwin. I think you forgot to start spotifyd with your credentials.

I think there is none. I've enabled mpris by default.

Thanks!

Builds on Mac OS, but I get the following error:

I tested it on Darwin. I think you forgot to start spotifyd with your credentials.

Indeed, with credentials supplied it works. But since it works also without credentials for me running the official builds on non-nix machines¹ I would consider this a bug if not:

for some reason it is always necessary to supply credentials on Mac OS, even with official builds of spotifyd (as mentioned and explained in my previous post on this, I cannot test this); and
nixpkgs-supplied spotifyd works without credentials on Linux.

(Since I no longer use nixpkgs-supplied spotifyd I will not investigate this further, nor open an issue—it is a non-issue for me—but perhaps this information will be of help to someone sometime.)
¹ Currently I use the official spotifyd builds on two Raspberry Pis: the armv6 build on a Pi 1 Model B Rev 2 and the armhf build on a Pi 3 Model B+ Rev 1.3. On both of these spotifyd does not need credentials but runs in “discovery mode” (which is convenient if you want guests to be able to connect). Relevant log from the systemd service startup:
May 11 16:56:19 rpi1b-rev2 spotifyd[462]: No config file specified. Running with default values
May 11 16:56:19 rpi1b-rev2 spotifyd[462]: No username specified. Checking username_cmd
May 11 16:56:19 rpi1b-rev2 spotifyd[462]: No username_cmd specified
May 11 16:56:19 rpi1b-rev2 spotifyd[462]: No password specified. Checking password_cmd
May 11 16:56:19 rpi1b-rev2 spotifyd[462]: No password_cmd specified
May 11 16:56:19 rpi1b-rev2 spotifyd[462]: No proxy specified
May 11 16:56:19 rpi1b-rev2 spotifyd[462]: Using software volume controller.
May 11 16:56:19 rpi1b-rev2 spotifyd[462]: no usable credentials found, enabling discovery


Broken links for bandit suggestions in codeguru results

The bandit suggestions after codeguru analysis for api usage recommendations are display with broken links.
Example:
Consider possible security implications associated with subprocess module. [https://bandit.readthedocs.io/en/latest/blacklists/blacklist\_imports.html#b404-import-subprocess](https://bandit.readthedocs.io/en/latest/blacklists/blacklist%5C_imports.html#b404-import-subprocess)
The underscores are not handled correctly during link formatting. It would be great if this could be resolved.
So basically this should be:
Broken: https://bandit.readthedocs.io/en/latest/blacklists/blacklist_imports.html#b404-import-subprocess
Fix: https://bandit.readthedocs.io/en/latest/blacklists/blacklist_imports.html#b404-import-subprocess

Hello, do we have any updates on this?


Call to function disappeared in decompiled code

The reproducing steps:
save the code below:
#include <stdio.h>
#include <stdlib.h>

void test1() {
	printf("1");
	exit(1);
}

void test2() {
	printf("2");
}

int main(int argc, char *argv[]) {
	test2();
	return 0;
}

compile it and strip (strip is required otherwise retdec can correctly infer test2 as a function in early stages):
g++ bug.cpp -o bug_test && strip bug_test

use retdec-compiler:
./retdec-decompiler bug_test

In the result bug_test.c:
// Address range: 0x1149 - 0x1161
// this is test1
int64_t function_1149(void) {
    // 0x1149
    putchar(49);
    exit(1);
    // UNREACHABLE
}

// Address range: 0x1161 - 0x1172
// this is test2
int64_t function_1161(void) {
    // 0x1161
    return putchar(50);
}

// Address range: 0x1172 - 0x118d
// this is main
int64_t function_1172(int64_t a1, int64_t a2) {
    // 0x1172
    return 0;
}

You can see the call to test2(function_1161) disappeared from main(function_1172).
After tracing the bug, it probably comes from:
https://github.com/avast/retdec/blob/18b434f02b64bfb85232525ca10a6026b5d1f54f/src/bin2llvmir/optimizations/decoder/decoder.cpp#L514-L544
The debugger says that tFnc and tTb are null pointers. It comes from:
https://github.com/avast/retdec/blob/18b434f02b64bfb85232525ca10a6026b5d1f54f/src/bin2llvmir/optimizations/decoder/ir_modifications.cpp#L211-L216
Where the code thinks it is in the middle of a basic block and not splitting it. The debug output says:
        processing : 0x1172 (LEFTOVER) (CS_MODE_LITTLE_ENDIAN, CS_MODE_64)
                found range = <0x1172, 0x1205)
                                S: createFunction() @ 0x1172
                                F: splitFunctionOn() @ 0x1172
                        translating = 0x1172
                        translating = 0x1173
                        translating = 0x1176
                        translating = 0x117a
                        translating = 0x117d
                        translating = 0x1181
                                S: ASM @ 0x1161
                                F: getBasicBlockContainingAddress() @ 0x1161
                        translating = 0x1186
                        translating = 0x118b
                        translating = 0x118c

The basic block map for reference:
(gdb) p/x _addr2bb
$5 = std::map with 30 elements = {[{address = 0x1003}] = 0x55555cbdfc70, [{address = 0x1014}] = 0x55555a7aa6c0, [{
    address = 0x1016}] = 0x55555a781dd0, [{address = 0x1030}] = 0x55555cbdc650, [{address = 0x1040}] = 0x55555cbd68d0, [{
    address = 0x1050}] = 0x555558984210, [{address = 0x1053}] = 0x55555a7adc20, [{address = 0x1093}] = 0x55555a7ae270, [{
    address = 0x109f}] = 0x55555cbdff50, [{address = 0x10a8}] = 0x55555a7aa7a0, [{address = 0x10b0}] = 0x55555cbde840, [{
    address = 0x10d4}] = 0x55555cbdfb00, [{address = 0x10e0}] = 0x55555a7ac860, [{address = 0x10e8}] = 0x55555a7ae220, [{
    address = 0x10f3}] = 0x55555cbdfc20, [{address = 0x10fd}] = 0x55555cbdffa0, [{address = 0x110b}] = 0x55555cbd04f0, [{
    address = 0x1118}] = 0x55555cbcc4d0, [{address = 0x111d}] = 0x55555cbd0770, [{address = 0x1130}] = 0x55555a78a880, [{
    address = 0x1143}] = 0x55555cbd60c0, [{address = 0x1149}] = 0x55555cbd6110, [{address = 0x1172}] = 0x55555cbde770, [{
    address = 0x3fd8}] = 0x55555a781e20, [{address = 0x3fe0}] = 0x55555a7aa2d0, [{address = 0x3fe8}] = 0x55555a7ab190, [{
    address = 0x3ff0}] = 0x55555a7ad4f0, [{address = 0x3ff8}] = 0x55555cbdf9e0, [{address = 0x4018}] = 0x55555cbdfe30, [{
    address = 0x4020}] = 0x55555a78a410}

FWIW function_1149 is placed right before function_1161 in assembly:
// test1
    1149:       55                      push   %rbp
    114a:       48 89 e5                mov    %rsp,%rbp
    114d:       bf 31 00 00 00          mov    $0x31,%edi
    1152:       e8 e9 fe ff ff          call   1040 <putchar@plt>
    1157:       bf 01 00 00 00          mov    $0x1,%edi
    115c:       e8 cf fe ff ff          call   1030 <exit@plt>
// test2
    1161:       55                      push   %rbp
    1162:       48 89 e5                mov    %rsp,%rbp
    1165:       bf 32 00 00 00          mov    $0x32,%edi
    116a:       e8 d1 fe ff ff          call   1040 <putchar@plt>
    116f:       90                      nop
    1170:       5d                      pop    %rbp
    1171:       c3                      ret
// main
    1172:       55                      push   %rbp
    1173:       48 89 e5                mov    %rsp,%rbp
    1176:       48 83 ec 10             sub    $0x10,%rsp
    117a:       89 7d fc                mov    %edi,-0x4(%rbp)
    117d:       48 89 75 f0             mov    %rsi,-0x10(%rbp)
    1181:       e8 db ff ff ff          call   1161 <putchar@plt+0x121>
    1186:       b8 00 00 00 00          mov    $0x0,%eax
    118b:       c9                      leave
    118c:       c3                      ret

The function at 1149 ends with an unreachable call instead of ret. And retdec is not recognizing 0x1161 as a basic block. Thus retdec is not working properly.

The BB is later added by Decoder::patternTerminatingCalls():
 splitOnTerminatingCalls():
	find all terminating functions:
		potential term @ function_1030
			-> IS terminating
		potential term @ function_1149
			-> IS terminating
	split BBs after terminating calls:
		split @ 0x1161
	split functions after terminating calls:
		split fnc @ 0x1161
				S: splitFunctionOn @ 0x1161
				S: splitFunctionOn @ 0x1161 on dec_label_pc_1161
					CAN S: split @ 0x1149
					CAN S: split @ 0x1161
				S: splitting @ 0x1161 on dec_label_pc_1161

Thanks for a thorough analysis.

... compile it and strip ...

Could you please attach the binary you produced to this issue? Zip it if it won't let you attach the binary itself. It would be easier and more deterministic if I looked at exactly the same thing as you (different gcc versions can produce different samples).

Sure. Here it is:
bug.zip


common: add macro for static checking array size

In C there's a feature to improve the check of the array size being
passed to a function, by specifying 'static' before the array
size. However this feature is not supported on C++.
This patch wraps the usage into a macro to let the public headers to be
used in C++ programs.
Signed-off-by: Caio Marcelo de Oliveira Filho<EMAIL_ADDRESS>

This should fix https://github.com/solettaproject/soletta/issues/1125.

other than that, +1 :-)

This only needs to go to the headers, not the .c files. No strong opposition, though.

Applied f3aa5fb82145e6dfc08a9ab58c5aa0c93a1fbe55 adding the n to the C++ case.
I've considered not changing the source files, but opted to do it so that is one less rule to think about, always use the macro.


Title:  Ceaser Cipher

Is your feature request related to a problem? Please describe.
Caeser Cipher is used for encryption and Decryption of the the stiring text
Describe the solution you'd like.
It will take the input from the user and encrypt the input according to the key and decrypt only when the key matches
Describe alternatives you've considered.
.
Add any other context or screenshots about the feature request here.
No response

@swapnilsparsh  assign me this issue under Gssoc


document cosmos/ tendermint params that impact hermes operations

Summary
I think we should document in one place the tendermint full node, cosmos and chain related parameters that have an impact on hermes operation.
Things like tm: mempool recheck, max_txs_bytes, etc, prunning, indexing, genesis: max_expected_time_per_block (vs hermes block_time), historical_entries

Problem Definition

Proposal
Add a cosmos section to hermes documentation to cover the above.

Acceptance Criteria

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate milestone (priority) applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

I think this would help clarify a lot of things, so I prioritized it for immediately post-v1 release.

Here is a small dump, not complete, but to give an idea on what is required here.
Assuming

hermes being the hermes' config.toml,
app being the app.toml,
tendermint being the tendermint config.toml,
genesis for the genesis.json

1. Tx-es spanning multiple blocks:
tendermint.recheck == true

2. Gas prices:
hermes.gas_price == app.minimum-gas-prices // check if hermes.gas_price >= app.minimum-gas-prices works

3. tx size
hermes.max_tx_size <= tendermint.max_tx_bytes

and hermes.max_tx_size and others (e.g. hermes.chains.max_msg_num) versus  genesis.consensus_params.block.max_bytes
4. Genesis Parameters
genesis.app_state.ibc.client_genesis.params.allowed_clients must include the clients implemented on-chain and hermes, e.g:
    "ibc": {
      "client_genesis": {
        ...
        "params": {
          "allowed_clients": [
            "06-solomachine",
            "07-tendermint"
          ]
        },
      ...
      },

5. Block time and consensus
hermes.max_block_time vs tendermint.consensus. Assuming a single round:
hermes.max_block_time >
       tendermint.consensus.timeout_propose +
       tendermint.consensus.timeout_prevote +
       tendermint.consensus.timeout_precommit +
       tendermint.consensus.timeout_commit

To tolerate N rounds:
hermes.max_block_time >
       tendermint.consensus.timeout_propose +
       tendermint.consensus.timeout_propose_delta * N +
       tendermint.consensus.timeout_prevote +
       tendermint.consensus.timeout_prevote_delta * N +
       tendermint.consensus.timeout_precommit +
       tendermint.consensus.timeout_precommit_delta * N +
       tendermint.consensus.timeout_commit

Also hermes.max_block_time vs genesis.app_state.ibc.connection_genesis.params.max_expected_time_per_block
For all, try our best to document what happens and the symptoms when the conditions fail (log messages, observable hermes behavior, etc)


Add code usage examples to docs

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@2199b8b). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #1   +/-   ##
=======================================
  Coverage        ?   91.07%
=======================================
  Files           ?        3
  Lines           ?       56
  Branches        ?        0
=======================================
  Hits            ?       51
  Misses          ?        5
  Partials        ?        0

Help us with your feedback. Take ten seconds to tell us how you rate us.


interop: crossl2inbox & cdm changes

Description
There have been some changes to the CrossL2Inbox to improve DevX

ethereum-optimism/optimism#11322

This allows others and the L2ToL2CrossDomainMessenger to be the sole contract
to interact with for initiating and relaying cross-l2 messages, leaving the CrossL2Inbox
to remain an low-level implementation detail.
Update the spec for the change to the CrossL2Inbox and changes for the
L2ToL2CrossDomainMessenger to incorporate these changes

#387  👈
main

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

Join @hamdiallam and the rest of your teammates on  Graphite

Great work @hamdiallam. A few small things then this can be merged


Cache isMember for auth checks

Description
the isMember check for auth checks on the node is not cached, resulting in a guaranteed contract call for each linked wallet associated with a user id every time we check their permissions. Let's use a positive / negative cache to reduce rpc calls to base for auth checks.

https://github.com/river-build/river/commit/6257e6dbf24e4272f15e20fe558269b009f08626


Remove batched styles updates

Fixes #136

@nkzawa @rauchg ping

👍
though not so sure if you really need to get values from styled components on React.

@nkzawa I noticed the bug when I was making a responsive slider. I'd imagine if anyone is working on something more robust with responsive design and/or animations they may run into this issue as well. #140 is related. In my case I didn't mind moving my components style to the global space to remedy the problem. Everyone's mileage varies though.

@iamjacks I would argue that even if it might do harm its still rather important as it "breaks" the promises one comes to rely on when working with the component live cycle methods mainly the component being there and ready when componentDidMount gets called. based on you comment does adding the global flag

By adding the global flag you lose scoped styles which is not acceptable imho.
Also style tags are blocking for a reason and in this case the user should get the expected behavior. I think that you could work around this issue by deferring your logic with setTimeout but again that's not the expected behavior.
@rauchg @nkzawa if you don't have any objections I will merge this PR

@giuseppeg thanks for the clarification. yes setTimeout is exactly what I used to work around this issue.

@giuseppeg I'm 👍 . I think we can reconsider when have any performance problems.


docs: improve readme

Proposal to use center logo rather than using table. I don't like that table that much.
Suggestions appreciated

Closes #161

LGTM


New doc on RTD: Broken "Edit on GitHub" link

Steps to reproduce:

Go to http://esprima.readthedocs.io/en/latest/getting-started.html
Look for the link (top right corner): Edit on GitHub
Click on the link

Actual:
404 from GitHub because the link opens https://github.com/jquery/esprima/blob/master/docs/getting-started.rst (the file does not exist).
Expected:
The link should open https://github.com/jquery/esprima/blob/master/docs/getting-started.md instead.

This seems to be working again. Most like, there was an RTD bug that got fixed.


Cocoapods support

I've found this library to be quite useful for development on iOS projects.
Would you mind if I created a podspec with this so it can be used from iOS projects?

@piercifani that library is about to be gutted if not completely removed with the introduction of Swift NIO...
You are probably better off forking it and adding a podspec to that!

But even if Swift NIO declares its own Future, would every module on vapor that needs a Future be required to import NIO?

So I haven't looked into the NIO integration too much but I believe that Vapor/Vapor will wrap the NIO types into the something that look familiar (could be completely wrong). At worst Vapor can just @_export NIO to expose all of the types without the need for another import


feat: Drop the hostname requirement when handling PV topology

Fixes #N/A
Description
How was this change tested?
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

-3 of 7 (57.14%)  changed or added relevant lines in 1 file are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage increased (+0.09%) to 80.683%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/controllers/provisioning/scheduling/volumetopology.go
4
7
57.14%

Files with Coverage Reduction
New Missed Lines
%

pkg/scheduling/requirements.go
2
97.85%

Totals

Change from base Build<PHONE_NUMBER>:
0.09%

Covered Lines:
7990

Relevant Lines:
9903

💛  - Coveralls

Testing this out: We actually get some interesting behavior here. When the PVC is deleted due to the node cleanup controller, this starts causing Karpenter to think that the capacity that it previously launched should no longer be used because we start ignore the pods due to their PVCs not existing. It's an interesting issue. Not sure that there's a good solve for that additional churn, because we shouldn't respect pods that have NotFound PDBs during our initial scale-out.

Closing for now, since it's still unclear who the users would be for this feature. May consider re-opening if we get more +1 on the original issue (#545).

Not sure that there's a good solve for that additional churn, because we shouldn't respect pods that have NotFound PDBs during our initial scale-out

Seems like the best solve for handling this kind of thing would be to just disable consolidationPolicy for nodes that are using PVs like this. Most likely, users that are going to be relying on the node ephemeral storage like this are going to be pretty cautious about their nodes anyways.
The other option here is to just enable the WhenEmpty condition and set the consolidateAfter value to long enough that the StatefulSet controller has enough time to re-hydrate the PVCs that it needs to when the pods go to reschedule.

The other thing that I'm noting: When I try to run this configuration with the Rancher local path provisioner, I run into some issues when the PVC isn't auto-deleted (or at least when it isn't auto-deleted quickly enough). If the kube-scheduler has enough time to react, it will see that there is a PVC that has a bound PV with a hostname affinity to a node that no longer exists. This causes the kube-scheduler to go lookup the node info and try and bind the pod to the node, which fails with a SchedulerError. That error looks like
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2024-03-01T01:05:16Z"
    message: nodeinfo not found for node name "ip-192-168-16-127.us-west-2.compute.internal"
    reason: SchedulerError
    status: "False"
    type: PodScheduled

The problem with this is that this doesn't match the v1.PodReasonUnschedulable scheduling reason that Karpenter looks for, which means that Karpenter will stop seeing this node for rescheduling and think that it's provisioned too much capacity for the nodes, causing it to scale-down the node that it just launched.
Yet again, I think the right solve here is to set a long enough consolidateAfter or just to disable consolidateAfter altogether to ensure that the node sticks around long enough for the PVC to get deleted, the new PVC to get created, and the pod to successfully schedule to the new node.


Setting prices/tariffs doesn't stick

When you set the Prices per kWh etc. they don't stick. When I look at debug logging I see errors when it's trying to update through the Alfen API's. Setting the 3 different tariffs results in the following error log:
2023-09-13 20:14:13.334 DEBUG (MainThread) [custom_components.alfen_wallbox.alfen] POST with login
2023-09-13 20:14:13.335 DEBUG (MainThread) [custom_components.alfen_wallbox.alfen] Send Post Request
2023-09-13 20:14:14.541 DEBUG (MainThread) [custom_components.alfen_wallbox.alfen] Login response <ClientResponse(https://<IP_ADDRESS>/api/login) [200 OK]>
<CIMultiDictProxy('Content-Type': 'alfen/json; charset=UTF-8', 'Connection': 'keep-alive', 'Content-Length': '0')>
2023-09-13 20:14:14.541 DEBUG (MainThread) [custom_components.alfen_wallbox.alfen] Send Post Request
2023-09-13 20:14:14.608 ERROR (MainThread) [custom_components.alfen_wallbox.alfen] Unexpected error on UPDATE VALUE Connection closed
2023-09-13 20:14:15.760 DEBUG (MainThread) [custom_components.alfen_wallbox.alfen] Login response <ClientResponse(https://<IP_ADDRESS>/api/login) [200 OK]>
<CIMultiDictProxy('Content-Type': 'alfen/json; charset=UTF-8', 'Connection': 'keep-alive', 'Content-Length': '0')>
2023-09-13 20:14:15.760 DEBUG (MainThread) [custom_components.alfen_wallbox.alfen] Send Post Request
2023-09-13 20:14:15.832 ERROR (MainThread) [custom_components.alfen_wallbox.alfen] Unexpected error on UPDATE VALUE Connection closed
2023-09-13 20:14:16.752 DEBUG (MainThread) [custom_components.alfen_wallbox.alfen] POST with login
2023-09-13 20:14:16.752 DEBUG (MainThread) [custom_components.alfen_wallbox.alfen] Send Post Request
2023-09-13 20:14:17.651 DEBUG (MainThread) [custom_components.alfen_wallbox.alfen] POST with login
2023-09-13 20:14:17.652 DEBUG (MainThread) [custom_components.alfen_wallbox.alfen] Send Post Request
2023-09-13 20:14:18.797 DEBUG (MainThread) [custom_components.alfen_wallbox.alfen] Login response <ClientResponse(https://<IP_ADDRESS>/api/login) [200 OK]>
<CIMultiDictProxy('Content-Type': 'alfen/json; charset=UTF-8', 'Connection': 'keep-alive', 'Content-Length': '0')>
2023-09-13 20:14:18.797 DEBUG (MainThread) [custom_components.alfen_wallbox.alfen] Send Post Request
2023-09-13 20:14:18.868 ERROR (MainThread) [custom_components.alfen_wallbox.alfen] Unexpected error on UPDATE VALUE Connection closed

I'm not sure if this is fixed, but I saw that the value is always (on GUI) parsed to integer.

i think it is broken after 2023.09.2

@menloperk can you take a look at this beta version if this solved the problem?
https://github.com/leeyuentuen/alfen_wallbox/releases/tag/2.7.12

For me this was already fixed some time ago with one of the previous updates. So for me this could have been closed (I thought it was).


[Bug]: CVA styling changes don't get applied without a server restart

Environment
Development/Production OS: Mac Ventura 13.6
Node version: v21.0.0
Package manager<EMAIL_ADDRESS>Radix Vue version: 1.0.0
Shadcn Vue version: (shadcn-nuxt) 0.1.0
Vue version: 3.3.13
Nuxt version: 3.9.0
Nuxt mode: universal
Nuxt target: server
CSS framework<EMAIL_ADDRESS>
Link to minimal reproduction
local server required
Steps to reproduce
-Start a new Nuxt project
-Install all shadcn requirements
-install a button component using CLI
-start local live server
-change the button/index.ts -> CVA styles (any)
-watch the browser and see that nothing has changed after hard browser refresh
-restart server
-confirm that changes are now live in the browser
Describe the bug
I am unable to update CVA styling without having to also restart my local server for the changes to take effect.
Other changes to templates, etc, do take affect as expected. It only seems to be CVA which doesn't update.
I don't see any similar github issue on CVA's repo, so I assume it's something about the Shadcn config, though I haven't seen others mention this here, so I'm a bit stumped. I previously used CVA in a Next.js project, and remember sometimes having similar issues, though it was intermittent as far as I can recall.
I've followed the Shadcn guide step by step, and have even started a new project as I thought maybe my initial JS (non-TS) project was the issue, but even with a fresh TS installation of Nuxt, the result is the same. I also tried wrapping components in <ClientOnly> tags, but no change.
If you could suggest anything I might check to resolve this, it would be appreciated.
Expected behavior
CVA style changes shouldn't require a server restart to take affect
Conext & Screenshots (if applicable)
No response

Are you using shadcn-nuxt?

@titusdecali
Thanks for the report, It kinda related to shadcn-nuxt #214
Which it's better Zernonia deprecates it

You can check this StackBlitz
https://stackblitz.com/edit/github-xkryhq-egbi1f?file=modules%2Fshadcn-vue.ts,nuxt.config.ts
modules/shadcn-vue.ts
import {
  defineNuxtModule,
  addComponent,
  addComponentsDir,
  tryResolveModule,
} from 'nuxt/kit';

export interface ShadcnVueOptions {
  /**
   * Prefix for all the imported component
   */
  prefix: string;

  /**
   * Directory that the component lives in.
   * @default "~/components/ui"
   */
  componentDir: string;
}

export default defineNuxtModule<ShadcnVueOptions>({
  defaults: {
    prefix: 'Ui',
    componentDir: '~/components/ui',
  },
  meta: {
    name: 'ShadcnVue',
    configKey: 'shadcn',
    version: '0.0.1',
    compatibility: {
      nuxt: '^3.9.0',
      bridge: false,
    },
  },
  async setup({ componentDir, prefix }) {
    const isVeeValidateExist = await tryResolveModule('vee-validate');

    addComponentsDir(
      {
        path: componentDir,
        extensions: ['.vue'],
        prefix,
        pathPrefix: false,
      },
      {
        prepend: true,
      }
    );

    if (isVeeValidateExist !== undefined) {
      addComponent({
        filePath: 'vee-validate',
        export: 'Form',
        name: `${prefix}Form`,
        priority: 999,
      });

      addComponent({
        filePath: 'vee-validate',
        export: 'Field',
        name: `${prefix}FormField`,
        priority: 999,
      });
    }

    addComponent({
      filePath: 'radix-vue',
      export: 'PaginationRoot',
      name: `${prefix}Pagination`,
      priority: 999,
    });

    addComponent({
      filePath: 'radix-vue',
      export: 'PaginationList',
      name: `${prefix}PaginationList`,
      priority: 999,
    });

    addComponent({
      filePath: 'radix-vue',
      export: 'PaginationListItem',
      name: `${prefix}PaginationListItem`,
      priority: 999,
    });
  },
});

declare module '@nuxt/schema' {
  interface NuxtConfig {
    shadcn?: ShadcnVueOptions;
  }
  interface NuxtOptions {
    shadcn?: ShadcnVueOptions;
  }
}

It's due to the module having ignorePath in components/ui, thus the HMR doesn't work until server restart.
@sadeghbarati  I dun quite understand why deprecate it? We just need to fix the above issue and it will all be good. And in future we can directly use withDefault utility from "radix-vue" to apply default props and stylign without creating more and more .vue file.

I dun quite understand why deprecate it?

I think he meant "replicated" instead of "deprecated".

I dun quite understand why deprecate it?
I think he meant that you "replicated" the issue, instead of "deprecate"

@zernonia
I meant this https://github.com/radix-vue/shadcn-vue/issues/214#issuecomment-1863361722
People want to have less dependency in their package.json

@zernonia Is there an interim solution I can use before this is fixed to get HMR working? I didn't find ignorePath anywhere... not sure what to change.

@titusdecali
Thanks for the report, It kinda related to shadcn-nuxt #214 Which it's better Zernonia deprecates it
You can check this StackBlitz https://stackblitz.com/edit/github-xkryhq-egbi1f?file=modules%2Fshadcn-vue.ts,nuxt.config.ts
Nuxt >= 3.9
Nuxt < 3.9

@titusdecali  this should works well 😁


Multiple Files JSON File Structure - Localized File Collections

Hello, it's me again, I'm trying add multiple-folders JSON structure to the Sveltia CMS so that the client can easily navigate and change localized navigation links:

Sveltia CMS let me directly define files:
  - label: Navigation
    name: navigation
    create: false
    delete: false
    icon: link
    i18n: true
    format: json
    extension: json
    files:
      - file: 'src/locales/lt/headerData.json'
        label: 'header'
        name: 'headerData'
        fields:
          - label: "Links"
            name: "links"
            widget: "list"
            i18n: duplicate
            fields:
              - label: "Text"
              ...
      - file: 'src/locales/lt/footerData.json'
        label: 'footer'
        name: 'footerData'
        fields:
          - label: "Links"
          ...
      - file: 'src/locales/lt/shared.json'
        label: 'shared'
        name: 'sharedData'
        fields:
          - label: "Title"
          ...

This setup works well, and surprisingly, Sveltia CMS functions with a single JSON file for both locales. However, the localization library I use is highly opinionated and uses a multiple-folder JSON file structure. It also doesn't support nested folders, which leads to issues. This is the folder structure of localized json files that I setup.

Would it be possible for you to add Multiple Folders JSON File Structure?
In this case, I would imagine the workflow:
provide the file path of json file:
i18n: true
files:
- file: 'src/locales/lt/headerData.json'
With i18n flag present, the Sveltia would look for locale identifiers in the JSON. If it does not find any, it would look for the second locale folder: 'src/locales/en/headerData.json'. Or just use some flag field to trigger the multiple-folder locale json structure,
I hope I explained my idea clearly.

It’s an open issue in Netlify/Decap CMS and on my todo list 😎

https://github.com/decaporg/decap-cms/issues/5280

I was wondering how to solve this without breaking backward compatibility, but it’s probably not hard to do it.

Allow developers to use the {{locale}} template tag in the file path file path, e.g. src/locales/{{locale}}/shared.json
Sveltia CMS enables multiple files/folders mode only if {{locale}} is used and the multiple_files or multiple_folders i18n structure is configured.
Sveltia CMS generates files for all the locales while replacing {{locale}}

Let’s see if this works.

Yes, I was thinking about a solution too that does not break the existing workflow, and your src/locales/{{locale}}/shared.json idea looks like an elegant solution. {{locale}} does not break any existing logic. 👍

thank you for the workaround, will try.

Done in v0.29.0 🚢

whoah! Thanks a lot! It was the last barrier to building a functional fully i18n web personal stack. 💯

@kyoshino,
serious question:
how are you so productive with this project? Decap CMS has 500 contributors, but their last commit was one month ago with a single feature.

I just want to ship a much better product than Decap CMS 😄 The i18n support is my particular concern since my own clients usually require a multilingual setup. A new client wants to have content in Japanese, English and French.
Not sure what’s happening with Decap. There are even no maintainer responses to new issues and PRs these days. Perhaps some of them have been laid off, or the company has limited their time working on the project 🤔

Yeah, something strange is happening. There are over 500 open issues, and most of them with bug tags concern me. I think I have tried almost all the CMSs on the market, from closed-source Contentful to open-source Fresh Star Payload CMS. Most of them were overkill for my needs, so I narrowed my search to Git-based CMSs to avoid running a server for the CMS or being at the mercy of corporations that might pull the plug. In my humble opinion, the Keystatic CMS is great, I liked the keystatic.cloud, but I didn't like the UX; it is too dev-centric with all the Git functions. Pages CMS is great too; I liked the UI a lot, but the i18n is non-existent and it lacks some advance features.
After some testing, I thought I would stick with the half-decent Decap until I found your CMS. This is all I need, and the i18n is perfect. In Europe, i18n is a must. I'm glad I found your CMS. 👍

I think I encountered a bug when I try to upload an image with a localized file structure. It doesn't matter whether it is an md, yaml, or json file. The image won't upload when there is a localized file structure. Additionally, I can't see my local images in the "All Asset" window.
To recreate, run this schema:
collections:
  - label: 'Test'
    name: 'test'
    create: true
    format: json
    extension: json
    i18n: duplicate
    editor:
      preview: false
    files:
      - file: 'src/content/{{locale}}/test.json'
        label: Test Data
        name: testData
        slug: testData
        i18n: duplicate
        editor:
          preview: false
        fields:
          - label: Test Image
            name: testImage
            widget: object
            i18n: duplicate
            fields:
              - {label: Image, name: src, widget: image, i18n: duplicate}

https://github.com/sveltia/sveltia-cms/assets/145860771/3f500ef6-c91b-4d79-9f11-fa550e40d2ab

Will check.

Fixed in v0.29.1 🙇🏼 Two unrelated issues were involved.

that was fast! It's now working 👍

Yeah, something strange is happening. There are over 500 open issues, and most of them with bug tags concern me.

I was checking the numbers last night. Sveltia CMS has already solved at least 90 (or 120 if you count duplicates) of these Netlify/Decap CMS issues. Will soon reach a milestone 💯


Problems with accents

Good work Giorgio,
I am Spanish and we have the problem of accents when sending a text to the printer, I already tried UTF-8 and ISO-8859-1, but it prints badly. Is there any way to send encoded and to print the accents correctly?
Thanks!

@Filmulti what is your printer model? Have you read about some limitation on the manual? Maybe a printer config?

Closing due to long time without activity.
If necessary I'll reopen.


UnicodeDecodeError when installing/updating BinSync on Windows via Manage Plugins

Version and Platform (required):

Binary Ninja Version: 4.1.4966-dev Personal (ddc14755)
OS: Windows
OS Version: 10.0.26080.1400
CPU Architecture: x64
Python Version: 3.11.4

Bug Description:
When installing/updating BinSync on Windows via Manage Plugins, I see this in the log:
[Default] BinSync
[Default] Exception ignored on calling ctypes callback function: <bound method PythonScriptingProvider._install_modules of <binaryninja.scriptingprovider.PythonScriptingProvider object at 0x000001F3564F4750>>
[Default] Traceback (most recent call last):
[Default]   File "C:\Program Files\Vector35\BinaryNinja\plugins\..\python\binaryninja\scriptingprovider.py", line 1414, in _install_modules
[Default]     if python_bin is not None and not self._pip_exists(str(python_bin), python_env=python_env):
[Default]                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[Default]   File "C:\Program Files\Vector35\BinaryNinja\plugins\..\python\binaryninja\scriptingprovider.py", line 1316, in _pip_exists
[Default]     return self._run_args([python_bin, "-m", "pip", "--version"], env=python_env)[0]
[Default]            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[Default]   File "C:\Program Files\Vector35\BinaryNinja\plugins\..\python\binaryninja\scriptingprovider.py", line 1311, in _run_args
[Default]     return (True, subprocess.check_output(args, startupinfo=si, stderr=subprocess.STDOUT, env=env).decode("utf-8"))
[Default]                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[Default] UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf8 in position 29: invalid start byte
[Default] Successfully updated:

Steps To Reproduce:
Install or update BinSync via Manage Plugins. I would guess that there are also some environmental factors needed to reproduce this, but I don't know what exactly.
Expected Behavior:
No exception.

I just realized I actually already mentioned this over in #4510. :eyes: But I guess it's a different issue since the Python plugin loads fine after that was fixed.
Also, it's just installing/updating BinSync in particular that seems to break. (No other plugins that I've tried have this issue.)

This happens when binary ninja tries to run the following command: python -m pip --version. On my box, this returns: pip 24.0 from /opt/homebrew/lib/python3.11/site-packages/pip (python 3.11). On a Windows box, this path probably includes the user's home directory, which contains non-ASCII chars. And since the python.exe that comes with binary ninja is not built with UTF-8 as default code page, it is probably returning the string in another encoding. So that the subsequent decode("utf-8") fails.
I guess we just need to apply the same fix as https://github.com/Vector35/binaryninja-api/issues/4510, but this time to python.exe. For reference: https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page

Just to clarify, I'm not using the Python shipped with BN, but rather Python 3.11.4 installed from python.org.

Just to clarify, I'm not using the Python shipped with BN, but rather Python 3.11.4 installed from python.org.

Thanks for the info! Then I think the problem is trickier -- we can control what Python we ship, but we cannot control what Python people are using.
Also, just wish to confirm my guess, would you please run python -m pip --version (with the python 3.11.4 you mentioned above), redirect the output to a file, and let me know its content and encoding?

We might need to do something like this: https://github.com/mandiant/capa/blob/master/capa/features/extractors/binja/find_binja_api.py, that have the python script encode the output as hex, and we then harvest it

I proposed a temporary fix which avoids running a command that may return non-ASCII chars: https://github.com/Vector35/binaryninja-api/commit/c6cad5b7c551

❯ /c/Program\ Files/Python311/python.exe -m pip --version > pip-ver
❯ file pip-ver
pip-ver: ISO-8859 text, with CRLF, CR line terminators

❯ /c/Program\ Files/Python311/python.exe -m pip --version > pip-ver
❯ file pip-ver
pip-ver: ISO-8859 text, with CRLF, CR line terminators

Thanks for the info! This confirms my guesses.
At the same time, would you like to apply the patch in https://github.com/Vector35/binaryninja-api/commit/c6cad5b7c551 and see it it actually fixes the problem? This issues is a bit inconvenient for me to test, so if I can get feedback from you directly that would be very helpful! The scriptingprovider.py should be in %APPDATA%\Vector35\BinaryNinja\python\binaryninja

Yes, that patch seems to work fine on my end. BinSync now installs w/o any errors.


Update the error message when subscripting String with Int.

Instead of referring to a doc comment that isn't really accessible to the developer, let's just be accurate about what type they should be using here.

I think this is an improvement — it gives concrete, actionable feedback of what to you should do when you see this error.
The doc comments have more detailed information about why these methods shouldn't exist.  However, I'm not finding a way to view that content in Xcode or on developer.apple.com.  Is that expected?

IIRC the doc comments that have this info are on extensions, which don’t end up being attached to any particular symbol when SourceKit imports the module. Would this info make sense to move to the actual subscript docs? It feels a little weird to explain why an API isn’t written a different way, and there is an SE proposal to add Int-offset-based element access and slicing…

@swift-ci Please smoke test and merge

Looks like the smoke test failed because test/stdlib/UnavailableStringAPIs.swift.gyb is expecting the old error messages.

@swift-ci Please smoke test

@swift-ci Please smoke test


Add Locality name prohibited check

@zakird feel free to take a look at this as well.

@zakird it's true, you have. Just different subject fields but the same properties on all of them. It's almost done though!


$refs can also contain CreateComponentPublicInstance

What kind of change does this PR introduce? (check at least one)

[ ] Bugfix
[x] Feature
[ ] Code style update
[ ] Refactor
[ ] Build-related changes
[ ] Other, please describe:

Does this PR introduce a breaking change? (check one)

[ ] Yes
[x] No

If yes, please describe the impact and migration path for existing applications:
The PR fulfills these requirements:

[ ] It's submitted to the dev branch for v2.x (or to a previous version branch), not the master branch
[ ] When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
[ ] All tests are passing: https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#development-setup
[ ] New/updated tests are included

If adding a new feature, the PR's description includes:

[ ] A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:
$refs in Vue's previous instance can also contain references to the new defineComponent style components. This fixes an issue where if you are referencing a defineComponent component inside a vue-class-component it throws errors about mismatching $refs type

@yyx990803 This fixes an error where $refs can't be typed properly when using the new defineComponent created components


unable to host cf command line

After installing latest version of cli 7, i try run cf.exe in my windows 10 64 bit, but the application opens and closes immediately, i could not find any logs in windows event viewer. Can you please let us know what could be issue.

Hi @satishpadidem, how did you install cf CLI 7? What happens if you run cf.exe -v from Powershell?

I have downloaded windowsx64 bit exe and and double clicked it.
And when i run the cf.exe -v it shows cf.exe version
6.53.0+8e2b70a4a.2020-10-01
thanks
satish
On Wed, Oct 7, 2020 at 3:51 AM Nick Webb<EMAIL_ADDRESS>wrote:

Hi @satishpadidem https://github.com/satishpadidem, how did you install
cf CLI 7? What happens if you run cf.exe -v from Powershell?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/cloudfoundry/cli/issues/2061#issuecomment-704583823,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEFPSRPXWIF4Y2GH5P32YKTSJOJ5RANCNFSM4SETSHJQ
.

--
Live every moment of your life

@satishpadidem The Cloud Foundry Command Line Interface (CLI) you have downloaded is working as expected.  It is a command line interface, and as such, is meant to be used on the command line.


data_sub not accessible on trackingdictionary it seems? check Mismatch journal

data_sub not accessible on trackingdictionary it seems? check Mismatch journal for example of the info I'm trying to access but that is not being saved.

addressed in development version.


Console app wait on operations to finish

So I followed the example in the readme, but I had an issue that the program ended before the operation completion was called. I fixed it by placing a CFRunLoopRun() at the bottom of my code, I was wondering what your thoughts are on dealing with this?

In order to receive callbacks on any asynchronous functions, some type of run loop must be in place.
OpenCloudKit is mainly designed to be used with a Swift web framework such as Vapor or Perfect which implement their own run loops. However you can use it by itself using the CFRunLoopRun() as you mentioned.


Deploy windows binary (#362)

Built using appveyor and uploaded when releases are made. See example: https://github.com/cxong/black/releases/tag/appveyor_deploy_test5
Note: this uploads an .exe which might be blocked depending on your computer settings. Should it zip the exe instead?

Pull Request Test Coverage Report for Build 598

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 96.003%

Totals

Change from base Build 590:
0.0%

Covered Lines:
2618

Relevant Lines:
2727

💛  - Coveralls


Feed data update

Description
Changes
DONE:

[x] checks submission count
[x] check heartbeat
[ ] check deviation threshold
[x] update feed update timestamp

BLOCKED:

need a way to map cosmos keys to chainlink keys

	// TODO will need to deconstruct each individual signature and make sure that the DP's key are equal.
	// TODO will need to figure out a scheme to correspond the chainlink signature (pubkey) to the cosmos account.
	// TODO only pay out the DP who provides their signature.

deviation threshold trigger:

	// TODO the feed data submitted is an arbitrary byte array, which could be deserialized to a OCRABIENCODED struct, but there is no price data that can be compared. this will need to be discussed.
	// TODO doesnt seem as though there is a PRICE variable sent in the OCRv2

Closes: #104

@@ -56,7 +56,7 @@ message MsgFeed {
   // TODO: RewardConfig: Struct describing how rewards should be paid
   uint32 feedReward = 8;
   // LastUpdate is the time of which the last feedData was submitted.
-  google.protobuf.Timestamp lastUpdate = 9;
+  google.protobuf.Timestamp lastUpdate = 9 [(gogoproto.stdtime) = true];
 }

 // DataProvider is the type defined for feed data provider

Maybe using standard time from Go? (Need 2 ou 3 simple code modification to use as standard time.Time)


Update netbox version to 3.0.7

Hi. Thanks for your PR.
Have you gotten a chance to review https://github.com/lae/ansible-role-netbox/issues/132 and if so, can you confirm that you've read through the changelogs for NetBox up until the current release to ensure that any new configuration changes/features are accounted for in this changeset?

So I quickly tried to validate for myself and read through the changes from 2.9.9 to 2.10.10 (so there might still be stuff missing for 2.11.x and 3.0.x), and found these two that affect this role:
https://github.com/netbox-community/netbox/issues/5938 (which we already have an issue for, #127, and I guess #125 is also of concern)
https://github.com/netbox-community/netbox/issues/6083 (see associated PR for details)
I also realised I could quickly do a diff on some files to help pinpoint configuration changes and upgrade.sh changes from 2.9.9 to current:
https://gist.github.com/lae/a24a0bc366e76626ff65f48c9ed32319
On a quick skim most of the config file changes look superficial and so the only thing that could probably use an update is the example at examples/netbox_config.yml. The redis change (the second PR mentioned above) is done in the config template/with role variables. One of the upgrade changes already has a PR at #124 that I guess I need to go back to later.


Add APIcast 2.0 OpenShift template to ansible-openshift installer

Add the APIcast 2.0 OpenShift template to the Ansible-Openshift installer, so when the customer installs OpenShift, the APIcast templates gets automatically installed.
The GitHub repository is this:
https://github.com/openshift/openshift-ansible
Process
From @sdodson: We just sync the file from your upstream repo into the installer repo. Your teams can either open pull requests against openshift-ansible or email me and let me know the new tag to
include and we'll update it then.

The productized template can be found here https://github.com/3scale/rhamp-openshift-templates
Nothing else required from engineering.

This will be overwritten in the future with the AMP 2.0 release apicast
template, correct?
New issue for that task?
On Jan 17, 2017 9:00 PM, "Vanessa Ramos"<EMAIL_ADDRESS>wrote:

Closed #175 https://github.com/3scale/apicast/issues/175.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/3scale/apicast/issues/175#event-926393967, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFReLCpMFgQ0GlN_KoJcCokUHYj4bwEUks5rTR3QgaJpZM4LE0Yp
.

I don't think it's needed. Nothing additional required from engineering.

I just mean that we'll need to remember to do the same action with the final template when we do GA of AMP 2.0 ..... will leave to you on how to ensure that is done.


Upgrade to org.dmfs:httpurlconnection-executor:1.x.x

The new version httpurlconnection-executor is not compatible with the latest version of oauth2-essentials.
java.lang.NoSuchMethodError: 'org.dmfs.jems.optional.Optional org.dmfs.httpessentials.client.HttpResponseEntity.contentType()'

Good point. I'll take care of that.

I just checked, the latest version of the httpurlconnection-executor is actually 0.20. I see there is a version 1.16.2 on Maven Central. Not sure how that came into being. Must have been a mistake. I'll think of a way to resolve that. Unfortunately there is no way to remove that version from Maven Central. I might have to publish a version newer than that.

@dmfs We just ran into this issue as we implemented Renovate Bot (dependency updater), which automatically bumped the version of that lib to 1.16.2. Would it be possible to release a version newer than that, as you suggested above? Thanks! 🙏🏼


connect error

it was working fine but now it gives me this error
I even deleted all from sd card and did all from scratch but no go
error
Error data will appear here
Connection closed.   at BotwTrainer.TcpConn.Read(Byte[] buffer, UInt32 nobytes, UInt32& bytesRead)
at BotwTrainer.Gecko.ReadDataBufferSize()
at BotwTrainer.Gecko..ctor(TcpConn tcpConn, MainWindow mainWindow)
at BotwTrainer.MainWindow.ConnectClick(Object sender, RoutedEventArgs e)

Are you sure you have the correct IP address? They can change from time to time depending on your network situation.

Yes ive set static ip and even ping tested it

If i uncheck read buffer size the game frezzes

If you uncheck it during playing?
I'd just suggest not changing that option until you disconnect


[Monaco] Add .cjs to monaco_languages.json

Adds .cjs to monaco_languages.json

PR Checklist

[x] Closes: #26875
[ ] Communication: I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
[ ] Tests: Added/updated and all pass
[ ] Localization: All end user facing strings can be localized
[ ] Dev docs: Added/updated
[ ] New binaries: Added on the required places

[ ] JSON for signing for new binaries
[ ] WXS for installer for new binaries and localization folder
[ ] YML for CI pipeline for new test projects
[ ] YML for signed pipeline

[ ] Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

,".cjs" has been added to "javascript" list

Validation Steps Performed
I manually checked if my .cjs file had some neat formatting

@Svenlaa
The file you have changed is auto generated based on a different file. You have to add this in a different file and then you need to generate monaco_languages.json file.
cc: @Aaron-Junker

The only other file it similar extenions .mjs appears in this repo is at /src/common/FilePreviewCommon/monacoSRC/min/vs/editor/editor.main.js
If it generates based on microsoft/monaco-editor, it should have been updated through this commit from over a year ago.

I guess #26375 should also fix this.