text:
Polish main view

There are some issues with main view, notably:

[x] it sometimes gets too wide causing horizontal scrollbar to appear
[x] there are scaling issues when using layout.css.devPixelsPerPx or changing font size in options
[ ] sources list items have variable height depending on badge existence

while I can reproduce first two problems I still can't figure out the reason

currently font size up to 150% and layout.css.devPixelsPerPx up to 1.5 seem to behave properly, setting layout.css.devPixelsPerPx to 2.0 still breaks (but there's not enough place to fit the layout any way so I think such high values can't be supported)

#18 fix for 1st item list

for future reference: Flexbox' min-height and min-width by default equals to the size of content, to allow it to shrink properly these properties have to be overridden

repo: zakius/Smart-RSS


text:
#23 added SECURITY.md file

Part of https://github.com/zalando-incubator/play-zhewbacca/issues/23

Codecov Report

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

@@           Coverage Diff           @@
##           master      #24   +/-   ##
=======================================
  Coverage   92.85%   92.85%
=======================================
  Files          12       12
  Lines         140      140
  Branches        5        5
=======================================
  Hits          130      130
  Misses         10       10

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 13ef3a7...676cc29. Read the comment docs.

👍

@raychenon , Zappr isn't configured yet, so you need to click "approve" for the request

source: gharchive/pull-request

repo: zalando-incubator/play-zhewbacca

license: MIT

license_type: permissive

license_source: github-api


text:
Topic Support

One-line summary
Adds support for indexing repository topics
Description
This functionality indexes repository topics into a seperate table and creates a n:m relationship between then and the repositories.
This is needed for our display of projects, grouped by their type and audience, next step is the classify all projects and export this data in a grouped format for easy display.
Types of Changes
What types of changes does your code introduce? Keep the ones that apply:

New feature (non-breaking change which adds functionality)
Documentation / non-code

Tasks
List of tasks you will do to complete the PR

[x] Database schema for topics
[x] Github client updates
[x] Part of the automated collection

Review
List of tasks the reviewer must do to review the PR

[ ] Tests
[x] Documentation
[ ] CHANGELOG

Deployment Notes
These should highlight any db migrations, feature toggles, etc.

Please note - this PR depends on #7 being merged beforehand

repo: zalando-incubator/roadblock


text:
Allow numbers after dots in event type name

Allow number after dots in event type name (same as https://nakadi.io/manual.html#definition_EventType*name)

👍

:+1:

authors: ferbncode rcillo

repo: zalando-nakadi/nakadi-ui


text:
Failed to get matching snapshots

Thanks for the library. I have an issue with the latest release

Assertion Failure: MonkeyXCTest.swift:33: Failed to get matching snapshots: Timed out while evaluating UI query.

Here is my setup
func testMonkey() {
    let monkey = Monkey(frame: app.frame)
    monkey.addDefaultUIAutomationActions()
    monkey.addXCTestTapAlertAction(interval: 100, application: app)
    monkey.monkeyAround()
}

Hey there! Is the sample App working for you? Also, are you integrating the library from CocoaPods repository, or are you referencing SwiftMonkey directly from GitHub (master)?

@wojciechczerski Hi, thanks for quick response. I use CocoaPods, and I see it origins from this call addXCTestTapAlertAction

Could you try referencing SwiftMonkey in your Podfile like that:
pod 'SwiftMonkey', :git => 'https://github.com/zalando/SwiftMonkey.git'

I would like to check whether perhaps the existing code on master could solve your issue.

@wojciechczerski ja will try, and also I have this issue which happens only during monkey tests

Failed to determine hittability of Button: Unable to fetch parameterized attribute XC_kAXXCParameterizedAttributeConvertHostedViewPositionFromContext, remote interface does not have this capability.

When you fetch the code from GitHub, could you also try replacing monkey.addDefaultUIAutomationActions  with monkey.addDefaultXCTestPublicActions(app: application)? I know it's not really solving the issue but maybe using XCTest public action could at least get you going while the issue is being solved.

@wojciechczerski seems to work, thanks

@wojciechczerski any news about this issue?
I'm using the GitHub version in my Podfile (currently at 2.1.1), and the matching snapshots failure is still present.
Regarding your suggestion to use monkey.addDefaultXCTestPublicActions(app: application) --
that method does not appear to be available.
Thank you.

@adario Hey there! Is this how your Podfile looks like?
pod 'SwiftMonkey', :git => 'https://github.com/zalando/SwiftMonkey.git'

If the monkey.addDefaultXCTestPublicActions method is not present, perhaps there is some caching issue that's preventing pulling the latest version. In such case you could try deleting the Pods directory and running pod install again.

@wojciechczerski Hey there, thanks for the quick reply —
yes, my Podfile contains the :git statement to locate the pod, so I'm on the latest (I assume: pod install reports version 2.1.1).
The method is indeed missing: I've looked at the sources, and couldn't find it.

Have you tried deleting the Pods directory so that SwiftMonkey gets reinstalled. Another thing to try could be to delete Podfile.lock. Alternatively, just to be sure you are getting the lastest sources, you could try adding this to your Podfile (as a test):
pod 'SwiftMonkey', :git => 'https://github.com/zalando/SwiftMonkey.git', :commit => '68f49bb69381103224b0e77ab615baac8b1fd750'

Please let me know whether that helps.

@wojciechczerski adding the commit ID in the Podfile (after manually removing Podfile.lock and Pods) seems to work — that is, the addDefaultXCTestPublicActions method is now visible...
Is the method supposed to work on actual devices, or only on the simulator?
Thank you.

It looks like the public actions do work on actual devices — cool!
Is it possible to add extra actions besides tap, press and drag?
Thank you.

Glad to hear it worked for you! As for adding extra actions - I am not sure. SwiftMonkey used to support quite a lot of actions, this was however possible due to usage of private APIs. These APIs do not exist anymore therefore public XCTest actions are used. Maybe it would be possible to combine these actions to simulate a pinch or rotate gestures, but I haven't checked that yet (it's still on my TODO).

@wojciechczerski I've tried adding public XCTest actions for swipe and rotate: unfortunately, they're not very useful.  That is, they are executed correctly, as well as shown by MonkeyPaws, but since they're run via the application XCUIElement instead of XCUICoordinate, they don't produce the expected results because of truly counterintuitive locations...
For instance, the rotate gesture is applied to the edges of the screen, instead of around the center of the screen, which obviously results in no rotation at all.  Conversely, the swipe gestures are applied around the screen center, instead of from the screen edges.

source: gharchive/issue

authors: adario onmyway133 wojciechczerski

repo: zalando/SwiftMonkey


text:
Add support for norway, "no" locale

[x] Updated config for separator
[x] Updated config for positions
[x] Added test

@grassator Should I update package json as well?

repo: zalando/banknote

license: mit

license_source: bigquery


text:
Issue with Boolean types in code generated by swagger-codegen

Here is a minimal (non-)working example needed to reproduce this issue.
test.yml:
---
swagger: '2.0'

info:
    version: '0'
    title: 'Boolean Test'

paths:
    /test:
        get:
            description: A test endpoint.
            parameters:
                - name: truthiness
                  in: query
                  description: A test parameter.
                  type: boolean
                  default: true
            responses:
                204:
                    description: Do some magic.

Process this file via swagger-codegen:
java -jar /usr/local/Cellar/swagger-codegen/2.1.5/libexec/swagger-codegen-cli.jar generate -i ./test.yml -l python-flask -o .
Here is the resulting swagger.yml:
---
swagger: "2.0"
info:
  version: "0"
  title: "Boolean Test"
paths:
  /test:
    get:
      tags:
      - "default_controller"
      description: "A test endpoint."
      operationId: "controllers.default_controller.test_get"
      parameters:
      - name: "truthiness"
        in: "query"
        description: "A test parameter."
        required: false
        type: "boolean"
        default: true
      responses:
        204:
          description: "Do some magic."
definitions: {}

Running this with python app.py results in the following error:
Traceback (most recent call last):
  File "~/.virtualenvs/swagger/lib/python3.5/site-packages/connexion/decorators/validation.py", line 75, in validate_type
    return make_type(value, param_type)
  File "~/.virtualenvs/swagger/lib/python3.5/site-packages/connexion/decorators/validation.py", line 53, in make_type
    return type_func(value)
  File "~/.virtualenvs/swagger/lib/python3.5/site-packages/connexion/utils.py", line 135, in boolean
    raise ValueError('Invalid boolean value')
ValueError: Invalid boolean value

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "~/.virtualenvs/swagger/lib/python3.5/site-packages/connexion/operation.py", line 118, in validate_defaults
    validation.validate_type(param, param['default'], 'query', param['name'])
  File "~/.virtualenvs/swagger/lib/python3.5/site-packages/connexion/decorators/validation.py", line 77, in validate_type
    raise TypeValidationError(param_type, parameter_type, parameter_name)
connexion.decorators.validation.TypeValidationError: Wrong type, expected 'boolean' for query parameter 'truthiness'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "app.py", line 8, in <module>
    app.add_api('swagger.yaml', arguments={'title': ''})
  File "~/.virtualenvs/swagger/lib/python3.5/site-packages/connexion/app.py", line 123, in add_api
    validate_responses=validate_responses)
  File "~/.virtualenvs/swagger/lib/python3.5/site-packages/connexion/api.py", line 95, in __init__
    self.add_paths()
  File "~/.virtualenvs/swagger/lib/python3.5/site-packages/connexion/api.py", line 136, in add_paths
    self.add_operation(method, path, endpoint)
  File "~/.virtualenvs/swagger/lib/python3.5/site-packages/connexion/api.py", line 117, in add_operation
    validate_responses=self.validate_responses, resolver=self.resolver)
  File "~/.virtualenvs/swagger/lib/python3.5/site-packages/connexion/operation.py", line 103, in __init__
    self.validate_defaults()
  File "~/.virtualenvs/swagger/lib/python3.5/site-packages/connexion/operation.py", line 122, in validate_defaults
    param_type=param['type']))
connexion.exceptions.InvalidSpecification: <InvalidSpecification: The parameter 'truthiness' has a default value which is not of type 'boolean'>

Manually changing boolean in swagger.yml to bool or Boolean causes the script to run without error, but then the datatype in the Swagger UI is incorrect:

Finally, changing boolean to bool or Boolean in the original test.yml causes the following error with swagger-codegen:
reading from ./test.yml
[main] INFO io.swagger.codegen.DefaultCodegen - generated operationId testGet	for Path: get /test
[main] WARN io.swagger.codegen.DefaultCodegen - Type is NULL for Serializable Parameter: io.swagger.models.parameters.QueryParameter@795a5d7b
[main] WARN io.swagger.codegen.DefaultCodegen - warning!  Property type "null" not found for parameter "truthiness", using String
writing file ./swagger/swagger.yaml
writing file ./app.py
writing file ./README.md

