text:
bad compatibility/deprecation issues

hi.
1- most the games using UIManager.cs as main script for managing ui components. and this is package tool! so plz add namespace to uimanager.
like: namespace TonSdk { }
2- using double filed is deprecating all unity versions before 2022 without any real upgrading to this tool. please use textfiled instead and convert value to double in try catch block.
ty.

Hi, the author of this solution is not a unity developer, so it's not surprising.
If you don't want to agonize with integrating this “library”, take a look at mine (soon to be added to the official ton connect documentation, by the way)
https://github.com/MrVeit/Veittech-UnitonConnect

authors: MrVeit mkfcga

repo: continuation-team/unity-ton-connect


text:
SQLITE_BUSY: Implement busy_timeout and WAL for all connections

Description
Add busy_timeout and WAL to all SQLite connections

Set busy_timeout on all SQLite connections to avoid SQLITE_BUSY errors during concurrent access.
Enable Write-Ahead Logging (WAL) for better concurrency and performance.
These changes improve the reliability and robustness of database operations under load.

Checklist

[x ] The base branch of this PR is dev, rather than main

Aiming to reproduce and prove that this solves before merging, will try soon to do this

@rootedbox Want to ask your expert opinion on this: we've discussed doing busy_timeout only right now to see if that solves the problem, and then doing WAL only after we've run the first experiment. Any reason to oppose? Am weary of changing too many variables at once with codebase indexing, historically this has gone wrong.

@sestinj sounds like a good plan I'll close this and I have created this https://github.com/continuedev/continue/pull/2183

@sestinj agreed.. created this https://github.com/continuedev/continue/pull/2184

source: gharchive/pull-request

authors: rootedbox sestinj

repo: continuedev/continue

license_type: permissive

license_source: github-api


text:
APP_ENDPOINT for symfony is /index.php instead of /app.php

PR #394  has broken our build!
/usr/local/share/40-stack has this line:
export APP_ENDPOINT=${APP_ENDPOINT:-/index.php}
Before DEFAULT_APP_ENDPOINT was computed and used to set APP_ENDPOINT to /app.php
in /usr/local/share/env/30-framework
This logic with DEFAULT_APP_ENDPOINT has been moved to /usr/local/share/env/45-framework, but that runs after /usr/local/share/40-stack, so the APP_ENDPOINT now always ends up as /index.php.

Hi @TerjeBr, sorry that you encountered this.
Does using the stable tag instead of latest work for you?
Which symfony image variant are you using?
Do you have symfony/flex in your composer.lock anywhere?

Our Dockerfile begins with
FROM quay.io/continuouspipe/symfony-php7.1-apache:latest
We were using latest instead of stable because of some other issues. But may be we can go back to stable, I will have to check.
No, symfony/flex is not in our composer.lock anywhere.

This issue can now be closed, since #408 has been merged.

Thanks @TerjeBr!

source: gharchive/issue

authors: TerjeBr kierenevans

repo: continuouspipe/dockerfiles

license: MIT


text:
Add support for IAM Instance profiles

Deployment of EC2 instances as Go Agents currently does not support IAM Instance Profiles. Any tasks a Go Agent runs that uses an instance profile for authentication to the AWS API will not work.
Provide a way to specify an instance profile in an elastic agent profile so that ec2 instances are provisioned with an instance profile associated to them.

Hello @brettcave! This feature seems very handy, thank you. I will review and test it and include to the next version as soon as I can.

Feature reviewed and tested on GoCD server 20.4. Will be included into the next release.

authors: brettcave v-sky


text:
Some small corrections and fix automatic adjustement of atlas size

Closes https://github.com/contour-terminal/contour/issues/1049
Issue was with atlas size, magic factor of 3 is enough for 2k resolution to not get this bug
I am not sure about 4k resolution though since i can test only on 2k, so @christianparpart  maybe you can give it a try?

Uff, many thanks. Let me try (to understand) that tomorrow first. We can talk about it in our call then, as well. :)

authors: Yaraslaut christianparpart

repo: contour-terminal/contour


text:
🛑 MPS - TESTPROCESS is down

In 58345f6, MPS - TESTPROCESS ($TESTPROCESS_URL) was down:

HTTP code: 200
Response time: 480 ms

Resolved: MPS - TESTPROCESS is back up in 0e7784f after 1 hour, 52 minutes.

repo: conuti-das/status-lfrcs


text:
Removing pillow dependency? revisited

This question was asked in 2017 -- Remove dependency on Pillow? #1286 -- but it seems worth bringing up again.
While reviewing my dependencies from my cookie-cutter generated Django project, I noticed the sizable and dependency on Pillow.  As far as I can tell, this dependency is completely unused.  Removing the Pillow dependency shrunk my docker container by 20 MB, significant to be worthwhile in my opinion.
I believe that Pillow was originally added here https://github.com/cookiecutter/cookiecutter-django/commit/988b4f8a46c73e5ae45b77aa00abed43a3d295a1 in 2013 and has been the requirements ever since.

@picturedots Thanks for the comment.
I don't know if @browniebroke  agrees with me, but cookiecutter-django is a highly opinionated project. Historically we have provided Pillow, because it has several non-Python dependencies that can be (or were) difficult to remember/install for each of the supported operating systems and also because Pillow will in most cases be a dependency that will be added later in projects .
Furthermore, removing Pillow from the generated project is trivial.
I vote to keep Pillow even though it is not initially used directly by the generated project.

Pillow is an dependency of Django itself, otherwise the ImageField cannot be used: https://github.com/django/django/blob/289f48c71b0fdd058defb29879368897fb837021/django/db/models/fields/files.py#L435

Thanks.  I'm glad I asked...now there's a bit more info for someone else who is interested in optimizing their docker containers.
I can confirm that for anyone not using ImageField that simply removing the line from requirements is all that is required to remove.

authors: foarsitter luzfcb picturedots

repo: cookiecutter/cookiecutter-django


text:
support after suite callbacks

Currently, rrrspec does not support "config.aster(:suite)".
This pr may work well but I can not add the test. It’s over my head.

LGTM

LGTM.

This pr may work well but I can not add the test. It’s over my head.

Add config.after(:suite) case to local_test specs. We can check the behavior manually.

I setuped local_test and tried to write spec.
However,  Writing the test of 'config.after(:suite)' is difficult for me. I have no idea.
Could I merge it without tests?

:ok:

authors: eagletmt eudoxa k0kubun

repo: cookpad/rrrspec

license: mit

license_source: bigquery


text:
travis

enabling caches will (hopefully speed up the build/tests).

looking at the built time of the pull request this is way faster

repo: coolcrowd/object-service


text:
[Enhancement]: Add the possibility to manage Volume and persistent storage of applications with Coolify API

Request Type
Improvement
Description
Is it possible to add the possibility to manage volume and persistent storage with the Coolify API

Are you planning to add a bounty to this issue, otherwise I will convert it to a discussion as issues are only for bugs and bounty enhancements?

authors: APKiosk-Developers peaklabs-dev

repo: coollabsio/coolify


text:
[Feature]: Add SOURCE_COMMIT and SOURCE_BRANCH ENV variables

Is there an existing issue for this?

[X] I have searched the existing issues

Summary
Adding build-time or runtime-variables such as SOURCE_COMMIT, SOURCE_BRANCH, SOURCE_PRMR_ID.
Why should this be worked on?
I see that there's such a SOURCE_COMMIT build arg in:
https://github.com/coollabsio/coolify/blob/main/apps/api/src/lib/buildPacks/common.ts#L707
It didn't work for docker-compose builds I believe it's for Dockerfile builds.
I belive if we make these variables it will be easier to manage versioning easily track errors for each release.
For example in sentry we can set SENTRY_RELEASE env variable so each error assigned to a spesific release. If we expose these env or build variables it will be easy to set SENTRY_RELEASE env variable.

I'm closing this issue, because tracking features will be moved to GitHub discussions. Github issues will be only for bugs.
Version 4 is in full focus. v3 related issues will be closed, if it is not a critical bug.
Thanks for your understanding.

authors: andrasbacsai zek


text:
手机作为中心，如何连接多个外设

你好，这个蓝牙库非常好用，最近有个需求要同时连接两个外设，实际开发过程中 连接第二个外设的时候会断开第一个外设，请问该如何操作，谢谢。

不可以

authors: DevDu yangxiangwei

repo: coolnameismy/BabyBluetooth


text:
HungerOverhaul is overwriting HungerTweaker changes

I can't figure out how to make HT load after HO

What specifically is it overriding? The loading order definitely doesn't matter, but there could be issues elsewhere, and I'll need more information to track them down.

Any change that I make using HT gets overriden by HO, making HT completely unusable while HO is installed

authors: Flypaste coolsquid

repo: coolsquid/HungerTweaker

license: Unlicense


text:
Avoid extra copying in ParserContextImpl.getSurroundingText

Fix a few places where unnecessary String or List copies were made.

This fix is now released in 4.0.1

repo: copper-leaf/kudzu


text:
Clear event

Adds a clear event that can Leave all Portraits, clear background, clear music, clear style and clear portrait position changes.
Also changes the icon for position event.

fixes #1699 (and in turn kinda #1646)

I will merge this as it works fine in my tests.

repo: coppolaemilio/dialogic


text:
emulator.read_file does not work with GitHub images (linux.iso, linux4.iso)

none of emulator.read_file and emulator.write_file method work on these images.

It works in linux4.iso but it's mounted in /mnt/. In older images it's not supported, so I'll close this issue.

This is what I get for linux4.iso
[   34.329300] Write protecting the kernel text: 8320k
[   34.341700] Write protecting the kernel read-only data: 2344k

[   34.801200] 9pnet_virtio: no channels available for device host9p
[   34.818400] 9pnet_virtio: no channels available for device host9p
mount: mounting host9p on /mnt failed: No such file or directory
Files send via emulator appear in /mnt/
~% [  176.409300] random: crng init done

This is the log for another browser
[   96.038599] Write protecting the kernel read-only data: 2344k

[   96.442899] 9pnet_virtio: no channels available for device host9p
mount: mounting host9p on /mnt failed: No such file or directory[   96.451699] 9
pnet_virtio: no channels available for device host9p

Files send via emulator appear in /mnt/

Even if I try to manually mount I get

~% mount -t 9p host9p /root/aa
[  157.307399] 9pnet_virtio: no channels available for device host9p
mount: mounting host9p on /root/aa failed: No such file or directory

authors: copy lunu-bounir


text:
changes for nixpkgs PR 285276

EDIT by @CohenCyril: testing https://github.com/NixOS/nixpkgs/pull/285276

Keeping this as draft until upstream PR https://github.com/NixOS/nixpkgs/pull/285276 is merged.

Thanks

repo: coq-community/coq-nix-toolbox


text:
Firehose metrics add subsystem, create override_default_tags

Description

Added subsystem value to common attributes of firehose metrics
Added override_default_tags to allow users to override the default tags we set

How Has This Been Tested?
Local testing with our AWS account
Checklist:

