Discrepancy between "getetag" property and ETag header

There is currently a discrepancy between the DAV property "getetag" obtained with PROPFIND and the ETag header obtained wit a HEAD or GET. The header value is quoted by wsgidav while the property value is not.
From the example in Section 9.1.5 of RFC4918 the "getetag" property should exactly match the header value. It would probably be best if the getETag() string be used directly as both the header value and the property. This would require simply removing the quoted formatting in the supplied server: https://github.com/mar10/wsgidav/blob/7b2f10adca764a9514f86bfc4dec055ee84c1202/wsgidav/request_server.py#L784
This would put the burden on the getETag() to supply either a strong or weak quoted etag value.

I found this issue on an older version (2.4.1) but this same problem applies to the current master https://github.com/mar10/wsgidav/blob/9b85f53d0dad9ec2db7b339049ee693f62ed52de/wsgidav/request_server.py#L847

I am comfortable patching my local package of this library. If there is agreement on which of the two is changing, I will patch my local source to agree with that decision.
Does it seem good to require any ETag quoting from the provider? It will affect existing users of the API for the header value, but not for the DAV property value.

Some first thoughts: This source suggests that ETag header is not enclosed in quotes (") per se, but the ETag value is:
ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

The If-*-Match headers use the same syntax:
If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
If-None-Match: *

A possible approach could be that

if getETag() returns a plain string xyzzy quotes will added: ETag: "xyzzy"
if getETag() returns a quoted string "xyzzy" it will be used as-is: ETag: "xyzzy"
if getETag() returns a weak etag, it should have the form W/"xyzzy" and it will be used  as-is: ETag: W/"xyzzy"
In this case (i.e. result.lower() starts with w/) we should add checks for the correct syntax and warn or error out if the trailing etag is not embedded in quotes

What do you think?

Unfortunately robust ETag handling is provided by libraries like werkzeug which is not currently a dependency.
If the API is going to be lax about whether the getETag() / get_etag() return RFC-conformant values, then I think simply stripping the text and quoting-if-not-quoted (i.e., assume a not-strictly-valid ETag value is really a strong ETag) would do the job.
This means that the output of getETag() needs to be postprocessed every time it is used, which is a few places (request_server.py and dav_provider.py at least). Seems like the easiest thing is to create a new utility function, something similar to:
def quote_etag(value):
    value = str(value).strip()
    if '"' not in value:
        value = '"{}"'.format(value)
    return value

This doesn't strictly enforce RFC conformance but it at least guarantees a strong ETag format for otherwise conformant values.
Then the users of the API-provided ETag would look like:
                headers = [("ETag", quote_etag(entitytag))]

Also, the default util.getETag() should properly quote its output as a good example.

I actually just found a similar issue, on the opposite site, in ETag handling for conditional comparison in https://github.com/mar10/wsgidav/blob/7b2f10adca764a9514f86bfc4dec055ee84c1202/wsgidav/util.py#L1018 and https://github.com/mar10/wsgidav/blob/7b2f10adca764a9514f86bfc4dec055ee84c1202/wsgidav/util.py#L1040
As you showed earlier, quotation marks are part of the ETag value and should not be removed from the string.


Hiding or deleting published assets

It's currently not possible to unpublish / delete or hide published assets. Whoops :D

It is possible through DB only...
Tagging as junior job, since it is just a query + backend binding + frontend binding (don't forget the permissions though) :smile:


How to build the src on Mac OS

Should I have to Install the PowerShell for Mac?

You can - if you want to run build script that does unit tests etc. But output in the "bin" folder should be ready for deployment too, so you can go away without running build script via PowerShell and just copy files from "bin" folder to your server.


thumbnails

It can be very useful program to create thumbnails for stl models if add some options like:

set background color
set filename to save image or send image to stdout

Hi,
I can add options for background color and output filename to the sample program (which is just a sample of how the library can be used). But the file format will be limited to PPM.
This repo is intended as a minimal library with no external dependencies, so no image codecs will be added here. That could be the case for a separate project, though.

If it is possible to send data to stdout, convert image to any format is very easy by imagemagick:
render model.stl | convert - model.png

Hi, latest master version can write to stdout if file name given is "--".
I tried this and it works:
render -o -- model.stl | convert - model.png

It also tries to fit the model in the view by setting the camera distance (if -d is not given).
The background is still black.

Checked, working fine.
./render -o -- -yaw 30 -tilt 40 model.stl | convert - thumb.png
Thank you.

Need to change
A useless software rasterizer for 3D meshes using a z-buffer.
to
Fast and compact software rasterizer for 3D meshes using a z-buffer.

:-)
Now you can also set background color:
render -bgcolor 10,10,5 ...

Already using minirender for my Telegram bot to create thumbnails for STL and STEP files.
Thank you.


Update Text Input styling to adhere to design specification

In implementing LG-8066, I noticed that text inputs and hints were not spaced correctly per the Figma Design System reference. The changes here eliminate all margins around the hint, and reduces the top margin of text fields from 0.5rem to 0.25rem.

Variant
Before
After

Default

With Hint

Live preview: https://federalist-2f194a10-945e-4413-be01-46ca6dae5358.sites.pages.cloud.gov/preview/18f/identity-style-guide/aduth-hint-spec/components/form-fields/

Visual regression failures are expecting since we're adjusting vertical spacing of form fields.
Example:

Got it. If it's a light lift to update across the board, I think it'd be good to have spacing consistency between any label and input field.

the %block-input-styles Sass placeholder, which is (a) not directly customizable

Actually, I take that back. Apparently in Sass, if you define a placeholder which already exists, it doesn't necessarily "override" what existed previously, but it does output an additional set of styles which would effectively take precedence over the initial definition, which should give us the effect we want.
Example: https://www.sassmeister.com/gist/d12223c9afc58b44c411146e54053df4

Ok, the changes in 2871d86 should get us what we want. The updated preview should be available shortly.

I'm going to go ahead and merge this since I want to start implementing "Big" inputs, but let me know if you spot any issues @nickttng and I'll be happy to follow-up on them.

Thank you, Andrew. I'll keep an eye out for the "Big" inputs.


Quantity instantly creates payments

I'm currently creating software that uses the quantity system. A user can create as many as they like and pay for each one of them monthly. Currently, a product is around 50 cents. When the customer adds 10 products, 10 payments will be created and I'll pay 10 times the transaction costs, which is around half the price of a product using SEPA.
Is there any way to queue these payments and send them in one big chunk daily (or any other interval), perhaps during the refresh of a subscription? I guess the software should keep track of the usage this way to calculate the time used of products.
A solution could be to let customers buy products in steps of 10 and chunk payments this way, although I prefer the precise quantity.
Thoughts?

Hi @MSnoeren ,
Have you checked in the Mollie dashboard that 10 payments were created? They should be all combined into a single OrderItem, not 10.
If it's 10 OrderItems, this would only occur on the first payment, on subsequent payments the scheduler will combine it into a single Order and payment. (Would still not be ok obviously!)

Currently I'm triggering the updateQuantity function each time a customer adds or removes a product. This means it'll create a payment for every quantity change. Using updateQuantity makes sure the quantity is always the same as the amount of active products. The payment is instantly processed and sent to Mollie; my testing-dashboard confirms this. The user has a valid mandate.
The behavior code can be found at; https://github.com/laravel/cashier-mollie/blob/61a3f0b40776fc2a395868be866e7f9281c3b38a/src/Subscription.php#L660
The updateQuantity function requests the restartCycleWithModifications function which then requests the order to be processed.

Perhaps we could add a default flag processNow = true?

Alternatively you could place a layer in between (Front-end JS?) to delay the update to the back-end, capturing all 10 updates in a single request.

The $processNow = true flag looks like a great idea. This way we can run the Cashier command, for example, daily and group payments per billable model, cutting costs. It will also support the anchor date feature which is is not yet implemented, but a fallback would be to run the Cashier command.

What do you think, should processNow default to true or false?
Given your use case, I'm leaning towards false.

I think it should be true, as the current behavior is also true. I'm switching a lot of quantities with small costs, so it's useful to me to cut the costs and push the payment into one large one, but I can imagine that other applications want to bill their customers immediately whenever they add, for example, another user at a higher cost.

Ok, we'll take that route for now.

For clarity the flag will be named invoiceNow.
processNow set to false suggests that the quantity is not instantly updated. Which it is, it's only invoiced later.

I've prepared a solution for the v1 release, planned for end of the month. 🤞


Add application stack for Service Manual Publisher

This allows us to run the application and visit it in a web browser.

Nudge to update compatibility :-).


Add .pytest_cache to .gitignore

Nothing major but useful to have locally.

Thanks for the addition!


Save a message as draft is possible using this gem?

I don't think this is provided out of the box, you'll probably have to build it yourself.

Thanks for the response David.
Regards
Kanagaraju
On Thu, Aug 4, 2016 at 3:26 PM, David Rodríguez<EMAIL_ADDRESS>wrote:

I don't think this is provided out of the box, you'll probably have to
build it yourself.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mailboxer/mailboxer/issues/424#issuecomment-237508228,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJKPBxuN59Y63Bdh1aa9BInSMVqoezqpks5qcbc6gaJpZM4JMKuK
.

You're welcome. Can you close the issue?

Sure
On Thu, Aug 4, 2016 at 4:18 PM, David Rodríguez<EMAIL_ADDRESS>wrote:

You're welcome. Can you close the issue?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mailboxer/mailboxer/issues/424#issuecomment-237519283,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJKPB-MlV_VAiGDMXoJkYFr7QLVjS6luks5qccNhgaJpZM4JMKuK
.


background region

How exactly is the background region defined?
Lets say I have a mask for a person in region 0. Does background region come from the original prompt map? or does it have to be a region?
If background region is from the prompt map, does the normal lora mapping apply to it? Or is the new lora mapping used?

https://github.com/s9roll7/animatediff-cli-prompt-travel/issues/147#issuecomment-1793738585


NX-596

Hi
I have a question:
Is there any way to make this work with NX-596 module?
I am unable to make it work with it.
Sorry if this is the wrong place to ask.
Thanks

I'm not to familiar with that model. Does it have a web page you can log into from your home network?

I'm not to familiar with that model. Does it have a web page you can log into from your home network?

Hi Caronc
Thanks for your reply
Yes it has a web interface where you can enable or disable your alarm.

Are you able to run a --debug-dump? Have a look at https://github.com/caronc/ultrasync

