Indent cloud cli configuration example code

What are you changing in this pull request and why?

The Cloud CLI's configuration code example is not properly formatted. This code change indents some of the code in the YAML example so that it is correct.
Checklist

[x] Review the Content style guide and About versioning so my content adheres to these guidelines.
[x] Add a checklist item for anything that needs to happen before this PR is merged, such as "needs technical review" or "change base branch."

Thank you @cesher! Good catch


react-redux installs @types/react@18

What version of React, ReactDOM/React Native, Redux, and React Redux are you using?

React: 17.0.2
ReactDOM/React Native: 17.0.2
Redux: -
React Redux: 7.2.6

What is the current behavior?
react-redux 7.2.6 installs @types/react@18
What is the expected behavior?
I expect that react-redux doesn't install @types/react@18. When @types/react@18 installed, our components' types goes crazy.
Which browser and OS are affected by this issue?
Ubuntu 20.4
Did this work in previous versions of React Redux?

[x] Yes

This isn't actually an issue with React-Redux itself as far as I know.
Up through v7, the React-Redux types have been maintained by the community in DefinitelyTyped, in the @types/react-redux package.
React-Redux v7.x has a hard dependency on @types/react-redux@^7, in order to ensure that our TS users automatically get the types.
However, DefinitelyTyped apparently automatically adds a dependency like "@types/react": "*" to any package that imports from @types/react.  So, the real issue here is how DT constructs its packages.
One option here is to specifically tell your package manager what version of @types/react to resolve to, and enforce that across your project:
https://github.com/facebook/react/issues/24304#issuecomment-1094565891
The other is to upgrade to React-Redux v8, which is currently in RC and will be released live in the next few days.  It's already written in TS, so we don't have a dependency on @types/react-redux any more, and it should work with whatever version of @types/react is already installed
https://github.com/reduxjs/react-redux/releases


Helm is inconsistent about handling actual state of resources

We see this quite often with people new to Helm who know how to use Kubernetes and kubectl.

User deploys a helm chart
They make a tweak to the resources (like running kubectl scale or kubectl annotate)
Later try to upgrade the chart (which apparently succeeds)

In most cases it seems like the upgrade works fine.  In other cases changes or settings either get merged in, or dropped depending on what the state of the resource is within the release that tiller knows about.
AFAICT It would make sense if Helm made use of the same merging behavior in kubectl patch / kubectl apply to solve this problem, perhaps in 2 stages like:

patch release with new changes to the chart
patch actual resources with changes

I can see it being tricky to handle deletions for actual resources in this case, but it it would make sense to favor the contents of the chart in that case I suppose?
At the very least, helm should refuse to upgrade a modified actual resource and tell the user why.

I realized after thinking about this for a while that maybe what I'm actually asking for is a --no-tiller mode, that applies rendered resources directly to the k8s API.
I realize this is a big change and probably not viable for charts installed via repository, but if this and the proposed change to allow a selection of a different template engine other than go-template were available, suddenly I have no qualms about helm at all and could see us using it indefinitely.

/remove-lifecycle stale
This seems to be relevant to the Helm 3 discussion but feel free to close it if it's being tracked elsewhere.

I'll move this to the milestone for now and we'll triage when we get there :)

closing as this is being tracked as part of the helm 3 proposals in https://github.com/kubernetes-helm/community/tree/master/helm-v3


langchain-core: Allow passing local cache to language models

Privileged issue

[X] I am a LangChain maintainer, or was asked directly by a LangChain maintainer to create an issue here.

Issue Content
Goal
Allow instantiating language models with specific caches provided as an init parameter. This will bring language models on feature parity with chat models w/ respect to caching behavior.
This is the cache parameter: https://github.com/langchain-ai/langchain/blob/50f93d86ec56a92e1d0f5b390514d9a67a95d083/libs/core/langchain_core/language_models/base.py#L82-L82
Implementation is required in BaseLLM for both sync and async paths: https://github.com/langchain-ai/langchain/blob/50f93d86ec56a92e1d0f5b390514d9a67a95d083/libs/core/langchain_core/language_models/llms.py#L737-L737
Here's a reference implementation for chat models: https://github.com/langchain-ai/langchain/pull/17386
Acceptance criteria

The PR must include unit tests that provide coverage of the various caching configurations. You can look at the reference PR for Chat Models which covers the relevant scenarios.

i want try.

Is this test case runnable? If it works fine, what exactly is this issue?
https://github.com/langchain-ai/langchain/blob/40f846e65da37a1c00d72da9ea64ebb0f295b016/libs/core/tests/unit_tests/language_models/chat_models/test_cache.py#L43

Is this test case runnable? If it works fine, what exactly is this issue?
https://github.com/langchain-ai/langchain/blob/40f846e65da37a1c00d72da9ea64ebb0f295b016/libs/core/tests/unit_tests/language_models/chat_models/test_cache.py#L43

As I understand this test is testing a chat model, and the intent of the issue is to extend the capability to LLMs. There is an analogous FakeListLLM class that could be useful for the test here.


Data download error

I'm trying to run this code from notebooks/01-vectorizers-quickstart.ipynb
ds = Dataset.load('20_newsgroups_pruned')
print(ds.DESCR)

Here's what I get:
2021-09-30 11:28:56,230 - _twenty_newsgroups - INFO - Downloading 20news dataset. This may take a few minutes.
2021-09-30 11:28:56,230 - _twenty_newsgroups - INFO - Downloading dataset from https://ndownloader.figshare.com/files/5975967 (14 MB)
2021-09-30 11:29:10,454 - datasets - INFO - Generated output datasets: ['20_newsgroups'] via edge:'_20_newsgroups'
2021-09-30 11:29:10,557 - datasets - WARNING - Hash Validation Failed. Dataset:'20_newsgroups' hashes:{'data': 'sha1:01e8537d7484b013d035bd170888166efb178ebb', 'target': 'sha1:5de7194d26d9f956834624fa18a54d8892efa606'} do not match catalog hashes:{'data': 'sha1:01e8537d7484b013d035bd170888166efb178ebb', 'target': 'sha1:07d6abde28d41f179d2a6eea6a80b221b74188fc'}
2021-09-30 11:29:10,564 - datasets - ERROR - Generation from DatasetGraph failed.

Do you have any advice for working around this?

OK, I think I understand now that I need to run the previous 00 notebook, and then the error seems to go away in the 01 notebook.
Sorry for the bother!

I tried again on a new machine, and now I get the same error again when I try to run the 00 notebook... I'm not sure what is wrong.
2021-09-30 11:57:20,553 - _twenty_newsgroups - INFO - Downloading 20news dataset. This may take a few minutes.
2021-09-30 11:57:20,554 - _twenty_newsgroups - INFO - Downloading dataset from https://ndownloader.figshare.com/files/5975967 (14 MB)
2021-09-30 11:57:41,092 - datasets - INFO - Generated output datasets: ['20_newsgroups'] via edge:'_20_newsgroups'
2021-09-30 11:57:41,196 - datasets - WARNING - Hash Validation Failed. Dataset:'20_newsgroups' hashes:{'data': 'sha1:01e8537d7484b013d035bd170888166efb178ebb', 'target': 'sha1:5de7194d26d9f956834624fa18a54d8892efa606'} do not match catalog hashes:{'data': 'sha1:01e8537d7484b013d035bd170888166efb178ebb', 'target': 'sha1:07d6abde28d41f179d2a6eea6a80b221b74188fc'}
2021-09-30 11:57:41,200 - datasets - ERROR - Generation from DatasetGraph failed.
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-5-bbbf956caa81> in <module>
      1 ds_in = Dataset.load('20_newsgroups')
----> 2 print(ds_in.DESCR)

AttributeError: 'NoneType' object has no attribute 'DESCR'

Could I please ask if you might have tried launching the notebooks on a fresh machine?

Workaround
Manually change this file to have the correct hashes:
https://github.com/hackalog/vectorizers_playground/blob/84cd7fdd2048d7663ba65897c92a6709317b8017/catalog/datasets/20_newsgroups.json#L1-L9
Specifically, change target to sha1:5de7194d26d9f956834624fa18a54d8892efa606
Then re-run ds = Dataset.load('20_newsgroups_pruned') and it should work without errors.


Add "Loopback" connection support

Should be able to chat inside Convos, without any external server, such as an Irc server. Just installing Convos should be enough to start chatting.

This would be a tremendous enhancement!!  Really great idea!!

I'm not going to implement this, since I think it's very easy to install an IRC server.
Please do let me know why it would be great to have this feature, if you're still interested.

There can be pain points along the way for all of the aspects of IRC infrastructure.  Perhaps not on a box where IRC can be installed?  Perhaps network issues?  Perhaps closed network?
It's great to have out-of-the-box functionality, even if limited functionality.
Not depending on IRC is also very helpful when it comes to troubleshooting.  Why isn't Convos working?  Is it the IRC server or connection?  Network connection?  Sometimes you just want something minimal up and running ASAP without all the dependency hassles.
On a related note, at this very moment, I'm working on creating a data cache for Mojo apps (kinda like redis?) for a really simple database feature.  Sometimes it's nice to have persistent shared storage (get / set), without having to fuss with setting up another database server, instance, user, permissions, tables, etc...  For validation, I ported mojo-pg's example blog.  Seems to work great!
Using something like this example, you can persistently share data across processes.  Only dependency is the Mojo::Mcache plugin.  It's very limited, yes, but for a PoC, it's kind of nice to be able to setup a framework for a good data model, but not bother with the database infrastructure right away.
Sorry for the ramble and the pitch -- hope that makes sense!

I think there's too many "perhaps" here for me to keep it open, but I don't mind a PR if you (someone) can implement (most of) the functionality in Convos::Core::Connection::Irc as Convos::Core::Connection::Loopback (or something). I guess it would have a singleton object shared between all the ::Loopback objects. that would emulate the "irc server" and then the rest should be fairly simple.
I don't need support for modes or anything in the first iteration (+k, +o, ...). Just "join", "part", "close", "msg" would be enough I think.