I was also going to open an issue with swagger-codegen, but given the fact that altering the name of the type messes up its representation in the Swagger UI indicates to me that the problem is likely on connexion's end.

@scolby33 thanks for the bug report, we'll look into it (apparently @rafaelcaricio will tackle it)..

I was investigating on this issue and I found out that the default property should be "true" (with quotes) in your fist example and then it would work. But I tried to run locally to reproduce the fix, but I did not worked. So I dig into more on that issue...
I found out that the Swagger model converts the default property to a native boolean value. And since the Connexion Codegen simply serializes the swagger definition to yml to be used when running the app by Connexion it breaks.
If you change the generated yml default value to "true" (with quotes) it works.
I guess that is a major issue in all generators that output swagger definitions like that.

Giving a second thought on it. Maybe an option to make Connexion accept literal boolean values and not only string boolean values as default value.

Yes, we should update Connexion (ref. https://github.com/swagger-api/swagger-core/issues/1368)

I can confirm that placing quotes around the default values fixes the issue.
Is the issue that YAML expects that Boolean values are quoted? Here in the spec, it seems that Booleans can be true or false, without quotes. This is matched in the Ansible documentation (scroll down a bit), which was the first place I could find an example with a Boolean value in YAML. Both of these sources seem to indicate that no quotes should be required.
I'm also confused as to why default: "true" is necessary, but required: true works just fine. Whatever YAML parser is being used chokes on Booleans only sometimes?

Yes, I searched further and we should accept in Connexion the true literal. I am working on it right now.

Oh, I see we commented at the same time. Thanks for the update!

@scolby33 the fix was released in https://github.com/zalando/connexion/releases/tag/1.0.49
Can you verify that it works for you? Thanks!

Everything looks good! Thank you for your quick response and fix for this issue.

authors: hjacobs rafaelcaricio scolby33

repo: zalando/connexion


text:
Add automatic status code sending

If a swagger method has one specified 200-299 status code in it's swagger specification, it would be nice if connexion automatically returned this status code e.g. if the specification contained:
delete:
    operationId: delete
    responses:
    '204':
        description: Succeeded, no response
    default:
        description: Error
        schema:
        $ref: "#/definitions/Error"

The handler for this:
def delete():
    delete_something()

should result in a 204 status code being sent

I think this is a reasonable idea, not sure how many cases this will match, but delete is certainly one of the common ones.

authors: ThomasHickman hjacobs


text:
Deep six the six module

Fixes # .

https://six.readthedocs.io#six.reraise
https://six.readthedocs.io#six.iteritems

Changes proposed in this pull request:

Coverage remained the same at 97.145% when pulling ee38dbffa842b02734da83f0ada1dbd4ed243415 on cclauss:deep-six into f46551cee8056dca65c1177e8252f19805d95d50 on zalando:main.

authors: cclauss coveralls


text:
More sources

The script should use more sources, for example uBlock Origin also comes with [EasyPrivacy] (https://easylist-downloads.adblockplus.org/easyprivacy.txt) and in my opinion also [Fanboy’s Enhanced Tracking List] (https://www.fanboy.co.nz/enhancedstats.txt) should be included
Also, I'd like to see an optional version with [Fanboy’s Annoyance List] (https://easylist-downloads.adblockplus.org/fanboy-annoyance.txt) and [Anti-ThirdpartySocial] (https://www.fanboy.co.nz/fanboy-antifacebook.txt) list to get rid of social media plugins.
My other suggestions:

Spam404: https://spam404bl.com/spam404scamlist.txt
Basic tracking list by Disconnect: https://s3.amazonaws.com/lists.disconnect.me/simple_tracking.txt
Malvertising filter list by Disconnect: https://s3.amazonaws.com/lists.disconnect.me/simple_malvertising.txt
Adblock Warning Removal List: https://easylist-downloads.adblockplus.org/antiadblockfilters.txt
And maybe 'EU: Prebake - Filter Obtrusive Cookie Notices' for the users in EU: https://github.com/liamja/Prebake

Except Disconnect, the lists that you mention are for Adblock Plus and uBlock. I can't add them because they are incompatible with the hosts file, which only supports domain names.

@zant95 Sorry, I wasn't aware of that. I thought that there were also domains in those filter lists.


text:
[Migrated] zappa init

Originally from: https://github.com/Miserlou/Zappa/issues/1042 by skaviani

Context
i am trying to deply kodi-alexa skill and getting a bizarre error mesage. talked to guys in kodi-alexa skills and they said this might be an error in Zappa.
i am using python27 and ot sure what zappa version i am using as i am new in this enviroment.
using zappa in virtual enviroment.

Expected Behavior

Actual Behavior

Possible Fix

Steps to Reproduce

1.pip install awscli
2.aws configure
3.pip install virtualenv
4.git clone https://github.com/m0ngr31/kodi-alexa.git
5.cd kodi-alexa
6.virtualenv venv
7.venv\Scripts\activate.bat
8.pip install -r requirements.txt
9.pip install packaging
10.pip install zappa
11.created the file kodi.config
an this point when i type zappa init
███████╗ █████╗ ██████╗ ██████╗  █████╗
╚══███╔╝██╔══██╗██╔══██╗██╔══██╗██╔══██╗
███╔╝ ███████║██████╔╝██████╔╝███████║
███╔╝  ██╔══██║██╔═══╝ ██╔═══╝ ██╔══██║
███████╗██║  ██║██║     ██║     ██║  ██║
╚══════╝╚═╝  ╚═╝╚═╝     ╚═╝     ╚═╝  ╚═╝
Welcome to Zappa!
Zappa is a system for running server-less Python web applications on AWS Lambda and AWS API Gateway.
This init command will help you create and configure your new Zappa deployment.
Let's get started!
Your Zappa configuration can support multiple production stages, like 'dev', 'staging', and 'production'.
What do you want to call this environment (default 'dev'):
AWS Lambda and API Gateway are only available in certain regions. Let's check to make sure you have a profile set up in one that will work.
Okay, using profile default!
Your Zappa deployments will need to be uploaded to a private S3 bucket.
If you don't have a bucket yet, we'll create one for you too.
What do you want call your bucket? (default 'zappa-3fj5iaoad'):
It looks like this is a Flask application.
Oh no! An error occurred! :(
==============
Traceback (most recent call last):
File "c:\kodi\venv\lib\site-packages\zappa\cli.py", line 2489, in handle
sys.exit(cli.handle())
File "c:\kodi\venv\lib\site-packages\zappa\cli.py", line 444, in handle
self.init()
File "c:\kodi\venv\lib\site-packages\zappa\cli.py", line 1506, in init
matches = detect_flask_apps()
File "c:\kodi\venv\lib\site-packages\zappa\utilities.py", line 143, in detect_flask_apps
lines = f.readlines()
File "c:\kodi\venv\lib\encodings\cp1252.py", line 23, in decode
return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x81 in position 301: character maps to
==============
Need help? Found a bug? Let us know! :D
File bug reports on GitHub here: https://github.com/Miserlou/Zappa
And join our Slack channel here: https://slack.zappa.io
Love!,
~ Team Zappa!
Your Environment

Zappa version used:
Operating System and Python version:
The output of pip freeze:
Link to your project (optional):
Your zappa_settings.py:

old migrated issue, considered resolved.
closing.

authors: jneves monkut

repo: zappa/Zappa


text:
Release 0.11 with Python 3.11 support

Opening this for planning around the next release.
closes: #397

@jakirkham : I updated the title with the hope that it will catch new-issue-creators.

Would like to schedule this for Dec 15 (Thursday). That way if any issues pop up that need a quick fix, there should be some time Friday (or maybe early next week?). Guessing folks will start taking off for the holidays very soon after. Thoughts?
cc @MSanKeys963

Sounds like a plan to me, @jakirkham. 👍🏻
Do you also want me to announce this at next Wednesday's community meeting?

Yeah think that is a good idea

Have tagged the release! 🚀 Artifacts should start be produced shortly 📦

authors: MSanKeys963 jakirkham joshmoore

repo: zarr-developers/numcodecs


text:
Mapp 1.1.1 (similar to 1.1) to autobuild

Mapp 1.1.1 (similar to 1.1) to autobuild Fixes #97

Local build passed but in the nick of time.
However, if upon PR merge the CI runs both local and remote build 30min would not be enough...
I would adjust to" travis wait 60 in the CI YAML...

So, can you then please push the change here first (this branch)?

Done. Once these checks pass it is ready to merge.

@fgypas: could you please merge this PR?

authors: AngryMaciek fgypas

repo: zavolanlab/Dockerfiles


text:
k3s vs k8s versioning

with CAPA, you need to pass a k8s version string like 1.21.5, while with cluster-api-k3s you need to pass the full qualified version including the k3s revision, like v1.21.5+k3s2.
This breaks the automatic AMI image lookup logic and requires you fiddle with the imageLookupFormat or to add an explicit ami ID (which depends on a region).
Example:
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: KThreesControlPlane
metadata:
  name: k3-test-13-control-plane
spec:
  version: v1.21.5+k3s2
...
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: AWSCluster
metadata:
  name: k3-test-13
spec:
  controlPlaneLoadBalancer:
    healthCheckProtocol: TCP
  imageLookupBaseOS: ubuntu-20.04
  imageLookupFormat: capa-ami-{{.BaseOS}}-1.21.5-*
...

I wonder if there is a more ergonomic way to use cluster-api-k3s.

Does it even make sense to use capa-ami-..... images to run k3s? These images have been tested and tuned for kubeadm based k8s, but doesn't necessarily mean k3s would benefit from that.
should cluster-api-k3s autodiscover the latest k3s revision (and offer the possibility to pin one if the user wants?)
should we just document how to use imageLookupOrg and imageLookupFilter to find a generic ubuntu image?
does k3s come with its own blessed AMIs?

should we just document how to use imageLookupOrg and imageLookupFilter to find a generic ubuntu image?

I successfully used this to find a working image on multiple regions using a canonical ubuntu image:
      imageLookupOrg: '099720109477'
      imageLookupFormat: 'ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*'

Does it even make sense to use capa-ami-..... images to run k3s? These images have been tested and tuned for kubeadm based k8s, but doesn't necessarily mean k3s would benefit from that.
I don't think so. The configuration for those amis lives in image builder. It is very tied to the kubeadm capi usage.
To make the usage more ergonomic, we would probably need to follow a similar pattern and start publishing k3s amis.
should cluster-api-k3s autodiscover the latest k3s revision (and offer the possibility to pin one if the user wants?)
I think the problem with this is mainly that there is no guarantee that cluster-api-k3s supports the latest k3s version. As you can see with your issue about 1.23 there is always the possibility of a breaking change.
So the solution would to be keep some mapping of the latest version that cluster-api-k3s supports in the code, which kind of defeats the purpose of "latest".
Even cluster-api has a similar weird relationship to kubernetes version.  I think the crux of the issue is that you have the two following inputs:

the kubernetes version on the cluster-api CRs.
the image/ami that you input to the infra provider.

With k3s it's easy to just use a vanilla ubuntu ami, but for kubeadm there is more that needs to be setup it. Because of this, you need a image/ami that aligns with your intended k8s version.
Most infrastructure providers have some sort of path to get a default cluster up if you only pass the kubernetes version to cluster-api, but it relies on them taking assumptions about the capi amis.

should we just document how to use imageLookupOrg and imageLookupFilter to find a generic ubuntu image?
Good Idea.

authors: mkmik zawachte


text:
Syntax error when launching any test files

Hello,
I have Cozmo with last update. Windows 10 , PyCozmo 0.2.0 with Python 3.5.4
I have installed Python on its charging platform.
I have rised and lowered his lift for discovering its key.
I'm connecting on Cozmo WIFI point via PC.
Steps :
1 Open commandline console
2. >pip install pycozmo
3. >python display.py
C:\dev\cozmo\pycozmo\examples>python display.py
Traceback (most recent call last):
File "display.py", line 5, in
import pycozmo
File "C:\Users\didie\AppData\Local\Programs\Python\Python35\lib\site-packages\pycozmo_init_.py", line 3, in
from .client import ROBOT_ADDR, Client
File "C:\Users\didie\AppData\Local\Programs\Python\Python35\lib\site-packages\pycozmo\client.py", line 105
self.sock: socket.socket = sock
^
SyntaxError: invalid syntax

OK, you are right. This is syntax that is not suppoted in Python 3.5 and I have been developing Python with 3.7.
Lucklily, this is not really necessary, so I fixed it with ef5df564
I'll set up automated tests with different Python versions soon.
Thanks!

Added automated tests with e9928fc .

authors: CozmoCyke zayfod

repo: zayfod/pycozmo


text:
User story: Have an overview of what's going on in the SemTec team

As a researcher visiting the pages of the SemTec team, I want to get an overview of what's going on there in terms of: projects and results.
For this we need to create a folder structure under the docs folder (the one used by the pages) as follows:

Projects
Datasets
Software
Vocabularies
People
Collaborations

These should be actual subfolders, please create them and for each add an empty md file with the same name as the subfolder.
Note: This cannot be done via configuration as you did, it has to be actual subfolders and file.
Thanks


text:
[#621] Add state property to SDKSynchronizer

Closes #621
This code review checklist is intended to serve as a starting point for the author and reviewer, although it may not be appropriate for all types of changes (e.g. fixing a spelling typo in documentation).  For more in-depth discussion of how we think about code review, please see Code Review Guidelines.
Author

[x] Self-review: Did you review your own code in GitHub's web interface? Code often looks different when reviewing the diff in a browser, making it easier to spot potential bugs.
[ ] Automated tests: Did you add appropriate automated tests for any code changes?
[ ] Code coverage: Did you check the code coverage report for the automated tests?  While we are not looking for perfect coverage, the tool can point out potential cases that have been missed.
[ ] Documentation: Did you update Docs as appropiate? (E.g README.md, etc.)
[x] Run the app: Did you run the app and try the changes?
[ ] Did you provide Screenshots of what the App looks like before and after your changes as part of the description of this PR? (only applicable to UI Changes)
[x] Rebase and squash: Did you pull in the latest changes from the main branch and squash your commits before assigning a reviewer? Having your code up to date and squashed will make it easier for others to review. Use best judgement when squashing commits, as some changes (such as refactoring) might be easier to review as a separate commit.

Reviewer

[ ] Checklist review: Did you go through the code with the Code Review Guidelines checklist?
[ ] Ad hoc review: Did you perform an ad hoc review?  In addition to a first pass using the code review guidelines, do a second pass using your best judgement and experience which may identify additional questions or comments. Research shows that code review is most effective when done in multiple passes, where reviewers look for different things through each pass.
[ ] Automated tests: Did you review the automated tests?
[ ] Manual tests: Did you review the manual tests?You will find manual testing guidelines under our manual testing section
[ ] How is Code Coverage affected by this PR? We encourage you to compare coverage befor and after your changes and when possible, leave it in a better place. Learn More...
[ ] Documentation: Did you review Docs, README.md, LICENSE.md, and Architecture.md as appropriate?
[ ] Run the app: Did you run the app and try the changes? While the CI server runs the app to look for build failures or crashes, humans running the app are more likely to notice unexpected log messages, UI inconsistencies, or bad output data.

Implemented in #624

repo: zcash/ZcashLightClientKit


text:
Mempool tx.Hash nil pointer dereference in frontend/service.go:480

What is the bug?
lightwalletd crashed a few times. Restarting seems to get it going again and it's running again for now.
This is on mainnet with the debian 5.1.0 release of zcashd and db2795aad7043fb226bbf579aee29633583990ef version of lightwalletd.
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x38 pc=0xa1009c]

goroutine 133 [running]:
github.com/zcash/lightwalletd/frontend.(*lwdStreamer).GetMempoolTx(0xc00000f7a0, 0xc000d86500, {0xd513e0, 0xc0002688f0})
	free2z/zcash/lightwalletd/frontend/service.go:480 +0x3fc
github.com/zcash/lightwalletd/walletrpc._CompactTxStreamer_GetMempoolTx_Handler({0xb51a00, 0xc0014f1340}, {0xd4de80, 0xc00000f7a0})
	free2z/zcash/lightwalletd/walletrpc/service_grpc.pb.go:632 +0xd0
github.com/grpc-ecosystem/go-grpc-prometheus.(*ServerMetrics).StreamServerInterceptor.func1({0xb51a00, 0xc0014f1340}, {0xd4dfa0, 0xc00024a5b0}, 0x8, 0xc85fb0)
	go/pkg/mod/github.com/grpc-ecosystem/go-grpc-prometheus@v1.2.0/server_metrics.go:121 +0x109
github.com/grpc-ecosystem/go-grpc-middleware.ChainStreamServer.func1.1.1({0xb51a00, 0xc0014f1340}, {0xd4dfa0, 0xc00024a5b0})
	go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware@v1.3.0/chain.go:49 +0x3a
github.com/grpc-ecosystem/go-grpc-middleware.ChainStreamServer.func1({0xb51a00, 0xc0014f1340}, {0xd4dfa0, 0xc00024a5b0}, 0xa5eae0, 0xc0002688e0)
	go/pkg/mod/github.com/grpc-ecosystem/go-grpc-middleware@v1.3.0/chain.go:58 +0xbf
google.golang.org/grpc.(*Server).processStreamingRPC(0xc000238540, {0xd54568, 0xc000285a00}, 0xc000263b00, 0xc0002a3170, 0x11f2c00, 0x0)
	go/pkg/mod/google.golang.org/grpc@v1.47.0/server.go:1549 +0xe8e
google.golang.org/grpc.(*Server).handleStream(0xc000238540, {0xd54568, 0xc000285a00}, 0xc000263b00, 0x0)
	go/pkg/mod/google.golang.org/grpc@v1.47.0/server.go:1624 +0x9e5
google.golang.org/grpc.(*Server).serveStreams.func1.2()
	go/pkg/mod/google.golang.org/grpc@v1.47.0/server.go:922 +0x98
created by google.golang.org/grpc.(*Server).serveStreams.func1
	go/pkg/mod/google.golang.org/grpc@v1.47.0/server.go:920 +0x294

I haven't looked into it yet but it's the tx.Hash in:
	for _, txid := range MempoolFilter(mempoolList, excludeHex) {
		tx := (*mempoolMap)[txid]
		if len(tx.Hash) > 0 {

happened again, I think that makes 5 times in about an hour after not happening for 24 hours ... zcashd seems to be running fine .. although some logging I'm not familiar with happened at the same time
2022-07-11T03:30:41.503203Z  INFO main: keypool reserve 1
2022-07-11T03:30:41.503255Z  INFO main: keypool return 1
2022-07-11T03:30:48.750634Z  INFO main: keypool reserve 1
2022-07-11T03:30:48.750699Z  INFO main: keypool return 1

Thanks for the report! This will be fixed by #403, awaiting review. The failure isn't exactly dereferencing a nil pointer, it's indexing a Go map using a nonexistent key. We should have this fixed within a few days.
While investigating this problem, I discovered that this gRPC, GetMempoolTx, isn't returning any entries at all. This will be fixed by #404.

authors: LarryRuane skyl

repo: zcash/lightwalletd


text:
Design: App Update Dialog

In order to implement zcash/zcash-android-wallet-sdk#211, we need a design for the app update dialog.  Because this dialog will be implemented on top of Google Play's app update API, we'll have limited information.  Basically, we'll know an "urgency" value of the update and can decide whether to force the update or allow a user to keep using their current version.
https://developer.android.com/guide/playcore/in-app-updates

The ping for an update could be received a half minute or so into a session (or even later) so assume the screen is already populated. AKA modal solution?

I would imagine using the "urgency" value to select one of two screens. There is an edge case here where if they never did a backup (assuming this is possible) we would want to force them to do that flow first.

Thanks @geffenz for the designs. Yes, the proposed solution with a link to the Play store is a good way to provide more information about changes in the new version and also it's very easy to implement. Users can also update our app from Google Play store right away, if they prefer to.

Small tweaks apply.

@geffenz Thank you, looks good to me. Just one comment on it. We can place the blue link to Google Play Store to both versions of the update screen (available x required). Imho it can be useful on both screens, what do you think?

Absolutely! The only real difference should be whether or not the action is forced. Please!

authors: HonzaR ccjernigan geffenz

repo: zcash/secant-android-wallet


text:
No completion after typing a dot...

See this small screencast:

I would expect that after typing the dot, it should suggest completions. But it doesn't do that till after typing the second character after the dot.

@svanharmelen Hi :)
I try to debug this, Could you post init.vim and this go file?

@zchee when trying to create a minimal init.vim I failed to reproduce the issue. Tried my normal init.vim again and it now works as expected (without any changes). Strange... But all seems to working as expected :grin:

Uuh... I just had it again. You should be able to reproduce this very easily by copying the code below:
package main

import "net"

func main() {
  n1 := &net.IPNet{}
  n1.
}

It turns out that this problem is related to the name of the variable. As you can see, the variable name ends with a number (the digit 1), which seems to cause this.
So maybe this is due to the regex used to match the pattern? Looking at that one...

Yep... It's the regex: '[^. \t0-9]\.\w*'
I'll make a PR with a fix in a moment.

Fixed by PR #31

Thanks!
I don't know the go language specification.
Go language cannot call the functions like them?
'string'.foo()
['hoge'].object()

@Shougo can't call either.

@nhooyr you are correct about the former, but not latter: https://play.golang.org/p/zwEMuC1ulm

@mmlb ['hoge'] is different from m["1"]

Oeps! The regex is for matching all valid identifiers (for packages, types and variables), but indeed I totally forgot about using the dot to invoke something on the return value of a func or index operation.
Have a meeting first, but will update the regex after that. The update in PR #34 fixes one use case, but it's not complete...

@svanharmelen definitely.

@nhooyr indeed, was mostly making a mis-worded statement on having to handle index returns.

authors: Shougo mmlb nhooyr svanharmelen zchee

repo: zchee/deoplete-go


text:
Handle up/down normals when drawing a circle

When using Vector3.up or Vector3.down as the normal for GizmosPlus.Circle(), the circle gets draw incorrectly with a radius of 0. This happens because the calculation for getting the component up and left vectors for the circle is done by taking the cross product of the normal and Vector3.up, and taking the cross product of two parallel vectors returns the zero vector.
To handle this, I've added an extra check for the case where the calculated left vector is zero and have the drawing logic use Vector3.left and Vector3.forward as the component vectors to ensure that the circle draws correctly in the X-Z plane.

I also noticed that GizmosPlus.Arrow() had the same issue, causing the head to not draw correctly for a vertical up/down normal. I've updated the pull request to catch all other cases where this issue came up, which seems to just be Arrow() and Rectangle().

Thanks for the PR! Looks good!

authors: randomPoison zchfvy

repo: zchfvy/GizmosPlus


text:
关于实验结果指标不正常

作者，您好，我使用您的代码进行实验结果复现，感觉实验结果始终与您的结果有所差距，想请教您是不是github上的代码与您的代码有区别，还是有哪些参数需要调整？

您好，github上的代码和实验代码是一致的。请问您是用几卡跑的呢，虽然在RL阶段会有波动，但不至于这么低。您可以参考下这个issue #2 ，看下在setting上时候有不同

您好，github上的代码和实验代码是一致的。请问您是用几卡跑的呢，虽然在RL阶段会有波动，但不至于这么低。您可以参考 #2 ，看下在setting上时候有不同
作者，您好，我采用torch版本与您提供的一致，我用的是双卡跑的，另外我将伪区域的个数改为6和7，发现实验结果虽然没有达到标准分数，但是都优于num=5的时候，我想请教您是为什么，是因为我的卡的问题吗/(ㄒoㄒ)/~~

您好，我是用8卡V100跑的，可能在训练过程中确实会有点影响。您可以适当调整一下batch_size和学习率，跑多次尝试下

您好，我是用8卡V100跑的，可能在训练过程中确实会有点影响。您可以适当调整一下batch_size和学习率，跑多次尝试下

作者您好，我看到您论文里面是说强化学习是采用固定的学习率5e-7?

但是我在代码里面时看到是5e-6,并且也有一个衰减过程，并不是固定的，我想问下哪个是正确的？

您好，前段时间太忙没能及时回复。可以设置为5e-6，这是我在整理代码后重新训练模型时的学习率，得到的结果会更好一点(133.7 CIDEr score)

authors: hzf-hhh zchoi


text:
tgbot 通知成功不了!

企业微可以成功
但是 tg 一直不成功!

有同样问题的朋友吗?

可以了

可以了

repo: zdz/ServerStatus-Rust


text:
track as label git_hash instead of git-commit

git_commit is a regular CI variable and as result we track as a label sha1 of the test project code. This particular knowledge is not so popular because in test automation multi-branching is a common and if no changes in the app then no commits in the TA code.
Let's adjust extra labels registration here: https://github.com/zebrunner/carina/blob/7631305df2a891d8d439de85f734e2b2ac75db3b/carina-core/src/main/java/com/qaprosoft/carina/core/foundation/listeners/CarinaListener.java#L228

rename everywhere including documentation git_commit -> git_hash
extra sha1 label should be registered only if git_hash is not empty
remove completely "branch" label registration and GIT_BRANCH parameter

done. changes are available in 7.3.15-SNAPSHOT. no need to do extra testing

repo: zebrunner/carina


text:
Return Test suite title how it was before

Issue on jenkins side for Test jobs:
How it was: iOS NEW AA Diary Test [project-ios-21.4.0-[XXX].ipa]
Now: iOS AA Diary Test
Need to return back how it was before

already fixed by carina and reporting changes

authors: okamara vdelendik

repo: zebrunner/zebrunner


text:
feat: allow setting custom environment to brokers

Description
Adds value env which allows users to set custom environment variables on the Zeebe broker pods. The variables should be specified in the raw, standard YAML as expected by Kubernetes.
Closes #44

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: npepinpe
If they are not already assigned, you can assign the PR to them by writing /assign @npepinpe in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/ok-to-test

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Zelldon
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Zelldon]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

authors: npepinpe salaboy

repo: zeebe-io/zeebe-cluster-helm


text:
WIP: German Translation

I will translate the original README paragraph by paragraph. Feel free to join in if you speak German.
I would recommend a Sqaush merge later to get rid of the temporary English used as a reference.

Hey!
I am happy to help with the german translation.

There are a lot of thins in English

@m1key-d1ce feel free to join. I copied the english version and started to translate it top down. Simply push to my branch and it will update this PR.

@Toxantron @m1key-d1ce That is a good idea!

Hey, I'd like to take this over. However, I'm still new to this - I've already started translating the readme.md in a text file on my computer. How do I go on about posting my results when I'm ready?

Because the PR is dead, the current status is here and needs your help https://github.com/bueltge/learn-regex/blob/master/translations/README-de.md

I finished this translation and made a PR to @bueltge 's fork. If you need me to open a separate PR for this repository, tell me

So, thanks a lot to the helping hands of @JohnnyJayJay For now the translation is done and ready for the public readers. Thanks a lot for this great how-to. @ziishaned It would be fine if you merge them so that other people with background German language have the chance to read them. Best!

@bueltge can you please open a new PR with your fork because this PR still has lots of English that still needs to be translated

Why not @ziishaned
#212  has the content to get a solid translation. Best.

Thank you all for the contribution as we have a new PR #212 with complete German translation I will close this PR

authors: JohnnyJayJay Toxantron bueltge eamanu elbatpord m1key-d1ce ziishaned

repo: zeeshanu/learn-regex


text:
Add Font Weight option to config

Along with setting the font family and size, there's currently no way to set the font weight without adding custom css. I hope you can support this in the future.

In the meantime, here's a workaround:
termCSS: 'x-row {font-weight: 100}',

Any idea on how to apply it on directory font weight?

I'm also still looking for a way to only apply this on directory font weight..

@matthewconstantine I tried adding font-weight property . But it seems like the hterm package doesn't support font-weight property. Should I overwrite hterm's package set method? Any other way around it? Any suggestion would be appreciated.

termCSS: 'x-row {font-weight: 100}', is deprecated in Hyper 2.1.1 (canary)

Working in 2.0.4 (stable)
termCSS: '.terminal {font-weight: lighter} .terminal .xterm-bold {font-weight: normal}'

Added in #2669.

@brandon93s Thanks!

authors: BobbieGoede IamSwap asthas brandon93s chabou drasbeck kurisubrooks matthewconstantine mingjie-evbg

repo: zeit/hyper


text:
Error: Next in dev yields "cannot read property call of undefined", in production throws an error

macOS 10.12.4
node v7.7.1
npm  v4.1.2
yarn v0.21.3
I'm using "with-react-md" example, and didn't change anything, just yarn install, npm run dev/start.
The error in dev mode is the same as issue 1510
And in production mode, the error is
> next start

Warning: Accessing PropTypes via the main React package is deprecated. Use the prop-types package from npm instead.
module.js:472
    throw err;
    ^
Error: Cannot find module '/Users/ce/Documents/production/alljs/.next/build-stats.json'
    at Function.Module._resolveFilename (module.js:470:15)
    at Function.Module._load (module.js:418:25)
    at Module.require (module.js:498:17)
    at require (internal/module.js:20:19)
    at new Server (/Users/ce/Documents/production/alljs/node_modules/next/dist/server/index.js:104:30)
    at Object.<anonymous> (/Users/ce/Documents/production/alljs/node_modules/next/dist/bin/next-start:48:11)
    at Module._compile (module.js:571:32)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:488:32)
    at tryModuleLoad (module.js:447:12)

@rauchg @arunoda

run "next build" before  "next start"

@reezon Yeah, thank you. npm run build solves the production error, but the dev error still exists.

In dev, just use next

Please follow the tutorial: https://learnnextjs.com/basics/getting-started

authors: arunoda ithinco reezon


text:
Dynamic import cache / HMR

Currently using dynamic imports like so:
const Templates = {
  Type1: dynamic(import('./type1')),
  Type2: dynamic(import('./type2'))
}

export default ({ type, ...props }) => {
  const Component = Templates[type]
  return <Component {...props} />
}

All's been fine for awhile. However, after upgrading to 5.0 it seems like HMR no longer re-fetches the dynamic chunk. It seems hard cached on the server. Reverting to next@^4 fixes the issue.
Is there a way to disable the cache or..?

Very easy to replicate w/ a fresh install:
$ git clone git@github.com:OutThisLife/nextjs-cache-issue.git
$ yarn && yarn dev

Edit test/index.js and see HMR "reload" but not really.

I believe this is also similar to this bug here https://github.com/zeit/next.js/issues/3775
Hope this can be solved soon :(

Definitely related to #3775

Still happening.

authors: OutThisLife brad-decker lolcoolkat


text:
some question with router

I use next's link as matching 127.0.0.1/:id,
i o[en the real route 127.0.0.1/demo still still 127.0.0.1/:id. I then configured the route of 127.0.0.1/demo on the server side to access the current page. Is there a better solution

Seems alright. Please follow the issue template in the future.

authors: Weipengzhou timneutkens


text:
Adding experimental config for public file server example.

Hi,
This might be more of a question and then you can just close this but as far as I can tell you need to add the experimental flag for the public folder to work. If not, feel free to close.
Cheers!

Sorry, but we don't take pull requests against master. This example has been removed from the canary branch!

Ah ok, no worries. So that example is wrong then?

The example was correct but the feature is experimental, so it's not ready for general consumption.
If you're OK with the experimental feature, you can turn it on!

Fair enough, thanks!

I updated the master branch to 9.0.3 which dropped this example 👍

authors: TimPerry Timer


text:
Re-enable "try to create a builds deployments with wrong config" integration test

It was temporarily disabled due to server-side issues, but that has been fixed now.

Codecov Report

Merging #2337 into canary will decrease coverage by <.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           canary    #2337      +/-   ##
==========================================
- Coverage   10.63%   10.63%   -0.01%
==========================================
  Files         247      247
  Lines        9052     9048       -4
  Branches      994      993       -1
==========================================
- Hits          963      962       -1
+ Misses       7979     7976       -3
  Partials      110      110

Impacted Files
Coverage Δ

src/commands/dev/lib/builder-cache.ts
68.86% <0%> (+1.59%)
:arrow_up:

Continue to review full report at Codecov.

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

authors: TooTallNate codecov-io

repo: zeit/now-cli


text:
Nuxt.js Universal / SSR example

Please could you create (or modify the existing) a Nuxt.js example that supports universal mode with SSR.
Thanks

There is no official Nuxt.js builder but there is a Community builder here:
https://github.com/nuxt/now-builder

authors: homerjam styfle

repo: zeit/now


text:
Is there a way to use this with create-react-app without ejecting?

STS

probably you can do something similar to this https://github.com/facebookincubator/create-react-app/blob/master/packages/react-scripts/template/README.md#adding-a-css-preprocessor-sass-less-etc but in your case you'd install babel and styled-jsx to transpile css before starting the app

Yes!

How can you use it with an ejected create-react-app? Please help!
Please answer on StackOverflow, so the answer gets more visibility 👍
https://stackoverflow.com/questions/49156164/add-styled-jsx-to-ejected-create-react-app-config

Just answered my own question above in the stackoverflow link 👍

authors: comerc fabioespinosa giuseppeg stevensacks

repo: zeit/styled-jsx


text:
tag "v1.0" is a invalid module version

It will show a error message "invalid module version v1.0" when use go mod build system, following the Semantic Versioning guid (https://semver.org/) v1.0.0 is a valid one.

Yes, please tag it as v1.0.0, otherwise v0.9.0 is the latest version available (easily) when go mod is used…

Tag v1.0 still invalid version in 2020. Seems like nobody's home

These tags predate the use of semver in the official Go tools, and I'm unwilling to delete git tags. So we're probably stuck with v1.0 forever, unfortunately.
I've just tagged v1.0.1, though, so hopefully things will be better going forward!

Thanks! That’s a perfect solution!

I'm unwilling to delete git tags.

Perfect! :)
Simply creating another tag named v1.0.0 would work, but v1.0.1 is even better, thank you 🙌🏻.

authors: gbbr hollomyfoolish meeDamian zenazn

repo: zenazn/goji


text:
MessageTrait::setHeaders looses original header name casing.

According to the PSR-7 MessageInterface - Case-insensitive header field names, it states:

Despite that headers may be retrieved case-insensitively, the original case
MUST be preserved by the implementation, in particular when retrieved with
getHeaders().

However, the \Zend\Diactoros\MessageTrait::setHeaders method at Line 327 is performing a strtolower on each header name before writing the headers array to to the headers protected variable. In doing so, the original header names' case is lost, which appears to be in violation of PSR-7. If this is a violation and to be corrected, it will require changes to other header related methods as they are all assuming the normalization to lowercase for the names has been completed when accessing the headers variable.

@rbchasesc

…before writing the headers array to to the headers protected variable.

Sorry, this is wrong. Look at the next line:
https://github.com/zendframework/zend-diactoros/blob/bb833f8e92297be103bf6cd3fc25219474bbf0d0/src/MessageTrait.php#L327-L328
$headerNames !== $headers
See also:
https://github.com/zendframework/zend-diactoros/blob/bb833f8e92297be103bf6cd3fc25219474bbf0d0/src/MessageTrait.php#L20-L32

As @froschdesign notes, we do keep track of the original casing, and that casing is used when emitting or serializing headers. We normalize the names in $headers to allow simplified lookups, but store the originally provided values in $headerNames, which is used for representation.

authors: froschdesign rbchasesc weierophinney

repo: zendframework/zend-diactoros


text:
How to get route result in action factory?

I am trying to create CRUD application using zend-expressive. My idea is to have default crud routes and if some entity needs non-default dependencies, it could be overriden.
'routes' => [
    'crud.add' => [ // default entites have default factory
        'name' => 'crud.add',
        'path' => '/crud/:entity/add',
        'middleware' => App\Action\CrudAddAction::class,
        'allowed_methods' => ['GET', 'POST'],
    ],
    'crud.add.article' => [ // articles have own factory
        'name' => 'crud.add.article',
        'path' => '/crud/article/add',
        'middleware' => App\Action\ArticleAddAction::class,
        'allowed_methods' => ['GET', 'POST'],
    ],
],

And the problem is, how could I grab entity name (from route result) in default action factory? If I have entity name I can get dependencies from container and inject them into CrudAddAction constructor.

I don't think this is possible without hacking expressive. The RouteResult is not available in the factory. You can get it only from the request. Solutions I can think of:

Hack the expressive-router, store the RouteResult in the match method and add a getRouteResult method to retrieve it.
Retrieve the RouteResult from the URLHelper, but you need to override that class and make getRouteResult() a public method.
(really really bad solution) Inject the container inside the default action and get the dependencies there. No hacking required.

Maybe there are better solutions, but if not I would go for option 2.

@xtreamwayz thx for your points. I have same opinion that option 2 is the best one.

I'd go with option 3, it is not so bad if you test it properly, and it's way better than relying on stateful service (option 2). Also, make sure to handle ServiceNotFound exception case. :)

@danizord option 3 is practically deprecated ServiceLocatorAwareInterface.
@xtreamwayz and option 4 - to create smth like RouteResultHelper and its middleware (simplified copy of UrlHelper). Done without inheriting UrlHelper.
Question is - how much cool is to rely on stateful service as @danizord mentioned.

Please do not do this: factories are pre-dispatch context, they do not know anything at all about the current request, and that for good reasons. If you need to build something aware of the current request, then make sure it is used and garbage-collected inside the action itself.
final class RouteRepositoryResolver implements RouteRepositoryResolverInterface
{
    public function getRepositoryFor(RouteResult $routingResult) : RepositoryInterface
    {
        // take decisions here...
    }
}

final class CrudPostFactory
{
    public function __invoke(ContainerInterface $container)
    {
         return new CrudPost($container->get(RouteRepositoryResolver::class)
    }
}

Now you can use CrudPost for any route:
'routes' => [
    'crud.list' => [
        'name' => 'crud.list',
        'path' => '/crud/:entity',
        'middleware' => CrudList::class,
        'allowed_methods' => ['GET'],
    ],
    'crud.get' => [
        'name' => 'crud.get',
        'path' => '/crud/:entity/:id',
        'middleware' => CrudGet::class,
        'allowed_methods' => ['GET'],
    ],
    'crud.post' => [
        'name' => 'crud.add',
        'path' => '/crud/:entity',
        'middleware' => CrudPost::class,
        'allowed_methods' => ['POST'],
    ],
    'crud.delete' => [
        'name' => 'crud.remove',
        'path' => '/crud/:entity',
        'middleware' => CrudPost::class,
        'allowed_methods' => ['DELETE'],
    ],
],

Your RouteRepositoryResolverInterface is responsible for fetching the right repository (and may actually use the service locator, in this very specific case).

@Ocramius here is another specific case;
I have a EntityManagerFactory ending with the following lines;
        // ... bunch of configuration lines..
        $evm->addEventSubscriber($translator);
        $evm->addEventSubscriber(new TimestampableListener());
        $evm->addEventSubscriber(new IpTraceableListener());
        return EntityManager::create($conf['connection']['orm_default'], $config, $evm);

and I need to pass the user's IP address from request to IpTraceableListener like:
$listener = new IpTraceableListener();
$ip = $request->getAttribute('user_ip');
$listener->setIpValue($ip);
$evm->addEventSubscriber($listener);

I also have a RealIPMiddleware which resolves remote ip address and appends it to the current request:
class RealIPMiddleware
{
    public function __invoke(Request $request, Response $response, callable $next)
    {
        $request = $request->withAttribute('user_ip', $this->resolveIP($request));
        return $next($request, $response);
    }

I truly understand the pre-dispatch context of the factories however i'm looking for a nice (or correct) way to do this. What is your suggestion?

authors: Ocramius danizord edigu vaclavvanik xtreamwayz

repo: zendframework/zend-expressive


text:
Cookies class doesn't allow Header\Cookie instances

As opposed to the comment in Cookies:: addCookie:

Cookie should be passed either as a Zend\Http\Header\Cookie object or as a string

Cookies:: addCookie actually only allow instances of SetCookie to be passed as an argument.
The comment is not aligned with the implementation. Which one represents the expected behaviour?

Considering we test the code, the code is correct. Would you please create a PR to update the comment?

Yes, I will, Thanks @weierophinney.

authors: noisebleed weierophinney

repo: zendframework/zend-http


text:
getallheaders on nginx backed by php7-fpm compatibility issues

Ubuntu 16.04 Xenial with php7-fpm and nginx presents compatibility issues with ACL roles management. In particular I'm running magento 1.9 and roles are not being recognized I think because of my custom implementation of getallheaders.

if (!function_exists('getallheaders'))
{
    function getallheaders()
    {
           $headers = '';
       foreach ($_SERVER as $name => $value)
       {
           if (substr($name, 0, 5) == 'HTTP_')
           {
               $headers[str_replace(' ', '-', ucwords(strtolower(str_replace('_', ' ', substr($name, 5)))))] = $value;
           }
       }
       return $headers;
    }
}

if (!function_exists('apache_request_headers')) {
        function apache_request_headers() {
            foreach($_SERVER as $key=>$value) {
                if (substr($key,0,5)=="HTTP_") {
                    $key=str_replace(" ","-",ucwords(strtolower(str_replace("_"," ",substr($key,5)))));
                    $out[$key]=$value;
                }else{
                    $out[$key]=$value;
        }
            }
            return $out;
        }
}

Unrelated with zendframework/zend-permissions-acl - you probably meant to report this as a PHP bug?
Closing here.

authors: Ocramius g-alfieri

repo: zendframework/zend-permissions-acl


text:
Refactor ObjectTags, intruducing a new concept called "relish"

This clarifies - I hope - the abstractions between Repository and
ObjectRepository. The ObjectTag struct was a mix of objects that could
be accessed directly through the public Timeline interface, and also
objects that were created and used internally by the ObjectRepository
implementation and not supposed to be accessed directly by the
callers.  With the RelishTag separaate from ObjectTag, the distinction
is more clear: RelishTag is used in the public interface, and
ObjectTag is used internally between object_repository.rs and
object_store.rs, and it contains the internal metadata object types.
One awkward thing with the ObjectTag struct was that the Repository
implementation had to distinguish between ObjectTags for relations,
and track the size of the relation, while others were used to store
"blobs".  With the RelishTags, some relishes are considered
"non-blocky", and the Repository implementation is expected to track
their sizes, while others are stored as blobs. I'm not 100% happy with
how RelishTag captures that either: it just knows that some relish
kinds are blocky and some non-blocky, and there's an is_block()
function to check that.  But this does enable size-tracking for SLRUs,
allowing us to treat them more like relations.
This changes the way SLRUs are stored in the repository. Each SLRU
segment, e.g. "pg_clog/0000", "pg_clog/0001", are now handled as a
separate relish.  This removes the need for the SLRU-specific
put_slru_truncate() function in the Timeline trait. SLRU truncation is
now handled by caling put_unlink() on the segment. This is more in
line with how PostgreSQL stores SLRUs and handles their trunction.
The SLRUs are "blocky", so they are accessed one 8k page at a time,
and repository tracks their size. I considered an alternative design
where we would treat each SLRU segment as non-blocky, and just store
the whole file as one blob. Each SLRU segment is up to 256 kB in size,
which isn't that large, so that might've worked fine, too. One reason
I didn't do that is that it seems better to have the WAL redo
routines be as close as possible to the PostgreSQL routines. It
doesn't matter much in the repository, though; we have to track the
size for relations anyway, so there's not much difference in whether
we also do it for SLRUs.
Review guide
This is a big patch, but it's mostly very mechanical code churn, replacing ObjectTags with RelishTags. For the substance, please start from relishes.rs. It has comments explaining the concept.
I ended up doing this when I started to rebase the 'layered-repo' branch over the non-rel changes in main. I didn't like how the SLRUs were treated specially, with the special way they were truncated, and this kind of ballooned from there. We had discussions on this earlier, when the ObjectTags were introduced in PR #268, but back then I was not able to articulate my criticism so clearly, and didn't have a good alternative in mind. I think this fixes some of the "layering violations" between the Repository/Timeline traits and the ObjectRepository/ObjectStore implementation of those traits.
Does anyone come with a better name for a "relish"? Something that would capture "a relation, or one of the other files that we store in the repository"? I considered just "file", but then you might expect a more POSIX-like API. I also considered "object", but "object" is an overloaded term, and it would differ from the way the term "object" is currently used. (Currently, an ObjectTag refers to an individual page in a relation (or one of the other things that are not relations), whereas a relish represents the relation itself). I also considered just calling everything a relation, even things that are not relations in PostgreSQL, but that could also be confusing. I kind of like "relish", but I'm not sure how it sounds to others or if it the connotation to food is too strong :-).

While working on this I noticed that current code didn't handle XID wraparound correctly for pg_multixact/offsets and pg_clog truncation. That needs to be fixed. I didn't try to fix it in this PR, and I didn't bother to refactor the existing broken code either so I just commented out the broken code with a FIXME comment.

I will look at this more precisely tomorrow, but can you explain me please why this tags are called "relish"?
Shame on me, I never have heard this word before and Google Translate gives me the following synonyms:
enjoy, relish, delight, savor, revel, take pleasure in... which are not somehow associated with object tags in my mind:)

-ish suffix add sense of "kind of" or "like", in other words Relish -> KindOfRelationButNotExactly

-ish suffix add sense of "kind of" or "like", in other words Relish -> KindOfRelationButNotExactly
Got it. But I afraid that it can confuse not only me:)

Does anyone come with a better name for a "relish"?

What about something like SegmentedObjectTag?
I found "relish" name confusing, because we consistently refer to SLRUs as "non-rels" to differ them from tables and indexes.  And this new name suggests that they are "rel-like".

Also, how does "Checkpoint" belong to this structure? I wouldn't expect to find it there. What is it that these objects really have in common?

FWIW, I also think that ObjectTag and object_store names are too generic and we may want to change it to something more specific. One more reason is that "object" and "object storage" is commonly associated with s3 (as in "s3 - cloud object storage")

P.S. I kindly ask you to queue this PR after my refactoring in #344

What about something like SegmentedObjectTag?

May be just PageTag? Would work both for rel and non-rel (however a bit of stretch for 2PC records)

What about something like SegmentedObjectTag?

May be just PageTag? Would work both for rel and non-rel (however a bit of stretch for 2PC records)

Nope. PageTag is kind of what we're trying to differentiate from.

Does anyone come with a better name for a "relish"?

1. What about something like SegmentedObjectTag?

'SegmentedObjectTag' has all the same problems as 'ObjectTag'. And not all the "relishes" are divided into segments, anyway.

   I found "relish" name confusing, because we consistently refer to SLRUs as "non-rels" to differ them from tables and indexes.  And this new name suggests that they are "rel-like".

They are "rel-like" because they are stored in the zenith repository alongside with relations. The SLRUs are stored exactly the same as relations. (Before this PR, SLRU truncation was handled differently, but that's no longer the case)

2. Also, how does "Checkpoint" belong to this structure? I wouldn't expect to find it there. What is it that these objects really have in common?

Well, we store the Checkpoint in the repository, along with the relations, the SLRUs et al. From the storage point of view, it's stored and versioned by LSN just like all the other relishes. There is no corresponding file in a PostgreSQL data directory, but at the level of the Repository/Timeline abstraction, it doesn't matter.

3. FWIW, I also think that ObjectTag and object_store names are too generic and we may want to change it to something more specific. One more reason is that "object" and "object storage" is commonly associated with s3 (as in "s3 - cloud object storage")

True.

P.S. I kindly ask you to queue this PR after my refactoring in #344

Ok.

What about something like SegmentedObjectTag?

May be just PageTag? Would work both for rel and non-rel (however a bit of stretch for 2PC records)

Nope. PageTag is kind of what we're trying to differentiate from.

Right, the RelishTag does not include the block number.
I also considered just calling the struct RelTag, and calling all the SLRUs, twophase state files etc. also relations. But that's also confusing in the places that actually need to distinguish relations and non-relations.

I've attempted to summarize what combinations we store now in the object store (prior to this PR).
Tag (aka Key in one zenith timeline) - Value

TimelineMetadataTag - TimelineMetadata
RelationMetadata - RelationSize (nblocks or Unlink)
RelationBuffer - Page (page image or WAL record)
Checkpoint - Page (Checkpoint struct as a "page image" or WAL record)
ControlFile - Page (ControlFileData struct as a "page image" or WAL record)
FilenodeMap - Page(pg_filenode.mao as a "page image" or WAL record)
Clog. MultiXactMembers, MultiXactOffset - Page (slru page or wall record) or SLRUTruncate
TwoPhase - Page (full pg_twophase segment as "page image" or wall record)

@hlinnaka, @knizhnik , please correct me, if anything is wrong.
IIUC
Of all tags only RelationBuffer() and TimelineMetadata() are actually used by public Timeline interface.
While others are specific to ObjectRepository implementation. This PR suggests hiding them under one tag "Relish".
What about calling them "PrivateObjectTag" or "InternalObjectTag" then?

I've attempted to summarize what combinations we store now in the object store (prior to this PR).
Tag (aka Key in one zenith timeline) - Value
* TimelineMetadataTag - TimelineMetadata

* RelationMetadata - RelationSize (nblocks or Unlink)

* RelationBuffer - Page (page image or WAL record)

* Checkpoint - Page (Checkpoint struct as a "page image" or WAL record)

* ControlFile - Page (ControlFileData struct as a "page image" or WAL record)

* FilenodeMap - Page(pg_filenode.map as a "page image" or WAL record)

* Clog. MultiXactMembers, MultiXactOffset - Page (slru page or WAL record) or SLRUTruncate

* TwoPhase - Page (full pg_twophase segment as "page image" or WAL record)

@hlinnaka, @knizhnik , please correct me, if anything is wrong.
IIUC
Of all tags only RelationBuffer() and TimelineMetadata() are actually used by public Timeline interface.
While others are specific to ObjectRepository implementation.
This PR suggests hiding them under one tag "Relish" and also get rid of SLRUTruncate in favor of RelationSize (unlink).
What about calling them "PrivateObjectTag" or "InternalObjectTag" then?

I am +1 for InternalTag

I've attempted to summarize what combinations we store now in the object store (prior to this PR).

thanks!

Tag (aka Key in one zenith timeline) - Value
* TimelineMetadataTag - TimelineMetadata
* RelationMetadata - RelationSize (nblocks or Unlink)
* RelationBuffer - Page (page image or WAL record)
* Checkpoint - Page (Checkpoint struct as a "page image" or WAL record)
* ControlFile - Page (ControlFileData struct as a "page image" or WAL record)
* FilenodeMap - Page(pg_filenode.map as a "page image" or WAL record)
* Clog. MultiXactMembers, MultiXactOffset - Page (slru page or WAL record) or SLRUTruncate
* TwoPhase - Page (full pg_twophase segment as "page image" or WAL record)

@hlinnaka, @knizhnik , please correct me, if anything is wrong.
IIUC
Of all tags only RelationBuffer() and TimelineMetadata() are actually used by public Timeline interface.
While others are specific to ObjectRepository implementation.

Not quite. These are accessed through the public Timeline interface:
RelationBuffer, Checkpoint, ControlFile, FilenodeMap, Clog, MultiXactMembers, MultiXactOffset and TwoPhase
Of these, only RelationBuffer is requested over the network by the compute node. The others are used to build the base backup tarball. But that distinction is not important to the Repository/Timeline implementation.
RelationMetadata and TimelineMetadata are internal to the ObjectRepository implementation.

This PR suggests hiding them under one tag "Relish" and also get rid of SLRUTruncate in favor of RelationSize (unlink).

That's right.

What about calling them "PrivateObjectTag" or "InternalObjectTag" then?

That's fine for RelationMetadata and TimelineMetadata, but the question remains: what do you call the others?

What about something like SegmentedObjectTag?

May be just PageTag? Would work both for rel and non-rel (however a bit of stretch for 2PC records)

Nope. PageTag is kind of what we're trying to differentiate from.

Right, the RelishTag does not include the block number.

Gotcha. Then I guess made-up work like RelishTag would work along with explanation. Or RelzTag/ZRelTag.

That's fine for RelationMetadata and TimelineMetadata, but the question remains: what do you call the others?

Checkpoint, ControlFile, FilenodeMap, Clog, MultiXactMembers, MultiXactOffset and TwoPhase -  are NonRels
and we want to unite them with RelationMetadata, right?
maybe some  "PGObjectMetadataTag"  or just "PGObjectTag" ?
So we will have three tags on the upper level:

TimelineMetadataTag
ObjectMetadataTag
Buffer (in your PR) which I propose to rename to BufferDataTag (BufferTag would be better, but it's already taken)

That's fine for RelationMetadata and TimelineMetadata, but the question remains: what do you call the others?

Checkpoint, ControlFile, FilenodeMap, Clog, MultiXactMembers, MultiXactOffset and TwoPhase - are NonRels
and we want to unite them with RelationMetadata, right?

Right. Well, we only need the RelationMetadata the SLRUs, the other relishes are "non-blocky", meaning they are not divided into multiple blocks, and hence we don't need to track their sizes separately.

maybe "PGObjectMetadataTag" or just "PGObjectTag" ?
So we will have three tags on the upper level:
* TimelineMetadataTag

* PGObjectTag

* Buffer (in your PR) which I propose to rename to BufferDataTag (BufferTag would be better, but it's already taken)

If we keep the RelishTag struct as it is in this PR, I think PGObjectTag should be RelishMetadata(RelishTag). If we want to rename Buffer, I'd propose Page or Block. So ObjectTag would be:
/// key type used by ObjectRepository when it stores pages and metadata in the key-value store
pub struct ObjectKey {
    pub timeline: ZTimelineId,
    pub tag: ObjectTag,
}
...
pub enum ObjectTag {
    // dummy tag preceeding all other keys
    First,

    // Metadata about a timeline. Not versioned.
    TimelineMetadata,

    // These objects store metadata about one relish. Currently it's used
    // just to track the relish's size. It's not used for non-blocky relishes
    // at all.
    RelishMetadata(RelishTag),

    // These are the pages exposed in the public Repository/Timeline interface.
    Block(RelishTag, u32),
}

Note: ObjectTag and ObjectKey will go away with the new storage format. It's not based on a key-value store, and it tracks the relation sizes differently.

// These objects store metadata about one relish. Currently it's used
// just to track the relish's size. It's not used for non-blocky relishes
// at all.
RelishMetadata(RelishTag),
// These are the pages exposed in the public Repository/Timeline interface.
Block(RelishTag, u32),

Do you see any issues with this naming? Sorry for this long discussion about naming, but I'd like to avoid introducing one more concept and keyword, if we can.
//Metadata about one postgresql object (rel or non-rel)
// that is used just to track object's size in number of blocks.
PgObjectMetadata(PgObjectTag),

// These are the pages (or WAL-records) exposed in the public Repository/Timeline interface.
Buffer(PgObjectTag, u32)

Buffer sounds better than Block to me just because it may contain not only a regular 8k block but something else (i.e. wal-record or twophase segment data)

On 22/07/2021 16:00, Konstantin Knizhnik wrote:

@.**** commented on this pull request.
First of all I thin it is necessary to strictly enumerate issues and
goals we are going to address with the proposed refactoring. From your
description, I can extract three points, please correct me if I am wrong:

Mix of public and private objects
Mix of "BLOBs" and "relations", or better say blocky and non-blocky
objects
Presence of special method for SLRU truncation
From my point of view 1) and 3) are not a problem at all.
Truncation of SLRU segment is semantically very different from
dropping or truncation relation, so I do not sees something awkward
in having separate method for it. Public and private usage should
not also affect API, and may be some accessors which are now private
will be made to other components in future.

The SLRU truncation is problematic for the layered-repo implementation.
If we treat the whole SLRU as one relation/file/relish, it will need a
concept of "missing" pages in the middle. That's doable, of course, but
it's a weird corner case I'd rather avoid.

Now concerning alternative design of SRLUs when SLRU object corresponds
to segment and not block. From my point of view, if we are doing such
massive refactoring, then splitting SLRU in segments rather than in
block in our object storage is better approach. We do not need to access
SLRUs by pages and reconstructing segments from blocks in basebackup
only adds extra head ache. I do not consider similarity with
correspondent postgres redo handlers as enough motivation. This code is
still written mostly from scratch and is not just port of correspondent
C code fragments. Actually the difference is mostly module divisor
(segment or block size).

Ok, we can try that. I don't think it makes much difference.

Also I do not like that new approach requires nested lookups in one of
the most performance critical functions: generation of tarball for spawn
of new node (which determines node restart time). Before "relish" there
was just one iteration through KV storage, Now for each SRLU we perform
separate lookup for each segment. I am not sure if this difference is
measurable, but why to try to do something in more complex and less
efficient way if simpler solution exists? Especially if we are replacing
existed more efficient code...

Meh, it's not really performance critical. And easy to improve if it
turns out to be a problem.

Heikki

The SLRU truncation is problematic for the layered-repo implementation.
If we treat the whole SLRU as one relation/file/relish, it will need a
concept of "missing" pages in the middle. That's doable, of course, but
it's a weird corner case I'd rather avoid.

Do you mean missing blocks or missing segments? There are should not be missing segments, because we are always truncating data from one side and appending to another. Concerning missing pages in the middle of segment, also not quite clear to me how them can arrive, but does filling the whole segment with zeroes solve this problem?

Meh, it's not really performance critical. And easy to improve if it
turns out to be a problem.

I can't agree that it is not performance critical: adding relation metadata cache increase speed more than two times. If it was not performance critical, then such optimization will have no effect. For SLRUs IMHO it is just useless work, especially if we will associate SLRU objects with segments.In this case there is no need to track SLRU size at all (if we treat each SRLU segment as separate fixed size object).

On 22/07/2021 16:50, Konstantin Knizhnik wrote:

The SLRU truncation is problematic for the layered-repo implementation.
If we treat the whole SLRU as one relation/file/relish, it will need a
concept of "missing" pages in the middle. That's doable, of course, but
it's a weird corner case I'd rather avoid.

Do you mean missing blocks or missing segments? There are should not be
missing segments, because we are always truncating data from one side
and appending to another. Concerning missing pages in the middle of
segment, also not quite clear to me how them can arrive, but does
filling the whole segment with zeroes solve this problem?

So, we can store the SLRUs in three different granularities in the storage:

Treat the whole SLRU as one relish, divided into blocks. This is the
model we have on 'main' now.

Treat each SLRU segment as a separate relish, divided further into
blocks. This is what I'm proposing in this PR.

Treat each SLRU segment as a separate relish, not divided into
blocks, just stored as one big blob.

With model 1), you need some way to represent the missing pages in the
middle of the SLRU. For example, in PostgreSQL after XID wraparound you
might have CLOG segments in the range 0F12-0010. In order to store that,
you need a way to represent that the blocks belonging to those segments
are in use, and the others, between 0010-0F12 are not. A simple relation
size won't do. We're currently doing that with the put_slru_trunction(),
it effectively punches a hole in the middle of the relish, storing a
0-sized page there.
With models 2) and 3), it's more straightforward. When a segment is
truncated away, it's unlinked, just like a dropped relation.

Heikki

PS. in get_page_at_lsn() you return an 8k all-zeros page for SLRU pages
that have been removed with put_slru_truncation(), but the comment in
add_slru_segment() suggests that you would use a zero-length page for
that. I think one of them is wrong.

On 22/07/2021 16:50, Konstantin Knizhnik wrote: The SLRU truncation is problematic for the layered-repo implementation. If we treat the whole SLRU as one relation/file/relish, it will need a concept of "missing" pages in the middle. That's doable, of course, but it's a weird corner case I'd rather avoid. Do you mean missing blocks or missing segments? There are should not be missing segments, because we are always truncating data from one side and appending to another. Concerning missing pages in the middle of segment, also not quite clear to me how them can arrive, but does filling the whole segment with zeroes solve this problem?
So, we can store the SLRUs in three different granularities in the storage: 1) Treat the whole SLRU as one relish, divided into blocks. This is the model we have on 'main' now. 2) Treat each SLRU segment as a separate relish, divided further into blocks. This is what I'm proposing in this PR. 3) Treat each SLRU segment as a separate relish, not divided into blocks, just stored as one big blob. With model 1), you need some way to represent the missing pages in the middle of the SLRU. For example, in PostgreSQL after XID wraparound you might have CLOG segments in the range 0F12-0010. In order to store that, you need a way to represent that the blocks belonging to those segments are in use, and the others, between 0010-0F12 are not. A simple relation size won't do. We're currently doing that with the put_slru_trunction(), it effectively punches a hole in the middle of the relish, storing a 0-sized page there. With models 2) and 3), it's more straightforward. When a segment is truncated away, it's unlinked, just like a dropped relation. - Heikki PS. in get_page_at_lsn() you return an 8k all-zeros page for SLRU pages that have been removed with put_slru_truncation(), but the comment in add_slru_segment() suggests that you would use a zero-length page for that. I think one of them is wrong.