I got the following error running it:
ERROR - No ultrasync configuration found.

I edited config.py with host name, user and pin
I placed the config in:
Windows users can store their default configuration files here:
%APPDATA%/UltraSync/config
%LOCALAPPDATA%/UltraSync/config
Or do i need to create a new file with:
host: <IP_ADDRESS>
user: User 1
pin: xxxx
if so what filename and extension i need to use? I also tried ultrasync.config

Just a simple text file with the credentials in it and you can run the command with --config=path/to/what/you/set

Getting this message:

I was searching on Google and found this topic.
Looks like you already tested this sort of?
https://community.home-assistant.io/t/interlogix-ultrasync/51464/43

That's unfortunate. If i recall, i asked the guy to provide me more information, and they never got back to me.
In the older models, everything surrounds login.cgi;  In order to add support for your module, i'd need to learn the new mappings of all the files and their URLS.
They all likely take the same web requests/parameters, however i don't personally have the alarm system to develop against. Thus there would be a LOT of trial and error to figure this out remotely with you.
First i would need the new path of the login page (in your browser).
Then before you log in, you'd have to capture the source (most browsers allow you to go view -> source (and/or some variation of this).  This info would allow me to understand how the device handles the logins.
This would only be the start.  We'd have to rinse and repeat this for all of the admin pages (and learn their new URLs)

Would you be interested in doing this project?
I would be able to delivery you the url's and do the testing.
Thanks

Sure, we can try.
Basically i need you to go view the source of as many html files as you can. You can also get this information from your console below on the network tab ( browser: ctrl + shift+ i )
The more files you can share with me, the better. With the browser network console open, you can even capture and save actions (such as arming and disabling your alarm). These produce .xml and/or .json requests that are very important.

I exported some file. I will send them by e-mail.
I will arm en disabling the alarm and capture that in the next days.
Thanks

I'm just going to move this ticket over to the ultrasync library


Upload new interactive Wolof books to development S3, deploy to dev Curious Reader, + QA

User Story
As a Product Owner,
I want to upload the files needed to play Colours, Hide and Seek, Let's Fly, The Bee and the Elephant, and The Lost Doll to the development server, create development URLs for the stories, and launch them into the development Curious Reader,
So that we can do a quick QA speedrun if those books could be released to production.
Wolof H5P files

App icons (if needed-- they're the same as all the other language icons)
Acceptance Criteria
Given that I have the Wolof H5P files for the stories,
When I've unpacked those and uploaded the necessary files to the development S3 bucket,
Then I should be able to create development server URLs that can be used to play the books in the development Curious Reader
Given that I have development server URLs to access the books,
When I add the URLs and app icons to the manifest file,
Then I should be able to read the stories in Wolof
Given that I can read the stories in Wolof on the development Curious Reader app,
When I QA the stories,
Then I should note if there are any issues in the Wolof stories as a new task card(s)

Hi @dz4va , Can you please merge the PR for this task.

Merged!


Issue #304: Corrected the misplaced installation step

Signed-off-by: avinashvishwanath<EMAIL_ADDRESS>

@avinashvishwanath can resolve issue #308 in this PR? Just let us know when you push the additional update.

@lwilson I have pushed the updates to resolve Issue #308.

@avinashvishwanath I don't see the change to fix #308, and it looks like you deleted your branch. I can close this out for #304 and we can setup a new PR for #308.


Add /account/me API endpoint

This pull request adds a new endpoint /account/me to the API. The endpoint is designed to validate session tokens in the Need for Heat application.
The endpoint is implemented as a GET request and requires authentication using a session token. Upon successful authentication, the endpoint returns a JSON object containing the provided session token so no information of the account is being exposed.

Hi Ward,
Thanks for your pull request.
You explained what this change does, but why do you need this change?

This PR can no longer be merged, but we plan on creating an endpoint like this soon.


refactor: use baseURI instead of base_uri

Description
Fixes #9265
Replaces and closes #9280
Checklist:

[x] Securely signed commits
[ ] Component(s) with PHPDoc blocks, only if necessary or adds value
[X] Unit testing, with >80% coverage
[ ] User guide updated
[X] Conforms to style guide

The test is useless because (1) in PHP, arrays with duplicate keys always retains the last key, and (2) CURLRequest::parseOptions() only checks for baseURI key not base_uri.


the

https://media.discordapp.net/stickers/1001883359053611109.webp?size=1024

ok

I should have reviewing access


Fix path to gitignore.txt file

Need to look up one more level to find /stubs/gitignore.txt

Thanks for mentioning this.
The problem has been fixed by another pull request.


If spark master reports failed, sometimes task does not exit

Example error line:
ERROR [sparkDriver-akka.actor.default-dispatcher-20] org.apache.spark.rpc.akka.AkkaRpcEnv - Ignore error: Exiting due to error from cluster scheduler: Master removed our application: FAILED

Spark bug, see https://github.com/metamx/spark/pull/17


REPL fails to connect after lein ring uberjar is run from the console like issue #1173

This issue is still on the latest verstion 0.7.2 for mac os

lein new compojure-app testconnect      ; then LT add connecttion success
lein ring uberjar      ; then LT add connecttion fail, like issue https://github.com/LightTable/LightTable/issues/1173
lein clean      ;; then add connecttion success

Can reproduce the issue with the project and description above.
This project: https://github.com/rundis/acme-buddy/tree/master/acme-auth works fine with regardless of uberjaring or not (tried with and with aot  as well).

Right... so it's a classpath problem with tools.reader.
Modifying the project.clj for the testconnect project generated above to something like:
  [org.clojure/tools.reader "0.8.1"]
  [compojure "1.1.6" :exclusions [[org.clojure/tools.reader]]]

and voila connection works as expected. Upping the compojure dependency to say version 1.2.1 helps as well  (since that has a transitive dep to a tools.reader version.
I guess the root problem is classloader isolation when implementing nrepl middleware. Light Table is not alone here (ref https://github.com/clojure-emacs/refactor-nrepl/issues/20)
@cldwalker @ibdknox : Any thoughts on how LT might better address the wider issue on classloader isolation between the projects and LT's nrepl middleware ?

@rundis I know very little about the JVM's classloader stuff unfortunately and I was never able to figure out a way to have LT's stuff sectioned off from the project's process. :(

One possible solution for classloader isolation here: https://github.com/LightTable/Clojure/issues/44

I think https://github.com/LightTable/Clojure/pull/48 pretty much addresses this issue properly.

This is a duplicate of #1052.


possible use for a suffix option?

I wanted to wrap the types in a namespace, so I set the prefix to be namespace DB { but I needed a closing }. I ended up just using fs to write it to the file, but I'm wondering if this would be a good use case for adding a suffix option.
By the way, I'm new to typings in javascript, but having the namespace made it so I didn't have to import the file to use any of the table definitions.

Or, declare global { ... }. Yeah, that can be useful.

I implemented the suffix option because I think it's more flexible. But it's your lib, let me know if you prefer the global option.


Exit code updates

Improve exit code logging
Use matrix outcome to set exit code

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@509cae7). Click here to learn what that means.
The diff coverage is 100%.

@@            Coverage Diff            @@
##             master     #605   +/-   ##
=========================================
  Coverage          ?   76.34%
  Complexity        ?      604
=========================================
  Files             ?       81
  Lines             ?     2274
  Branches          ?      323
=========================================
  Hits              ?     1736
  Misses            ?      322
  Partials          ?      216


fixed the broken link

Fixed broken link
Replaced all absolute paths to relative paths

Learn Build status updates of commit eb99a33:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs-ref-services/legacy/service-bus.md
:warning:Warning
View (azure-node-legacy)
Details

docs-ref-services/legacy/service-bus.md

Line 2, Column 1: [Warning: ms-prod-and-service - See documentation] Only one of the following attributes can exist: 'ms.prod', 'ms.service'. Use ms.prod for on-premise products, or ms.service for cloud services.
Line 10, Column 16: [Warning: ms-prod-technology-invalid - See documentation] Invalid value for 'ms.technology': 'azure' is not valid with 'ms.prod' value 'azure'.
Line 12, Column 13: [Warning: ms-service-subservice-invalid - See documentation] Invalid value for 'ms.service': 'Service Bus'.
Line 19, Column 18: [Suggestion: docs-link-absolute - See documentation] Absolute link 'https://learn.microsoft.com/azure/service-bus-messaging/service-bus-messaging-overview' will be broken in isolated environments. Replace with a relative link.
Line 28, Column 40: [Suggestion: docs-link-absolute - See documentation] Absolute link 'https://learn.microsoft.com/javascript/api/overview/azure/arm-servicebus-readme?view=azure-node-latest' will be broken in isolated environments. Replace with a relative link.
Line 28, Column 40: [Suggestion: preserve-view-not-set - See documentation] You've pinned this link to a specific version of content with the view parameter. It's recommended not to pin a version unless that version is A) not the default view and B) the context is about that version specifically. To proceed with pinning a version add the &preserve-view=true to the URL.  Otherwise, remove the view parameter. URL: https://learn.microsoft.com/javascript/api/overview/azure/arm-servicebus-readme?view=azure-node-latest
Line 39, Column 40: [Suggestion: docs-link-absolute - See documentation] Absolute link 'https://learn.microsoft.com/javascript/api/@azure/service-bus/?view=azure-node-latest' will be broken in isolated environments. Replace with a relative link.
Line 39, Column 40: [Suggestion: preserve-view-not-set - See documentation] You've pinned this link to a specific version of content with the view parameter. It's recommended not to pin a version unless that version is A) not the default view and B) the context is about that version specifically. To proceed with pinning a version add the &preserve-view=true to the URL.  Otherwise, remove the view parameter. URL: https://learn.microsoft.com/javascript/api/@azure/service-bus/?view=azure-node-latest
Line 41, Column 76: [Suggestion: docs-link-absolute - See documentation] Absolute link 'https://learn.microsoft.com/samples/browse/?languages=javascript&products=azure-service-bus' will be broken in isolated environments. Replace with a relative link.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Learn Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings or suggestions unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

Learn Build status updates of commit 4af7773:
:bulb: Validation status: suggestions

File
Status
Preview URL
Details

docs-ref-services/legacy/service-bus.md
:bulb:Suggestion
View (azure-node-legacy)
Details

docs-ref-services/legacy/service-bus.md