I can't find the time to implement this in any foreseeable future, so I'm putting this issue in the fridge.


Updated module version to make a new release

i used 0.4.1 instead of 0.4.0, so you can make a new git release tag.

Thanks @jhoelzl


[Bug]: ID=QUERY-n0wng Message=Instance not found

Preflight Checklist

[x] I could not find a solution in the documentation, the existing issues or discussions
[X] I have joined the ZITADEL chat

Environment
Self-hosted
Describe the bug
after starting zitadel using docker compose with default values
as stated in the documentation
I get the following on browser
http://localhost:8080/ui/console
ID=QUERY-n0wng Message=Instance not found
To reproduce
Download the docker compose example configuration.
wget https://raw.githubusercontent.com/zitadel/zitadel/main/docs/docs/self-hosting/deploy/docker-compose.yaml
Run the database and application containers.
docker compose up --detach
Screenshots
No response
Expected behavior
No response
Version
latest
Operating System
Ubuntu 20
Relevant Configuration
No response
Additional Context
No response

Hi There
I just tested this, and it is working with me like it should.
Can you provide with the log you see?

@SlimJUC Any updates on this issue? Can you provide the logs so we can help you? Without some more information it will be really hard to find out where the problem could be.

Definitely seeing the same issue. What/how logs do you want to see. I have deployed on 20.04 and 22.04 on AWS and VMware ubuntu instances running docker 20.10.23. Leveraging docker compose just as above.

Because this error indicates that zitadel cannot map the domain name received in the host header.
Per default this is set to localhost, but it looks like that is not what is sent to the zitadel endpoint

Indeed, it was my issue. I needed to leverage my custom domain and tls. A few more tweaks of the compose and is working like a charm. I was trying to run on a remote instance and this default guide definitely refers to local install. I was causing my own issues.

Indeed, it was my issue. I needed to leverage my custom domain and tls. A few more tweaks of the compose and is working like a charm. I was trying to run on a remote instance and this default guide definitely refers to local install. I was causing my own issues.

Let me know if you need further assistance 😁

As it looks like this is resolved I will close the issue.

I get the same error, I am also using the docker compose configuration offered by the zitadel documentation but in my case the error appears when I want to generate the access token from another container, on my localhost the endpoint works perfectly

I get the same error, I am also using the docker compose configuration offered by the zitadel documentation but in my case the error appears when I want to generate the access token from another container, on my localhost the endpoint works perfectly

Usually this comes down to a proxy no passing along the http host header. We have some examples here https://zitadel.com/docs/self-hosting/manage/reverseproxy/reverse_proxy

I get the same error, I am also using the docker compose configuration offered by the zitadel documentation but in my case the error appears when I want to generate the access token from another container, on my localhost the endpoint works perfectly

Usually this comes down to a proxy no passing along the http host header. We have some examples here https://zitadel.com/docs/self-hosting/manage/reverseproxy/reverse_proxy

It is my first time trying to implement an identity provider to authenticate my applications, I have some doubts about the proxy configuration, should I configure the proxy in my applications or in the Zitadel container? I'm sorry if the question may seem somewhat absurd but I can't understand exactly where this configuration must be done (I ask it in case the configuration must be done where I have Zitadel hosted).

Same issue with and without proxy.

zitadel was installed in remote server
docker compose file was direct from example without changed

access with proxy(caddy)

$ curl http://zitadel.nas.home/ui/login
ID=QUERY-n0wng Message=Instance not found

config of caddy
http://zitadel.nas.home {
  reverse_proxy h2c://<IP_ADDRESS>:8080
}

direct access without proxy

$ curl http://<IP_ADDRESS>:8080/ui/login
ID=QUERY-n0wng Message=Instance not found

Any advice?

I'm running into the same issue. The comments here sound like you need to run zitadel on your current PC so you can access it via http://localhost:8080/ui/console
I'm running zitadel on my NAS so I am trying to access it via http://NAS-IP:8080/ui/console
No reverse proxy involved yet and its already failing.

@leopku @ovizii you need to configure zitadel to allow you domainname of choice by setting the ExternalDomain.
More infos can be found here https://zitadel.com/docs/self-hosting/manage/custom-domain

Thanks, I had just found that setting and I also saw that here: https://zitadel.com/docs/self-hosting/manage/configure
it is mentioned:

Maybe add a sentence there that with this setup you can only access zitadel if it's running on localhost? That would have saved some people including me some time :-)

There is an ongoing effort on improving the UX of zitadel when managing it.
We just started discussing some changes here #5396 and here #5395

yeah, I've hit this issue on two occasions

running on gitpod - there is no localhost, and the url is random for every workspace that is started. Would be hard to try and develop in this scenario

running on localhost with the port mapping removed from the docker-compose

I am going to try and see if I can map the ports in gitpod, but also make the host docker network available as "myhost" as an addtional network in the compose file. That may then work with port mapping

@leopku @ovizii you need to configure zitadel to allow you domainname of choice by setting the ExternalDomain.
More infos can be found here https://zitadel.com/docs/self-hosting/manage/custom-domain

It works. Thanks a lot.
I came from Docker compose deployment document. Maybe it should be mentioned clearly at the document.


Fix git push error for protected CLA branch

The pull request is created from master636893927324134660 to master to fix git push error for protected CLA branch

@Taojunshen : Thanks for your contribution! The author, @conceptdev, has been notified to review your proposed change.

@gewarren : Thanks for your contribution! The author, @conceptdev, has been notified to review your proposed change.


Usage as a library in Java?

Hello,
I have been struggling with coming up with a realistic world generation algorithm for my Minecraft mod and came across this repository. Unfortunately, worldengine is only available as a python standalone program, which added to that uses a native library.
I'd like to ask if there's possibly a way to use this in this way? If not, is there a knowledge base describing your algorithms?
Thanks,
Knedlik

Most of the knowledge that went into creating this is available online. :)  That's how it was created.
I've been fooling around with re-writing this in Rust (RWIR) which would expose a C API that anyone can link into.


Additional work to README appendix

Added the Schlick BRDF model, the microfacet distribution and the Lambert diffuse to the README.
Also removed the rendered output gifs; they're out of date, and I want to encourage people to just look at the sample instead of maintaining those.

Great to see this project get some attention.  @moneimne Are you still available to take a peek at this sometime?

My bandwidth for the next month is going to be very limited, so hopefully I'll be able to contribute after then!

OK.
@abwood any thoughts?

@snagy One thing I noticed is the metal/rough images still show metallic in the red channel instead of blue.  I know you didn't touch that here, but something to consider.

This is great, adding a much needed intro for the appendix, thanks @snagy!  Lets fix the metal/rough images in a separate issue/pr.

Thanks for the reviews.  I'm going to pull this text into the core glTF 2.0 spec appendix about pbr.


Improve logging and tracing