[ ] I have updated the relevant example in the examples directory for the module.
[ ] I have updated the relevant test file for the module.
[ ] This change does not affect module (e.g. it's readme file change)

Hey @ryantanjunming just an idea, perhaps var.override_default_tags should be a boolean. var.user_supplied_tags remains the variable for user input. The former just changes the behavior of the merge. If true, the user-supplied tags come later in the merge, if false the other way around (which is the default).
Having two maps for user-supplied tags will be confusing.

@macmiranda i'll set it as var.use_default_tags boolean default to true. If false, it will remove the default tags and leave just the var.user_supplied_tags.
So it's possible to have it empty also.

authors: macmiranda ryantanjunming

repo: coralogix/terraform-coralogix-aws


text:
🛑 Guangdianyun is down

In fa1e51f, Guangdianyun (https://www.guangdianyun.tv) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Guangdianyun is back up in a14ea6b.

Resolved: Guangdianyun is back up in a14ea6b.

repo: corcd/charlotte


text:
CORE-12786: Add an Evm Worker

This is the shell of the worker.  The processor wil be added after

We won't need a worker any time soon and things will probably change so we'll revisit when necessary

repo: corda/corda-runtime-os


text:
On Ubuntu 16 "Unrecognized Content-Security-Policy directive" reported from some tests

I chose to use Ubuntu 16 (not 14) as my newest base, since I expect we'll be moving there, and I get a lot of warnings during testing ("rails test").  I believe they're all from test/feature testing, where Capybara is in use.  The warnings all look like this (in real output there are a lot of them):
Unrecognized Content-Security-Policy directive 'base-uri'.
Unrecognized Content-Security-Policy directive 'block-all-mixed-content'.
Unrecognized Content-Security-Policy directive 'form-action'.
Unrecognized Content-Security-Policy directive 'frame-ancestors'.

The following test does not create these reports:

rails test test/features/access_home_test.rb:10

But the following test does create these reports:

rails test test/features/access_home_test.rb:15

These two tests do almost exactly the same thing, but the second one sets "js: true" as follows:

scenario 'New Project link', js: true do

So the problem ones are the ones where capybara is invoking the JavaScript driver.  At that point, Capybara.current_driver is :poltergeist.
As a test, I switched the JavaScript driver to Chrome (I already had Chrome installed), and that worked perfectly:

DRIVER=chrome rails test test/features/access_home_test.rb

However, using Chrome directly is much slower - I don't really want to do that during testing if we don't need to.
I didn't find any immediate hints by Googling.

Here's a few notes on our tech stack:
Capybara provides the basic infrastructure for browser-level tests. When we set js: true (to test with JavaScript processing enabled), we call our default javascript_driver, which is poltergeist. Poltergeist is "a driver for Capybara. It allows you to run your Capybara tests on a headless WebKit browser, provided by PhantomJS."
A serious issue is that PhantomJS development has been suspended as of March 3 this year - here are more details.
That suggests to me that we should consider an alternative Capybara driver for JavaScript.  The alternatives are selenium and capybara-webkit.  Selenium requires Firefox to be installed, and is slower because it actually invokes the real Firefox browser.   In contrast, "capybara-webkit driver is for true headless testing. It uses QtWebKit to start a rendering engine process.  It can execute JavaScript as well. It is significantly faster than drivers like Selenium since it does not load an entire browser."
I intend to investigate switching to capybara-webkit further.  If it fixes the problem, and is maintained, that'd be a win-win.

I think we should use Capybara with Headless Chrome.
https://robots.thoughtbot.com/headless-feature-specs-with-chrome
--
Dan Kohn dan@linuxfoundation.org
Executive Director, Cloud Native Computing Foundation https://www.cncf.io
+1-415-233-1000 https://www.dankohn.com
On Thu, Jul 12, 2018 at 7:32 PM, David A. Wheeler notifications@github.com
wrote:

Here's a few notes on our tech stack:
Capybara
https://github.com/teamcapybara/capybara#using-capybara-with-minitest
provides the basic infrastructure for browser-level tests. When we set js:
true (to test with JavaScript processing enabled), we call our default
javascript_driver, which is poltergeist. Poltergeist
https://github.com/teampoltergeist/poltergeist is "a driver for
Capybara. It allows you to run your Capybara tests on a headless WebKit
browser, provided by PhantomJS."
A serious issue is that PhantomJS development has been suspended
http://phantomjs.org/ as of March 3 this year - here are more details
https://github.com/ariya/phantomjs/issues/15344.
That suggests to me that we should consider an alternative Capybara driver
for JavaScript. The alternatives are selenium and capybara-webkit. Selenium
requires Firefox to be installed, and is slower because it actually invokes
the real Firefox browser. In contrast, "capybara-webkit driver is for true
headless testing. It uses QtWebKit to start a rendering engine process. It
can execute JavaScript as well. It is significantly faster than drivers
like Selenium since it does not load an entire browser."
I intend to investigate switching to capybara-webkit further. If it fixes
the problem, and is maintained, that'd be a win-win.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/coreinfrastructure/best-practices-badge/issues/1194#issuecomment-404682019,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC8MBnn5tiKmND4sEOmT_TzH7mdLGg1Mks5uF9x9gaJpZM4VOBsD
.

Thanks for the idea for using ChromeDriver! I was going to complain that Chrome is not open source software, though chromium is, and then we have some serious discussions to have. but it turns out this is from the chromium project. They could do with better documentation, but it looks like they are installing chromium, which therefore has no issue at all. This appears to be a selenium driver, so we would select selenium and then configure selenium to call this. Quite a deep tech stack to do something straight forward... but if it works, it's a good thing.
The trade-offs appear as follows:
Capybara-WebKit runs test slightly faster than Chrome driver. However, ChromeDriver is much easier to install on macOS, and more accurately reflects what happens to real users in their browsers. I can accept slightly longer test times for those reasons. In practice the longer time probably won't be noticeable, since many of our tests don't require JavaScript anyway.

authors: dankohn david-a-wheeler

repo: coreinfrastructure/best-practices-badge


text:
doc/security.md links to a document behind 403 Forbidden

doc/security.md has a link to A Sample Security Assurance Case Pattern by David A. Wheeler (2018), clicking on which I get 403 Forbidden. Please make this document reachable.

Can you try again? It worked for me just now.
That's an external site; they may have briefly gone down or had a temporary configuration error.

Still 403. Can you reach it even from an incognito/private tab?

I was able to do it from a private tab in Firefox

@KitsuneRal - try using a VPN or Tor. I suspect they're rejecting some IP ranges.
That's an external website for us, so we can't control their policies . I'm closing this issue since it seems to work (to the limits of what we can control).

authors: KitsuneRal TonyLHansen david-a-wheeler


text:
Thanks ! + testing the "src_only" baseline ...

Hello, recently I've been working with your PyTorch implementation of ADDA so first of all thanks for your code!
For now I am only interested in testing the network Ms (trained on the source domain) on the target domain (src_only baseline):
Surprisingly on your github page you announced ~84% accuracy of this src_only baseline which is around 9% over the reported accuracy (75.2%) in the original paper (https://arxiv.org/abs/1702.05464). How can you explain such a difference?
I have tried to limit the number of samples in source domain (MNIST) to 2000 (as in the original paper) and yet I observed a ~87%  accuracy (the last modifications I made from your master branch corresponds to that experiment : https://github.com/emmanuelrouxfr/pytorch-adda)
To be as close as possible from the paper setup, I have also tried to set the original batch size to 128 (adjusting the number of epochs to be 625 to fit the mentioned 10 000 learning iterations) and the original learning rates and parameters:
d_learning_rate = 2e-4
c_learning_rate = 2e-4
beta1 = 0.5
beta2 = 0.999
but I can't reproduce the results originally presented in the original paper (~75% accuracy of src_only tested on USPS). It is always much higher than it is supposed to be.
I hope you could help me identify a possible reason to this phenomenon, thanks !

Hi，I  use the code and get the results:
=== Evaluating classifier for encoded target domain ===

source only <<<
Avg Loss = 0.3980948992383977, Avg Accuracy = 96.290323%
domain adaption <<<
Avg Loss = 0.41198907047510147, Avg Accuracy = 97.258065%

By modify the config:
batch_size = 128
num_epochs = 1000
And it works.

Hi @JinmingZhao !
It works but the "source only" baseline (you got 96.290323 %) is much higher than in the original paper (around 75 %) which is the issue I raised.
Anyway, thanks you !
Bye bye

@emmanuelrouxfr
I also have the same concern - how come the results (even the baseline) here are better than what the ADDA's authors have reported in their main paper?

authors: JinmingZhao aasharma90 emmanuelrouxfr

repo: corenel/pytorch-adda


text:
Testing: Feature matrix

This project has been growing lots of features lately, which is awesome!
Many of these features are modal in nature (route53 integration, mutliple subnets, etc) and have subtle interactions with each other which we do not currently test beyond unit tests.
We need a conformance testing matrix which does e2e/conformance tests repeatedly with various combinations of configuration values.
Ref #500 for why is is becoming necessary.
\cc @cgag @aaronlevy

Given the time cost / complexity of running tests against a configuration matrix, I'd prefer to start off with:

Set a version for deprecating legacy features (this seems to be much of the current pain)
Create a blessed testing configuration which exercises as much of the functionality as you can in a single run.

authors: aaronlevy colhom

repo: coreos/coreos-kubernetes


text:
All tags on quay.io have vulnerabilities

Hello,
on the tag page, all tags have vulnerabilities. I guess we need a full rebuild of all the tags to avoid that.
https://quay.io/repository/coreos/dex?tab=tags

Hi @dolanor
All the vulnerabilities reported by Quay are zlib bugs, which dex doesn't compile against. None of these actually impact dex.
We should update our base image for good measure, but "All tags on quay.io have vulnerabilities" is going a bit far.

Fixed by https://github.com/coreos/dex/pull/994

authors: dolanor ericchiang

repo: coreos/dex


text:
mvcc: add benchmark for watch put and improve it

Remove the aggressive array preallocation. Improve benchmark result 100%
Before change
go test -bench=BenchmarkWatchableStorePut -run=xxx -benchmem -cpu=1,2,4
PASS
BenchmarkWatchableStorePut  	   50000	     28181 ns/op	   12157 B/op	      19 allocs/op
BenchmarkWatchableStorePut-2	  100000	     21586 ns/op	   12032 B/op	      17 allocs/op
BenchmarkWatchableStorePut-4	  100000	     19479 ns/op	   12028 B/op	      18 allocs/op
ok  	github.com/coreos/etcd/mvcc	9.143s

After change
go test -bench=BenchmarkWatchableStorePut -run=xxx -benchmem -cpu=1,2,4
PASS
BenchmarkWatchableStorePut  	  100000	     12463 ns/op	    2014 B/op	      19 allocs/op
BenchmarkWatchableStorePut-2	  200000	      9679 ns/op	    1836 B/op	      17 allocs/op
BenchmarkWatchableStorePut-4	  200000	      9222 ns/op	    1877 B/op	      18 allocs/op
ok  	github.com/coreos/etcd/mvcc	10.716s

@gyuho Probably you want to rerun the e2e benchmark to verify the change?

@xiang90 LGTM. Below are the bench results:
# original
go test -bench=BenchmarkWatchableStorePut -run=xxx -benchmem -cpu=1,2,4
PASS
BenchmarkWatchableStorePut  	  100000	     24558 ns/op	   11857 B/op	      16 allocs/op
BenchmarkWatchableStorePut-2	  100000	     21278 ns/op	   11855 B/op	      16 allocs/op
BenchmarkWatchableStorePut-4	  100000	     16363 ns/op	   11878 B/op	      16 allocs/op

# with patch
go test -bench=BenchmarkWatchableStorePut -run=xxx -benchmem -cpu=1,2,4
PASS
BenchmarkWatchableStorePut  	  200000	     10196 ns/op	    1713 B/op	      16 allocs/op
BenchmarkWatchableStorePut-2	  200000	      9471 ns/op	    1710 B/op	      16 allocs/op
BenchmarkWatchableStorePut-4	  200000	      9417 ns/op	    1704 B/op	      16 allocs/op

repo: coreos/etcd


text:
clientv3/integration: test client closes correctly when server is down

grpc likes to Sleep() leak on the shutdown path
fails without https://github.com/grpc/grpc-go/pull/680

great. LGTM. Thanks.

not sure why semaphore is passing, it's failing locally for me...

@heyitsanthony Yeah semaphore sometimes don't complain about it. I am getting errors in my local machine with this test:
--- PASS: TestKVStoppedServerClientClose (0.07s)
PASS
Too many goroutines running after all test(s).
1 instances of:
time.Sleep(...)
	/usr/local/go/src/runtime/time.go:59 +0xf9
google.golang.org/grpc.(*Conn).resetTransport(...)
	/home/gyuho/go/src/google.golang.org/grpc/clientconn.go:494 +0x7d3
google.golang.org/grpc.(*Conn).reconnect(...)
	/home/gyuho/go/src/google.golang.org/grpc/clientconn.go:529 +0xc4
google.golang.org/grpc.(*Conn).transportMonitor(...)
	/home/gyuho/go/src/google.golang.org/grpc/clientconn.go:554 +0x16b
created by google.golang.org/grpc.NewConn
	/home/gyuho/go/src/google.golang.org/grpc/clientconn.go:346 +0x49f
exit status 1

this test doesn't add much, closing

authors: gyuho heyitsanthony


text:
etcdctl/ctlv3: auth: wildcard terminated paths specify ranges

Still needs tests, but creating pull request to facilitate the discussion in #6359

What if other people ask for //abc? Or //abc/*/cef? Should we support these as well? I feel people would ask for globbing eventually, which we do not really want to support in etcd core.

What if other people ask for //abc? Or //abc/*/cef? Should we support these as well? I feel people would ask for globbing eventually, which we do not really want to support in etcd core.

I don't need them or find them compelling.
But maybe I don't understand what the situations they would be used to model.  Could you elaborate on the first one in particular -- what does having two slashes as the first two runes trying to do?
I think this simple PR is perfectly defensible. nats.io and many other pub/sub systems have used similar (filesystem) semantics.

@glycerine Sorry. Github messed up the format. I updated my previous reply.

My answer stays the same. : )
I don't find them compelling, nor I don't need them. It seems we agree.

My implementation is flawed in some way, as tests would have shown.
Where is not obvious... gets seem to work, but put doestn't. When I track it down, it is because the tocheck slice in the checkKeyPerm() function has length zero during the write attempt; here: https://github.com/coreos/etcd/blob/master/auth/range_perm_cache.go#L148
Hints appreciated.

Yes, I'm mightily confused. Still trying to debug why I have no writes going through.
I have a role, jason, that has write permissions.
$ etcdctl --user root:123 role get jason
Role jason
KV Read:
        /home/jason/*
KV Write:
        /home/jason/*

And yet: inside isRangeOpPermitted(), even if I force a call to getMergedPerms() every time, I still get back no write permissions (at https://github.com/coreos/etcd/blob/master/auth/range_perm_cache.go#L168; with the if !ok changed to an if true)
perms back: '&auth.unifiedRangePermissions{readPerms:[]*auth.rangePerm{(*auth.rangePerm)(0xc42041a0c0)}, writePerms:[]*auth.rangePerm(nil)}'

sigh, gets (reads) on a "directory" don't work right unless /home/xiang/* gets turned into a range.
So just how does one construct the range [0x0, 0xffffffff] ?

arg, had to track down of number of insidious bugs in the existing range and range-mergin code. those are fixed now, but I still need tests for the new functionality.

If somebody could help out with getting a test that does the following (in library/code rather than shell outs to etcdctl of couse) I would very much appreciate it. I'm out of time for a while to figure out how to write these tests, it would be nice get these fixes and additions in place, and I'm sure somebody is more familiar with the testing facilities already available than I am.
test plan:
- create a root user, pw 456, a root role, assign the root role to the root user
- create a regular user called joe, with pw 123, a role called 'regular'
- assign the regular role to the user joe
- give the regular role readonly permissions on /home/*
- create a role called joe, assign it to joe, give it readwrite on /home/joe/*  (joe ends up with 2 roles)
etcdctl auth enable
etcdctl --user root:456 put /home/haddy/hello
etcdctl --user joe:123 put /home/joe/bday 040181
etcdctl --user joe:123 put /home/joe/height "6-0"
- verify that joe can read /home/haddy/hello but not delete it or write a key alongside it. (using the regular role).
- verify that joe can read bday and height from home/joe/ using 'get /home/joe/*'
- verify that joe can delete 2 keys with the library equivalent of : 'etcdctl --user joe:123 del '/home/joe/*'

It looks like this breaks for any key with a * suffix. There's no way this can go in the way it's designed since it restricts the values keys may take even though etcd3 should be a clean binary keyspace.

@heyitsanthony what would be acceptable for handing the presence of special characters like *? Do you have an approach in mind? I'm open to ideas.
We're used to bash/filesystem interfaces that treat certain characters specially, spaces and * at the shell prompt for example. To embed them literally in a filename from bash, one would have to escape them with a backslash.
Does escaping a star * with a backslash, as in \*, seem reasonable?

with the latest:

Added backslash escaping to allow \* in the presence of wildcard *.
Addressed the other comments by centralizing wildcard handling into a separate package.
Addressed the code duplication by defining an interface, BegEndRange, to unify treatment of ranges.

Added a test file.
@xiang90, @heyitsanthony -- I think this is in good shape. Please take a look.

@glycerine anything that imposes special structure on the keys can't be part of the base KV API. Expecting people to escape * needlessly complicates the key semantics and absolutely breaks the contract that etcd3 will accept arbitrary binary keys without modification.
This really should be done with a proxy.

conclusion was that this won't be the way to go. Closing this, and opening a separate pr with the bug fixes to range handling.

authors: glycerine heyitsanthony xiang90


text:
etcdserver: move 'EtcdServer.send' to raft.go

Clear 'TODO'
/cc @xiang90 @heyitsanthony @fanminshi

defer to @heyitsanthony

lgtm

authors: gyuho heyitsanthony xiang90


text:
Building flannel- consultation question

Can I change Flannel Alpine base image to Debian 9 (iptables compatibility is of concern)
The Dockerfile builds iptables into the image. The dist/iptables-wrapper-installer.sh script says it "installs a wrapper iptables script in a container that will figure out whether iptables-legacy or iptables-nft is in use on the host and then replaces itself with the correct underlying iptables version."
Is this to say that k8s iptables operations are done by the iptables package inside of the container, and not the iptables package on the host? I want to replace flannel's Alpine base image with Debian 9, and there is no iptables-nft package on Debian 9. However, I have iptables-nft on the host. The Dockerfile will build, but I need to pass the --no-sanity-check- argument to the script. Is it safe to change the base image when using Flannel for k8s?

The Flannel-required iptables manipulation for Kubernetes is done by utilizing the userspace binaries from within the Flannel image. The iptables-wrapper-installer.sh script installs a helper script that is capable of manipulating the userspace of the Flannel container, to swap the necessary iptables binary into place depending on what the script detects. There should be no major issue with using Debian 9 as a base image for Flannel, although I have not explicitly tested this myself and can not give any guarantees.
You have two options for using Debian 9 as a base image --

Comment out the iptables-wrapper-installer.sh sections of the Dockerfile/discard them, and simply use the iptables package that is installed by Debian 9, thus using the backend of iptables that Debian 9 installs. Upon a quick test, it looks like Debian Stretch (9) ships with iptables 1.6.0, which is using the legacy backend. This should be OK for systems that are also using iptables legacy on the backend, i.e. this will not work well on CentOS 8/RHEL 8/Debian Buster (10), but will work on Ubuntu, Debian Stretch, CentOS 7/RHEL 7, etc. as long as the host level binaries are programming in legacy (ip_tables) rules.
Figure out how to install both iptables into the Debian 9 image. This is a bit more complicated, but if you do this, you'll have compatibility with both legacy and nftables systems.

It's important to keep your host network namespace operating with the same packet filter implementation, i.e. all ip_tables/legacy or all nftables
Does this help answer your question?

repo: coreos/flannel


text:
fix incorrect window in containerQuery

Fixing bug introduced in #254 (more in @tbarrella comment: https://github.com/coreos/kube-prometheus/pull/254#issuecomment-538136792 )
Thanks, @tbarrella and @gitfool for noticing this.
/cc @s-urbaniak

needs re-generate, otherwise lgtm

/lgtm

authors: brancz paulfantom s-urbaniak

repo: coreos/kube-prometheus


text:
Grafana dashboards update

Update after mixins relative links merge:
https://github.com/kubernetes-monitoring/kubernetes-mixin/commit/a19b4c0a6ec563aa002c64e764ef652b42316472

Thanks!

authors: brancz kpucynski


text:
jsonnet/kube-prometheus: bump prometheus-operator

Side note: this pins node-mixin due to an upstream bug, cc @paulfantom (who is already working on it).
/cc @LiliC @paulfantom

/lgtm

authors: paulfantom s-urbaniak


text:
kube-prometheus with Prometheus 2.7.0 or 2.7.1 records prometheus_rule_group_iterations_missed_total = 1

What did you do?
Installed kube-prometheus from prometheus-operator 0.29.0 on an empty docker desktop kubernetes cluster with Prometheus version overridden to 2.7.1. Looking at Prometheus stats for prometheus_rule_group_iterations_missed_total{job=~"prometheus-k8s"}, there seems to be a missed iteration which didn't show up in 2.5.0 or 2.6.1.
What did you expect to see?
0 total missed rule group iterations.
What did you see instead? Under which circumstances?
1 total missed rule group iterations at all times.
Environment
Docker Desktop Version 2.0.0.3 (31259) on a Mac

Prometheus Operator version:

0.29.0

Kubernetes version information:

Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.2", GitCommit:"cff46ab41ff0bb44d8584413b598ad8360ec1def", GitTreeState:"clean", BuildDate:"2019-01-13T23:15:13Z", GoVersion:"go1.11.4", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.11", GitCommit:"637c7e288581ee40ab4ca210618a89a555b6e7e9", GitTreeState:"clean", BuildDate:"2018-11-26T14:25:46Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

Kubernetes cluster kind:

Docker desktop though same issue arises in Kops created cluster on AWS.

Manifests:

N/A

Prometheus Operator Logs:

N/A

As long as this is not increasing at a constant rate, there is nothing to worry about, this means that a rule group once took longer than the evaluation interval.

Thank you for the response.
I agree that as long as it is not incrementing there is no significant underlying problem, I just noted the change in behaviour as it now is consistently one long rule evaluation per start where before there were none and thought that this would not be expected (and for our installation it highlighted that we were monitoring the sum of this figure over time where it is already a total).

This seems resolved.

authors: brancz fredmtyro metalmatze

repo: coreos/prometheus-operator


text:
Support Volumes on kind: Prometheus

It would be useful if we had the ability to express Volumes in the Prometheus Operator's CRD kind: Prometheus.  These volumes would be useful for passing data between initContainer instances that are part of a Prometheus instance pod.  A particular use case for this is when trying to use InitContainers to log into and fetch secrets from Vault, then insert them into template files (the 'vault-auth/consul-template' process).  Secrets could include things such as TLS certs, as well as login creds for scrap targets, etc.
InitContainers themselves are not currently supported in the operator's Prometheus object, either.  However, there is an existing issue that seeks to address that:
https://github.com/coreos/prometheus-operator/issues/1888

I'd like to focus on the end goal which is fetching secrets from vault to use by Thanos. initContainers seem like a poor mechanism for this, volumes on the other hand with something like this seems like a reasonable approach. What do you think of that?

@brancz -- To be clear, the initContainers in question here just run the Vault login and consul-template processes, in a defined order.
However, the fact that they can be used to prevent the rest of the Pod's containers from starting if they don't succeed is a desirable trait.  Such is the case where the initContainers are pulling secrets that are critical to the operation of the 'main' containers; this fast-fail prevents perhaps less obvious errors further down the line.  TBH, I thought there was a symmetry between the way the PromSpec allows for arbitrary Containers definitions, and this request for something similar but for initiContainers.  Aren't they kind of similar?
Also, when you're talking about 'something like' the secrets-store-csi-driver project -- did you mean that we should try using that, or were you proposing that having a solution (baked into the Prometheus Operator) that leverages volumes for secret passing would be a good model?

I was suggesting to use that csi volume provider to provide the secrets to the prometheus container as opposed to init containers (and us adding support for mounting volumes enabling to use that), as I fear they will cause inconsistent setups causing unreasonably higher support burden on us.

@brancz -- If any initContainer specs in the PrometheusSpec were simply propagated to the final StatefulSet configuration (the way that the PrometheusSpec.Containers are, what additional support burden would that place on the project?  If users specified invalid Volume information, that would be their error to deal with, no?

I think it would be ok to add specification of init containers, however, I want us to explicitly call out that these are only meant to be used for secret fetching use cases, all other use cases are unsupported and will not be triaged (eg. config modification, permission fiddling, etc.).

This work has been done, (see reference above) and is almost mergable.  Resolve some conflicts and update API docs to reflect intended use of initContainers

Two things:

The work to add initContainers the PrometheusSpec has already been done, and is almost ready to merge.  All that remains is resolving conflicts and updating the API doc to suggest that users only use initContainers to fetch secrets, and that other uses are not supported.

If we consider the initContainers issue sorted, thenVolumes would be a similar extension of the Prometheus CRD.  Does anyone have any objection to that in principle/theory?  I could do the work on that, modeled after the way @tongpu added initContainers.

authors: brancz rchapple


text:
k8sControllerManagerDown/k8sSchedulerDown alerts happening daily

Hi Team
I'm novice to here and i have set up the prometheus-operator in Kubernetes Cluster. But daily I'm seeing the below alert. I'm not sure what went wrong and where to trace the issue. Kindly please help me.

1 alert for alertname=K8SSchedulerDown

1 alert for alertname=K8SControllerManagerDown

Kubernetes version information:
Client Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.0", GitCommit:"6e937839ac04a38cac63e6a7a306c5d035fe7b0a", GitTreeState:"clean", BuildDate:"2017-09-28T22:57:57Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.0", GitCommit:"6e937839ac04a38cac63e6a7a306c5d035fe7b0a", GitTreeState:"clean", BuildDate:"2017-09-28T22:46:41Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}

Kubernetes cluster kind:
kops

@sujithnss @brancz  I also met the same issue, but in my case i have used binary packages to install the cluster , can you give me a piece of advice fix the issue?

In that case you either need to make use of the additionalScrapeConfigs functionality to use another service discovery mechanism other than Prometheus, or maintain a Service and respective Endpoints object manually.

@brancz Thank you for your help, for example. I have create a service object as below:
apiVersion: v1
kind: Service
metadata:
  namespace: kube-system
  name: kube-controller-manager-prometheus-discovery
  labels:
    k8s-app: kube-controller-manager
spec:
  selector:
    k8s-app: kube-controller-manager
  type: ClusterIP
  ports:
  - name: http-metrics
    port: 10252
    targetPort: 10252
    protocol: TCP

but I don't understand how to create Endpoints object manually, do I have to do anything else?

You want to skip the selector, as that will allow you to manually provision the underlying Endpoints object. In the end that looks something like:
apiVersion: v1
kind: Service
metadata:
  namespace: kube-system
  name: kube-controller-manager-prometheus-discovery
  labels:
    k8s-app: kube-controller-manager
spec:
  type: ClusterIP
  ports:
  - name: http-metrics
    port: 10252
    targetPort: 10252
    protocol: TCP
---
apiVersion: v1
kind: Endpoints
metadata:
  namespace: kube-system
  name: kube-controller-manager-prometheus-discovery
  labels:
    k8s-app: kube-controller-managersubsets:
- addresses:
  - ip: 127.0.0.1
  ports:
  - name: http-metrics
    port: 10252
    protocol: TCP

Just replacing or adding the IPs to the addresses array.

@brancz    According to your guidance, the issue has been solved，thank you again.

authors: brancz ne1000 sujithnss


text:
*: bump docker2aci

We'll need to bump docker2aci for 0.6.0 after https://github.com/appc/docker2aci/pull/68 lands

Should be addressed by #1037

covered by #1052

authors: iaguis jonboulle

repo: coreos/rkt


text:
docs: rename gsg-ubuntu-vivid -> gsg-ubuntu

No need for this to be named so specifically; this way we don't need to
rename it every time we change the ubuntu release.
/cc @robszumski

LGTM

authors: jonboulle robszumski


text:
Terraform unable to detect ct provider

I am having an issue where the terraform provider isn't detected.
I have a providers.tf file defined like so:
provider "ct" {
  version = "0.3.1"
}

provider "local" {
  version = "~> 1.0"
  alias = "default"
}

provider "null" {
  version = "~> 1.0"
  alias = "default"
}

provider "template" {
  version = "~> 1.0"
  alias = "default"
}

provider "tls" {
  version = "~> 1.0"
  alias = "default"
}

After manually installing ct v0.3.1 and specifying the directory for all plugins of the project, I get the following:
$ terraform init -plugin-dir=.terraform/plugins/linux_amd64/

Initializing provider plugins...

Missing required providers.

The following provider constraints are not met by the currently-installed
provider plugins:

* ct (0.3.1)

Terraform can automatically download and install plugins to meet the given
constraints, but this step was skipped due to the use of -get-plugins=false
and/or -plugin-dir on the command line.

If automatic installation is not possible or desirable in your environment,
you may manually install plugins by downloading a suitable distribution package
and placing the plugin's executable file in one of the directories given in
by -plugin-dir on the command line, or in the following directory if custom
plugin directories are not set:
    terraform.d/plugins/linux_amd64

The structure of the plugin folder is as follows:
$ tree .terraform
.terraform/
├── plugin_path
└── plugins
    └── linux_amd64
        ├── terraform-provider-ct_v0.3.1_x4
        ├── terraform-provider-local_v1.2.0_x4
        ├── terraform-provider-null_v1.0.0_x4
        ├── terraform-provider-template_v1.0.0_x4
        └── terraform-provider-tls_v1.2.0_x4

2 directories, 6 files

I notice on the terraform documention for 3rd party plugins that the naming convention doesn't include the _x4 part of the current filenames, however removing that part of the name still yields the same result.
I am currently using Terraform v0.11.13.  Am I missing something?

I doubt Terraform will infer that by .terraform/plugins/linux_amd64/ you mean within your home directory. Try a full path. Also, you probably don't need to specify, the default should be fine.

You also don't neccessarily need the os/arch specific directories either. And drop the _x4, not sure why that's there.
Here's a related guide with examples I've written.

That path was actually just a relative path for a folder in the current directory.
I originally tried it without the -plugin-dir= flag, but it kept giving the the "Provider "ct" not available for installation." error, despite having the provider in my ~/.terraform.d/plugins folder.
By explicitly using the -plugin-dir, I figured I could ensure all the providers were in the folder I specified explicitly.

Even with an absolute path, it does did not detect this provider for some reason. Renaming the provider with or without the _x4 suffix did not fix the issue.
What's weird is that I tried this same setup on a different machine and it worked using the default methods (vanilla terraform init and placing the providers within the $HOME/.terraform.d/plugins directory).  It must be a weird configuration I have on this machine or something.
I have a slight suspicion that this is more of an issue with terraform, rather than a terraform-provider-ct issue, so I'll probably submit an issue with them to hopefully gain some more insight on the situation.
Thanks for your help!

repo: coreos/terraform-provider-ct


text:
nvm use latest

Wondering if we can get nvm use to support the same token as nvm install: latest.
Trying to set up a chocolatey install to do nvm install latest && nvm use latest without maintaining the specific node version. However, receiving:
node vlatest.0.0 (64-bit) is not installed.

I'd be willing to make a PR if this is acceptable.

Nevermind, I was using an old version! This works fine.

repo: coreybutler/nvm-windows


text:
Update build-and-test.yml | Run tests in parallel

We want to edit the build-and-test workflow, which is triggered on pull requests, so that it first works on the required build job. Once that required job succeeded, the optional jobs (one for each test using matrix) will start by making use of the build done in the previous job to save time.
Not only would this be an improvement in total time needed to complete all tests, as they would be performed in parallel instead of back to back, but it would also give users a better understanding on what specific test went wrong on the first look.

In my current draft I linked above, every test builds the page again. This is a problem that is also observable in the build-and-test that is currently in use on master here, as we also couldn't find a proper solution for the problem described above.
Although GitHub provides these resources for free on open source repositories, we still want to use them responsibly. Going ahead with the draft I currently have wouldn't meet these standards for us, but we're still looking out for a solution for this.

@MikeMcC399 brought https://github.com/actions/upload-artifact & https://github.com/actions/download-artifact to my attention, which I will test in this soon. Depending on the time needed to upload / download, this could be a sufficient solution. The documentation for this can be found here https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts
In addition, I've remove the long check_links test for now.

@larswmh

PR https://github.com/corona-warn-app/cwa-website/pull/3394 solved the browser crash issue in PR https://github.com/corona-warn-app/cwa-website/pull/3384 however I suggest for you to make progress on this PR and then see if it makes sense to extend it to check_links later.

Uploading and downloading an artifact seems to be a good solution once good exclusions are figured out, as it would take very long without (see manually cancelled check). One test fails because of a path I excluded where I thought the content wouldn't be used in tests (see check_videos)
Some test still seem to fail without giving much information about the cause, for example in faq_link_attr or check_anchor_links

@larswmh
I see you made some good progress! Well done!
You managed to workaround the very large size of the web by excluding the big files.

One test fails because of a path I excluded where I thought the content wouldn't be used in tests (see check_videos)

I suggest to move any science video files to the specifc video directory /src/assets/video. All the blog videos area hosted there, so the science videos should go there as well. That would allow the test to run.

Some test still seem to fail without giving much information about the cause, for example in faq_link_attr or check_anchor_links

Those jobs were cancelled because the video job failed. To stop that happening, you need to add if: always() I believe.

@MikeMcC399

I suggest to move any science video files to the specifc video directory /src/assets/video. All the blog videos area hosted there, so the science videos should go there as well. That would allow the test to run.

I've opened up a PR for your suggestion in #3400

Sorry, the second part was bad advice:
https://docs.github.com/en/actions/examples/using-concurrency-expressions-and-a-test-matrix
"Setting fail-fast to false prevents GitHub from cancelling all in-progress jobs if any matrix job fails."

Thanks for the advice @MikeMcC399. As expected, all tests are passing. This PR is now ready for review.

repo: corona-warn-app/cwa-website


text:
Support for Google Pay Covid vaccination cards

Feature description
As previously requested in Digitaler-Impfnachweis/certification-apis#37, corona-warn-app/cwa-app-ios#2965 and corona-warn-app/cwa-app-android#3486. The original issue on this has been closed due to privacy concerns, that were unfortunately discussed internally, so I can't know if all of them still exists. However since the original issue on this has been closed, Google has released a new pass type in the passes API specifically, which might solves some concerns? In other open discussions about this, people have been concerned about being able to see the phones Covid certificates even if it's locked, which won't be an issue, since this certificates require a display lock to be set and the phone to be unlocked.
Documentation links

https://developers.googleblog.com/2021/06/google-updates-passes-api-to-save-covid-testing-and-vaccination-information-on-Android-devices.html
https://developers.google.com/pay/passes/guides/pass-verticals/use-cases?vertical=covid-cards
https://payments.developers.google.com/terms/aup#covid-cards
https://developers.google.com/android/reference/com/google/android/gms/pay/package-summary

Problem and motivation
It can come in quite handy to have all of your cards and passes in one place, also having an official way to do this can make use of the new Pass type which is only available to authorities which can actually create vaccination certificates
Is this something you're interested in working on
Maybe. I am not sure how much I could do as the documentation on Covid certificate is locked behind a registration form only authorities have access to, I would be able to work on the Integration in the App itself since this Documentation is public

@ Community Managers, please move to the Android repository, as this does not affect iOS.

@ Community Managers, please move to the Android repository, as this does not affect iOS.

This repo is iOS specific?

@DRSchlaubi
This repo contains issues that affect both OS, iOS & Android.
E.g., the request to be able to add vaccination certificates into the Apple Wallet, has been transferred to the iOS repository from the wishlist repository, as it does not affect Android.
Same applies here, this request does not affect iOS, so it should be transferred to the Android repository.

@DRSchlaubi Please repost your comment in https://github.com/corona-warn-app/cwa-app-android/issues/3486 and we'll see if we can reopen the related issue.

Corona-Warn-App Open Source Team

Closed as discussion has been moved back to corona-warn-app/cwa-app-android#3486

Duplicate of https://github.com/corona-warn-app/cwa-app-android/issues/3486

authors: DRSchlaubi Ein-Tim heinezen

repo: corona-warn-app/cwa-wishlist


text:
Extend reporter chart configurator so that its more similar to compose

Added some configurations to reporter charts so they can be configured like compose.
Note some configurations are still missing, we should combine the two into the same configurator at a later stage.
Added:

Rotate labels for x and y axis
Always show tooltips checkbox
Legend configuration
Offset configuration

Everything looks good just this needs to be aligned:

Added:

What: Most missing configuration options that were in compose charts but not in reporter charts, e.g. Legend, Tooltip, Offset, label rotation for X and Y axis.
Why: In an effort to provide the same set of features on both chart configurators

authors: Bojan-Svirkov Fajfa

repo: cortezaproject/corteza


text:
Unable to set SVG hex color, despite svg property set to true

Using the following config the marker always shows up red, no matter which hex value I use for markerColor.
 let iconOptions = L.ExtraMarkers.icon({
        icon:  'fa-bus',
        iconColor: 'white',

        svg: true,
        markerColor:'#ffffff',

        shape: 'circle',
        prefix: 'fa' // Font Awesome prefix
      });

I cannot reproduce, please take a look at this codesandbox

authors: PortableDiag coryasilva


text:
Does this support implied flags, like tar?

'-' to ensure next argument must be a flag

That seems to imply that implied flags will work here the same as they do with tar:
tar -xvf test.tar.gz
tar xvf test.tar.gz

Is that true?

no, you can just ignore this rule, and this library doesn't supports this syntax tar xvf test.tar.gz

Thanks.

repo: cosiner/flag


text:
Garrtbrayn_Inno

Документ_1204384(2).pdf
https://github.com/cosmos/chain-registry/blame/c99fe60b950b75aa15f6cdeec33037573bf8a485/cosmoshub/chain.json#L1
### Tasks
- [ ] https://github.com/cosmos/chain-registry/pull/3198
- [ ] https://github.com/cosmos/chain-registry/pull/3197

### Tasks

Uploading Документ_1212312.pdf…

Anything else required here?

👍👍👍

repo: cosmos/chain-registry


text:
refactor: rename genesis type RegisteredRelayer to RegisteredCounterpartyPayee

Description
Renaming GenesisState field to RegisteredCounterpartyPayee to align
needs: #1513
closes: #XXXX

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against correct branch (see CONTRIBUTING.md)
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Code follows the module structure standards.
[ ] Wrote unit and integration tests
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
[ ] Added relevant godoc comments.
[ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
[ ] Re-reviewed Files changed in the Github PR explorer
[ ] Review Codecov Report in the comment section below once CI passes

Codecov Report

Merging #1514 (49f585b) into main (5e5e2cd) will decrease coverage by 0.02%.
The diff coverage is 87.80%.

@@            Coverage Diff             @@
##             main    #1514      +/-   ##
==========================================
- Coverage   80.27%   80.24%   -0.03%
==========================================
  Files         166      166
  Lines       12252    12257       +5
==========================================
+ Hits         9835     9836       +1
- Misses       1954     1957       +3
- Partials      463      464       +1

Impacted Files
Coverage Δ

modules/apps/29-fee/types/codec.go
44.44% <50.00%> (+0.69%)
:arrow_up:

modules/apps/29-fee/types/genesis.go
78.12% <60.00%> (-3.85%)
:arrow_down:

modules/apps/29-fee/ibc_middleware.go
93.97% <100.00%> (ø)

modules/apps/29-fee/keeper/genesis.go
87.50% <100.00%> (ø)

modules/apps/29-fee/keeper/grpc_query.go
75.54% <100.00%> (ø)

modules/apps/29-fee/keeper/keeper.go
92.48% <100.00%> (ø)

modules/apps/29-fee/keeper/msg_server.go
96.00% <100.00%> (ø)

modules/apps/29-fee/keeper/relay.go
88.23% <100.00%> (ø)

modules/apps/29-fee/types/msgs.go
90.75% <100.00%> (ø)

authors: codecov-commenter damiannolan

repo: cosmos/ibc-go


text:
chore: adding sdk.Msg impl for ics27 MsgRegisterAccount

Description

Implement sdk.Msg interface

Adding ValidateBasic
Adding GetSigners
Adding tests

closes: #2053

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against correct branch (see CONTRIBUTING.md)
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Code follows the module structure standards.
[ ] Wrote unit and integration tests
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
[ ] Added relevant godoc comments.
[ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
[ ] Re-reviewed Files changed in the Github PR explorer
[ ] Review Codecov Report in the comment section below once CI passes

Do we have a changelog entry already for adding this message type

Good point! I think I'll need to add one retrospectively for #2068

Codecov Report

Merging #2081 (7160c2f) into main (5765fe7) will increase coverage by 0.08%.
The diff coverage is 84.61%.

@@            Coverage Diff             @@
##             main    #2081      +/-   ##
==========================================
+ Coverage   79.94%   80.03%   +0.08%
==========================================
  Files         170      170
  Lines       11801    11813      +12
==========================================
+ Hits         9434     9454      +20
+ Misses       1950     1941       -9
- Partials      417      418       +1

Impacted Files
Coverage Δ

...ps/27-interchain-accounts/controller/types/msgs.go
90.90% <84.61%> (+90.90%)
:arrow_up:

.../apps/27-interchain-accounts/host/keeper/keeper.go
83.33% <0.00%> (ø)

...27-interchain-accounts/controller/keeper/keeper.go
94.73% <0.00%> (ø)


text:
feat: adding msg server implementation for ChannelUpgradeAck

Description

Reorder code in upgrade.go
Add msg server implementation with tests

closes: #3742

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against correct branch (see CONTRIBUTING.md).
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Code follows the module structure standards and Go style guide.
[ ] Wrote unit and integration tests.
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/).
[ ] Added relevant godoc comments.
[ ] Provide a commit message to be used for the changelog entry in the PR description for review.
[ ] Re-reviewed Files changed in the Github PR explorer.
[ ] Review Codecov Report in the comment section below once CI passes.

I've omitted the final part of the handler from the spec as I think we can handle it separately since its related to the final opening step of the channel upgrade and requires the flush status checking.
Specificially this part:
// if both sides have already flushed then open the upgrade handshake immediately
if currentChannel.state == FLUSHCOMPLETE && counterpartyFlushStatus == FLUSHCOMPLETE {
    openUpgradelHandshake(portIdentifier, channelIdentifier)
    module.onChanUpgradeOpen(portIdentifier, channelIdentifier)
}

I'm happy to add it in a follow up or if folks think this PR is the home for it then I can do that too.

I like the idea of adding flush to flush complete in a followup

authors: colin-axner damiannolan


text:
check_misbehaviour_and_update_state(): commit verification might use the wrong chainId

In ibc-go, the chainID's revision_number is substituted with the header's revision_number before validator set commit verification (here). Our current implementation does not do that (here).

Curiously, we make the substitution before ensuring that chain id match here. I am not sure if this is equivalent (i.e. if our chainID does not match both headers' chain IDs, then the commit verification would fail)

repo: cosmos/ibc-rs


text:
Integrate the 08-wasm ethereum light client from ibc-go

As per https://github.com/cosmos/ibc-go/issues/7581, the Etheruem light client is going to be moved to the abc-go repo. When that has been done, this repository should be updated to use the light client from there.
Definition of done:

Replace the wasm binary we currently store in the repo with some other method that gets it from ibc-go.
Use the new light client in our pos mode e2e tests (including CI)

Superseded by https://github.com/cosmos/solidity-ibc-eureka/issues/143

repo: cosmos/solidity-ibc-eureka


text:
Pick full node

As a follow up for https://github.com/cosmos/voyager/issues/1291 we might allow the user to pick a node they trust.
Scope:

component: ability to enter an IP of a trusted node
logic: ability to connect to a full node based on an IP set in the view

a better ux might be to let the user pick from a list of full nodes including monikers and IPs.
but i'm not sure we need to do any of this before launch.

agreed

this will probably often be used by people how know the IP of their trusted node

even if you know the IP of the node, having a list would be nice / could help with verification etc...

Maybe make it a config setting.

Maybe make it a config setting.

what do you mean?

Make it configurable in the config.toml.

isn't it already with COSMOS_NODE? i thought the point of this was to let users (not developers) pick a node...?

Make it configurable in the config.toml.

This was an outcome of a discussion in the team meeting. We want to be able to define the set of trusted full nodes when shipping Voyager. A regular user will not use COSMOS_NODE as you pointed out. As we discussed that validators may ship a branded Voyager, validators may want to put in their preferred full node in the configuration easily.

authors: faboweb jbibla

repo: cosmos/voyager


text:
Secure Cell passphrase API: PyThemis

Add support of Secure Cell passphrase API to PyThemis. The API is described in RFC 3.3 (with corrections).
User notes
Passphrase-based interface of Secure Cell allows you to use short and memorable passphrases to secure your data. While symmetric keys are more secure, they are also longer and much harder for humans to remember.
Here is how you can use passphrases with Secure Cell:
from pythemis.scell import SCellSeal

cell = SCellSeal(passphrase='my little password: secrets are magic')

plaintext = b'precious message'

encrypted = cell.encrypt(plaintext)
decrypted = cell.decrypt(encrypted)

assert decrypted == message

Passphrase API accepts passphrases as relatively short strings, suitable for human memory. Master key API uses randomly generated, long binary keys, which are more suitable for machines to remember. However, they are also more efficient and generally more secure due to considerable length. You should prefer to use keys over passphrases if there are no humans involved. The interface is almost the same:
from pythemis.skeygen import GenerateSymmetricKey

# Get a new key if you don't have one already:
master_key = GenerateSymmetricKey()
# Or use an existing value that you store somewhere:
master_key = base64.b64decode(b'b0gyNlM4LTFKRDI5anFIRGJ4SmQyLGE7MXN5YWUzR2U=')

cell = SCellSeal(key=master_key)

plaintext = b'precious message'

encrypted = cell.encrypt(plaintext)
decrypted = cell.decrypt(encrypted)

assert decrypted == message

API compatibility
Normally you should use SCellSeal constructor for Secure Cell in Seal mode:
cell = SCellSeal(key=master_key)

cell = SCellSeal(passphrase=user_passphrase)

However, you can also import the SCellSealPassphrase class and construct it directly:
cell = SCellSealPassphrase(user_passphrase)

Previously, Secure Cell could be initialized with master key as a simple positional argument:
cell = SCellSeal(master_key)

This API is still available and supported. However, it is a good idea to explicitly say key= or passphrase= when using SCellSeal unless it is obvious from context.
Only SCellSeal supports passphrase argument and passphrase encryption. SCellTokenProtect and SCellContextImprint work only with key.
Unicode considerations
Master keys are always binary data (bytes). Passphrases may be provided either as Unicode strings (str) or as encoded bytes. If you provide a Unicode passphrase it will be encoded in UTF-8 for compatibility with other Themis platforms. If you need a different encoding, please use encode() method explicitly.
In Python 2 master keys are expected as str values and passphrases may be provided either as unicode (will be encoded in UTF-8) or str (used as is). Take care with string encodings.
Technical notes
__special__.__python__.__magic__.__with__.__new__ allows us to maintain syntax compatibility and introduce passphrase= as an extension. Initially a different syntax was planned:
SCellSeal.with_passphrase('a secret')

SCellSeal.with_key(binary_master_key)

It had a noble idea of maintaining similarity with other languages which do not have named arguments. However, after updating tests and examples this syntax came off as unnatural and non-Pythonic. The Zen of Python says:

There should be one — and preferably only one — obvious way to do it.

So now we have exactly one way to construct a Secure Cell in each mode: via SCellMode constructor. (Well, you can also import SCellSealPassphrase if you like that more.)
Note that another language with named arguments (Swift) is also going to get a similar API, so this is sort of a prior example.
Checklist

[X] Change is covered by automated tests
[X] The coding guidelines are followed
[X] Public API has proper documentation
[X] Example projects and code samples are up-to-date
[X] Changelog is updated

I’ve merged PHP PR which enables integration testing between platforms. Now integration tests between Python and PHP are broken 🤔 Okay, tests, just with that you have paid off all effort that has been put into you. However, this also raises some questions:

Where is the bug? Since both wrappers seem to use correct API.
How much I should be afraid, given that C++, Android, Objective-C/Swift, and Themis Core itself do not have integration tests with the rest of the wrappers?

repo: cossacklabs/themis


text:
[feature] additional recipe metadata

This addresses #4
You can specify recipe metadata keys in following TOML header
[tool.hatch.build.targets.conda.recipe]
...

Recipe metadata is defined in TOML syntax. The metadata is merged using deepmerge with the following strategies
recipe_merger = Merger(
    type_strategies=[
        (dict, ["merge"]),
        (list, ["append"])
    ],
    fallback_strategies=["override"],
    type_conflict_strategies=["override"]
)

Most importantly, this will append list values if the key already exists. For example you can use nested key TOML
syntax:
[tool.hatch.build.targets.conda.recipe]
requirements.run = ["anaconda-anon-usage"]
test.imports = ["my_package"]

will append the package name anaconda-anon-usage to the autogenerated run requirements and inject the test
section into the recipe before it is built.

I'm going to leave this as a draft until #2 is merged

repo: costrouc/hatch-conda-build


text:
🛑 Mainnet [TezTools] (eu01-node.teztools.net) is down

In 7e6344c, Mainnet [TezTools] (eu01-node.teztools.net) (https://eu01-node.teztools.net/chains/main/blocks/head/header) was down:

HTTP code: 502
Response time: 377 ms

Resolved: Mainnet [TezTools] (eu01-node.teztools.net) is back up in 7443bd6.

repo: cotezos/teznodes


text:
🛑 Mainnet Smartpy is down

In 09c3335, Mainnet Smartpy (https://mainnet.smartpy.io/chains/main/blocks/head/header) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Mainnet Smartpy is back up in 73bb3a7.


text:
Missing AndroidContext and BasicAuthenticator in latest builds

Hi,
trying to test latest build:
compile 'com.couchbase.lite:couchbase-lite-android:0.0.0-766'
compile 'com.couchbase.lite:couchbase-lite-android-forestdb:0.0.0-766'

but I get error about missing:
import com.couchbase.lite.android.AndroidContext;
import com.couchbase.lite.auth.BasicAuthenticator;

It's from: 0.0.0-750. Build with 0.0.0-748 is ok, but newer failed.

I look into source codes, and see replace BasicAuthenticator with PasswordAuthorizer, so I'm abble to resolve PasswordAuthorizer.
But still have a problem with: AndroidContext

After 3rd resync gradle, now resolve resources ok :/. Have no idea where was a problem...

Hi @mtrakal,
Sorry for changing class name without notifying community. I have tried to make consistency with CBL iOS.

Hi @mtrakal,
Both PasswordAuthorizer and BasicAuthenticator are internal class. Please use folllowing method to create Authenticator for basic authentication.
Authenticator basicAuth = AuthenticatorFactory.createBasicAuthenticator("username", "password");

We know our API is messy.  We could not isolate well between Couchbase public API and Java public access level modifier. We will fix this with v2.0 release.

authors: hideki mtrakal

repo: couchbase/couchbase-lite-android


text:
chore(react): lock other react deps

Proposed changes
Other dependencies are marked as a major update because they drop support for React 17. So we locked 'em up.

Fun fact: #742, my OG PR has been rejected... by the god darn bot.

repo: coveo/cli


text:
feat(quantic): Case Classification Component

Case Classification Component
quanticCaseClassification is a section for a user to classify his case aided by suggestions provided by Coveo Case Assist. There is also a dropdown available to see all available values for a given category.
Demo:
https://user-images.githubusercontent.com/86681870/148321784-933edea1-b4be-4475-8322-28d39d50d461.mov
🚨 maxChoices property is used to determine the number of suggestions we can show. A choice can be a suggestion, an inline option or the select dropdown. This same property plays a role in whether we show the select dropdown or not. This role is explained bellow:
- If maxChoices >= total number of options :
  1.  We don't show the select dropdown.
  2. Suggestions will be shown first using the `slds-visual-picker` components.
  3. Other options will follow and will be shown also using  `slds-visual-picker` components.(aka inline options)

Example:  Max choices is set to 5 and the total number of options is 5

- If  maxChoices <  total number of options :
  1.  We do show the select dropdown containing all the options.
  2. Only suggestions will be shown using the `slds-visual-picker` components.

Example: Max choices is set to 4 and the total number of options is 5, and after fetching suggestions we got 2 suggestions

🚨 When no suggestions are provided by our ML models, the component will be displayed as a simple select dropdown:

I didn't review all the changes, mostly did a quick check on the component itself. The Cypress tests are not running on my side though. I guess it is because this task is not yet completed (https://coveord.atlassian.net/browse/SFINT-4327).

Exactly that's why, I'm currently working on that Jira, so the tests will be good to run soon 👌

I didn't review all the changes, mostly did a quick check on the component itself. The Cypress tests are not running on my side though. I guess it is because this task is not yet completed (https://coveord.atlassian.net/browse/SFINT-4327).

Exactly that's why, I'm currently working on that Jira, so the tests will be good to run soon ok_hand

Perfect, thanks! I updated the ticket accordingly.

This was clearer a lot of work and it's looking real good! It works nicely and the test suite is awesome. A few comments and some points i'll write here:

The mock-ups say the classification with the highest degree of confidence should be selected automatically. This isn't the case here. Was it discussed with UX?
The height of the buttons and the select input is different from the mock-ups as well. It's fine as long as it was discussed with UX and the mock-ups gets updated so that QA can validate efficiently.
This should be adjusted just a bit so the colors match and the overlay doesn't stick out.

The feature of having the classification with highest degree of confidence is now added.
Yes the hight of the buttons and the select input was discussed with the UX, I sync with them to update the mockups like you mentioned 👌.
The overlay is now adjusted, no more stick out and it's now with the correct color:

https://user-images.githubusercontent.com/86681870/148387852-d64b31a4-6d56-401c-a8e7-e4d9fab4e99a.mov

Can we have an option to set number of Suggestion display?
for example, suggestion returns 4 values, and I want to display only first 2, the rest will be on the dropdown?

Like our discussion

Probably we can consider about the maxChoice naming, a bit confusing
According to first discussion during our meeting, we should support user uncheck the box and submit it --> option need to be supported from Quantic

*Also, consider to have default value for number of suggestion shows _ maybe 3 suggestions + 1 dropdown (like in the mockups)

authors: lbergeron lvu285 mmitiche

repo: coveo/ui-kit


text:
add CDC country vaccine numbers

This PR addresses https://trello.com/c/JQh3iWkJ/1344-add-cdc-us-country-level-data-without-being-overwritten-by-aggregation
Tested
./run.py data update and git difftool --no-prompt -t vimdiff main -- data/multiregion-wide-dates.csv shows 4 time series changed, all country level vaccine data gained the CDC source tag.

 Add CDC US country level vaccine data without being overwritten by aggregation

repo: covid-projections/covid-data-model


text:
Charts - Fix missing label on hospitalizations chart

Close 193 - Make sure that the capacity horizontal line is labeled in projections chart
The vertical scale maps the min and max values on the data to the min and max values of the inner chart dimensions in pixels. If the number of beds is the maximum data value, the label ends up outside the chart because it's above the line.
This PR moves the label outside the clipping path boundaries to avoid cropping the label and adjusts the chart margins a bit so it fits. I also adjusted where the minimum value goes (chartHeight - MAX_LINE_WIDTH) to avoid hiding the lines if they are too close to the x-axis.
Before https://covidactnow.org/us/ak?s=41740

After

Can @chasulin review?

 Make sure capacity horizontal line is labeled in projection charts

repo: covid-projections/covid-projections


text:
data.json生成自動化

改善詳細 / Details of Improvement

xxxx(できるだけ簡潔に/as concise as possible)

スクリーンショット / Screenshot

期待する見せ方・挙動 / Expected behavior

xxxx(できるだけ簡潔に/as concise as possible)

動作環境・ブラウザ / Environment

macOS / Windows / Linux / iOS / Android
Chrome / Safari / Firefox / Edge / Internet Explorer

別リポジトリに作成しました。


text:
Collapsed navbar for mobile (#799)

Description of PR
Added a collapsed navbar for mobile (<769px)
Type of PR

[x] Bugfix
[x] New feature

Relevant Issues
Fixes https://github.com/covid19india/covid19india-react/issues/779
Checklist

[x] Compiles and passes lint tests
[x] Properly formatted
[x] Tested on desktop
[x] Tested on phone

Screenshots

Thank you for the PR! :)

authors: ciaasteczkowy jeremyphilemon


text:
Use a new method in covidcaremap to fetch USAFacts data dynamically.

This way we are always using the most up-to-date information.
this also deletes the committed CSV file and adjusts the README
appropriately. Also it adds a TOC of to the readme and makes some
quick improvements.

@Geoyi here's the changes I mentioned in Gitter.


text:
Improve tests of axis validation

Now axis schema has been factored into separate schema (primitive, tuple, polygon), we can be more specific in the tests

Now addressed in latest schemas

repo: covjson/covjson-validator


text:
/summarize command fails

Describe the bug
Using ollama with dolphin2.2-mistral:7b-q8_0 and chatml wrapper. Cannot summarize in place.
Please describe your setup

[x] How did you install memgpt?

pip install pymemgpt? pip install pymemgpt-nightly? git clone?
Installed with pip install pymemgpt

[x] Describe your setup

What's your OS (Windows/MacOS/Linux)? Linux
How are you running memgpt? memgpt run

Debug log:
> Enter your message: /summarize
MESSAGE_SUMMARY_TRUNC_TOKEN_FRAC=0.75
MESSAGE_SUMMARY_TRUNC_KEEP_N_LAST=3
token_counts=[88, 68, 48, 98, 70, 104, 70, 86, 68, 87]
message_buffer_token_count=1011
desired_token_count_to_summarize=758
len(candidate_messages_to_summarize)=10
Selected cutoff 10 was a 'user', shifting one...
Attempting to summarize 9 messages [1:10] of 14
Using model ollama, endpoint: http://localhost:11434
unsetting function_call because functions is None
'function_call'
/summarize failed:
Failed to convert ChatCompletion messages into prompt string with wrapper <memgpt.local_llm.llm_chat_completion_wrappers.simple_summary_wrapper.SimpleSummaryWrapper object at 0x7f9973d7a6e0> - error: 'function_call'

Figured out the issue. Submitting patch for this.

repo: cpacker/MemGPT


text:
Bring back Video-Linking for MV3

In MV2, the extension supports finding the YouTube video for a Nebula video and vice-versa.

YouTube to Nebula: Transform all injectFunction* to bundled files and put into web_accessible_resources, the content policy disallows injecting arbitrary code
Nebula to YouTube: Use offscreen API instead of DOMParser (stashed implementation exists), figure out why sending a response from background script doesn't work

Is this expected to be solved soon or is there a way I can downgrade my version? This video linking is the whole reason I have this extension and I'd hate to lose it until a fix is eventually found if it's going to take a while

Depends on how much time I have.
If you are on firefox, everything works. Unfortunately, Chromium forces manifest V3 starting now, so not really, though I don't know what their policy is on manually installing MV2 (you can try to install the zip from the releases page, make sure to not take the v3 version).

This is now fixed and published, though it may take a while for Google to approve it, especially since this requires a new permission, please check for v1.5.2

authors: SudoWatson cpiber

repo: cpiber/NebulaEnhance


text:
Doesn't find PresentationSource hosted in CustomTaskPane (ElementHost) in Office VSTO Add-in

Hi,
Snoop can't find PresentationSource that contains WPF control. I did some investigation and it is not the case which was related to Wpf controls hosted in ElementHost of WinForms window.
The issue arises by specificity of Office VSTO Add-in which loads in its own appdomain.
PresentationSource.CurrentSources can't enumerate sources from another appdomain which is caused the issue.
Attached minimal project for repro.
SnoopTestAddIn.zip

Hi @batzen , how are you doing? Any news on topic?

I am doing fine.
Had to wait for my SettingsTransport PR to be merged as the changes i made there require changes to the cross-appdomain stuff for this issue.
Now that my PR is merged i will make the required changes for this issue till early march as i am on vacation starting tomorrow.

Hi @batzen , Is there any news regarding to multi-appdomain support?

I am currently very busy. Will try to get this done next week.

Fixed in 2.11.

authors: HamletHakobyan batzen

repo: cplotts/snoopwpf

license: MS-PL


text:
Doxygen+Sphinx+Breathe = Inline Documentation

This is the initial attempt at getting inline documentation in the
project implementation into the sphinx-generated documentation. The way
we achieve this is by doing the following:

Add michaeljones/breathe as a submodule, making it simpler to
generate the documentation with just Sphinx installed on the
developer machine.
Define a Doxyfile configuration which generates HTML and XML
documentation. The generated XML files are needed by Breathe to
generate the HTML as part of the Sphinx docs generation process.
Update the documentation for the client type. This is a starting
point showing how the generated docs are in-lined in the RST docs
via breathe.
Wire up the documentation generation in the Sphinx configuration.

To generate the documentation now, we need two things installed on the
machine generating the docs: Sphinx and Doxygen. The steps involved are:

cd cpp-netlib && doxygen
cd libs/network/doc/ && make html

The results should be in libs/network/doc/_build/html, and the
generated HTML for the HTTP Client reference page should include the
doxygen-generated docs.

Hi @glynos -- are you able to have a look at this?

Thanks @glynos!

@deanberris See the issue linked above.
FWIW, it looks like 853385ef4f0c3dd126887750e20d5f7456065998 (the commit you pointed this submodule at) is equivalent to a564b991b5eb2dc220ca29ef21b9c68bdc2f8ac6 in their new history. Perhaps this submodule should be updated to point to this new commit?

Thanks @davidvandebunte -- merged your PR. :)

authors: davidvandebunte deanberris

repo: cpp-netlib/cpp-netlib


text:
Minor improvements

Especially the undo/redo improvement is nice.

Not much left now, its getting there. I only got a few items left on my TODO:

New menuitem under file: create C++ example project (for people testing the application for the first time mostly. This is quite essential and can thus be hardcoded into Juci, that is no need to put this into a plugin).
Check if file/dir opened exists to avoid crash
Use boost::filesystem everywhere (not use std::string::find("/") etc)
Cleanup of Terminal
Maybe make a Juci::Platform static class with various constants set depending on the operating system Juci is compiled on. The rest of the code should then be platform independent (with a few exceptions like apple-arrow keys on OS X).

Forgot this TODO:

Make compile, and compile and run run in the background (using Terminal::async_execute, which I'll write in day or two).

repo: cppit/jucipp


text:
client用python3的话，CPU占用一直都为0

client端用client-linux.py 如果用python3运行的话，CPU占用一直都为0。如果用Python 2.7，则CPU占用显示是正确的。

已修复

repo: cppla/ServerStatus


text:
Multiple applications to an object with 1 free attribute

Steps to reproduce

Place the following code in sandbox/eo/app.eo:

app.eo
+package sandbox
+alias stdout org.eolang.io.stdout
+alias sprintf org.eolang.txt.sprintf

[x] > empty
  x > @

[args...] > app
  (empty 5) > res1
  (res1 6) > res2
  (1 7) > res3
  seq > @
    stdout
      sprintf "res1 = %d\n" res1
    stdout
      sprintf "res2 = %d\n" res2
    stdout
      sprintf "res3 = %d\n" res3

Compile it
Run the compiled program

Expected output
Compilation or runtime error, because res1 does not have free attributes.
Actual output
res1 = 5
res2 = 6
res3 = 1

res1) Ok
res2) Certainly not ok
res3) Ok, this can be interpreted by a programmer as data has free attributes, which is not used by the object, but is it okay from language design point of view?

@Sitiritis the bug is still valid?

Yes, the output is the same

@rultor release, tag is 0.1.32

@rultor release, tag is 0.1.32

@yegor256 OK, I will release it now. Please check the progress here

@rultor release, tag is 0.1.32

@yegor256 Done! FYI, the full log is here (took me 9min)

@Sitiritis I believe it's fixed, please check version 0.1.32.

@yegor256 everything is fine now, thank you!

Program output
res1 = 5
Exception in thread "main" java.lang.IllegalArgumentException: java.lang.IllegalArgumentException: java.lang.IllegalArgumentException: org.eolang.phi.Attr$Exception: Error at sandbox.EOempty#x in sandbox.EOempty#193064360:{
_order=[x]
x(0)=𝜂SFN
ρ=sandbox.EOapp#812265671:{
_order=[args, res1, res2, res3]
args(0)=[]VN
ρ=𝜂SN
res1(1)=λOBN
res3(3)=λOBN
φ=λOBN
res2(2)=λOBN
}SN
φ=λOBN
}
at org.eolang.phi.AtLambda.lambda$toData$0(AtLambda.java:84)
at org.eolang.phi.AtLambda.get(AtLambda.java:63)
at org.eolang.phi.AtBound.get(AtBound.java:56)
at org.eolang.phi.AtNamed.get(AtNamed.java:66)
at org.eolang.phi.PhDefault.attr(PhDefault.java:143)
at org.eolang.phi.PhOnce.attr(PhOnce.java:65)
at org.eolang.phi.PhOnce.attr(PhOnce.java:65)
at org.eolang.phi.PhOnce.attr(PhOnce.java:65)
at org.eolang.phi.PhOnce.attr(PhOnce.java:65)
at org.eolang.phi.PhDefault.attr(PhDefault.java:143)
at org.eolang.phi.Dataized.take(Dataized.java:54)
at org.eolang.phi.Dataized.take(Dataized.java:72)
at org.eolang.phi.Main.exec(Main.java:80)
at org.eolang.phi.Main.main(Main.java:57)
Caused by: java.lang.IllegalArgumentException: java.lang.IllegalArgumentException: org.eolang.phi.Attr$Exception: Error at sandbox.EOempty#x in sandbox.EOempty#193064360:{
_order=[x]
x(0)=𝜂SFN
ρ=sandbox.EOapp#812265671:{
_order=[args, res1, res2, res3]
args(0)=[]VN
ρ=𝜂SN
res1(1)=λOBN
res3(3)=λOBN
φ=λOBN
res2(2)=λOBN
}SN
φ=λOBN
}
at org.eolang.phi.AtLambda.lambda$toData$0(AtLambda.java:84)
at org.eolang.phi.AtLambda.get(AtLambda.java:63)
at org.eolang.phi.AtBound.get(AtBound.java:56)
at org.eolang.phi.AtNamed.get(AtNamed.java:66)
at org.eolang.phi.PhDefault.attr(PhDefault.java:143)
at org.eolang.phi.PhOnce.attr(PhOnce.java:65)
at org.eolang.phi.PhOnce.attr(PhOnce.java:65)
at org.eolang.phi.Dataized.take(Dataized.java:54)
at org.eolang.EOseq.lambda$new$0(EOseq.java:55)
at org.eolang.phi.AtLambda.lambda$toData$0(AtLambda.java:82)
... 13 more
Caused by: java.lang.IllegalArgumentException: org.eolang.phi.Attr$Exception: Error at sandbox.EOempty#x in sandbox.EOempty#193064360:{
_order=[x]
x(0)=𝜂SFN
ρ=sandbox.EOapp#812265671:{
_order=[args, res1, res2, res3]
args(0)=[]VN
ρ=𝜂SN
res1(1)=λOBN
res3(3)=λOBN
φ=λOBN
res2(2)=λOBN
}SN
φ=λOBN
}
at org.eolang.phi.AtLambda.lambda$toData$0(AtLambda.java:84)
at org.eolang.phi.AtLambda.get(AtLambda.java:63)
at org.eolang.phi.AtBound.get(AtBound.java:56)
at org.eolang.phi.AtNamed.get(AtNamed.java:66)
at org.eolang.phi.PhDefault.attr(PhDefault.java:143)
at org.eolang.phi.PhOnce.attr(PhOnce.java:65)
at org.eolang.phi.PhOnce.attr(PhOnce.java:65)
at org.eolang.phi.PhOnce.attr(PhOnce.java:65)
at org.eolang.phi.Dataized.take(Dataized.java:54)
at org.eolang.phi.Dataized.take(Dataized.java:72)
at org.eolang.io.EOstdout.lambda$new$0(EOstdout.java:49)
at org.eolang.phi.AtLambda.lambda$toData$0(AtLambda.java:82)
... 22 more
Caused by: org.eolang.phi.Attr$Exception: Error at sandbox.EOempty#x in sandbox.EOempty#193064360:{
_order=[x]
x(0)=𝜂SFN
ρ=sandbox.EOapp#812265671:{
_order=[args, res1, res2, res3]
args(0)=[]VN
ρ=𝜂SN
res1(1)=λOBN
res3(3)=λOBN
φ=λOBN
res2(2)=λOBN
}SN
φ=λOBN
}
at org.eolang.phi.AtNamed.put(AtNamed.java:81)
at org.eolang.phi.PhWith.lambda$new$1(PhWith.java:60)
at org.eolang.phi.Data$Once.take(Data.java:65)
at org.eolang.phi.PhOnce.toString(PhOnce.java:50)
at org.eolang.phi.PhOnce.toString(PhOnce.java:50)
at java.util.Formatter$FormatSpecifier.printString(Formatter.java:2886)
at java.util.Formatter$FormatSpecifier.print(Formatter.java:2763)
at java.util.Formatter.format(Formatter.java:2520)
at java.util.Formatter.format(Formatter.java:2455)
at java.lang.String.format(String.java:2940)
at org.eolang.phi.Dataized.take(Dataized.java:59)
at org.eolang.txt.EOsprintf.lambda$new$0(EOsprintf.java:58)
at org.eolang.phi.AtLambda.lambda$toData$0(AtLambda.java:82)
... 33 more
Caused by: org.eolang.phi.Attr$Exception: This free attribute is already set, can't reset
at org.eolang.phi.AtFree.put(AtFree.java:79)
at org.eolang.phi.AtNamed.put(AtNamed.java:78)
... 45 more
ERROR: 1

authors: Sitiritis rultor yegor256

repo: cqfn/eo


text:
Invalid JSON: Duplicate 'type' property generated for ListTypeSpecifier

I am using the 1.3.10 converter on the following snippet:
define Test: { 1 } union {  'A' }

This returns the following JSON:
{
   "library" : {
      "identifier" : {
      },
      "schemaIdentifier" : {
         "id" : "urn:hl7-org:elm",
         "version" : "r1"
      },
      "usings" : {
         "def" : [ {
            "localIdentifier" : "System",
            "uri" : "urn:hl7-org:elm-types:r1"
         } ]
      },
      "statements" : {
         "def" : [ {
            "name" : "Test",
            "context" : "Patient",
            "accessLevel" : "Public",
            "expression" : {
               "type" : "Union",
               "operand" : [ {
                  "type" : "As",
                  "operand" : {
                     "type" : "List",
                     "element" : [ {
                        "valueType" : "{urn:hl7-org:elm-types:r1}Integer",
                        "value" : "1",
                        "type" : "Literal"
                     } ]
                  },
                  "asTypeSpecifier" : {
                     "type" : "ListTypeSpecifier",
                     "elementType" : {
                        "type" : "ChoiceTypeSpecifier",
                        "type" : [ {
                           "name" : "{urn:hl7-org:elm-types:r1}Integer",
                           "type" : "NamedTypeSpecifier"
                        }, {
                           "name" : "{urn:hl7-org:elm-types:r1}String",
                           "type" : "NamedTypeSpecifier"
                        } ]
                     }
                  }
               }, {
                  "type" : "As",
                  "operand" : {
                     "type" : "List",
                     "element" : [ {
                        "valueType" : "{urn:hl7-org:elm-types:r1}String",
                        "value" : "A",
                        "type" : "Literal"
                     } ]
                  },
                  "asTypeSpecifier" : {
                     "type" : "ListTypeSpecifier",
                     "elementType" : {
                        "type" : "ChoiceTypeSpecifier",
                        "type" : [ {
                           "name" : "{urn:hl7-org:elm-types:r1}Integer",
                           "type" : "NamedTypeSpecifier"
                        }, {
                           "name" : "{urn:hl7-org:elm-types:r1}String",
                           "type" : "NamedTypeSpecifier"
                        } ]
                     }
                  }
               } ]
            }
         } ]
      }
   }
}

There are duplicate type properties for the elementType property of both ListTypeSpecifiers.

Adressed in 1.3.14

authors: brynrhodes msteinbr


text:
Update scala-library to 2.13.13

About this PR
📦 Updates org.scala-lang:scala-library from 2.12.19 to 2.13.13
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

💡 Applied Scalafix Migrations

org.scala-lang:{scala-library,scala-compiler,scala-reflect,scalap}:2.13.0 (created no change)

dependency:Collection213Upgrade@org.scala-lang.modules:scala-collection-migrations:2.8.1
Documentation: https://github.com/scala/scala-collection-compat#collection213upgrade

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-lang", artifactId = "scala-library" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.scala-lang", artifactId = "scala-library" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, scalafix-migrations, commit-count:1

Superseded by #262.

repo: cquiroz/sbt-tzdb


text:
Update ./flip help

blame jacob1 for changing the chance :P

Close enough, there may be minor rounding errors


text:
General questions around Windows support with Nitro V2

Description
I'm currently using the Docker images at craftcms/docker as I'm on Windows and I know Nitro v2 doesn't support Windows currently. I'm curious though in terms of the Windows support, as based on my testing and experimenting after sacking off Nanobox and every other VM solution prior the key thing I found unless Docker is ran through WSL 2 i.e. with a real Linux kernel, the performance is horrible when running a development environment for Craft 3. Docker themselves also recommend projects should be mounted on a WSL distro filesystem path not a Windows path i.e. C:\ or /mnt/c due the performance issues you will likely encounter and Craft 3 really does struggle on Windows FS path (dev mode on or off) when virtualisation is involved. I've tried Vagrant, Nanobox and some others, they all have horrible performance because of the combination of virtualisation and Windows filesystem layer. At one point I literally thought about just using IIS...
I myself am probably jaded have experienced much pain with any Virtualisation layer when a Windows FS mountpoint is involved, ranging from symlink shenanigans (looking at you npm), to even Yii2 itself breaking when it didn't know the difference being on a Linux environment hosted on a Windows FS (was fixed). Being quite late to the Docker party, I finally at least found that Docker with a WSL backend seems to be fairly performant and very workable, certainly similar to any environment on macOS or Linux. This is largely thanks to WSL2 having a proper Linux kernel inside Windows, which Docker can take advantage of, so when you have a WSL2 distro, let's say (Ubuntu) and Docker Desktop linked to that WSL distro all the sys calls and hence performance is so much better. So happy days?
So really my TL;DR question is what is the Windows support going to look like, will it involve WSL2, or are you trying to support it natively? If native, it will be interesting to see the performance of Nitro as given it's using a Docker backend, it's possibly likely to encounter the same general problems Docker Desktop on Windows has without WSL2.
Thanks!
P.S I know this isn't a bug, but I can't create an issue that's not a bug or security issue, so please ignore the bug tag!

will it involve WSL2

WSL2 will be required.
You can read the WIP docs for Nitro 2 and Windows here:
https://github.com/craftcms/docs/blob/feature/nitro2-windows/docs/nitro/2.x/installation.md
https://github.com/craftcms/docs/blob/feature/nitro2-windows/docs/nitro/2.x/windows.md
That last link covers performance. The latest Nitro release is fairly solid on Windows if you want to test it, but there are a couple more issues to work through before we merge the docs in.

Ah thanks @angrybrad. I wasn't looking hard enough for existing information on the topic clearly! Confirms what I thought around WSL2 and similar guidance for performance and recommendations.
I will certainly take a look at Nitro at some point, for now I am using the general Docker images at https://github.com/craftcms/docker which work well.

authors: angrybrad jamesmacwhite

repo: craftcms/nitro


text:
jquery.confirm.min.js has console messages

I have installed the library with using bower. But there are log messages on console when I open a dialog. Is it normal? Can I disable it?

This is the line which shows message;
console.log(that._lastFocused);

This is to be removed in the next version, this was a debug message.

I've removed the console message in the v3.0.3 now.

Thank you very much. I appreciate. 👍

authors: craftpip ozziest

repo: craftpip/jquery-confirm


text:
How can i debug in local

i want to edit some codes, but when i write pageId in blog.config.js, then enter yarn dev shell report errors.

Nobelium is just a normal Next.js project. What error did you see from the terminal? Could you provide the log or a screenshot?

repo: craigary/nobelium


text:
DSN / Better Rolls Incompatibility

When using the Dice So Nice module, the players can read their roll on the 3D dice, even though the result is hidden in the chat.

Hi there! What version of dnd5e and Foundry are you running, and are you using any other modules that change how rolls work (better rolls, mess, etc)?

DND5e version 0.98, Foundry version 0.6.6. I can recreate this error consistently with only your module, Dice so Nice(v2.0.4) and Better Rolls 5e (v1.1.11).

Ah. Yeah, that'd do it. Currently the module doesn't work when using Dice So Nice in conjunction with Better Rolls.
It's unfortunate, but it's due to the way that BR modifies the way that rolling works; there's no point in the BR roll process that I can hook into to tell it to shut Dice So Nice animations off. The good news is that it seems like the creator of BR is working on some changes that may make this a possibility in the near future. I'm not sure when that'll be, but if/when it gets done, I'll get a fix for this out!
If you're on the Foundry discord server and drop me a message on there, I can make sure to ping you when that happens. Otherwise I'm just going to leave this issue open until I can get everything fixed and you should be notified that way. 👍

Thank, I appreciate that greatly! I'll be sure to check in on discord.

Should have a fix for this in the next release (sometime this evening, probably). It's only been tested on the alpha version of BR, so make sure you're using that.

Should have a fix for this in the next release (sometime this evening, probably). It's only been tested on the alpha version of BR, so make sure you're using that.