Line 26, Column 40: [Suggestion: preserve-view-not-set - See documentation] You've pinned this link to a specific version of content with the view parameter. It's recommended not to pin a version unless that version is A) not the default view and B) the context is about that version specifically. To proceed with pinning a version add the &preserve-view=true to the URL.  Otherwise, remove the view parameter. URL: /javascript/api/overview/azure/arm-servicebus-readme?view=azure-node-latest
Line 37, Column 40: [Suggestion: preserve-view-not-set - See documentation] You've pinned this link to a specific version of content with the view parameter. It's recommended not to pin a version unless that version is A) not the default view and B) the context is about that version specifically. To proceed with pinning a version add the &preserve-view=true to the URL.  Otherwise, remove the view parameter. URL: /javascript/api/@azure/service-bus/?view=azure-node-latest

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings or suggestions unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the learn.microsoft.com contributor guidesPost your question in the Learn support channel

#sign-off

no one seems to care.


What are differences to EfficientZero?

Hi there, I am wondering in which way your implementation differs from EfficientZero. Obviosuly the repo is named MuZero, but when I go to network specifications you define networks in haiku as EfficientZero. This suggets that this is actually EZ model, but it seems that the performance is slightly worse when compared to official results from the paper. That is why I am asking this, would just like to know what else is missing from the implementation. Cheers!

Sorry for the late reply!
The architecture was copied from the EfficientZero paper indeed. But all of the other algorithmic improvements are not implemented. Namely, the self-supervised representation learning loss, the value prefix trick, and the model-based off-policy correction were not implemented in this repo. These missing parts explain the performance gap.


Compilation error

I got a expected non-macro attribute, found attribute macro error when I tried to use it.

Hey, thanks for the report. I've initially been unable to reproduce this with the examples showcased in the documentation, but after searching for the error message a bit, I've found that you might have tried to write something like:
struct SomeStruct {
    #[cfg_attr(…, visibility::make(pub))]
    some_field: SomeType,
    …
}

In that case, indeed, Rust will complain since we are not allowed to put a procedural macro in that position.

Truth be told, I didn't think of this use case, but I can see how it might be useful. In order to support this use case, the best / least unergonomic API I can offer is the following:
#[visibility::with_field_granularity] // or some other name
struct SomeStruct {
    #[cfg_attr(…, visibility::make(pub))]
    some_field: SomeType,
    …
}

If that would suit you, I can implement this within the following weeks 🙂

The visible crate does this for struct fields.


Point to the roadmap wiki for release notes in nuspec files

We've moved our release notes from Release Notes to Roadmap. Point to Roadmap instead for all occurrences of <releaseNotes>https://github.com/Microsoft/ChakraCore/wiki/Release-Notes</releaseNotes> in this query.

@dilijev

Specific link https://github.com/Microsoft/ChakraCore/wiki/Roadmap#release-notes to scroll to the right part of the page.
Because the Release Notes page points to the new location in the Roadmap, existing links in packages already published will not be broken and the user will be able to find the right section of the page.

Current releases are fine. I'd recommend targeting this change to release/1.4 so that future patch releases will have the right link and that change will flow to all other branches.


Encountered a problem

When I execute the import data (02-import-data. Ipynb), an error is reported, indicating that the database is locked

Are you opening the database from another client?


Add an easy to use installer for Windows

The installation process on Windows seems to be pretty painful at the moment as it requires cygwin/perl to be installed and the link to download the PlatformSDK is broken.
Can you just add an MSI file to sort all this out for users please? We want people to secure their sites properly and if the tools aren't easy to use the temptation is very great to simply not bother with security.
Should note as I care about security I'm going to use openssl on my Mac instead which comes with it out the box, but that is a pretty poor workaround.

As a project it is our policy to only distribute source code. It is highly unlikely that that policy will change. There are a couple of different places where you can you download precompiled binaries:
https://wiki.openssl.org/index.php/Binaries

Seems like a reasonable approach for Linux and other *nix based OS's. Doesn't seem like a reasonable approach for Mac OS X or Windows.
A link at least to the wiki page in the Windows 'installer' would be good though.


Added accountId to SummonerDto

AccountId is added to SummonerDto as Match-V3 needs this attribute in the following calls:
-/lol/match/v3/matchlists/by-account/{accountId}
-/lol/match/v3/matchlists/by-account/{accountId}/recent

thank you @sigr3s but i dont understant to link with matchlists
i think this is not for match api but summoner api results ?

/lol/summoner/v3/summoners/by-account/{accountId}
/lol/summoner/v3/summoners/by-name/{summonerName}
/lol/summoner/v3/summoners/{summonerId}

thank you

Sorry about creating PR to master.
You are right this value is returned in the summoner api results. But you may need this attribute from this calls to make the match api ones.


Switch environment file with -e flag

prisma2 -e .env-file
Use case, developing locally, deploying to lambda using serverless, my package.json would have the following script:
"deploy-production": "yarn prisma2 lift up --auto-approve && sls deploy --stage production",

To make it work without this, I need to do the following for all env vars
"deploy-production": "DB_URL=$(cat .env.production | grep DB_URL | cut -d '=' -f 2) yarn prisma2 lift up --auto-approve && sls deploy --stage production",

I like the idea but would suggest to call the argument --env-file same as Docker:

In order to tackle this, we need to create a spec document first, which holistically describes our env var approach.

This is mostly relevant for Migrate, so we will not do any product work on this before the launch of Client.