We already have some rudimentary logging in place, but we need to improve this quite a bit (I had to do a lot of manual logging when debugging #133). The things I think we should do are:

Use logging much more generously. We don't need to log every single function call, but we should be able to see how things move through the pipeline. For things which are not super important, we can use trace log level.
Log relevant data for various actions. For example, it would be great to log hash of the block that is being created (or maybe even entire block header).
Add timing information for important events - e.g., how long it took to load the store, build a block, insert the new block into the DB etc.

We should have a single key that is used to correlate multiple lines, because of the async nature of the server we can't rely on the ordering of lines (it will be interleaved from multiple requests). IMO the key should be the request id used for the distributed tracing, since for example, the RPC does not have the block details to include.

Agreed for requests that come through the RPC. For other things we may not have natural request IDs. For example:

When a batch is generated we should log some kind of batch ID and transaction IDs of transactions that went into this batch.
When the block producer picks batches to put into a block, we should also log that such and such batches got selected to go into a block.
When the block producer builds a block, we should log that a block with such and such hash containing such and such batches has been built.
When the store receives a block, we should log that a block with such and such hash has been received.
etc.

Agreed for requests that come through the RPC. For other things we may not have natural request IDs.

We shouldn't use a natural ID, even if one exists. Given this is a distributed application retries will happen, and we must have different IDs for reach retry. To put this in other words, a request is not the same as the data it contains, and should not use the data to derive an ID.

Closed by #172, #189, #190 and others.
@polydez, could you create an issue for adding request IDs for tracking requests across different components?


How to delete the song menu items?

What is your question?
How to delete the song menu items?

Remove their files from the weeks folder and delete them from weeksList.txt

what do you mean by song menu items?


throw when onOk, onGenerateScript errors

This PR fixes #12836

Pull Request Test Coverage Report for Build 296490430

1 of 9 (11.11%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.001%) to 39.839%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

extensions/resource-deployment/src/ui/modelViewUtils.ts
0
2
0.0%

extensions/resource-deployment/src/ui/notebookWizard/notebookWizard.ts
1
7
14.29%

Totals

Change from base Build 296475600:
-0.001%

Covered Lines:
20086

Relevant Lines:
46189

💛  - Coveralls


How do you validate NRICs?

I found your repository under the Singapore topic on GitHub, and it looked pretty interesting.
I was wondering, what exactly are you doing to validate the NRIC in 02_validate nric2003.py? Is the algorithm explained anywhere?

Hi Ninest! Thank you for taking interest in this.
I am validating the NRICs according to their last alphabet . I believe it is called a checksum. This method of validation has been reversed engineered and a quick google search will yield back results on how to perform validation. I will link it here nonetheless: https://en.wikipedia.org/wiki/National_Registration_Identity_Card#Structure_of_the_NRIC_number/FIN
(that said, my code in 02_validate nric2003.py may not be totally flawless, but it did the job)


All workers failed to make targeted api requests in distributed mode.

Describe the bug

We are running locust in distributed mode on a single machine (Jenkins executor), which has 4 cores. The master runs on 1 core and workers are on other 3 cores. All the workers register with master successfully, we see this log message in our jenkins job "Currently 3 clients ready to swarm." and "Sending spawn jobs of 60 users and 1.00 spawn rate to 3 ready clients". But after test completion the aggregated # of requests and req/sec is way less than running locust in non-distributed mode (with same test configuration). The load difference is in range of 1.5x to 2x between distributed and non-distributed test runs. Also, we are using FastHttpUser in both scenarios. We are using single HttpUser class with weighted tasks for this test.
We tried with latest version of locust(1.5.3) but it fails for FastHttpUser with this error "{**self.user.context(), **context}AttributeError: "str" object has no attribute "context"" , so we used version 1.4.4 instead.
Expected behavior

Distributed mode should run more load (using multiple cores) than non-distributed mode for same test configuration.
Actual behavior

With non-distributed mode we are able to run higher load than distributed mode for same test configuration. Following are the test configuration:

NUM_CLIENTS: 180
HATCH_RATE: 3
RUN_TIME: 15m
MIN_WAIT: 1
MAX_WAIT: 1

Steps to reproduce

Environment

OS: linux
Python version: 3.6
Locust version: 1.4.4
Locust command line that you ran: worker: ${venvPath}/bin/locust -f ${filePath}/${locustFile} --worker,
master: ${venvPath}/bin/locust -f ${filePath}/${locustFile} -u ${numClients} -r ${hatchRate} -t ${runTime} --csv=${outputFile} --headless ${userClass} --master --expect-workers=${cpuCores}
Locust file contents (anonymized if necessary):

Hi @rahul-sehgal, can you tell me how many user classes and what are the weights of those user classes?

Hi @rahul-sehgal, can you tell me how many user classes and what are the weights of those user classes?

Only one user class and tasks in that class are weighted.

Sorry, I see you already mentioned it in the description of the issue.
The log:
Sending spawn jobs of 60 users and 1.00 spawn rate to 3 ready clients

is normal when running in distributed mode because the master is dividing the total number of users and the hatch rate between the 3 workers, so 180 / 3 = 60 and 3 / 3 = 1.
Can you provide a minimal locustfile that reproduces the issue?

Hi! It seems there are two issues. I’m particularly interestes in the issue that gives the error about context in 1.5 (because it may be a regression) please share as much as you can from your locust file and the full exception trace.

Hi! It seems there are two issues. I’m particularly interestes in the issue that gives the error about context in 1.5 (because it may be a regression) please share as much as you can from your locust file and the full exception trace.

Attached is log snapshots, one is intermediate snap shot and other one after test completion.

Sorry, I see you already mentioned it in the description of the issue.
The log:
Sending spawn jobs of 60 users and 1.00 spawn rate to 3 ready clients

is normal when running in distributed mode because the master is dividing the total number of users and the hatch rate between the 3 workers, so 180 / 3 = 60 and 3 / 3 = 1.
Can you provide a minimal locustfile that reproduces the issue?

Yeah I got the spawn users part but I added that because the log message confirms all the workers were registered with the master but all workers were generating the required load. Attached is the locust file in the
smoke-test-locust.txt
most simple form.

Hi! It seems there are two issues. I’m particularly interestes in the issue that gives the error about context in 1.5 (because it may be a regression) please share as much as you can from your locust file and the full exception trace.

closed it accidentally.

Is your real test actually making requests to google? If so, then you might be rate limited by google when running in distributed mode because 3 workers can do much more requests than a single python process. Thus, the distributed test ends up not making as much requests.

Is your real test actually making requests to google? If so, then you might be rate limited by google when running in distributed mode because 3 workers can do much more requests than a single python process. Thus, the distributed test ends up not making as much requests.

no, that is not the case. The real test is used against our own micro-service and we don't rate limit that service.

Looks like you are doing requests with catch_response=True but missing
with … as resp:
That is invalid and could be the problem.

Looks like you are doing requests with catch_response=True but missing
with … as resp:
That is invalid and could be the problem.

I tried with catch_response=False but still see the problem.

try it with latest version (it should at least get rid of that weird context error)

try it with latest version (it should at least get rid of that weird context error)

which version? I tried 1.5.3 and its still broken.

try it with latest version (it should at least get rid of that weird context error)

which version? I tried 1.5.3 and its still broken.

My first idea was wrong, but I think my second one (regarding your ”special” client) is right.

try it with latest version (it should at least get rid of that weird context error)

which version? I tried 1.5.3 and its still broken.

My first idea was wrong, but I think my second one (regarding your ”special” client) is right.

The second one worked but the distributed is still not using all cores (workers) to create the load.

The second one worked but the distributed mode is still not using all cores (workers) to create the load.

Ok, I dont see what could be causing that.


Calls to the default method of a question should include the answers object

See: https://github.com/SBoudrias/Inquirer.js#question for the spec. This is preventing some generators from working as they rely on the given answers to calculate a default.

Do you have an example of a generator failing so I can test it properly? Thanks for the report!

If you use generator-docker on an ASP.NET 5 RC2 project it will fail when trying to determine the default port with the error: "Cannot read property 'projectType' of undefined"

Alright, thanks for the info.

Fixed in 0.9.0. Sorry for the delay, had some other priorities.


K9 Mail crashes with replicant 6

Hello,
When I first start K9 mail, it asks for mail, password. I  fill these fields, and when clicking next it freezes.
The K9-mail version is Version 5.731, from f-droid.
The replicant version is 6.0 0003
The phone is Samsung S3 i9300

I attached the output of adb logcat
logcat.pdf

I don't think this is a bug in K-9 Mail. Please report this to the Replicant project.

?
Before, K9 Mail worked well.
If I downgrade, it works

K-9 Mail is triggering the bug in the OS, it is not causing it. It's working fine when not using Replicant.
We're not going to work around a bug in an OS that a) can be easily updated and b) has a market share of approximately 0%.

It's the only OS which is supported by the free software foundation, and people who work on replicant are rather nice and hard-working (they work on newer versions).
I'm rather beginner, and try to help like I can.
I have some "difficulties" to hear that it's "approximately 0%".
Pinephone is approximately 0%, GrapheneOS is approximately 0%, Mobian and PostmarketOS are approximately 0%… but in the future?

The 5.400 version of K9 Mail works well with replicant, no crashes.
Download of attached files work too, with the replicant default download manager.


Fix IsPodAvailable readiness check

Hey there!
It appears to me as if the condition in k8s.IsPodAvailable should return false either if:

the pod's container is not started
or if the pod's container is not ready

However, the current implem will return false only if both conditions are true.
This PR fixes it.

Hi @Jerska, thanks for the contribution! Code LGTM, could you also add a unit test to verify this fix? Thanks!

@infraredgirl I just noticed that this PR seems to be identical to https://github.com/gruntwork-io/terratest/pull/713, but the latter has tests. Closing in favor of that one!

Ah, good catch!


filled_data does not act as array if not sliced

cube.filled_data does not act like an array if not sliced:
>>> cube.filled_data.shape
...
AttributeError: 'SliceIndexer' object has no attribute 'shape'

Maybe we can pass all requested attributes to the underlying data?

Some of this was solved at some point:
In [3]: cube.filled_data.shape
Out[3]: (77, 1251, 777)

Other attributes like dtype do not.
@keflavich - thoughts on whether this is effectively "solved"?

yeah, let's call it solved for now.  If we refactor to use ndcube under the hood, this will become doubly irrelevant


[BACKLOG-37948] HCP in native mode not working for Drag and Drop

:white_check_mark: Build finished in 6m 31s
Build command:
mvn clean verify -B -e -Daudit -amd -pl \
plugins/file-open-save-new/core

:ok_hand: All tests passed!
Tests run: 38, Failures: 0, Skipped: 0    Test Results

:information_source:  This is an automatic message


Bugfix/alertview truncated text

Bugfix Suggestion for Alert
I noticed that our Alert component would truncate text if the text was sufficiently long...but only in Tori.
Here's now that looks (notice the "We apologize for t...")

So I took a look to see if I could fix it and I think I've got it now
Reading Order 👀
AlertView
The main attraction is of course the Alert view itself. I made the following changes:

got rid of the ZStack in the body as I find they often mess with the layout. Instead the background is now placed in a .background
shuffled things around in the foregroundView

moved the leftLineView to an .overlay
made icon and text top align in the HStack
added padding to the HStack so we control it "globally" for that view

since we control padding globally for the HStack and since we top align icon and text I could get rid of a lot of the padding in the toolTipIconView
added .fixedSize(horizontal: false, vertical: true) to the informationView as that seemed to be the only way to ensure that text was not truncated when you started adding links and buttons to the mix 🤔
the preview builder was complaining about properties on Text that it couldn't find...because we were actually using a Warp.Text, so I prefixed the Text used in titleView and subtitleView and then preview worked again...just makes it so much easier to experiment 😅

And here is how it looks now with the same text in Tori

Removing No Longer Building Tests
Some of the tests were no longer building and was using something that seems to have been gone since version 0.0.6 so...they were deleted as well, don't know if we need them 🤷 .
And
That's it 😅
Hope it is useful 🤞

Thank you @pbodsk for contributing to WARP 🥳 yeah I remember seeing this issue before (not in WARP) and it behaved differently depending on the accessibility setting, custom font and device. I guess the system does not calculate the height of the label correctly.
This does not happen to me using your text, what device and version did you use?
And comparing to main branch the attached video happens for me, Tori Alert is a bit smaller in width, but Finn Alert is a lot smaller. Any ideas why that happens for me and not for you?
https://github.com/warp-ds/warp-ios/assets/89784012/0b65aeba-6b38-4457-ab86-f079f8d2ace4

Hey @mohsen-schibsted, welcome back

This does not happen to me using your text, what device and version did you use?

I use an iPhone 15 Pro with iOS 17.5 and this text:

Due to regularory requirements, we need to collect your social security nummer. Therefore please verify your information again. We apologize for the inconvenience

And here's how that looks on the main branch:

And comparing to main branch the attached video happens for me, Tori Alert is a bit smaller in width, but Finn Alert is a lot smaller. Any ideas why that happens for me and not for you?

I think I do 😅
As far as I recall I no longer has a .frame(maxWidth: .infinity) on the alert component, so it is dynamic in size, compared to the existing that always take up all space.
I can fix that (I think!) so we always take up the entire width (minus padding of course). Let me take  a look! 😅

@mohsen-schibsted There we go, the alert is now full width 🤞

@mohsen-schibsted There we go, the alert is now full width 🤞

Works great now 🥳 thank you


Remove new create survey option from engagement

Description of changes:
Remove templates from attach to engagement
Remove new create survey option from engagement
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the met-public license (Apache 2.0).

Codecov Report

Merging #1484 (a314eae) into main (b8c87bd) will decrease coverage by 0.01%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##             main    #1484      +/-   ##
==========================================
- Coverage   72.01%   72.01%   -0.01%
==========================================
  Files         330      330
  Lines        9698     9700       +2
  Branches      696      696
==========================================
+ Hits         6984     6985       +1
- Misses       2597     2598       +1
  Partials      117      117

Flag
Coverage Δ

metapi
79.15% <50.00%> (-0.02%)
:arrow_down:

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

Impacted Files
Coverage Δ

met-api/src/met_api/resources/survey.py
72.97% <ø> (ø)

met-api/src/met_api/services/survey_service.py
70.96% <ø> (ø)

met-web/src/services/surveyService/index.ts
30.30% <ø> (ø)

met-api/src/met_api/models/survey.py
82.92% <50.00%> (-0.83%)
:arrow_down:


[ROCKETMQ-90] Include client IP in consumerProgress command output

Include client IP per message queue of consumer progress command output

Coverage increased (+0.3%) to 31.623% when pulling c3bfdb770d7f30b7fecf19ad38903f4e57699d59 on lizhanhui:ROCKETMQ-90 into e6aaedcf4d23f95791c51fb510baf369c8b1f5c1 on apache:master.

Coverage increased (+0.3%) to 31.623% when pulling c3bfdb770d7f30b7fecf19ad38903f4e57699d59 on lizhanhui:ROCKETMQ-90 into e6aaedcf4d23f95791c51fb510baf369c8b1f5c1 on apache:master.

Coverage increased (+0.3%) to 31.58% when pulling 2874c569fd02501ec6ae97d3ee9377303c30bcb8 on lizhanhui:ROCKETMQ-90 into e6aaedcf4d23f95791c51fb510baf369c8b1f5c1 on apache:master.

Coverage increased (+0.3%) to 31.58% when pulling 2874c569fd02501ec6ae97d3ee9377303c30bcb8 on lizhanhui:ROCKETMQ-90 into e6aaedcf4d23f95791c51fb510baf369c8b1f5c1 on apache:master.

Coverage increased (+0.3%) to 31.58% when pulling 2874c569fd02501ec6ae97d3ee9377303c30bcb8 on lizhanhui:ROCKETMQ-90 into e6aaedcf4d23f95791c51fb510baf369c8b1f5c1 on apache:master.

@shroman @vongosling  Any idea on this PR?

LGTM~

@shroman Please re-check and  help merge this issue if it's all right.

Coverage decreased (-0.2%) to 31.101% when pulling cb8092a5cad021dad05497d9283dc0c5a3cef3bc on lizhanhui:ROCKETMQ-90 into e6aaedcf4d23f95791c51fb510baf369c8b1f5c1 on apache:master.

Coverage decreased (-0.2%) to 31.101% when pulling cb8092a5cad021dad05497d9283dc0c5a3cef3bc on lizhanhui:ROCKETMQ-90 into e6aaedcf4d23f95791c51fb510baf369c8b1f5c1 on apache:master.

Coverage decreased (-0.2%) to 31.101% when pulling cb8092a5cad021dad05497d9283dc0c5a3cef3bc on lizhanhui:ROCKETMQ-90 into e6aaedcf4d23f95791c51fb510baf369c8b1f5c1 on apache:master.

@lizhanhui +1

@lizhanhui why did we close this PR without merge?

@zhouxinyu it's been merged.


Ticket 34462 check ci

Sorry for the noise, checking why CI is failing for #16792

There is no need to check, bulk_create() doesn't return IDs on SQLite < 3.35 (as documented).


Add Tools information technology co. LTD to powered-by page

support！

Coverage decreased (-0.002%) to 15.411% when pulling d86cb44f0d931977e7974933b53c1e367ac169a2 on KangZhiDong:master into 2aa46edbb8834d00b972804a0f7242361f9242c4 on apache:master.

Ref #443


Update gatling-sbt to 4.3.0

Updates io.gatling:gatling-sbt from 4.2.6 to 4.3.0.
GitHub Release Notes - Version Diff
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!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "io.gatling", artifactId = "gatling-sbt" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "io.gatling", artifactId = "gatling-sbt" }
}]