I mean 3).
I do not see reasons in scattering segment into blocks if we do not need page access.

Rebased.

I mean 3).
I do not see reasons in scattering segment into blocks if we do not need page access.

Ok, I just tried doing that. Some functions become a bit simpler, like import_slru_file and add_slru_segment. But in save_decoded_record, the handling of the ZEROPAGE records for the SLRUs become a bit more complicated, as you cannot just do put_page_image(..., ZERO_PAGE) to extend the SLRU anymore. Seems better to not do that.

We didn't come up with better names for "relishes" or the other structs, so I pushed this. Thanks for the reviews!

authors: hlinnaka kelvich knizhnik lubennikovaav

repo: zenithdb/zenith


text:
Better documentation for handling Safari

Per caniuse.com, you can correctly determine the availability of copy with document.queryCommandSupported().

Hey @listrophy, thanks for sending this pull request. I decided not to mention this because there are a lot of inconsistencies on Blink and Gecko regarding this API.
https://hacks.mozilla.org/2015/09/flash-free-clipboard-for-the-web/
https://developers.google.com/web/updates/2015/04/cut-and-copy-commands

authors: listrophy zenorocha


text:
[Feature Request] add @@filter annotation to enable/disable access

Is your feature request related to a problem? Please describe.
Sometimes i want baked in logic like soft delete mechanism into my model access policy.  But sometimes the user/client can still access the data but only in implicit circumstances.  Most of this could be implemented through the access policy and passing the parameter to the auth() but then you would need to create a new enhanced client. i believe you might want to enable/disable the access at the transaction level.
To rephrase, sometimes a single user of elevated "role" wants to view the application data the same as other users but by toggling an "flag" they can now include rows previously excluded (ie. archived, deleted)
Describe the solution you'd like
    attribute @@filter(_  name: String, _ condition: Boolean, _ enabled: Boolean?)