This would also solve the issue which arose since the change to how the .env file is located (https://github.com/prisma/prisma2/issues/1519) in preview022.
Right now we either have to write some loader script, or have the .env file in multiple locations. Neither is very appealing.

This also seems relevant for making yarn prisma2 generate work with an .env in the project root (instead of the prisma folder) as discussed in #1519, unless someone else knows another way to run that without copying/symlinking my application's .env file to the prisma folder (or managing multiple .env files).

In the mean time, dotenv-cli can be used as a workaround. It works with npm/yarn scripts as well.

@divslinger got an example of using dotenv? Right now I am renaming my .env files before every deploy.

@jimsorock for prisma migrate am using something like
dotenv -e prisma/.env.prod -- npx prisma migrate save --experimental
Similarly for migrate up. Seems to work fine with dotenv-cli.
But i cant get a similar setup to work for prisma generate. It will keep targeting the default .env file.

I hate to pile on to the +1, but having a configurable env location would be really helpful.
All of our applications use a pretty standard config.env that we lay down via our build for AWS.  Adding this one off is annoying and makes it a harder sell to our team for adoption.

Hi @mjknight50
What does environment switching look like with this setup?

/config/production.env
/config/development.env
...

Something like that?

Hi @matthewmueller
In our shop, we lay down the different environmental variables via AWS Parameter Store while the image is built (Docker) and then pushed to AWS.
It's a pretty conventional env file:
port=4300
whatever=foo

# MySQL
MYSQL_HOST=XXX
MYSQL_PORT=3306
MYSQL_USER=XXX
MYSQL_PASS=XXX
MYSQL_DB=XX

#here is some more config for something else like passport-saml

We grab the config file for each region (sandbox, production) via a script:
get config file
aws ssm get-parameter
--region us-east-1
--name "/custom-apps/${SECRETS_APP_NAME}/${SECRETS_APP_ENV}/config.env"
--output text --query 'Parameter.Value'
--with-decryption \

/usr/src/app/dist/config/config.env

So, circling back to the original question or issue.
It would be ideal to have my connection string for Prisma just be a value in config.env and not a whole separate env just for Prisma.
Yes, I could add it in to the build process, but Prisma is kind of an outlier here as pointed out:
https://github.com/motdotla/dotenv#should-i-have-multiple-env-files
Maybe I am missing something in the Prisma connection string options?   I don't know...

@mjknight50 thanks for clarifying your setup!
I think we may have you covered already if you ignore the .env file entirely or only use it for development. It depends a bit on your setup:
Case 1: If config.env loaded into the environment before your app starts ``, we can use DATABASE_URL in the environment.
DATABASE_URL="postgresql://johndoe:randompassword@localhost:5432/mydb?schema=public" node app.js

import { PrismaClient } from '@prisma/client'
const client = new PrismaClient()

Case 2: If config.env is loaded by the application using dotenv or some equivalent, you can load the environment before initializing the client
node app.js

import { PrismaClient } from '@prisma/client'

// Normally you'd do dotenv.load("./config.env") or something
process.env.DATABASE_URL = "postgresql://johndoe:randompassword@localhost:5432/mydb?schema=public"

const client = new PrismaClient()

Would one of these options work for you?

Ah, so as long as I set an environmental variable to DATABASE_URL we're good... no matter where or how.
Great, thanks!  I apologize if you had stated this somewhere in documentation and I missed it.  It seemed like I had to use the .env file the examples.   It is clear now that Prisma is just looking for DATABASE_URL
Thanks for your time and help!

This would also help avoiding warn(prisma) Conflict for env vars for us who rely on symlinks for monorepo setups. #9726

it would be great if we can just pass in
const prisma = new PrismaClient({url: process.env.DATABASE_URL})

@senghuotlay You can: https://www.prisma.io/docs/orm/reference/prisma-client-reference#datasourceurl


Remove Old "Show in Local Time" toggle

We don't longer use this, however, we are going to keep it hidden until we are sure that users don't want to show the calendar in US Pacific Time.
Openning this issue as a reminder to delete it in the future.

@maririos I'm unassigning myself from this issue, but if I recall correctly this toggle is now gone. If that's the case, you can close this.


Decompose the sync function template

The sync function template file (etc/sync-function-template.js) has grown to a size that makes it increasingly difficult to navigate its embedded functions and variables. Group related components into external files/modules and import them into each generated sync function using a technique similar to that used in #67 for modular document definitions.

Addressed by #83


添加 Ruby on Rails Guide

添加 Ruby on Rails 简体中文指南

Great addition! We'd really appreciate it if you made the linter happy. It wants the lists in unicode sort order (笨 after R).


Add global lock for syslog structured output conversion to avoid bug

Summary
In the go-syslog code, there is global state causing concurrent messages being constructed to occasionally stomp on each other. I'm working on an upstream fix here, but in the meantime until that gets published, we want to prevent this from happening.

[x] Signed CLA.
[x] Associated README.md updated.
[x] Has appropriate unit tests.

I think Shri's changes are in the release branch right now. This fix might be held up by that unless we work around it somehow.


files.put not updating (on r/w filesystem)

Kind of like #878, here's another files.put silently failing to update the file. Before:
bang% ls -l /tmp/net_traffic.aarch64
-rwxrwxr-x 1 drewp drewp 8361192 Dec 30 15:22 /tmp/net_traffic.aarch64

pipe% % ls -l /opt/net_traffic/
total 8132
-rwxr-xr-x 1 root root 8326736 Dec  2 10:11 net_traffic.aarch64

bang% sudo ssh root@pipe touch /opt/net_traffic/not_a_readonly_fs

pipe% ls -l /opt/net_traffic/
total 8132
-rwxr-xr-x 1 root root 8326736 Dec  2 10:11 net_traffic.aarch64
-rw-r--r-- 1 root root       0 Dec 30 15:48 not_a_readonly_fs

deploy.py follows:
from pyinfra.operations import files, systemd

target = '/opt/net_traffic'

files.directory(target)
files.put(src="/tmp/net_traffic.aarch64", dest=target, mode="a+rx")

files.put(src='./net_traffic.service',
          dest='/etc/systemd/system/net_traffic.service')
systemd.service(service='net_traffic.service',
                daemon_reload=True,
                enabled=True,
                running=True,
                restarted=True)

I ran pyinfra -vvv pipe deploy.py.
pyinfra logs:
      6 --> Connecting to hosts...
      7     [pipe] Connected
      8
      9 --> Preparing Operations...
     10     Loading: deploy.py
     11 [pipe] >>> sh -c '! (test -e /opt/net_traffic || test -L /opt/net_traffic ) || ( stat -c '"'"'user=%U group=%G mode=%A atime=%X mtime=%Y ctime=%Z size=%s %N'"'"' /opt/net_traffic 2> /dev/null || stat -f '"'"'user=%Su group=%Sg mode=%Sp atime=%a mtime=%m ctime=%c s     11 ize=%z %N%SY'"'"' /opt/net_traffic )'
     12 [pipe] user=drewp group=drewp mode=drwxrwxr-x atime=1672441894 mtime=1670004715 ctime=1670004715 size=4096 '/opt/net_traffic'
     13     [pipe] Loaded fact files.Directory (path=/opt/net_traffic)
     14     [pipe] noop: directory /opt/net_traffic already exists
     15 [pipe] >>> sh -c '! (test -e /opt/net_traffic || test -L /opt/net_traffic ) || ( stat -c '"'"'user=%U group=%G mode=%A atime=%X mtime=%Y ctime=%Z size=%s %N'"'"' /opt/net_traffic 2> /dev/null || stat -f '"'"'user=%Su group=%Sg mode=%Sp atime=%a mtime=%m ctime=%c s     15 ize=%z %N%SY'"'"' /opt/net_traffic )'
     16 [pipe] user=drewp group=drewp mode=drwxrwxr-x atime=1672441894 mtime=1670004715 ctime=1670004715 size=4096 '/opt/net_traffic'
     17     [pipe] Loaded fact files.File (path=/opt/net_traffic)
     18 [pipe] >>> sh -c '! (test -e /opt/net_traffic/net_traffic.aarch64 || test -L /opt/net_traffic/net_traffic.aarch64 ) || ( stat -c '"'"'user=%U group=%G mode=%A atime=%X mtime=%Y ctime=%Z size=%s %N'"'"' /opt/net_traffic/net_traffic.aarch64 2> /dev/null || stat -f '     18 "'"'user=%Su group=%Sg mode=%Sp atime=%a mtime=%m ctime=%c size=%z %N%SY'"'"' /opt/net_traffic/net_traffic.aarch64 )'
     19 [pipe] user=root group=root mode=-rwxr-xr-x atime=1672442515 mtime=1670004716 ctime=1672442515 size=8326736 '/opt/net_traffic/net_traffic.aarch64'
     20     [pipe] Loaded fact files.File (path=/opt/net_traffic/net_traffic.aarch64)
     21 [pipe] >>> sh -c '! (test -e /etc/systemd/system/net_traffic.service || test -L /etc/systemd/system/net_traffic.service ) || ( stat -c '"'"'user=%U group=%G mode=%A atime=%X mtime=%Y ctime=%Z size=%s %N'"'"' /etc/systemd/system/net_traffic.service 2> /dev/null ||      21 stat -f '"'"'user=%Su group=%Sg mode=%Sp atime=%a mtime=%m ctime=%c size=%z %N%SY'"'"' /etc/systemd/system/net_traffic.service )'
     22 [pipe] user=root group=root mode=-rw-r--r-- atime=1672438834 mtime=1670004649 ctime=1670004649 size=273 '/etc/systemd/system/net_traffic.service'
     23     [pipe] Loaded fact files.File (path=/etc/systemd/system/net_traffic.service)
     24 [pipe] >>> sh -c '! (test -e /etc/systemd/system || test -L /etc/systemd/system ) || ( stat -c '"'"'user=%U group=%G mode=%A atime=%X mtime=%Y ctime=%Z size=%s %N'"'"' /etc/systemd/system 2> /dev/null || stat -f '"'"'user=%Su group=%Sg mode=%Sp atime=%a mtime=%m c     24 time=%c size=%z %N%SY'"'"' /etc/systemd/system )'
     25 [pipe] user=root group=root mode=drwxr-xr-x atime=1672438834 mtime=1671657241 ctime=1671657241 size=4096 '/etc/systemd/system'
     26     [pipe] Loaded fact files.Directory (path=/etc/systemd/system)
     27 [pipe] >>> sh -c 'test -e /etc/systemd/system/net_traffic.service && ( sha1sum /etc/systemd/system/net_traffic.service 2> /dev/null || shasum /etc/systemd/system/net_traffic.service 2> /dev/null || sha1 /etc/systemd/system/net_traffic.service ) || true'
     28 [pipe] ba56cf7b6203fb99310c395dd490bd86c090090f  /etc/systemd/system/net_traffic.service
     29     [pipe] Loaded fact files.Sha1File (path=/etc/systemd/system/net_traffic.service)
     30     [pipe] noop: file /etc/systemd/system/net_traffic.service is already uploaded
     31 [pipe] >>> sh -c '! command -v systemctl >/dev/null || systemctl show --all --property Id --property SubState '"'"'*'"'"''

(service lines removed)

   1989     [pipe] Loaded fact systemd.SystemdEnabled (machine=None, user_mode=False, user_name=None)
   1990     [pipe] Ready: deploy.py
   1991
   1992 --> Proposed changes:
   1993     Ungrouped:
   1994     [pipe]   Operations: 4   Change: 2   No change: 2
   1995
   1996
   1997 --> Beginning operation run...
   1998 --> Starting operation: Files/Directory (/opt/net_traffic)
   1999     [pipe] No changes
   2000
   2001 --> Starting operation: Files/Put (src=/tmp/net_traffic.aarch64, dest=/opt/net_traffic, mode=a+rx, force=True)
   2002     Failed to upload file, retrying: Failure
   2003 [pipe] file uploaded: /opt/net_traffic/net_traffic.aarch64
   2004 [pipe] >>> sh -c 'chmod a+rx /opt/net_traffic/net_traffic.aarch64'
   2005     [pipe] Success
   2006
   2007 --> Starting operation: Files/Put (src=./net_traffic.service, dest=/etc/systemd/system/net_traffic.service)
   2008     [pipe] No changes
   2009
   2010 --> Starting operation: Systemd/Service (service=net_traffic.service, daemon_reload=True, enabled=True, running=True, restarted=True)
   2011 [pipe] >>> sh -c 'systemctl daemon-reload'
   2012 [pipe] >>> sh -c 'systemctl restart net_traffic.service'
   2013     [pipe] Success
   2014
   2015
   2016 --> Results:
   2017     Ungrouped:
   2018     [pipe]   Changed: 2   No change: 2   Errors: 0

2003,2005 suggest success, but the new file content has not actually been put:
% ls -l /opt/net_traffic/
total 8132
-rwxr-xr-x 1 root root 8326736 Dec  2 10:11 net_traffic.aarch64
-rw-r--r-- 1 root root       0 Dec 30 15:48 not_a_readonly_fs

Retrying with put(...,force=True) didn't help.
pyinfra 2.6

Thank you for raising this @drewp, concerning given the similar #878 - at this point I'm not sure I trust paramiko's checking of the uploaded size to properly validate an upload. Worst thing is the false positive so I think a solution to that is to calculate a checksum of the file locally and after uploading to compare which should prevent any such issues.
Regarding this issue specifically - does this happen every time or only on some occaisions?

Had a second pass at the retry code and found a pyinfra bug which may well be the cause of both false-positives here! Won't fix any underlying issues but will raise the errors properly. I believe in this case it would now retry correctly and likely succeed (note paramiko does identify the failure "Failed to upload file, retrying: Failure").
Fix: https://github.com/Fizzadar/pyinfra/commit/277cb6fedd7b025940b254817b302ab1149bee76
Released just now in v2.6.1.

With 2.6.1:
--> Starting operation: Files/Put (src=/tmp/net_traffic.aarch64, dest=/opt/net_traffic, mode=a+rx, force=True)
    Failed to upload file, retrying: Failure
    Failed to upload file, retrying: Failure
    Failed to upload file, retrying: Failure
    [pipe] Command socket/SSH error: OSError('Failure',)
    [pipe] Error: executed 0/2 commands
--> pyinfra error: No hosts remaining!

:)

--> Starting operation: Files/Put (src=/tmp/net_traffic.aarch64, dest=/opt/net_traffic, mode=a+rx, force=True)
Traceback (most recent call last):
  File "/stor6/my/proj/infra/env/lib/python3.10/site-packages/pyinfra/connectors/ssh.py", line 480, in _put_file
    sftp.putfo(file_io, remote_location)
  File "/stor6/my/proj/infra/env/lib/python3.10/site-packages/paramiko/sftp_client.py", line 714, in putfo
    with self.file(remotepath, "wb") as fr:
  File "/stor6/my/proj/infra/env/lib/python3.10/site-packages/paramiko/sftp_client.py", line 372, in open
    t, msg = self._request(CMD_OPEN, filename, imode, attrblock)
  File "/stor6/my/proj/infra/env/lib/python3.10/site-packages/paramiko/sftp_client.py", line 822, in _request
    return self._read_response(num)
  File "/stor6/my/proj/infra/env/lib/python3.10/site-packages/paramiko/sftp_client.py", line 874, in _read_response
    self._convert_status(msg)
  File "/stor6/my/proj/infra/env/lib/python3.10/site-packages/paramiko/sftp_client.py", line 907, in _convert_status
    raise IOError(text)