labels: sbt-plugin-update, early-semver-minor, semver-spec-minor, commit-count:1

Superseded by #164.


(PUP-8773) Fix logging to a JSON file target

This fixes PUP-8773 whereby setting the --logdest option to a JSON file target causes the following:
[root@localhost ~]# /opt/puppetlabs/bin/puppet agent -t --noop --logdest "/tmp/foo.json"
/opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/multi_json-1.13.1/lib/multi_json.rb:130:in `current_adapter': undefined method `[]' for #<File:/tmp/foo.json> (NoMethodError)
        from /opt/puppetlabs/puppet/lib/ruby/vendor_gems/gems/multi_json-1.13.1/lib/multi_json.rb:139:in `dump'
        from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/json.rb:61:in `dump'
        from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/log/destinations.rb:112:in `handle'
        from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/log.rb:191:in `block in newmessage'
        from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/log.rb:190:in `each'
        from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/log.rb:190:in `newmessage'
        from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/log.rb:308:in `initialize'
        from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/log.rb:88:in `new'
        from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/log.rb:88:in `create'
        from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/logging.rb:11:in `send_log'
        from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/logging.rb:20:in `block (2 levels) in <module:Logging>'
        from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/logging.rb:69:in `log_exception'
        from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util.rb:673:in `rescue in exit_on_fail'
        from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util.rb:660:in `exit_on_fail'
        from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application.rb:366:in `run'
        from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:137:in `run'
        from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:73:in `execute'
        from /opt/puppetlabs/puppet/bin/puppet:5:in `<main>'

Can one of the admins verify this patch?

New test fails against master, passes on my branch. OK?

Given the existing tests create actual files on the disk, I've just tested the contents contain the JSON form of the message I've just created. I gave up trying to work out how to mock this stuff.

CLA signed by all contributors.

Rebased and squashed my commits

Re-targeted against 5.5.x and changed the test to read and parse the JSON itself.


Accommodate "nogray" option in desisurvey & associated API changes

This PR accompanies https://github.com/desihub/desisurvey/pull/130, making surveysim accommodate the nogray option in desisurvey.  A lot of plotting and statistics tracking code assumes that a gray layer exists.  That all needed to become more flexible.

This now additionally updates surveysim to work in nopass mode.


Housekeeping: Add tests & docs for modern plugin arguments to apply compiler plugin

See https://github.com/JetBrains/kotlin/commit/928416c9c5fe0287ed38c11ce3e93051c76eb598
There are two different syntaxes for applying & configuring compiler plugins. Both should be tested & docs should reflect each syntax (or possibly just the new one).
The linked commit introduced it as an experimental flag, but it's not experimental anymore, and the old syntax is now considered legacy: https://github.com/JetBrains/kotlin/blob/v2.0.10/compiler/testData/cli/jvm/plugins/mixingModernAndLegacyArgs.out

This issue is stale because it has been open 90 days with no activity. Please comment or this will be closed in 7 days.

This issue was closed because it has been stalled for 7 days with no activity.


query string parameters support in urlFor

Thanks for this.

Does the signature for Slim\Interfaces\RouterInterface::urlFor() need updating too?
public function urlFor($name, array $params, array $queryParams);

I can make a PR if it helps.

you are totally right! :-) a fixing PR would be good


kubernetes-helm: 3.6.0 -> 3.6.1

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/helm/versions.
meta.description for kubernetes-helm is: "A package manager for kubernetes"
meta.homepage for kubernetes-helm is: "https://github.com/kubernetes/helm"
meta.changelog for kubernetes-helm is: ""
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

/nix/store/gygbpy58vkpyn7n1sac25pdnccb5fmgy-helm-3.6.1/bin/helm passed the binary check.

1 of 1 passed binary check by having a zero exit code.

0 of 1 passed binary check by having the new version present in output.

found 3.6.1 with grep in /nix/store/gygbpy58vkpyn7n1sac25pdnccb5fmgy-helm-3.6.1

found 3.6.1 in filename of file in /nix/store/gygbpy58vkpyn7n1sac25pdnccb5fmgy-helm-3.6.1

directory tree listing: https://gist.github.com/cb1e525568987bb7f79e16eeee347a47

du listing: https://gist.github.com/3d20150da4773f4fe9c3abba65078100

Rebuild report (if merged into master) (click to expand)

8 total rebuild path(s)

2 package rebuild(s)

2 x86_64-linux rebuild(s)
2 i686-linux rebuild(s)
2 x86_64-darwin rebuild(s)
2 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
helmfile
kubernetes-helm

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/gygbpy58vkpyn7n1sac25pdnccb5fmgy-helm-3.6.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A kubernetes-helm https://github.com/r-ryantm/nixpkgs/archive/7a5312158124798b8a9b3bbc73d1175dc5aad3f2.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/gygbpy58vkpyn7n1sac25pdnccb5fmgy-helm-3.6.1
ls -la /nix/store/gygbpy58vkpyn7n1sac25pdnccb5fmgy-helm-3.6.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

3 packages built:

helmfile
kubernetes-helm
kubernetes-helm-wrapped