Name
Description
Default

name
Key to be passed to 'enhanced' client to enabled/disable filter behavior

condition
Boolean expression to be evaluated/inject if the fitler is enabled

enabled
Boolean indicating if the filter is enabled by default, should not have "args()"
false

model Post {
  id String @id @default(cuid())
  title String
  owner User @relation(fields: [ownerId], references: [id])
  ownerId Int
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
  publishedAt DateTime
  archivedAt DateTime
  createdAt DateTime

  // Filter Annotation will always inject this where clause when accessing model,
  @@filter('excludeArchived', archivedAt != null, true)
  @@filter('existingAsOf', createdAt = args().date)
  @@filter('publishedBetween', publishedAt > args().min && publishedAt < args().max)

  @@deny('all', auth() == null)
  @@allow('all', auth() == owner)
  @@allow('read', auth() != null)
}

This could then be used as such:
import { PrismaClient } from '@prisma/client';
import { enhance } from '@zenstackhq/runtime';

const prisma = new PrismaClient();
const db = enhance(prisma);

// then elsewhere ...

// this will excludeArchived by default
await db.post.findMany();

// this will disable exclude archived logic
await db.post.findMany({
   filters: {
     excludeArchived: false
   }
});

// this will enable the other filters, multiple should be allowed
await db.post.findMany({
   filters: {
     existingAsOf: {date: new Date() },
     publishedBetween: { min: new Date(), max: new Date()}
   }
});