code=4 and text=Failure

Hm, rather annoyingly per this table code 4 is an unknown/generic failure and the text should explain more. It is interesting that the issue seems to be opening the remote file, rather than part of the upload. @drewp would you mind testing a few things here as this seems specific to your setup?:

do other remote file locations work
can you upload other files to other locations
can you upload this file using scp

This should give us a bit more debugging direction I think 🙏!


Bug: Fixed Homepage's Responsiveness

Description:
This PR fixes the Responsiveness Issue for the Landing Page and ensures that the website is compatible with all devices.
Issue Mentioned:
Closes #628
Video:
https://github.com/mdazfar2/HelpOps-Hub/assets/72603662/f413e1b6-ee32-4e84-8143-f1339a8d0b18
DarkMode:

Additional Context:
N/A

@mdazfar2 kindly review

@shreyash3087 please update sync fork

done


Feature request: interactive ruckus in drracket

I'm super excited to see Ruckus, and would love to use it in teaching my kids. I'm wondering if there's any hope of getting Ruckus to work in an interactive mode similar to what OpenSCAD does, where when you hit #R, you immediately get a visualization of your model to pop up.

It's certainly possible!  I just haven't put the work in.
My workflow in Ruckus is to edit in vi and hit F5 to reload the design.  (This is also my workflow in OpenSCAD; I don't care for the internal text editor in either OpenSCAD or DrRacket.)

Yeah, I mostly want it for using with my kids, for whom the DrRacket IDE is a real boon.

That makes sense.  (I know adults who love DrRacket -- no judgment.  It's just not something I've put work into.)
I'm going to leave this open because it would be a great addition, but I'm not personally likely to get time to hack on it soon.


Migrated wiki to GitHub Pages + MkDocs ❤

Hey there! The context for this PR is in #153
Demo
First, here is a demo of the GitHub Pages + MkDocs running on my fork of this repo; https://vestrel00.github.io/mobius/
https://user-images.githubusercontent.com/4332753/158274451-fae0196f-14c0-467e-b659-7fa8234b87d1.mp4
Here's a side-by-side of the wiki (left) vs MkDocs (right) in a mobile browser.
https://user-images.githubusercontent.com/4332753/158274523-7247da7b-2cf7-4e83-858f-e8d77972747b.mp4
Here's what I've done in this PR
Here are the exact steps I took in cooking up this PR.

Install MkDocs on my machine (MBP - Big Sur)
Install Material for MkDocs on my machine
Clone the wiki

git clone https://github.com/spotify/mobius.wiki.git
I cloned it yesterday. The most recent commit in my clone is 66d6eef10cd91002f780e141d71dd57e6adebe78

Cloned wiki and placed it all into docs folder
Moved contents of wiki Home to README
Moved images to docs/assets/images folder
Removed wiki _Sidebar file and moved files into folders to match the structure in the wiki sidebar
Fixed links and made them relative and formatted non-code paragraphs
Added header titles to each docs page (the wiki pages used the file names as the page title)
Lower cased all file names in docs
Added mkdocs config (mkdocs is now ready to serve and build a fully functional site)
Added shell script for generating website via mkdocs

I'm not sure if there is a way to have done all this automatically. Even if there is, you can bet that I did a better job because I put a lot of love and care when working on this (I even made sure the markdown formatting is top-notch) ❤🔥

Next steps
If you like what you see, please feel free to merge this PR or just use it as a reference and DIY. In the case the you do merge this, here's what you need to do next to complete everything and get the website up and running.

Review this PR thoroughly and resolve every comment I added
Merge this PR
Install MkDocs on your machine
Install Material for MkDocs on your machine
Run the mkdocs.sh to generate the website locally

./mkdocs.sh
The website will be in the generated site folder
Move the site folder outside of the project directory

Create a new empty (orphan) branch called gh-pages

https://gist.github.com/ozh/4734410git checkout --orphan gh-pages
git rm -rf .

Add an empty file with the name .nojekyll

echo "" > .nojekyll

Move the contents of the site folder into the root folder of the project
Delete the empty site folder
Commit everything and push it up the gh-pages branch
Go to the GitHub Settings -> Code and automation (Pages)
Set source branch to gh-pages and folder to / (root)

This is typically done automagically by GitHub for you when pushing up the gh-pages branch for the first time.

Edit repository details and set the Website to https://spotify.github.io/mobius/
Celebrate! 🥂🎉

Maintenance
So you decided to adopt GitHub Pages + MkDocs? Here's how you'd keep it up-to-date.

Make all of the documentation changes in the main branch
Run the mkdocs.sh to generate the website locally

./mkdocs.sh
The website will be in the generated site folder

Checkout to the gh-pages branch

git checkout gh-pages

Delete all tracked and untracked files, except for the .nojekyll file
Move the contents of the site folder into the root folder of the project
Delete the empty site folder
Commit everything and push it up the gh-pages branch

It might take a few seconds or minutes for the website to update but it will 👌

You might want to look into automating these steps with GitHub actions. I'm not sure if the community came up with any automation around this yet. I do things manually on my projects. It's not much work IMO.

Great job! Really appreciated the detailed description and the demos. 😄
I'll merge this and follow the Next steps to get it up and running (thanks for the instructions too btw!)

❤ ❤ ❤ ❤ ❤ ❤ ❤ ❤ ❤ ❤ ❤ ❤ ❤ ❤ ❤ ❤ ❤ ❤ ❤ 🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥🔥


cannot set blockOwnerDeletion if an ownerReference refers to a resource you can't set finalizers on: , "

Bug Report

What did you do?
Deploy a controller on the openshift cluster

What did you expect to see?
reconciliation loop to succeed.

What did you see instead? Under which circumstances?
2020-10-13T11:31:23.909Z	INFO	controllers.KataConfig	Creating a new installation Daemonset	{"ds.Namespace": "kata-operator-system", "ds.Name": "kata-operator-daemon-install"}
2020-10-13T11:31:23.918Z	ERROR	controller	Reconciler error	{"reconcilerGroup": "kataconfiguration.openshift.io", "reconcilerKind": "KataConfig", "controller": "kataconfig", "name": "kataconfig-sample", "namespace": "", "error": "daemonsets.apps \"kata-operator-daemon-install\" is forbidden: cannot set blockOwnerDeletion if an ownerReference refers to a resource you can't set finalizers on: , <nil>"}
github.com/go-logr/zapr.(*zapLogger).Error
	/go/pkg/mod/github.com/go-logr/zapr@v0.2.0/zapr.go:132
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.6.3/pkg/internal/controller/controller.go:246
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.6.3/pkg/internal/controller/controller.go:218
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).worker
	/go/pkg/mod/sigs.k8s.io/controller-runtime@v0.6.3/pkg/internal/controller/controller.go:197
k8s.io/apimachinery/pkg/util/wait.BackoffUntil.func1
	/go/pkg/mod/k8s.io/apimachinery@v0.19.0/pkg/util/wait/wait.go:155
k8s.io/apimachinery/pkg/util/wait.BackoffUntil
	/go/pkg/mod/k8s.io/apimachinery@v0.19.0/pkg/util/wait/wait.go:156
k8s.io/apimachinery/pkg/util/wait.JitterUntil
	/go/pkg/mod/k8s.io/apimachinery@v0.19.0/pkg/util/wait/wait.go:133
k8s.io/apimachinery/pkg/util/wait.Until
	/go/pkg/mod/k8s.io/apimachinery@v0.19.0/pkg/util/wait/wait.go:90

Environment
Operator type:

/language go

Kubernetes cluster type:
OpenShift

$ operator-sdk version
operator-sdk version: "v0.16.0", commit: "55f1446c5f472e7d8e308dcdf36d0d7fc44fc4fd", go version: "go1.13.8 linux/amd64"

$ go version (if language is Go)
go version go1.15.2 linux/amd64

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.2-0-g52c56ce", GitCommit:"711c56a65d92d8a61930378670ba92e04a27ef86", GitTreeState:"clean", BuildDate:"2020-07-01T23:11:19Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.0+d59ce34", GitCommit:"d59ce3486ae3ca3a0c36e5498e56f51594076596", GitTreeState:"clean", BuildDate:"2020-10-08T15:58:07Z", GoVersion:"go1.15.0", Compiler:"gc", Platform:"linux/amd64"}

Possible Solution

Additional context

I have already added the daemonset finalizers to role.yaml but doesn't seem to be helping.

Getting the same result with operator sdk v1.0.1,
operator-sdk version: "v1.0.1-10-g3efd819c", commit: "3efd819c712f96fa9ce85133c6b660f0c37bb23f", kubernetes version: "v1.18.2", go version: "go1.15.2 linux/amd64", GOOS: "linux", GOARCH: "amd64"

@harche It looks like you're trying to set blockOwnerDeletion in an owner reference that refers to a kataconfiguration.openshift.io KataConfig object. Therefore, I think you need the finalizers permission on the KataConfig resources (not the DaemonSets).

Oh yes, sorry I overlooked that. Thanks for pointing that out.


GridField "link existing" autocomplete is broken

You can trigger the autocomplete by typing something, but when you hover over the results with your mouse in order to click it, the results disappear. Tested in latest Chrome.

Frustrating UX

This seems resolved to me, tested in frameworktest module although the border and drop-shadow of the dropdown are missing.

Tested and fixed.

Am encountering this in 4.1 at the moment, somehow it has resurfaced.


No way to achieve CSRR on a capability

The RISC-V spec says that CSRR rd, csr is encoded as CSRRS rd, csr, x0. Under the current CHERI-RISC-V spec, CSRRS can only read the address, not the metadata. CSRRW has a special case for rd=x0 but none for rs1=x0, so unless I'm missing something, it's not possible to read the full value of a capability CSR without overwriting its contents?

Yes, you are correct, the RISC-V spec states this:

For both CSRRS and CSRRC, if rs1=x0, then the instruction will not write to the CSR at all ...
Both CSRRS and CSRRC always read the addressed CSR and cause any read side effects
regardless of rs1 and rd fields. Note that if rs1 specifies a register holding a zero value other
than x0, the instruction will still attempt to write the unmodified value back to the CSR and
will cause any attendant side effects. A CSRRW with rs1=x0 will attempt to write zero to the
destination CSR.

This needs to be fixed, otherwise there is no way to read a whole cap from CSRs without writing to it.