Maintainer pings
cc @rlupton20 @edude03 @saschagrunert @Frostman @Chili-Man @kalbasit for testing.

Result of nixpkgs-review pr 127256 at 7a531215 run on aarch64-linux 1

2 packages built successfully:

helmfile
kubernetes-helm


build_index_column/probe_index_column

predicate_slots
materialize
Opt
fix
fix
fix
Runtimefilter
Runtimefilter
fix
fix
fix
fix
fix
fix
fix
fix
fix
fix
fix
Fixes #issue
What type of PR is this:

[ ] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[x] Yes, this PR will result in a change in behavior.
[ ] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[ ] I have checked the version labels which the pr will be auto-backported to the target branch

[ ] 3.2
[ ] 3.1
[ ] 3.0
[ ] 2.5

[FE Incremental Coverage Report]
:heart_eyes: pass : 0 / 0 (0%)

[BE Incremental Coverage Report]
:disappointed: fail : 87 / 269 (32.34%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
src/exec/hash_joiner.cpp
0
20
00.00%
[111, 112, 161, 162, 163, 164, 166, 170, 171, 172, 174, 175, 178, 179, 181, 184, 185, 186, 187, 188]

:large_blue_circle:
src/exec/hash_join_components.cpp
0
9
00.00%
[30, 34, 35, 37, 38, 47, 52, 53, 54]

:large_blue_circle:
src/exec/hash_join_node.cpp
0
20
00.00%
[184, 185, 204, 205, 206, 207, 209, 210, 211, 212, 226, 227, 228, 229, 706, 713, 720, 722, 727, 728]

:large_blue_circle:
src/exec/join_hash_map.h
8
25
32.00%
[180, 181, 182, 183, 184, 185, 191, 192, 193, 194, 195, 196, 510, 511, 512, 513, 533]

:large_blue_circle:
src/exec/join_hash_map.tpp
58
147
39.46%
[539, 540, 541, 553, 554, 555, 556, 557, 558, 560, 561, 562, 564, 565, 566, 568, 572, 573, 580, 581, 582, 583, 584, 585, 603, 604, 605, 623, 631, 632, 673, 674, 680, 681, 682, 688, 689, 698, 713, 715, 722, 723, 724, 725, 728, 729, 796, 797, 798, 799, 800, 801, 806, 807, 808, 826, 827, 828, 829, 830, 831, 832, 833, 834, 835, 836, 837, 838, 844, 845, 846, 847, 848, 849, 850, 851, 852, 853, 938, 939, 940, 941, 942, 989, 992, 993, 994, 995, 998]

:large_blue_circle:
src/exec/join_hash_map.cpp
21
48
43.75%
[310, 368, 555, 556, 557, 558, 559, 560, 561, 562, 563, 565, 566, 567, 568, 569, 570, 571, 572, 573, 574, 575, 576, 577, 578, 579, 580]


added semantic dom diff as dependency to fix lit jest test issues

What I did

Added @open-wc/semantic-dom-diff to package.json, as tests with Lit 2.0 components started to fail with jest-environment-jsdom setup.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Add Architecture x86: chrdavis.smartrename version 1.1.0

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?

[x] Does your manifest conform to the 1.0 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Have you gone mad? It is successfully validated. 😡

Manifest Error: Schema validation failed. Error context: <root>[Installers] Description: Array should contain no more than 1 elements. Error context: <root> Description: Failed to validate against schema associated with property name 'Installers'.  File: chrdavis.smartrename.yaml
You need a multi manifest to have multiple installers

Okay, but in the screenshot, it is successfully validated.

Okay, but in the screenshot, it is successfully validated.

So? The Singleton Schema only allows one Installer. The bot and winget validate is 2 different validations. winget validate check if the metadata fields are ok and winget install checks if the installer worked, that does not mean you will pass validation.

Ok, is there any way to convert it directly or will I have to start from scratch?

Just use YamlCreate since it will add more information, also add the ProductCode when prompted.
Try to use this version #20359 since it fixes some Yaml breaking issues.

Thanks, I will make changes.

The new script is not working.

The new script is not working.

wot, i believe it says you're missing a }
Copypaste from here: https://raw.githubusercontent.com/microsoft/winget-pkgs/5b946af61b187b169df055f54600d4795367a588/Tools/YamlCreate.ps1

Done.

Now, is it fine?

Perfect!

@palenshus once again added the wrong label...

Please merge this PR.

/azp run


bug: delete recipe button

z-index seem to be off between navbar and this button
https://github.com/user-attachments/assets/31193ae3-cdd2-41fb-93ca-4ecfc7570794

Solved since we changed the navbar.


[Example: Todo List] - Use action type constants instead of strings

I think it’s better to encourage people using action type constants rather than string literals.
I think it would be good if we could recommend this practice by using it in the full source code of the todo application.
Why: avoid typos using actions type strings, to use constants instead, place action type constants in a separate file to hold our action type and export them, so that we can benefit of auto-completion, and use them everywhere in our app without making typos.
You can see this implementation here: https://codesandbox.io/s/todos-71gtc
If you think it is a good idea, I can submit a pull request.

I don't think there's a specific need to change the example atm.  In fact, when we revamp the docs, I'm actually considering not using constants in the initial tutorials to simplify things.  Thanks for the comment, though!

What has confused me is that in the basic tutorial, the constants are used while they aren't in the complete source code. Thanks


mod_auth_openidc installation successfull but Single Sign On configuration giving error while starting Apache

While configuring mod_auth_openidc in Apache files, I am getting below error
Starting httpd-ssc: httpd-ssc: Syntax error on line 58 of /etc/httpd-ssc/conf/httpd.conf: Syntax error on line 10 of /etc/httpd-ssc/conf/includes.conf: Syntax error on line 26 of /etc/httpd-ssc/conf/xclinkssc.xdev.motive.com_3443.conf: Cannot load /usr/lib64/httpd/modules/mod_auth_openidc.so into server: /usr/lib64/httpd/modules/mod_auth_openidc.so: undefined symbol: ap_requires
Below are the version I am using
Redhat                                 6.10
mod_auth_openidc              mod_auth_openidc-1.8.9-1.el6.x86_64.rpm
Apache                                 2.2.15

https://github.com/zmartzone/mod_auth_openidc/wiki#20-why-is-my-ticket-closed-as-invalid


Clarify argument documentation slightly

Hey @cdown - I really love this script. I tried to improve the readme slightly in this PR, let me know what you think.

LGTM. @cdown can we merge?


[core-http] Fix bug with xml2js parser

The xml2js parser is sharing the configurations across instances.
This is leading to unexpected side-effects and needs fixing - for cases when a consumer utilizes the different XML parsing utilities from core-http in one application.
This issue was surfaced as part of adding and running tests for Atom XML serialization policy alongside the default deserialization policy.
This issue is to track investigation efforts for fixing the bug, and subsequently add tests for the serialization utilities that uses this parser.
For more context, the issue was the tests were breaking and expected outputs were different when using multiple instances of xml2js's Parser.
The workaround I have in place is that all the settings are assigned at time of each instance creation, ensuring the overridden values get overridden again.
This in general needs to be done by the users as well so that the intended setting do not get set to some other non-defaults, that other code in app which is creating a new Parser instance might.

Does this essentially mean that if you use an atom-based SDK (like service-bus) and an XML-based SDK (storage-blob) in the same app, there will be parsing issues? Wondering how serious a bug this is, but if using these two packages will cause errors that seems like something we should fix before shipping.

The problem is with xml2js parser. As it stands today, if a user is using any XML based SDK which in turn uses core-http, and they have user code that uses xml2js parser as well, this would likely interfere and break things.
The damage is already done since it's an issue with xml2js, and this is unrelated to the feature work as such actually.
cc @AlexGhiondea @ramya-rao-a

For more context, the issue was the tests were breaking and expected outputs were different when using multiple instances of xml2js's Parser.
The workaround I have in place is that all the settings are assigned at time of each instance creation, ensuring the overridden values get overridden again.
This in general needs to be done by the users as well so that the intended setting do not get set to some other non-defaults, that other code in app which is creating a new Parser instance might.

@ramya0820 do you have a repro that we can look at?
@chradek if @ramya0820 shares a repro, can you take a look at this?

Sure. I did take a quick look at the xml2js source code and it looks like anytime you call new Parser, it only stores the provided options in that instance. Looks correct to me but I was looking at transpiled coffeescript so the code isn't the easiest to read. If we can reproduce it we should definitely file an issue on their repo.
I'm worried about this bug since with the ATOM support our own SDKs can trigger it if used together, whereas before you'd have to use one of our SDKs and then another library (e.g. xml2js directly) for a chance to have this error occur.

@chradek
We have a workaround in place that allows for the features to work alongside without any issues, since the settings that get overridden are overridden each time the utility is used. (this is the workaround)
So technically, the issue is not reproducible using current feature.
The risk is only in case of where another xml2js Parser gets introduced or is already existing in user code. That would get broken. The repro for this issue would involve using storage, as the Service Bus Atom XML feature isn't published/checked in yet, and instantiate another Parser and the functionality in storage would break. (In local repro, the deserialization policy tests would break.)
Specific steps to reproduce would be, to use SDK that uses core-http and have a separate user scenario alongside that uses xml2js parser and code.

The key here is to check that the user code using  xml2js parser uses and relies on settings that are explicitly different from ones used in core-http.
Now by using the storage SDK or some other, the user code will break

Please see https://github.com/Azure/azure-sdk-for-js/pull/4916/files/30509afa5d80713b928eec5c041d14845eec3bc0#r331135689
It looks like our code is mutating the default settings.

Thanks for the catch! @chradek
Closing per comment https://github.com/Azure/azure-sdk-for-js/pull/4916#discussion_r331158525
Also, filed issue on xml2js to consider making the default settings immutable as discussed - https://github.com/Leonidas-from-XIV/node-xml2js/issues/536


CLI: fix #1006 grid logs --tail breakage

Quick fix for #1006 where #987 broke grid logs --tail. I ended up fixing this in #1001 without noticing it was broken. Let's discuss any more complete fix there, including the lack of any test specs covering this functionality :(
kontena grid logs --lines 10

2016-09-12T18:05:16.000Z test-client-1: Mon Sep 12 18:05:16 UTC 2016
2016-09-12T18:05:17.000Z test-client-1: Mon Sep 12 18:05:17 UTC 2016
2016-09-12T18:05:18.000Z test-client-1: Mon Sep 12 18:05:18 UTC 2016
2016-09-12T18:05:19.000Z test-client-1: Mon Sep 12 18:05:19 UTC 2016
2016-09-12T18:05:20.000Z test-client-1: Mon Sep 12 18:05:20 UTC 2016
2016-09-12T18:05:21.000Z test-client-1: Mon Sep 12 18:05:21 UTC 2016
2016-09-12T18:05:22.000Z test-client-1: Mon Sep 12 18:05:22 UTC 2016
2016-09-12T18:05:23.000Z test-client-1: Mon Sep 12 18:05:23 UTC 2016
2016-09-12T18:05:24.000Z test-client-1: Mon Sep 12 18:05:24 UTC 2016
2016-09-12T18:05:25.000Z test-client-1: Mon Sep 12 18:05:25 UTC 2016

kontena grid logs --lines 10 --tail

test-client-1 | Mon Sep 12 18:05:31 UTC 2016
test-client-1 | Mon Sep 12 18:05:32 UTC 2016
test-client-1 | Mon Sep 12 18:05:33 UTC 2016
test-client-1 | Mon Sep 12 18:05:34 UTC 2016
test-client-1 | Mon Sep 12 18:05:35 UTC 2016
test-client-1 | Mon Sep 12 18:05:36 UTC 2016
test-client-1 | Mon Sep 12 18:05:37 UTC 2016
test-client-1 | Mon Sep 12 18:05:38 UTC 2016
test-client-1 | Mon Sep 12 18:05:39 UTC 2016
test-client-1 | Mon Sep 12 18:05:41 UTC 2016
test-client-1 | Mon Sep 12 18:05:42 UTC 2016
test-client-1 | Mon Sep 12 18:05:43 UTC 2016
test-client-1 | Mon Sep 12 18:05:44 UTC 2016
test-client-1 | Mon Sep 12 18:05:45 UTC 2016
test-client-1 | Mon Sep 12 18:05:46 UTC 2016

The Travis failure seems like a random glitch?

Yes, random glitch. Now it's all green.


Fix a bug where query is generated in incorrect way, which causes requests to fail

This is an important fix to a bug that was introduced after swift 3 migration

Thanks!


Thread crash when parsing some special file

This file has name with .doc, but actually is html file. When processing it, yomu will running for a very long time without and response, until I force to kill the thread.
Even if I change the filename to *.html, it still the same, so maybe the file is special.
And then I try to parse with tika directly, it extract text rightly.
fake_doc_but_htm.doc.zip

@sherllochen I don't believe this project is maintained. Suggest try using the newer version of Tika (v1.14). I've forked this project and updated Tika. See https://github.com/abrom/henkei


Failover with Shipyard

Hey Guys,
I have a problem with Failover in Shipyard. I figured out that you can reschedule Containers if a Node falls out. The command for this is "reschedule:[always,never]". But now I need your help how I can use this in Shipyard

There is currently no support for that.  That sounds like something great that could be contributed :)