Describe alternatives you've considered
Now some the examples above are contrived and arguably pointless, for example the publishedBetween could/should just be written in the where clause and this layer of abstraction is complicated.  I agree, the example was to illustrate the concept.
The real benefit here is for complex use-cases like effectiveDated/Versioned/Temporal models and "version" control, where a filter enabled at the top level will be enabled for relations that invoke the same filter name.
model Post {
  //...
  effectiveStart DateTime
  effectiveEnd DateTime
  comments Comment[]
  @@filter('asOf', effectiveStart < args().timestamp && (effectiveEnd > args().timestamp || effectiveEnd == null))
}

model Comment {
  //...
  effectiveStart DateTime
  effectiveEnd DateTime
  @@filter('asOf', effectiveStart < args().timestamp && (effectiveEnd > args().timestamp || effectiveEnd == null))
}

Then query the tree -->
await db.post.findMany({
  filter: { asOf: { timestamp: '2024-12-24' } },
  select: {
    title: true,
    comments: {
      select: {
        id: true,
        message: true,
      },
    },
  },
});

**Additional context**
Based on concept from Hibernate: https://thorben-janssen.com/hibernate-filter/

possibly related to #1402 and #520

Hi @bvkimball , thank you for filing this FR with a great explanation! If I'm understanding it correctly, the proposal covers two aspects:

A way of passing extra variables to policy rules at runtime
A way of conditionally enabling/disabling some rules (on multiple models)

# 1 is similar to #1402. We can probably start by allowing the args() construct at the client level and then extend it to the query level for better flexibility. The latter will involve extending PrismaClient's current TS interface, but we're already doing it in V2 anyway 😄.
# 2 may be related to another thing that I've been thinking about for a while. Let me try to explain it here.
The current way policies are modeled in ZenStack is probably not good enough for modeling applications with multiple "sides". For example, an EC app can have a storefront "side" and a fulfillment "side". Authoring their rather different authorization rules in a "flat" way can be quite cumbersome and hard to maintain. So maybe we should introduce something like "profile" to segregate different sets of rules. (Please ignore the syntax, as it's just for showing the idea).
model Order {
  ...

  @@profile('storefront', [
    allow('read', ...),
    deny('update', ...)
  ])

  @@profile('fulfillment', [
    allow('read', ...),
    deny('update', ...)
  ])

}

So at enhancement time we can do:
const storefrontDb = enhance(prisma, ..., { profiles: ['storefront'] });

We can also allow overriding profiles at query time.
Back to your proposal, the equivalent will probably be something like:
model Post {
  //...
  effectiveStart DateTime
  effectiveEnd DateTime
  comments Comment[]
  @@profile('asOf', [
    deny('read', !(effectiveStart < args().timestamp && (effectiveEnd > args().timestamp || effectiveEnd == null))))
  ])
}