Reading the priv spec, it sounds like we have to change CSRS (and most likely also CSRC) to return the full capability register in capmode. This then allows csrr cd, <reg> to be encoded as csrs cd, <reg>. I don't think this should add much implementation complexity?

The main issue here would be needing to special-case things so that if you're trying to read a sealed capability it doesn't count as a set address

The main issue here would be needing to special-case things so that if you're trying to read a sealed capability it doesn't count as a set address

The privileged spec already has the following wording:

For both CSRRS and CSRRC, if rs1=x0, then the instruction will not write to the CSR at all, and so shall not cause any of the side effects that might otherwise occur on a CSR write, nor raise illegalinstruction exceptions on accesses to read-only CSRs. Both CSRRS and CSRRC always read the addressed CSR and cause any read side effects regardless of rs1 and rd fields. Note that if rs1 specifies a register holding a zero value other than x0, the instruction will still attempt to write the unmodified value back to the CSR and will cause any attendant side effects. A CSRRW with rs1=x0 will attempt to write zero to the destination CSR.

This implies that using x0 is just a read?

Hmm, thinking on this a little more: isn't the main purpose of having pcc in a CSR to allow legacy mode (I guess without fast mode switch instructions) to get hold of a PCC to jump to to get itself into cap-mode in the first place? Wouldn't making CSRRS only return the full capability in cap mode undermine that goal?

Hmm, thinking on this a little more: isn't the main purpose of having pcc in a CSR to allow legacy mode (I guess without fast mode switch instructions) to get hold of a pcc to jump to to get itself into cap-mode in the first place? Wouldn't making CSRRS only return the full capability in cap mode undermine that goal?

I agree that without the mode switch you would need an explicit instruction to get PCC, so allocating csr space for it doesn't make much sense IMO. But isn't that an orthogonal issue? This issue is about being able to read a CLEN-size csr without writing to it and making csrrs mode-aware seems like the approach that makes the most sense.

Is there actually a sensible use case for having legacy support without a mode switching instruction?

Is there actually a sensible use case for having legacy support without a mode switching instruction?

I doubt it and requiring the switch would also avoid the need for this kind of getpcc workaround.

Is there actually a sensible use case for having legacy support without a mode switching instruction?

I doubt it and requiring the switch would also avoid the need for this kind of getpcc workaround.

Unless there's a compelling reason to support such a configuration it seems like optionality for the sake of it rather than because it serves a purpose.

To be clear then, we're proposing that Zcheri_mode (or whatever it ends up getting called) is mandatory if you support both the new base ISA (Zcheri_purecap) and Zcheri_legacy? I suppose it must remain a separate extension then to allow Zcheri_purecap only or Zcheri_legacy only to exist. Regardless, sounds like mode issues are being discussed elsewhere, so I'll submit a PR to fix this that just gets the capability metadata in capmode.

This removes the point of Zcheri_mode entirely - and the simple objective here was to allow legacy mode without allocating the mode bit in the PCC - so that it can be used for another purpose.
We could argue that this isn't useful - merge Zcheri_legacy and Zcheri_mode - as they previously were before I separated out Zcheri_mode - and say that if that pcc.M is reserved it must be a purecap only core.
This is certainly possible as a direction, and a specification simplification.

Is there actually a sensible use case for having legacy support without a mode switching instruction?

I doubt it and requiring the switch would also avoid the need for this kind of getpcc workaround.

Unless there's a compelling reason to support such a configuration it seems like optionality for the sake of it rather than because it serves a purpose.

I answered a similar question in the CHERI SIG's mailing list, so I will paste some of that answer here:
Compatibility with standard RISC-V is a key goal of the currently proposed CHERI draft specification with the expectation that this will facilitate ratification. Another equally important goal was that the specification allows designing purecap-only implementations. Therefore, the specification was split into three main extensions.

Zcheri_purecap: The core of CHERI which is sufficient for purecap-only implementations

Then there are two extensions providing different levels of support for compatibility with standard RISC-V:

Zcheri_legacy: Introduces Legacy mode. The machine's current CHERI execution mode is given by a bit in xenvcfg. The idea is that supporting Zcheri_purecap and Zcheri_legacy is sufficient for implementations that are expecting to execute programs that are either only purecap, or only capability unaware standard RISC-V. Zcheri_legacy by itself is not meant for hybrid software that expects to frequently change CHERI execution mode, for example, a program that is mostly purecap but relies on a library that is capability unaware standard RISC-V. Therefore, Zcheri_legacy does not allocate a mode bit in the capability metadata, so there are more reserved bits in the capability format for future extensions -- this is particularly important for RV32 where space is very limited.

Note: M-mode must still be capability-aware because there is currently no way of forcing it to Legacy with Zcheri_legacy only in the current spec.

Zcheri_mode: Built on top of both Zcheri_purecap and Zcheri_legacy. The extension introduces the mode (M) bit in the capability format and instructions to switch CHERI execution mode. Implementations supporting Zcheri_mode are suitable for executing hybrid programs efficiently. Implementations supporting Zcheri_mode are of course able to execute purecap and capability unaware standard RISC-V programs as well.

Ok, so the use case is you want to have a CHERI system and run some old binaries without needing to allocate something in PCC’s metadata to support it. So in that world there’s no need to read PCC in legacy code and this the concern doesn’t exist?

Hmm, thinking on this a little more: isn't the main purpose of having pcc in a CSR to allow legacy mode (I guess without fast mode switch instructions) to get hold of a pcc to jump to to get itself into cap-mode in the first place? Wouldn't making CSRRS only return the full capability in cap mode undermine that goal?

I agree that without the mode switch you would need an explicit instruction to get PCC, so allocating csr space for it doesn't make much sense IMO. But isn't that an orthogonal issue? This issue is about being able to read a CLEN-size csr without writing to it and making csrrs mode-aware seems like the approach that makes the most sense.

The purpose of PCC in a CSR is not for programs in Legacy mode. It is for debuggers to get a hold of PCC.
Recall that entering debug mode causes PCC to be set to Infinite capability. And that debuggers will need a source of authority to, for example, perform memory access particularly when only implementing Zcheri_purecap and there is no ddc. In this case, you need to get your source of authority from somewhere and the easiest way is to provide access to PCC which is set to Infinite. However, the problem is that the debug spec allows implementations to not support executing PC relative instructions from the program buffer (like AUIPCC) and this is a very common implementation choice. So the solution currently in the spec is to expose PCC as a CSR so the debugger can simply do csrr cd, pcc to get that source of authority.

Ok, so the use case is you want to have a CHERI system and run some old binaries without needing to allocate something in PCC’s metadata to support it. So in that world there’s no need to read PCC in legacy code and this the concern doesn’t exist?

@jrtc27 : Yes. And the purpose of PCC access via a CSR is as I described above

Could we change the spec as follows to resolve this issue?

CSRRS/CSRRC, if rs1=x0, to only read a full capability when the CSR number accessed is a CLEN-wide CSR
CSRRS/CSRRC, if rs1!=x0, write the address part of the CSR in the way the instruction normally would with the CHERI constrains that are well understood (rep, sealing, etc check) and:

read XLEN (i.e. address only) if the CSR number accessed is a XLEN-wide CSR
read CLEN (i.e. whole cap) if the CSR number accessed is a XLEN-wide CSR.

Could we change the spec as follows to resolve this issue?

CSRRS/CSRRC, if rs1=x0, to only read a full capability when the CSR number accessed is a CLEN-wide CSR

CSRRS/CSRRC, if rs1!=x0, write the address part of the CSR in the way the instruction normally would with the CHERI constrains that are well understood (rep, sealing, etc check) and:

read XLEN (i.e. address only) if the CSR number accessed is a XLEN-wide CSR
read CLEN (i.e. whole cap) if the CSR number accessed is a XLEN-wide CSR.

I agree with this, but for the rs1=0 case it should still read XLEN for an XLEN-wide CSR?
For clarification, are you proposing it reads CLEN regardless of mode or only when in capability mode?

Hmm, thinking on this a little more: isn't the main purpose of having pcc in a CSR to allow legacy mode (I guess without fast mode switch instructions) to get hold of a pcc to jump to to get itself into cap-mode in the first place? Wouldn't making CSRRS only return the full capability in cap mode undermine that goal?

I agree that without the mode switch you would need an explicit instruction to get PCC, so allocating csr space for it doesn't make much sense IMO. But isn't that an orthogonal issue? This issue is about being able to read a CLEN-size csr without writing to it and making csrrs mode-aware seems like the approach that makes the most sense.

The purpose of PCC in a CSR is not for programs in Legacy mode. It is for debuggers to get a hold of PCC.
Recall that entering debug mode causes PCC to be set to Infinite capability. And that debuggers will need a source of authority to, for example, perform memory access particularly when only implementing Zcheri_purecap and there is no ddc. In this case, you need to get your source of authority from somewhere and the easiest way is to provide access to PCC which is set to Infinite. However, the problem is that the debug spec allows implementations to not support executing PC relative instructions from the program buffer (like AUIPCC) and this is a very common implementation choice. So the solution currently in the spec is to expose PCC as a CSR so the debugger can simply do csrr cd, pcc to get that source of authority.

If it's just for the debugger, wouldn't it also be simpler to allocate a dinfinite CLEN CSR (or some more sensible name) to get access to inifinitey instead of writing PCC as infinite and then reading that?

Could we change the spec as follows to resolve this issue?

CSRRS/CSRRC, if rs1=x0, to only read a full capability when the CSR number accessed is a CLEN-wide CSR

CSRRS/CSRRC, if rs1!=x0, write the address part of the CSR in the way the instruction normally would with the CHERI constrains that are well understood (rep, sealing, etc check) and:

read XLEN (i.e. address only) if the CSR number accessed is a XLEN-wide CSR
read CLEN (i.e. whole cap) if the CSR number accessed is a XLEN-wide CSR.

I agree with this, but for the rs1=0 case it should still read XLEN for an XLEN-wide CSR?
For clarification, are you proposing it reads CLEN regardless of mode or only when in capability mode?

I am proposing that these instructions do not depend on the mode. The amount of data you read/write depends on the CSR number that you access just like in the case for CSRRW:

If you access any of the standard RISC-V CSR numbers, you will always get an XLEN-wide read
If you access any of the new alias CSR numbers from the CHERI extension, you will always get a CLEN-wide read

If it's just for the debugger, wouldn't it also be simpler to allocate a dinfinite CLEN CSR (or some more sensible name) to get access to inifinitey instead of writing PCC as infinite and then reading that?