WIP: Configure Vagrant VMs to always collect core files.

Description

Motivation and Context

How Has This Been Tested?

[ ] Covered by existing integration testing
[ ] Added integration testing to cover
[ ] Tested locally
[ ] Have not tested

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.

Note: I've marked this WIP.  It works fine, but I'd like to clean up the code a bit before merging.


Simpler Checking for Valid Link

There are linting errors and the code has not been checked yet to make sure it works.


ValueError: num_samples should be a positive integer value, but got num_samples=0

Hello Authors,
Good work, thank for uploading it.
I am getting an error, please let me know what am I missing.
'''
File "train.py", line 132, in
sampler=sampler, shuffle=shuffle, pin_memory=True)
File "/home/gaurav/anaconda3/envs/hmp1/lib/python3.6/site-packages/torch/utils/data/dataloader.py", line 268, in init
sampler = RandomSampler(dataset, generator=generator)
File "/home/gaurav/anaconda3/envs/hmp1/lib/python3.6/site-packages/torch/utils/data/sampler.py", line 103, in init
"value, but got num_samples={}".format(self.num_samples))
ValueError: num_samples should be a positive integer value, but got num_samples=0
'''

It might because you didn't put the dataset in the right place?


Add support for double-width/double-height lines in conhost

Summary of the Pull Request
This PR adds support for the VT line rendition attributes, which allow for double-width and double-height line renditions. These renditions are enabled with the DECDWL (double-width line) and DECDHL (double-height line) escape sequences. Both reset to the default rendition with the DECSWL (single-width line) escape sequence. For now this functionality is only supported by the GDI renderer in conhost.
PR Checklist

[x] Closes #7865
[x] CLA signed.
[ ] Tests added/passed
[ ] Documentation updated.
[ ] Schema updated.
[x] I've discussed this with core contributors already. Issue number where discussion took place: #7865

Detailed Description of the Pull Request / Additional comments
There are a lot of changes, so this is just a general overview of the main areas affected.
Previously it was safe to assume that the screen had a fixed width, at least for a given point in time. But now we need to deal with the possibility of different lines have different widths, so all the functions that are constrained by the right border (text wrapping, cursor movement operations, and sequences like EL and ICH) now need to lookup the width of the active line in order to behave correctly.
Similarly it used to be safe to assume that buffer and screen coordinates were the same thing, but that is no longer true. Lots of places now need to translate back and forth between coordinate systems dependent on the line rendition. This includes clipboard handling, the conhost color selection and search, accessibility location tracking and screen reading, IME editor positioning, "snapping" the viewport, and of course all the rendering calculations.
For the rendering itself, I've had to introduce a new PrepareLineTransform method that the render engines can use to setup the necessary transform matrix for a given line rendition. This is also now used to handle the horizontal viewport offset, since that could no longer be achieved just by changing the target coordinates (on a double width line, the viewport offset may be halfway through a character).
I've also had to change the renderer's existing InvalidateCursor method to take a SMALL_RECT rather than a COORD, to allow for the cursor being a variable width. Technically this was already a problem, because the cursor could occupy two screen cells when over a double-width character, but now it can be anything between one and four screen cells (e.g. a double-width character on the double-width line).
In terms of architectural changes, there is now a new lineRendition field in the ROW class that keeps track of the line rendition for each row, and several new methods in the ROW and TextBuffer classes for manipulating that state. This includes a few helper methods for handling the various issues discussed above, e.g. position clamping and translating between coordinate systems.
Validation Steps Performed
I've manually confirmed all the double-width and double-height tests in Vttest are now working as expected, and the VT100 Torture Test now renders correctly (at least the line rendition aspects). I've also got my own test scripts that check many of the line rendition boundary cases and have confirmed that those are now passing.
I've manually tested as many areas of the conhost UI that I could think of, that might be affected by line rendition, including things like searching, selection, copying, and color highlighting. For accessibility, I've confirmed that the Magnifier and Narrator correctly handle double-width lines. And I've also tested the Japanese IME, which while not perfect, is at least useable.

I've tried to keep this as simple and efficient as I could, but it touches on almost every part of the system, so it seems inevitable that it's going to have some impact on performance. And given that there isn't much demand for this functionality, I'd completely understand if you decide not to merge this.
That said, here are a couple of screenshots so you can see how well it handles VT Test and the VT100 Torture Test.

wow

I've tried to keep this as simple and efficient as I could, but it touches on almost every part of the system, so it seems inevitable that it's going to have some impact on performance. And given that there isn't much demand for this functionality, I'd completely understand if you decide not to merge this.

James... with high quality contributions like this, it would be a crime for us to not merge it at some point. I'll even catch your back with the performance implications and writing out the DX version of the rendering if I must. It just might take us a little bit of time to digest the whole thing before we can take it.
Once again, thank you so much. I hope to read through it soon.

I've tried to keep this as simple and efficient as I could, but it touches on almost every part of the system, so it seems inevitable that it's going to have some impact on performance. And given that there isn't much demand for this functionality, I'd completely understand if you decide not to merge this.

James... with high quality contributions like this, it would be a crime for us to not merge it at some point. I'll even catch your back with the performance implications and writing out the DX version of the rendering if I must. It just might take us a little bit of time to digest the whole thing before we can take it.
Once again, thank you so much. I hope to read through it soon.

This is the only thing I noticed in writing big.txt between main and this branch. Note that big.txt doesn't output anything but standard text in standard lines.

It looks like we're calling Set/ModifyWorldTransform to GDI even when there isn't really anything to talk about. Unfortunately when I expand it, it looks like this goes all the way into kernel to resolve that there's nothing to change. So if we could not call it when there's nothing to be done on our side, it would probably save us something.

This is the only thing I noticed in writing big.txt between main and this branch. Note that big.txt doesn't output anything but standard text in standard lines.

It looks like we're calling Set/ModifyWorldTransform to GDI even when there isn't really anything to talk about. Unfortunately when I expand it, it looks like this goes all the way into kernel to resolve that there's nothing to change. So if we could not call it when there's nothing to be done on our side, it would probably save us something.

It looks like we're calling Set/ModifyWorldTransform to GDI even when there isn't really anything to talk about.

I'm really glad you spotted that. I actually had checks in place to avoid setting and resetting the transform unnecessarily in the PrepareLineTransform and ResetLineTransform methods, but I got caught out by the fact that -0.0 and 0.0 aren't equal.
And I just realised there's also the special case handling for the inverted cursor, which has to "uninvert" itself when scrolling, and that requires setting a transform first. So that's also going to need a check to avoid the transform when it's just the identity matrix.