await db.post.findMany({
  select: {
    title: true,
    comments: {
      select: {
        id: true,
        message: true,
      },
    },
  },
  profiles: [ 'asOf' ],
  args: { timestamp: '2024-12-24' }
});

I'm still not really sure to what extent this really overlaps with your original thoughts, but just wanted to throw out some wild ideas 😄.

repo: zenstackhq/zenstack


text:
Settings: should leave important decisions to the application

Is your enhancement proposal related to a problem? Please describe.
Settings module does some arbitrary decisions thus it can lead to system failure or data loss.
Settings did 2 things that it really should not be allowed to do without the application interaction:

Clears flash if it cannot initialize: This may lead to data loss. Imagine that you have upgraded the application and the data format changed. In some application, it does not matter and you can just clear the data. But in some others, we cannot afford configuration lost. It should be an application decision to clear the flash and try the settings initialisation one more time. Some applications would show a warning then to the user and allow him to downgrade to restore the settings.

It crashes the whole system if it cannot initialize. What? How important is settings module? One more time - this should be the application decision. The way it works right now, it may lead to the whole system crash just because settings module is broken. What if settings module is implemented on file backend and uses FLASH card? If settings module would not use kernel panic inside the application may at least display some notification like: "Settings file not present, do you wish to create empty one?" or even "Insert SD Card". In the worst case, in many... many cases application may still continue to work even if the settings module is non-functional.