That's another way of doing it and that register would need to only be accessible in Debug mode.


Delta is not available for AP districts

Daily updates were missing from AP districts, Please check and update.
Thanks a lot for developing this API.

This could be a delay in updating the cases. Volunteers update the case data through out the day. Earlier on some days and later on other.
We assure we will update them all! Thanks for reporting!


Way to disable runtime environment variables

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.6.2 windows/amd64

What operating system and processor architecture are you using (go env)?

set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\projects\golang
set GORACE=
set GOROOT=C:\Go
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GO15VENDOREXPERIMENT=1
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0
set CXX=g++
set CGO_ENABLED=1

What did you do?
Building software

What did you expect to see?
Way to disable runtime environment variables (like GOMAXPROCS, GODEBUG, etc...) for release build which will shipped to end users. I don't want to get this funtional to end users of my program.

What did you see instead?
I can't find any way to do this at this moment

There is no way to prevent a Go program from checking those environment variables.  That is not a feature we are going to add without a good reason.  Having those environment variables is complicated enough.  Having a way to disable them makes the runtime that much more complicated.


Refactor parser

Warning: massive brain dump here largely unproductive.
Preface: the lib has great compliance to the spec, but I personally find the code base could be cleaned up a bit. This is largely a superficial nudge in one direction, removing static, stop using exposing public fields, etc.
This is just a quick and dirty first pass trying to get the interfaces to be slightly nicer. Next pass would be to work on using type checking instead of relying on checking field existence.
Problems: it's not backward compliant in anyway. One could also argue that in the current state it's not much of an improvement. I just wanted to put a feeler out there for wether you guys wish to take the project in a direction that allows for DI, doesn't rely on statics and doesn't expose internal data structures.
Oh also 2 of the tests are still failing I will get on that.
Thoughts?

I do agree with some of your statements and disagree with some others.
For example about using publics vs getters/setters - this is because of performance reasons primarily. PHP is not the best tool for parsers and huge queries already produce significant overhead. It is not uncommon to use public props for this. For example Doctrine ORM does the same for the most intensive cases: https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php#L46
As for other notes and changes - will get back to you as soon as I get a chance. Give me some time to digest it %)

Yeah totally up to you :) I was just playing about, wanted to use the parser for something else and "needed" / wanted it to resemble what is was replacing slightly more.

I reviewed your changes and will definitely cherry-pick some of them. Yet there are two main principles which I prefer to follow in this lib:

Backwards compatibility and deprecation strategy vs breaking. In other words - deprecated stuff stays in library long enough for all users to adapt (with optional E_USER_DEPRECATED notice) - for at least one medium release (better longer if possible).