It looks like we're calling Set/ModifyWorldTransform to GDI even when there isn't really anything to talk about.

I'm really glad you spotted that. I actually had checks in place to avoid setting and resetting the transform unnecessarily in the PrepareLineTransform and ResetLineTransform methods, but I got caught out by the fact that -0.0 and 0.0 aren't equal.
And I just realised there's also the special case handling for the inverted cursor, which has to "uninvert" itself when scrolling, and that requires setting a transform first. So that's also going to need a check to avoid the transform when it's just the identity matrix.

OK. I've added the requested comments, made the GetTextRects parameters explicit, and improved the checks to avoid unnecessary transform changes. You shouldn't be seeing any Set/ModifyWorldTransform calls now if you're just rendering regular single-width text, with no horizontal viewport offset.

OK. I've added the requested comments, made the GetTextRects parameters explicit, and improved the checks to avoid unnecessary transform changes. You shouldn't be seeing any Set/ModifyWorldTransform calls now if you're just rendering regular single-width text, with no horizontal viewport offset.

@hafixo Please stop commenting on unrelated PRs without actionable feedback.

@hafixo Please stop commenting on unrelated PRs without actionable feedback.

@hafixo Tolong berhenti memberi komen mengenai PR yang tidak berkaitan tanpa maklum balas yang boleh diambil tindakan.

Im sorry..,im hit more button because my page so lagging to view code... apologize me

@hafixo Tolong berhenti memberi komen mengenai PR yang tidak berkaitan tanpa maklum balas yang boleh diambil tindakan.

Im sorry..,im hit more button because my page so lagging to view code... apologize me

Sorry, @j4james, this is all on me. I've been travelling and not had a chance to look over this in-depth. I'll clear the stale state and get it in this week. :smile:
Thanks again for excellent work.

@DHowett Take your time. I've been messing about with this for months, so I'm in no hurry to get it merged.

Double-click word selection seems to treat the click and expansion coordinates as buffer instead of screen (resulting in the wrong range being selected)

I thought I might miss a few of these operations. But that should be an one easy to fix. I think it just needs a couple of ScreenToBuffer and BufferToScreen calls in the SCREEN_INFORMATION::GetWordBoundary method.

I encountered a crash resizing the console down (horizontally) after putting a normally double-width glyph into a double-width line²

Oof. That's bad. Thanks for catching that. It looks like the TextBuffer::_GetPreviousFromCursor method needs to be adjusted to take the current line width into account rather than assuming the full buffer width. If that's all it is, that should be an easy fix too.

I don't expect this to work, but MAN this makes COOKED_READ angry. It stops wrapping (even at buffer width). I also don't expect for you to fix that!

Yeah, I wouldn't have expected that work either. I assume if you're mixing VT sequences with console APIs then weird things are going to happen. I suspect this isn't the only escape sequence that'll freak out COOKED_READ.

When testing the fix for the crash which occurred when reflowing a double width line with double width characters, I noticed that the double width characters could end up split in half as they were forced to wrap onto another line. I've since fixed that in commit 55c93dc7e944e5c3e9d4a4e51cf7ac07b5274952.

This will regrettably need a second merge from main (or rebase), but I'm ready to set automerge and click that button. :smile:

FYI, I'm going to bed now, so if there is many more merging or changes required it'll have to wait until tomorrow.

Beautiful work with great attention to detail, as always. Thanks again @j4james!

What the... I am very glad to see you having implemented this. Good work!

This is available in conhost as of Windows Insider Preview build 21337. Congrats! :smile:


wire-desktop: refactor to add Darwin support

Motivation for this change
The derivation didn't have Darwin support but the software does.
I refactored the package putting all the linux/darwin specific stuff in their own attrsets and then that's  merged into the common bits like pname and meta.
I updated the meta while I was at it. The license in the repo is actually GPLv3 or later but I'm not sure whether that's accurate because terms and conditions apply.
You can find them in the README for the project, reproduced here for convenience:

For licensing information, see the attached LICENSE file and the list of third-party licenses at wire.com/legal/licenses/.

If you compile the open source software that we make available from time to time to develop your own mobile, desktop or web application, and cause that application to connect to our servers for any purposes, we refer to that resulting application as an “Open Source App”. All Open Source Apps are subject to, and may only be used and/or commercialized in accordance with, the Terms of Use applicable to the Wire Application, which can be found at https://wire.com/legal/#terms. Additionally, if you choose to build an Open Source App, certain restrictions apply, as follows:

a. You agree not to change the way the Open Source App connects and interacts with our servers;
b. You agree not to weaken any of the security features of the Open Source App;
c. You agree not to use our servers to store data for purposes other than the intended and original functionality of the Open Source App;
d. You acknowledge that you are solely responsible for any and all updates to your Open Source App.

For clarity, if you compile the open source software that we make available from time to time to develop your own mobile, desktop or web application, and do not cause that application to connect to our servers for any purposes, then that application will not be deemed an Open Source App and the foregoing will not apply to that application.

No license is granted to the Wire trademark and its associated logos, all of which will continue to be owned exclusively by Wire Swiss GmbH. Any use of the Wire trademark and/or its associated logos is expressly prohibited without the express prior written consent of Wire Swiss GmbH.

Things done

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

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

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/) Tested the executable inside the .app.
[ ] Determined the impact on package closure size (by running nix path-info -S before and after) Tried to but the original derivation wouldn't build on darwin. The result is about 150MB though.
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

adding @silverhook for legal review, as I am not a lawyer. I don't think that the restrictions that Wire has added would be considered permissable "additional terms" as per GPL3, section 7 but instead be a "further restriction".

I didn’t dive deep, but at a quick glance, I’d agree with @armijnhemel that this would go into the “further restrictions” territory. But also that these “further restrictions” fall away, if you modify the client in a way to not connect to Wire’s own servers.
It seems like a very mixed bag to me.

I work at Wire and have poked someone at the company who might be able to help with this question.

@toonn I've made a patch to fix some style issues and to make it easier to update manually

https://gist.github.com/worldofpeace/d02bcda1ab44bb37e438335a46579232

@worldofpeace, I applied your patch, I'd originally grouped the makeDesktopItem with the other linux-specific dependencies but I don't feel strongly about that. Keeping the versions together does look like a definite improvement.

@toonn The client source code is only governed by GPLv3. The terms you quote apply to the usage of Wire servers, not the client server.

@toonn The client source code is only governed by GPLv3. The terms you quote apply to the usage of Wire servers, not the client server.

Although I agree that these terms only seem to be when the Wire servers are used (and not when your own server is used), they do read on the client code and are, I think, a "further restriction" according to the license.

I should have clarified: I work for Wire. The terms of use only govern Wire accounts (which is a prerequisite for using the Wire servers).
The source code is not affected by them.

I should have clarified: I work for Wire. The terms of use only govern Wire accounts (which is a prerequisite for using the Wire servers).
The source code is not affected by them.

But it is not "terms of use"! The README actually calls them "restrictions" :-)
"Additionally, if you choose to build an Open Source App, certain restrictions apply"
I absolutely understand why you would want these restrictions as rogue code could interfere with your operations, but the way it is currently worded it reads on the client code and thus could be seen as a "further restriction" according to the license.
Personally I would move these restrictions to general terms and conditions and just terminate people's accounts if they don't comply with those rules. GPL3, section 6 would already allow you to do this:
"Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network."
It might be worthwhile to talk to an experienced open source lawyer. I would be more than happy to give some suggestions for various jurisdictions (Germany, Switzerland, Italy, Spain, UK, etc.)

I should have clarified: I work for Wire. The terms of use only govern Wire accounts (which is a prerequisite for using the Wire servers).
The source code is not affected by them.

@raphaelrobert, thanks for the clarification. But if that is case, please make sure to clarify it in the license itself and official documentation, instead of an issue buried on a source code forge.

@silverhook I'm not sure what you mean exactly. The README file points to the license file directly for all source code licensing questions:

For licensing information, see the attached LICENSE file and the list of third-party licenses at wire.com/legal/licenses/.

@raphaelrobert, the relevant part of the https://github.com/wireapp/wire-desktop/blob/staging/README.md reads as follows (emphasis mine):

For licensing information, see the attached LICENSE file and the list of third-party licenses at wire.com/legal/licenses/.
If you compile the open source software that we make available from time to time to develop your own mobile, desktop or web application, and cause that application to connect to our servers for any purposes, we refer to that resulting application as an “Open Source App”. All Open Source Apps are subject to, and may only be used and/or commercialized in accordance with, the Terms of Use applicable to the Wire Application, which can be found at https://wire.com/legal/#terms. Additionally, if you choose to build an Open Source App, certain restrictions apply, as follows:
a. You agree not to change the way the Open Source App connects and interacts with our servers; b. You agree not to weaken any of the security features of the Open Source App; c. You agree not to use our servers to store data for purposes other than the intended and original functionality of the Open Source App; d. You acknowledge that you are solely responsible for any and all updates to your Open Source App.
For clarity, if you compile the open source software that we make available from time to time to develop your own mobile, desktop or web application, and do not cause that application to connect to our servers for any purposes, then that application will not be deemed an Open Source App and the foregoing will not apply to that application.

The parts emphasised in bold, seem to be connected to the license of the code, not the Terms of Service of the official Wire server(s). I agree that you clarification makes sense, but it is not (unambiguously) reflected in the README.md. The way it reads now is that it restricts the use of the code and splits the market into two, giving a different license to each part of the market.
It would be good to re-write the wording in order to clarify the distinction between the license of the code (GPL-3.0) and the terms of service that apply when a client connects to the official Wire servers.

Thanks for the feedback @silverhook! I guess we could make it more clear that the README is just an extract of the Terms of Use.

Thanks for the feedback @silverhook! I guess we could make it more clear that the README is just an extract of the Terms of Use.

Yes, this would, I think, suffice (as I already commented). It basically comes down to "if you mess with our operations, we will terminate your account" and that's perfectly fine. For the rest: what @silverhook said :-)