Describe the solution you'd like

Settings module should allow the application to decide if it prefers to erase the backend memory.
Settings module should return error code not crash the whole system.

Describe alternatives you've considered
NULL

cc @nvlsianpu @carlescufi

This also relates partially to the #16275

yes: Settings module should allow the application to decide if it prefers to erase the backend memory. Should be able to inform the application about unknow format which open possibility to fix or run an adaptation patch.
yes: because of similar reasons.

authors: nvlsianpu rakons

repo: zephyrproject-rtos/zephyr


text:
Bluetooth: Mesh: Send Model Message shouldn't require explicit NetKey Index

According Mesh Profile 3.8.6 Keys Application keys are bound to network keys. This means application keys are only used in a context of a network key they are bound to. An application key shall only be bound to a single network key. A device key is implicitly bound to all network keys.
https://github.com/zephyrproject-rtos/zephyr/blob/42c5b0a7fafa3360b8d835d4b76d7b1bebbe9237/samples/bluetooth/mesh_demo/src/main.c#L233-L251
But what the above code shows is that when we send data, we need to specify net_idx and app_idx.
The current protocol stack does not confirm whether the two parameters are bound together. My task doesn't have to specify net_idx, this parameter should be generated automatically through bound with app_idx

You're right that the net_idx can be implicitly derived from the app_idx. Removing app_idx completely from bt_mesh_msg_ctx is a bit trickier since that struct is also used by the transport layer to send transport control messages, and those messages are only encrypted with a network key (no app key involved). So removing the struct member would require some redesign of the stack, which I'm not convinced is worth it. What we could do is resolve the app_key to a net_key in bt_mesh_model_send so that the application doesn't need to initialise net_key to anything.

@LingoMeng will you send a PR for this?

well, I think it's best to add some binding query statements at the beginning of bt_mesh_model_send function:
    if (!BT_MESH_IS_DEV_KEY(ctx->app_idx))
    {
        app_key = bt_mesh_app_key_find(ctx->app_idx);

        if (app_key == NULL)
        {
            BT_ERR("Unable find binded netkey app_idx: 0x%04x", ctx->app_idx);
            return -EINVAL;
        }

        ctx->net_idx = app_key->net_idx;
    }

@jhedberg What do you think?

@trond-snekvik Can you also provide feedback on the proposal above?

@jhedberg What do you think?

@moringe yes, that would probably work, though we should probably also cover the device key case (which is always used together with the primary net key of the device that the device key belongs to, IIRC). Do you want to submit a PR for this?

@jhedberg What do you think?

@moringe yes, that would probably work, though we should probably also cover the device key case (which is always used together with the primary net key of the device that the device key belongs to, IIRC). Do you want to submit a PR for this?

But,according Mesh Profile 3.8.6.1 Device key The device key (DevKey) is an access layer key known only to the node and a Configuration Client. Thedevice key shall be bound to every network key known to the node.

But,according Mesh Profile 3.8.6.1 Device key The device key (DevKey) is an access layer key known only to the node and a Configuration Client. Thedevice key shall be bound to every network key known to the node.

@moringe you're right. Somehow I had missed this part. I had (wrongly) assumed that the device key is only bound to the network key that it comes together with as part of the provisioning data.

authors: LingoMeng carlescufi jhedberg moringe


text:
Allow to select between advertising packet/scan response for BT LE device name

Currently when starting legacy advertising and setting BT_LE_ADV_OPT_USE_NAME option, the device name is set inside the scan response if one is provided when calling bt_le_adv_start else inside the advertising packet.
So there is not user-friendly way to send the same in the advertising packet if BT_LE_ADV_OPT_USE_NAME and scan response are used.
It would be nice to have an additional flag to select where to put the name
A workaround to achieve the desired result is to no use BT_LE_ADV_OPT_USE_NAME and set explicitly the device name in the advertising packet

@jhedberg Currently bt_set_name would clear the rest of the Scan Response data.
Should we perhaps change that and instead document that the application will have to toggle advertising (in order to provide the scan response data pointer again) when setting the name this way and using the USE_NAME option?
Should we add the option to select the advertising name in the advertising packet instead? I remember you had some opinions on this.
If we don't want to do this we should close this issue.

@joerchan I don't have a strong opinion either way wrt bt_set_name(), however that seems orthogonal to this particular issue. My gut feeling is that putting the name in the advertising data rather than the scan response is such a minority use case that we can require apps to just do the manual work in that case. I'm open to be convinced to change my mind, however 😄

authors: jhedberg joerchan kurddt