It is not always possible, but very desireable. We only had one release with major BC break sine the inception of this lib (if my memory doesn't lie) and even then the only reason for break was that it was almost impossible to introduce needed change via deprecations.

Keeping surface area of library API small. It is hard to do in PHP, so we should probably document it instead (in new docs + maybe using @api dockblock as symfony used to do).

So we do expose:
parse() -> AST tree
validate() -> Error[]
execute() -> ExecutionResult

type definitions and AST structures. (maybe there are couple other APIs which I forgot to mention now - we definitely need to document all of them).

Everything else is pretty much implementation detail and should not be relied upon by end-users. Every exposed API requires time and efforts to maintain (or irresponsibility in exposing it in the first place with the cost of breaks and errors in future).
As for DI. The trick with DI is that you only need it if you do want to expose something for extension or when you need polymorphism for your internal implementations. Same applies to Interfaces and other polyporphism-related tools in general.
But if you do not expose something - polyporphism-related tools often complicate things (at least when they introduce new entities like interfaces, factory classes, etc which you could avoid otherwise, hence breaking Occam's razor rule). Doing these things mechanically somehow became a rule of thumb and good practice, but I do not subscribe to this point of view %)
For example changing parse() to new Parser(new Lexer)->parse() pretty much exposes implementation details of the Parser. Do we want to add other lexer in our implementation? No. Do we want to allow end-users define their own Lexers and are ready to maintain Lexer interface for that? No. Then why doing this?
So to summarize - I am very much in favor of polymorphism-enablement (DI, interfaces, etc) for cases where we decide to expose some functionality to end-users for extension or when we do need it for our own implementations. But not mechanically.
Obviously these are just principles. Sometimes they are hard to follow, but we try in this lib.
As for your changes - I do agree with some of them (style changes, changes of statics to objects where appropriate) - will cherry pick them when I find time to work on lib next time.
publics will stay because of performance and backwards compatibility.
We can consider replacing them with getters/setters for type definitions, yet I do not see any particular advantage in doing this (more lines of code to maintain, worse read performance, bigger serialization size if we decide to allow definition serializations in the future). But even if we do - we'll add __isset, __get, __set for BC.
Anyway I am really glad to see your PR and will be happy to see other PRs as long as they follow two principles above. I'd like to keep this library open to contributions!

Glad to hear back from you so swiftly. Here's my thoughts:
I don't think the public interface only extends to those 3 methods. When you do execution you might be looking at the AST in your resolve function to come up with a better strategy, so the entire AST is part of the public interface.
However I fully agree that injecting the lexer is a bit of an odd move, it was only done to make the initial refactor pass fast. This is far from how I would ideally want the code to look. I can come up with an argument for injecting in lexers though. You talk about overhead of lexing the query. Well part of this is that you have a lexer that both does Schema and Query lexing. Since these never occur in the same payload you could split them, here DI could become useful. Again this is very contrived.
But yeah fully agree with your point that you shouldn't make decisions mechanically. That being said I don't see the advantage to your static approach.
On backwards compatible changes thats very subjective obviously. I think it's very early days for graphql and your lib and I worry that your putting too many limitations on your self. But I'm very much in the build fast and break things camp :D
You've done an amazing job writing this library though, so I really shouldn't be complaining :D thanks so much for all the hard work and attention to detail. It was amazing to see that your test coverage is  extensive when doing these refactors.

Hey, your PRs are welcome anyway! Even if they break stuff - we can negotiate %)

Closing as I cherry-picked several commits from this PR.


Try updating GDAL

@Theodore-Chatziioannou was having problems on Windows with GDAL v3.6 but with this relatively strict dependency pinning we might be causing other downstream issues in https://github.com/arup-group/ersa/pull/56 so I'm trying out updating the pinning to skip v3.6 and seeing what the CI thinks about it.
Checklist
Any checks which are not relevant to the PR can be pre-checked by the PR creator.
All others should be checked by the reviewer(s).
You can add extra checklist items here if required by the PR.

[ ] CHANGELOG updated
[ ] Tests added to cover contribution
[ ] Documentation updated

Codecov Report
Attention: 89 lines in your changes are missing coverage. Please review.

Comparison is base (07813c8) 86.84% compared to head (9836ec0) 87.59%.
Report is 161 commits behind head on main.

Files
Patch %
Lines

pam/planner/choice_location.py
80.85%
12 Missing and 6 partials :warning:

pam/planner/utils_planner.py
76.59%
9 Missing and 2 partials :warning:

pam/write/matsim.py
59.25%
6 Missing and 5 partials :warning:

pam/read/diary.py
66.66%
6 Missing and 4 partials :warning:

pam/optimise/grid.py
70.00%
9 Missing :warning:

pam/vehicles.py
94.97%
4 Missing and 5 partials :warning:

pam/core.py
87.87%
7 Missing and 1 partial :warning:

pam/plot/plans.py
81.81%
3 Missing and 3 partials :warning:

pam/optimise/random.py
71.42%
2 Missing and 2 partials :warning:

pam/activity.py
50.00%
1 Missing :warning:

... and 2 more

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #266      +/-   ##
==========================================
+ Coverage   86.84%   87.59%   +0.74%
==========================================
  Files          49       48       -1
  Lines        5496     5747     +251
  Branches     1372     1436      +64
==========================================
+ Hits         4773     5034     +261
+ Misses        462      445      -17
- Partials      261      268       +7

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Segementation faults encountered in some Windows runs, so I'll return to this once this issue is resolved: https://github.com/OSGeo/gdal/issues/8959


Do not use seperate TOC for desktop and mobile?

After experimentation, the current input-label-label model is not compatible with mobile browsing experience.


[FLINK-12024] Bump universal Kafka connector to Kafka dependency to 2.2.0

What is the purpose of the change
This pull request bumps universal Kafka connector to Kafka dependency to 2.2.0
Brief change log

Bump universal Kafka connector to Kafka dependency to 2.2.0

Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (yes / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

cc @aljoscha and @pnowojski

No problems in terms of licensing.

Please, this fixes some really annoying bugs in Kafka

While the universal tries to track the latest Kafka client version, at times it may fall behind.  E.g. before this update it was using 2.0.1, skipping the 2.1.x series entirely.  At the moment the version of the client used for the universal connector is not mentioned in the Flink documentation.  It may be useful to do so.  Users may be interested is knowing the specific version so they can tell whether specific features or fixes are included in the connector.

@eliaslevy Your comment makes sense. I agree with you. I suggest we should describe the current kafka client version which the universal kafka connector tracks in the documentation. Any time when we upgrade the kafka's version, we also should update the document. What do you think? @pnowojski @aljoscha @zentol

I think this makes sense, yes.

@aljoscha OK, thanks for your reply. I will remark the kafka client version in the document.

That's no good, because the Kafka client is also forward compatible, except
for be features. An that is needed is just a comment stating the version
used.
On Thu, Mar 28, 2019 at 6:55 AM vinoyang<EMAIL_ADDRESS>wrote:

@yanghua commented on this pull request.
In docs/dev/connectors/kafka.md
https://github.com/apache/flink/pull/8055#discussion_r269953483:

@@ -85,7 +85,7 @@ For most users, the FlinkKafkaConsumer08 (part of flink-connector-kafka) is
1.7.0
FlinkKafkaConsumer
FlinkKafkaProducer

   >= 1.0.0

   >= 1.0.0 (until 2.2.0)

@aljoscha https://github.com/aljoscha and @pnowojski
https://github.com/pnowojski What do you think about this change?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/apache/flink/pull/8055#pullrequestreview-219957348,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAsQ4nHbn53NEzXjFyi3V0AYAVYFr3Keks5vbKP2gaJpZM4cM1us
.

@eliaslevy Sounds reasonable. My change will make the users confused.

Good enough, but I would rephrase it as "As of this release, it uses the Kafka 2.2.0 client."

@eliaslevy Thanks for your suggestion, accepted your opinion.

@pnowojski Thanks for pointing these version number. I have upgraded them to 2.2.0 except :
flink-filesystems/flink-fs-hadoop-shaded/src/main/resources/META-INF/NOTICE:Azure Data Lake Store - Java client SDK 2.0.11.
Moreover, I found the first arg KAFKA_CONNECTOR_VERSION in test_sql_client_kafka_common.sh seems useless. I suggest that we should remove them in another  PR in the future.


Fix replaceChars -> replaceStrings

replaceChars is deprecated in nixos-unstable. Its use generates the following warning:
trace: warning: replaceChars is a deprecated alias of replaceStrings, replace usages of it with replaceStrings.

This looks good to me.

This PR has been cherry picked into the release maintenance branch and will be merged through there.  Thanks for changes!  Closing.


Testcafe doesn't handle state/url in Ionic/Angularjs app with tabs

Are you requesting a feature or reporting a bug?
Bug
What is the current behavior?
In a tab with more than one view (for example, the default Ionic "tabs" app) (https://ionicframework.com/getting-started/), the browser history is not maintained correctly during "back" operations. For example, in the Ionic-supplied default app, if the test visits the "chats" tab, then visits the chat labeled "Ben Sparrow", then hits the "< Chats" button to return to the previous page, testcafe returns to the home "Status" tab rather than the "Chats" tab, as interactive usage would do.
What is the expected behavior?
testcafe should maintain appropriate view history so that buttons return to the proper state.
How would you reproduce the current behavior (if this is a bug)?
To install the default Ionic app, do:
ionic start tabTest tabs --type ionic1
Run the app with 'ionic serve'
Then create the following test (you may need to adjust the port number below to 8100 or similar):
import { Role, Selector } from 'testcafe';
import { AngularJSSelector } from 'testcafe-angular-selectors';

const span = Selector('span');
const a = Selector('a');
const button = Selector('button');

fixture `Getting Started`
    .page `http://localhost:8101/`;

test('Browse test', async t => {
    await t
	.click(span.withText('Chats').parent())
	.click(a.withText('Ben Sparrow'))
	.click(button.withText('Chats'))
	.click(a.withText('Ben Sparrow'))
});

The last click on 'Ben Sparrow' will fail because the test is on the incorrect page, it has returned to the home state rather than returning to the previous view of Chats tab, as interactive usage will do.
Provide the test code and the tested page URL (if applicable)
Tested page URL:
Test code

Specify your

operating system: MacOS High Sierra 10.13.3
testcafe version: 0.19.1
node.js version: v8.9.4

Hi @viking2917
I've reproduced the issue. I need additional time to investigate the cause of the problem.

I'm working on it

Thank you! What is the best way for me to get the fix? Simply re-install testcafe? Or do I need to wait for a release?

Hi, we will publish a new version of TestCafe with the fix the next week. It can take a couple of days after the weekend. We will let you know when it's done. Thanks for your cooperation.

will be traveling for a bit but will give it a try when I return, thanks!

I can confirm this works now, after re-installing testcafe. Thank you!

@viking2917 Hello, "twice click" test failed in Edge / Windows 10 / TestCafe 0.19.2. Could you please specify your browser/OS configuration, it's Safari  / Mac OS X 10.13.3 / TestCafe 0.19.2?

 I had a local installation of testcafe 0.19.1 covering an installation of 0.19.2. When I removed that and made sure to have 0.19.2 everything works. Thanks!

@viking2917 Thanks for your feedback, I'm glad that the problem is solved.


Overflow on smaller screens in the top nav

Documentation Issue
There is some overflow on smaller devices on the top nav when trying to create a new project

Additional Details
It is easily fixable with a overflow-x: hidden or a general overflow: hidden on the div with the following class:  "DashboardBreadcrumbs_wrapper__p6nF4"

Thanks for the report @OmegaHawkeye, this should be fixed now!


Self-referential Data Modeling Leads to Unexpected Behavior

Problem:
The order of field elements in a model impact whether the self-referential relationship behaves appropriately.
Environment (Docker containers):

Prisma2 pre-release 3.2 running on Ubuntu (latest)
Postgres database

Example:
I have a model Group, that can have many child Groups.
First Attempt
Simply applying the reference to a single field, like the example from the docs (https://github.com/prisma/prisma2/blob/master/docs/relations.md#self-relations) leads to the following error when migrating via prisma2 lift up: "Ambiguous self relation detected."
model Group {
  id    String  @default(cuid()) @id @unique
  name String
  parent Group?
}

Second Attempt
So, if I then explicitly create a parent field for Group and a childGroups field for Group[] on the model with a reference linking them, this clears up the lift up error, but then leads to unexpected outcomes when running Photon.
model Group {
  id    String  @default(cuid()) @id @unique
  name String
  parent Group? @relation(name: "ChildGroups")
  childGroups Group[] @relation(name: "ChildGroups")
}

If I try to create a parent group with its children in one pass, like this:
await photon.groups.create({
      data: {
        name: "PARENT_GROUP",
        childGroups: {
          create: [
            {
              name: "CHILD_GROUP1",
            },
            {
              name: "CHILD_GROUP2",
            },
            {
              name: "CHILD_GROUP3",
            }
          ]
        }
      }
})

Or if I try to create each group one by one, like this:
const parent = await photon.groups.create({
    data: {
      name: "PARENT_GROUP",
    }
  });

  if (parent) {
    const group1 = await photon.groups.create({
      data: {
        name: "CHILD_GROUP1",
        parent: {
          connect: {
            id: parent.id
          }
        },
      }
    });

    const group2 = await photon.groups.create({
      data: {
        name: "CHILD_GROUP2",
        parent: {
          connect: {
            id: parent.id
          }
        },
      }
    });

    const group3 = await photon.groups.create({
      data: {
        name: "CHILD_GROUP3",
        parent: {
          connect: {
            id: parent.id
          }
        },
      }
    });
  }

They both result with the parent group being the only one with a reference in the parent field and it is to the last child group created.
id | name | parent
cjyox9y2c0002alrzxi4wvgf1 | CHILD_GROUP1 | null
cjyox9y2q0003alrz723c94uc | CHILD_GROUP2 | null
cjyox9y320004alrzmyl6d1yv | CHILD_GROUP3 | null
cjyox9y200001alrzqotpza6d | PARENT_GROUP | cjyox9y320004alrzmyl6d1yv
I am looking for the opposite behavior, where each child group has a reference to its parent if there is one.
Final Attempt - Success
Simply ordering the childGroups field before the parent field resulted in the desired behavior:
model Group {
  id    String  @default(cuid()) @id @unique
  name String
  childGroups Group[] @relation(name: "ChildGroups")
  parent Group? @relation(name: "ChildGroups")
}

id | name | parent
cjyox9y200001alrzqotpza6d | PARENT_GROUP | null
cjyox9y2c0002alrzxi4wvgf1 | CHILD_GROUP1 | cjyox9y200001alrzqotpza6d
cjyox9y2q0003alrz723c94uc | CHILD_GROUP2 | cjyox9y200001alrzqotpza6d
cjyox9y320004alrzmyl6d1yv | CHILD_GROUP3 | cjyox9y200001alrzqotpza6d
Expected Behavior:
Order of model fields would not matter and still result in the same final output.

I am even unable to deploy this datamodel in SQLite. Possibly related to #200

@pantharshit00 : Can you test that again on latest alpha please? I worked in that area today and might have fixed this.

@mavilein Still unable to deploy with<EMAIL_ADDRESS>binary version: 308a79c48cb22db008241f79742f20803cee710b
Failed listMigrations at 2019-07-31T17:17:24.198Z
RPC Input One Line
{"id":1,"jsonrpc":"2.0","method":"listMigrations","params":{"projectInfo":"","sourceConfig":"datasource db {\n  provider = \"sqlite\"\n  url      = \"file:dev.db\"\n  default  = true\n}\n\ngenerator photon {\n  provider = \"photonjs\"\n}\n\nmodel Group {\n  id   String @default(cuid()) @id @unique\n  name String\n   parent Group? @relation(name: \"ChildGroups\")\n  childGroups Group[] @relation(name: \"ChildGroups\")\n}\n}"}}

RPC Input Readable
{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "listMigrations",
  "params": {
    "projectInfo": "",
    "sourceConfig": "datasource db {\n  provider = \"sqlite\"\n  url      = \"file:dev.db\"\n  default  = true\n}\n\ngenerator photon {\n  provider = \"photonjs\"\n}\n\nmodel Group {\n  id   String @default(cuid()) @id @unique\n  name String\n   parent Group? @relation(name: \"ChildGroups\")\n  childGroups Group[] @relation(name: \"ChildGroups\")\n}\n}"
  }
}

RPC Response
null

Stack Trace
thread 'main' panicked at 'loading the connector failed.: DataModelErrors { code: 1001, errors: ["Unexpected token. Expected one of: end of input, type declaration, model declaration, enum declaration, source definition, generator definition."] }', src/libcore/result.rs:997:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::continue_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::result::unwrap_failed
   9: migration_core::migration_engine::MigrationEngine::init
  10: <F as jsonrpc_core::calls::RpcMethodSimple>::call
  11: <F as jsonrpc_core::calls::RpcMethod<T>>::call
  12: <futures::future::lazy::Lazy<F,R> as futures::future::Future>::poll
  13: <futures::future::then::Then<A,B,F> as futures::future::Future>::poll
  14: <futures::future::map::Map<A,F> as futures::future::Future>::poll
  15: <futures::future::either::Either<A,B> as futures::future::Future>::poll
  16: futures::task_impl::std::set
  17: std::thread::local::LocalKey<T>::with
  18: futures::future::Future::wait
  19: jsonrpc_core::io::IoHandler<M>::handle_request_sync
  20: migration_core::rpc_api::RpcApi::handle
  21: migration_engine::main
  22: std::rt::lang_start::{{closure}}
  23: std::panicking::try::do_call
  24: __rust_maybe_catch_panic
  25: std::rt::lang_start_internal
  26: main

@pantharshit00 : Please try again now. Lift should not fail anymore.

Ok, I am finally able to deploy the datamodel to SQLite.
Now that is possible, I am able to successfully reproduce this issue posted above.

This is fixed in binary version b8957df02bca6708b7aefa56832eda409dbb1114. It is already available on alpha.