Ping @worldofpeace.

@grahamc at https://github.com/NixOS/nixpkgs/pull/64931#discussion_r304112617 you said "this is very fishy".
I'm not sure what you meant by that and what to change, and @toonn changed their expression significantly https://github.com/NixOS/nixpkgs/pull/64931/commits/f5beda50ca643cb4a26321d513772186410cfec5.

@worldofpeace, I made the changes in response to @grahamc's complaints. They didn't like the common // if darwin then darwin else linux), preferring inheriting the common attributes. (aside: I personally don't like the inherit mechanism because with can bring things in scope implicitly so you can't always tell where inheritted attributes are coming from.)
@grahamc also didn't like that all this derivation does is fetch the .app for darwin, preferring homebrew for this. But the linux derivation essentially does the same and I wrote this because I want to move away from brew. (Note there was some support for having this in nixpkgs despite "just fetching the .app.")

Did you discuss in private? Because he only left that comment here.
At any rate I'm sure the changes are fine, going to give it the last look over since it has been a week here for me.

We discussed in #nixos-dev or #nixos-chat, not quite sure. I could share the relevant parts of my logs if necessary. Note that these changes were made almost a week ago. I didn't ping until now because I figured people are busy and this isn't high priority anyway.

Thanks for clearing it up @toonn, it just confused me as to where the inspiration for these changes for coming from.
@GrahamcOfBorg build wire-desktop

@GrahamcOfBorg build wire-desktop

@toonn Can you squash your commits?
I'm not sure where to go with the history so I'll leave this up to you.

@worldofpeace, should we worry about the ofborg failure?

Oh, I just now noticed that.

I undid this change when merging staging-next into staging because of a merge conflict. Please open a new PR for staging to reapply the change.

Nevermind, it is in. However, there was a problem with evaluation, see 15564fbb4d9e349f75edc1d4791bd7b5f4865973.

@FRidh, does this require further action? Would my original approach work better maybe? Then meta.platforms can be evaluated without running into this (if nix is lazy enough).


Filter breaks when using global & viewport functions

When using populated_places to build the guide on Aggregations (#1023), I found this:
This viz works fine:
 const citiesViz = new carto.Viz(`
            color: grey
            width: 15
            @g_max: globalMax($pop_max)
            @g_avg: globalAvg($pop_max)
            @g_p95: globalPercentile($pop_max, 95)
            filter: ($pop_max > @g_p95)
`);

But adding another variable with a viewport aggr. function seems to break it. This doesn't work:
        const citiesViz = new carto.Viz(`
            color: grey
            width: 15
            @g_max: globalMax($pop_max)
            @g_avg: globalAvg($pop_max)
            @g_p95: globalPercentile($pop_max, 95)
            filter: ($pop_max > @g_p95)
            @v_sum: viewportSum($pop_max)
`);

The error is CartoRuntimeError: Unimplemented at GlobalPercentile.eval

Fix merged to master 🚀


Fixes issue with dispatch view not scrolling to current day

_scrollRatio being set to null was preventing the scroll

@manishsingh08 I removed one line of code that you added so I want to double check with you if that line is needed for anything else, theres a comment above that line that read:
// Only do this once

@manishsingh08 I removed one line of code that you added so I want to double check with you if that line is needed for anything else, theres a comment above that line that read:
// Only do this once

I think this is from original calendar code. I cannot tell what it would break if we remove it.
But if everything is working during testing, we can ship it. If you put it on staging, let me know. I'll help test.

Will defer to manish/cory here


bug：chinese encoding error

from steamship import Steamship
instance = Steamship.use("PACKAGE_HANDLE", "INSTANCE_HANDLE", config={
"default_name": "王某"
})
print(instance.invoke("greet")      #######.  chinese encoding error

Thank you for reporting!  I've been able to reproduce locally.  Will work on a fix.

Hi again - just reporting that I have a backend fix in the works.  Will close this issue once it's deployed to production.


ambiguously multi_select filtering - issue

Sorry Daniel,
I find a issue for multi_select filtering. AND and OR condition are used ambiguously if you set text delimiter for text.
you need a function that allows you to choose whether to use the AND condition or OR condition, or even both. I suppose problem is caused by select_type: 'select2'
Correct me if I wrong
Here a better explanation
http://stackoverflow.com/questions/29175813/ambiguous-multi-select-filter-and-and-or-condition-javascript
Regards

Questions to be asked on stackoverflow, if I decide its an issue I will ask you to open it here, till then post you thoughts on stackoverflow only.


Interval-aware default ticks/tick formats

When the data only contains integers, it would be great if the default tickFormat would not do "1.0, 2.0, 3.0"… but rather "1, 2, 3".
In #849 I hoped that indicating an integer interval would be used, in this case to infer an intent of only having integers. (Similarly, if we used interval: d3.utcYear we'd rather format the ticks as "%Y", and d3.utcMonth would result in a default of "%Y-%m" or something.)
Example: the test plot integer-interval.js (svg) should have inferred an integer tickFormat for the x axis. (See also the discussion here.)
Also related to #768

I’ve retitled this issue to describe the more general issue.

A related typical use case is
Plot.tickX([new Date(2001, 0, 1), new Date(2001, 1, 1)]).plot({
  x: {interval: "day", tickRotate:40},
  height: 70, marginBottom: 50})

Since the interval is "day" we could have a stricter tickFormat than the default "multiscale".
cc: @mootari

Related feedback from Misha Tsvelik: https://vimeo.com/829300247/91d6c7eeef
This issue applies to ticks, and not just tick formats: for example if the data is just integers, then we wouldn’t want to show ticks at 0.1, 0.2, 0.3, etc., or if the data is just months, we don’t want to show weekly ticks.
I guess we would need some heuristic that looks at the channel values and guesses what the interval is; if we guess successfully, then we can choose an appropriate tick interval and accompanying tick format.

This is pretty much fixed by #1728 for time axes, but we’d need to do something similar to numbers/integers.

I got this working in https://github.com/observablehq/plot/pull/1790/files#r1303485576.


Standalone based sanity test for KubernetesContainerFactory

Adds a basic sanity test based for KubernetesContainerFactory using Standalone mode
Description
This PR creates a small k8s setup based on kind using approach taken in apache/openwhisk-deploy-kube#535. Here we just create base kind cluster with no OpenWhisk related components installed.
Later the Standalone server is used and configured to connect to this kind cluster (#4671) to run a basic invocation test
Related issue and scope

[ ] I opened an issue to propose and discuss this change (#????)

My changes affect the following components

[ ] API
[ ] Controller
[ ] Message Bus (e.g., Kafka)
[ ] Loadbalancer
[ ] Invoker
[ ] Intrinsic actions (e.g., sequences, conductors)
[ ] Data stores (e.g., CouchDB)
[ ] Tests
[ ] Deployment
[ ] CLI
[ ] General tooling
[ ] Documentation

Types of changes

[ ] Bug fix (generally a non-breaking change which closes an issue).
[ ] Enhancement or new feature (adds new functionality).
[ ] Breaking change (a bug fix or enhancement which changes existing behavior).

Checklist:

[ ] I signed an Apache CLA.
[ ] I reviewed the style guides and followed the recommendations (Travis CI will check :).
[ ] I added tests to cover my changes.
[ ] My changes require further changes to the documentation.
[ ] I updated the documentation where necessary.

Codecov Report

Merging #4689 into master will decrease coverage by 5.93%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #4689      +/-   ##
==========================================
- Coverage   84.42%   78.48%   -5.94%
==========================================
  Files         193      193
  Lines        8711     8711
  Branches      598      598
==========================================
- Hits         7354     6837     -517
- Misses       1357     1874     +517

Impacted Files
Coverage Δ

...core/database/cosmosdb/RxObservableImplicits.scala
0% <0%> (-100%)
:arrow_down:

...ore/database/cosmosdb/cache/CacheInvalidator.scala
0% <0%> (-100%)
:arrow_down:

...core/database/cosmosdb/CosmosDBArtifactStore.scala
0% <0%> (-96.17%)
:arrow_down:

...tabase/cosmosdb/cache/CacheInvalidatorConfig.scala
0% <0%> (-94.74%)
:arrow_down:

...sk/core/database/cosmosdb/CosmosDBViewMapper.scala
0% <0%> (-92.6%)
:arrow_down:

...e/database/cosmosdb/cache/ChangeFeedListener.scala
0% <0%> (-86.67%)
:arrow_down:

...e/database/cosmosdb/cache/KafkaEventProducer.scala
0% <0%> (-76.48%)
:arrow_down:

...whisk/core/database/cosmosdb/CosmosDBSupport.scala
0% <0%> (-74.08%)
:arrow_down:

...a/org/apache/openwhisk/common/ExecutorCloser.scala
0% <0%> (-66.67%)
:arrow_down:

...abase/cosmosdb/CosmosDBArtifactStoreProvider.scala
7.69% <0%> (-50%)
:arrow_down:

... and 8 more

Continue to review full report at Codecov.

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

@dubee sounds to me like a topic for the dev list to discuss. I agree that's a lot more complexity on testing. I do see there are still ways to exclude tests though, just requires a conf file at first glance.

fwiw, it is being successfully excluded in 5 of the 6 tests in the travisci matrix.  For example, see https://travis-ci.org/apache/openwhisk/builds/598015175 where the test only runs in the StandaloneTests entry in the matrix.  Test sets are selected here https://github.com/apache/openwhisk/blob/master/tests/build.gradle#L66-#L120.  Matrix jobs ensure the proper environment variable are set.

I do not understand why users are required to have kubectl, kind, and a Kubernetes cluster just to run tests now.

I have now modified the test to skip run if KUBECONFIG env is not defined as part of changes for #4690. With that these test should not cause the build to fail if local k8s is not running
These tests are needed to ensure local integration testing for KubernetesContainerFactory as so far there was not complete test coverage for KCF mode.