[HUDI-783] Added python3 to the spark_base docker image to support pyspark

Tips

Thank you very much for contributing to Apache Hudi.
Please review https://hudi.apache.org/contributing.html before opening a pull request.

What is the purpose of the pull request
This pull-request adds python3 to the apachehudi/sparkbase docker image, which is required to run pyspark shell command. This is part of the effort to add official python-support to hudi package.
We can run the following pyspark command on sparkmaster, sparkworker, sparkadhoc docker images after merging this pull request.
Brief change log

Added python-support to the hudi demo docker images to enable pyspark shell

Verify this pull request
This change added tests and can be verified as follows:

Manually verified the change by building the docker image locally, registering with the local Docker registry, using the local docker image in the docker-compose file, started all the docker images and tested the change by invoking pyspark from the adhoc-1 machine via command-line.

The details of the testing can be found in this gist: https://gist.github.com/vingov/347548f2df9af11892c8331123b42967
Committer checklist

[x] Has a corresponding JIRA in PR title & commit

[x] Commit message is descriptive of the change

[ ] CI is green

[ ] Necessary doc changes done or have another open PR

[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

@bhasudha - As we discussed, I've followed the steps to test the docker images using local registry, check out the detailed testing report here
Can you please review and merge this PR?

@vingov Sorry for the delay. I ll get to this PR in a day or two.


Multiple versions warning spam messages

Projects  importing @acala-network/test-providers are finding a lot of errors along the lines of @polkadot/util has multiple versions, ensure that there is only one installed.
It this fixable at this package level?

at the package level we already locked all versions https://github.com/AcalaNetwork/bodhi.js/blob/master/common/config/rush/.pnpmfile.cjs#L21
Is it because the other project explicitly installed some other versions of the overlapping packages? They can try use the same versions as we do, or add version locks in their package json

@ThunderDeliverer by the way I remember seeing similar warning when installing packages with yarn for the tutorials, maybe we should also lock the versions in tutorials to make them consistent with bodhi?

Fixed by https://github.com/AcalaNetwork/bodhi.js/pull/380


FakeNavBar Change height and background color.

Hi,
I am currently using SPStorkController and using SparrowKit for the fake Nav Bar. Is there anyway I can make the height of the nav bar smaller? Also can I change the background color of it?
    self.navBar.elementsColor = ColorCodes.ThemeBlue
    self.navBar.backgroundColor = ColorCodes.ThemeBlue

I used that code. Only the element color changed though. The background is still the same.

About height:
For change style see property style of SPNavigationTitleStyle. You can set .small. Also you can set custom height, use property height.
About color:
View use UIVisualEffectView of background. You need add subview with equal frame for colorise nav bar.


npm install i markdown-it-emoji

Hey everyone
I would like to express my sincere gratitude for the extraordinary work you have done with this package. As a new user of this package, I really appreciate the feature it offers and the way it has simplified my development process.
I just have a question.
Is this the real command to install
npm install i markdown-it-emoji
or
npm install markdown-it-emoji
Do we need to install "i"?
Thank you.

Pretty sure that's a typo.
It's either npm install markdown-it-emoji or npm i markdown-it-emoji (i is shortcut for install).

https://github.com/markdown-it/markdown-it-emoji/commit/bdd07260f080e4d3d812928f3eb0b00883e4e71b
Fixed, thanks!


[Bug]: environments are not working properly

Is there an existing issue for this?

[X] I have searched the existing issues

Example public repository
coolify
Description
When I try to deploy an application I get the following error

I have tried downgrading to 3.12.2 and it works properly.
Steps To Reproduce

Make sure you are using the version 3.12.3 or 3.12.4
Try to deploy an application which requires some environments/secrets
See the error in the build logs

Version
3.12.3 & 3.12.4

Just submitted a fix on #809

It doesn't look like it is fixed in the latest release contrary to the change log 😣

It doesn't look like it was fixed in the latest release contrary to the change log... :(

@cruonline just to confirm, you're still facing this in docker-compose builds or in other types of builds?

docker-compose builds

the bug still exists in version 3.12.8 (latest)

Facing the same issue with 3.12.8.
Fixed it temporarily by moving all variables to secrets:
environment:
      # see https://ghost.org/docs/config/#configuration-options
      - database__client
      - database__connection__host
      - database__connection__user

instead of
environment:
      database__client: mysql
      database__connection__host: db
      database__connection__user: user

Appereantly this issue is not fixed. Currently I'm on v3.12.10
Trying to install following registry https://github.com/repman-io/repman
[12:07:18.573] Cloning repman-io/repman:master...
[12:07:19.939] Configuration changed
[12:07:21.176] {}
[12:07:21.181] environment is not iterable

This is the error I'm getting

@zek I believe that at this point after so many releases this is now a feature 😉
I am sticking with 3.12.2 until it is fixed. Not sure why this report is closed though...

Getting this too as well

Definitely not a feature! 🙂

Definitely not a feature! 🙂
So this is happening with the docker compose build pack, right?

Yes

Build time env variables are not working for docker-compose builds.

Appereantly this issue is not fixed. Currently I'm on v3.12.10
Trying to install following registry https://github.com/repman-io/repman
[12:07:18.573] Cloning repman-io/repman:master...
[12:07:19.939] Configuration changed
[12:07:21.176] {}
[12:07:21.181] environment is not iterable

This is the error I'm getting

The next version will have a fix for this!

Build time env variables are not working for docker-compose builds.

Also adding this to the next version.

Is there a workaround for this:
[12:07:18.573] Cloning repman-io/repman:master...
[12:07:19.939] Configuration changed
[12:07:21.176] {}
[12:07:21.181] environment is not iterable

until it will be fixed in the next version?

Is there a workaround for this:
[12:07:18.573] Cloning repman-io/repman:master...
[12:07:19.939] Configuration changed
[12:07:21.176] {}
[12:07:21.181] environment is not iterable

~until it will be fixed in the next version?~
Okay, as far as I understand, the version with the fix is released.
But, for example this docker-compose still produces the environment is not iterable error.

Hi! I had the same issue and it looks like coolify only works with object in environment property because of this line: https://github.com/coollabsio/coolify/blob/main/apps/api/src/lib/buildPacks/compose.ts#L56
So in order to make it work in current version i had to modify enviroment property from array to object
Before:
environment:
    - VARIABLE=VALUE

After:
environment:
    VARIABLE: "VALUE"

@andrasbacsai FYI

Thats why it didnt work please update it the way docker-compose config is meant to do it. Imagine if we follow this workaround it could cause issue when auto updating coolify with the fix

Is there a workaround for this:
[12:07:18.573] Cloning repman-io/repman:master...
[12:07:19.939] Configuration changed
[12:07:21.176] {}
[12:07:21.181] environment is not iterable

~until it will be fixed in the next version?~
Okay, as far as I understand, the version with the fix is released.
But, for example this docker-compose still produces the environment is not iterable error.

Hi! I had the same issue and it looks like coolify only works with object in environment property because of this line: https://github.com/coollabsio/coolify/blob/main/apps/api/src/lib/buildPacks/compose.ts#L56
So in order to make it work in current version i had to modify enviroment property from array to object
Before:
environment:
    - VARIABLE=VALUE

After:
environment:
    VARIABLE: "VALUE"

@andrasbacsai FYI

Thats why it didnt work please update it the way docker-compose config is meant to do it. Imagine if we follow this workaround it could cause issue when auto updating coolify with the fix


Release 0.19.8

[0.19.8]
Added

Add filter for entity match feature #814
Add noise re-weight factor in LogRegIntentClassifier #815
Add warning logs and improve errors #821
Add random seed parameter in training CLI #819

Fixed

Fix non-deterministic behavior #817
Import modules lazily to speed up CLI startup time #819

Codecov Report

Merging #824 into master will increase coverage by 0.05%.
The diff coverage is 83.23%.

@@            Coverage Diff             @@
##           master     #824      +/-   ##
==========================================
+ Coverage   88.46%   88.52%   +0.05%
==========================================
  Files          76       78       +2
  Lines        4588     4784     +196
  Branches      889      904      +15
==========================================
+ Hits         4059     4235     +176
- Misses        394      411      +17
- Partials      135      138       +3


Add prerequisite for difference-of-squares exercise

@TomPradat Can you clarify this a little bit? Because the exercise can be solved without arrays so I would not consider array-transformations as a "prerequisite".

That's true @tejasbubane , I chose a set of concepts that can be used to solve the exercise.
According to https://github.com/exercism/javascript/issues/960 if alternative concepts also allow the student to solve the exercise, we can specify the concepts of either approaches.
That said It seems that currently more exercises teach array-transformations than for-loops. So I don't mind changing for for-loops. What do you think ?

Loops sounds good. Even when we use transformations, we're using loops, but not the other way around, I guess.


Switch to cryptolcourse/saw

I added the additional solvers to the saw Docker image on Dockerhub:
https://hub.docker.com/repository/docker/cryptolcourse/saw
Consider changing Docker instructions for SAW to this.

Oh great! Someone should definitely update the instructions...someone...anyone?

INSTALL.md needs updating with @jpziegler's Cryptol and SAW containers.

Best to do it on PR #47 atm.

I made the change in #47


Refactor custom matchers (closes #45)

This is a proposed refactor to the custom matchers code, as briefly discussed in https://github.com/kentcdodds/react-testing-library/pull/44#discussion_r179593891:

[x] Use common message format across all custom matchers
[x] Make it easy to adopt the same format in any future matchers
[x] Simplify code, remove unneeded if/else logic

Closes #45
Proposed changes not yet performed (pending discussion)

[ ] Make each custom matcher a named export, instead of bundling them in an object as default export
[ ] Better organize in a sub folder with one file per matchers and some utils file for common stuff

Pending to be fixed

[ ] Code coverage is not full because getDisplayName never gets called during the tests with a class as argument, only with html elements. I wonder if that is expected, given that this library is only dealing with rendered html and not the virtual dom, or is it?

Thanks for this!

Better organize in a sub folder with one file per matchers and some utils file for common stuff

There are only 3 custom matchers, with few common utils like getMessage, checkHtmlElement. Do we really move them per file basis? May be / May be not :)

Code coverage is not full because getDisplayName never gets called during the tests with a class as argument, only with html elements. I wonder if that is expected, given that this library is only dealing with rendered html and not the virtual dom, or is it?

What if someone does this:
expect(queryByText('notindom').toBeInTheDOM()

then we decided to throw exception like:
The given subject is a object, not an HTMLElement

And also I guess you had to add checkHtmlElement for toBeInTheDOM.

Agree that it might not be a good idea to split the custom matchers. That's why I did not do it, just wanted to throw the idea out there. What do you think about exporting each of them individually as named exports? Not that's too important right now, but I find it odd to have them all bundled in an object, when they are independent pieces.
About this

And also I guess you had to add checkHtmlElement for toBeInTheDOM.

The whole point of .toBeInTheDOM is that it could be called with something that is not found in the DOM, so it won't be a HTML element. We cannot throw an exception in that case. The actual matcher will take care of that when we return pass: false.
Regarding the getDisplayName issue
I guess what I need to do is to add a test case where we expect something that's not null (but also not a html element) to be in the DOM. That has to be a test that does not use queryByText or any of the other query* functions, because those all return either a html element of null. I'll do that.

Ok, sorry about the rushed response. I fully get what you mean now. I added the check for html elements in toBeInTheDOM, but only when the argument is not null. If the argument is null or undefined I leave it to fail normally, because it does not pass.
I was confused at first because this check was never there before, just a superfluous call to getDisplayName whose return value was not being used.

Agree that it might not be a good idea to split the custom matchers. That's why I did not do it, just wanted to throw the idea out there. What do you think about exporting each of them individually as named exports? Not that's too important right now, but I find it odd to have them all bundled in an object, when they are independent pieces.

May be we can take this up.

The whole point of .toBeInTheDOM is that it could be called with something that is not found in the DOM, so it won't be a HTML element. We cannot throw an exception in that case. The actual matcher will take care of that when we return pass: false.

Yes, but since we have checks like:
checkHtmlElement(htmlElement)
const textContent = htmlElement.textContent

What if the htmlElement is not an HTMLInstance? We might end up in other issues. Yes, as you said we have to remove the error logic and pass the control to matchers, so that it ends up in fail test cases.

Could we move this over to dom-testing-library?
Sorry to change things underneath you!

No problem, it makes sense. I'll re-create the PR over there.


canopen sample wont respond on pdo mapping with CO_ODs from objdict.eds

Describe the bug
I try to run the canopen sample with CO_OD.h and CO_OD.c that i have generated from objdict.eds. But when i run the pdo mapping python script i dont get any pdo from my devkit when i push its button.
In contrast when i run the sample with the provided CO_OD.h and CO_OD.c it works fine and the python script gets the pdo.
Im using Object Dictionary Editor v0.8-0-gb60f4eb to generate the files. My devkit is ST Nucleo F091RC.
Why is CO_OD files generated from objdict.eds not sending any pdo but the "stock" CO_ODs does?
To Reproduce
Steps to reproduce the behavior:

Generate CO_OD.c and CO_OD.h from objdict.eds
Change CO_NO_TS to CO_NO_TIME in CO_OD.h
Build and run the canopen sample
Run pdo mapping python script form canopen sample webpage

Expected behavior
Im expecting the same pdo response when running the sample with CO_ODs generated from objdict.eds as with the "stock" CO_ODs.

Normall you would not use the EDS file for generating the OD as the EDS doesn't contain the full meta data for the OD. Try using the objdict.xml file instead. Beware that you will need a revision of https://github.com/robincornelius/libedssharp which is compatible with https://github.com/CANopenNode/CANopenNode/tree/v1.3-master (latest stable CANopenNode, v1.3, the version integrated in the Zephyr Project) for generating the OD implementation files.
Without any indication of what is changed in your custom generated CO_OD.{ch} files, I'm afraid I cannot assist in debugging your issue any further.

@henrikbrixandersen Your are absolutly right, this is a question and not a bug. I choosed the wrong category and I apologize for this.
Ok, I generated the CO_ODs from the objdict.xml and now the sample works (it responds to the pdo mapping python script).
I did no change to the objdict.eds before I generated the CO_ODs. Initially my plan was to copy the TPDO mapping  from the script to the OD (by editing objdict.eds) just to test how/if it worked (also I deleted the mapping in the script). And when it didn't, I restored the  objdict.eds to its original state and generated the CO_ODs again (from objdict.eds) the to see if that would make the sample work, but still it would not respond.
But now when I generate CO_ODs and objdict.eds from the objdict.xml as suggested and the sample responds as expected. I have even made my own custom edits to the objdict.xml and my devkit responds to my PDOs. I believed that there was no diffrence between the objdict.eds and objdict.xml so I edited the .eds. I have to stop believing.
Regarding https://github.com/robincornelius/libedssharp I have used the pre compiled release because I couldn't figure out how build the editor on my machine. It seams to edit/generate ODs fine except that I have to change  CO_NO_TS to CO_NO_TIME in CO_OD.h. This is something I can to live with until some kind soul can build the correct version of the editor to use with Zephyr.
Thank you for the help @henrikbrixandersen.

@LonesomeUnixCowboy Glad you got it working!


Changed ActNorm flag to buffer to allow saving

Without it being a buffer, when you load a model and sample from it, the flow thinks it is the first run through so overwrites all the trained ActNorm parameters.

Good observation, thanks a lot!


Refresh and download live tableau datasource

Describe the bug
Not a bug, but wanted some help in figuring out if there exists any method to refresh and download a live tableau data source. I know of download option in server.datasources, but it doesn't refresh the connection. And .refresh method is not valid for live connections.
When I publish a data source, it is not refreshed until I create a workbook using it. Now, I want to download a refreshed/updated data source using python. (Also, note that db connections credentials are embedded in the data source when publishing)
To Reproduce

Publish a live connection data source to server using API.
Update the data connected to data source. (do not create a workbook using this data source. This refreshes the data. This is what I want to do using API)
Download the data source. Using Tableau desktop, view it, the data source is not in sync with actual connection. If I click on "Edit Data source", it will update and new fields will appear.

Hi v6shah,
I have a query regarding steps to reproduce
step 1. How are you establishing a live connection data source to server using API?


Question related to the model tuning

Hi,
Great work first!
I am confused with the model tuning part.
According to the code, it seemed that you used the lora method.
This, in my opinion, will destroy the sparsity you have made in the original model after merging the lora weights to the model weights.
could you explain this?
Thanks
Shawn

Hi @shawnricecake, LLM-Pruner is a structural method and thus produces a dense model after pruning.

Hi @shawnricecake, LLM-Pruner is a structural method and thus produces a dense model after pruning.

Hi, thanks for your reply, so, the model weights after merge the lora weights will be dense?
the main contribution of paper is the structure pruning?
Thanks
Shawn


[BUG] Checkboxes in ValidationView disappear.

How to reproduce:

Create table and add some building blocks
Go to ValidationView
Click on table column so you can see checkboxes.
Resize window so checkbox and slider are shown side by side.
Click around on the checkboxes. Some of them will disappear (visually).

Added custom css for checkradio elements. This should be nicely customizable and even has fields for css specifically if the checkradio is disabled.


discussion: Lets discuss about if actions are nil, we can ack or not?

actions := c.mapper(e)

for i := range actions {
    c.bulk.AddAction(ctx, e.EventTime, actions[i], e.CollectionName)
}

In this code, we are using ctx.Ack() only actions are not nil. When actions are nil or length zero, we cannot Ack(). Because of this, we are re-processing bad malformed, or invalid documents again, we can change this implementation. Let's discuss

Already merged #17 💯


Azure Event Grid: Creating baseline version for new API version 2017-09-15-preview

Azure Event Grid: Creating baseline version for new API version 2017-09-15-preview.

With the first commit, the contents of this file are EXACTLY the same as the contents of 2017-06-15-preview with the exception of updating the API version from 2017-06-15-preview to 2017-09-15-preview.
The follow-up commit contains the actual changes corresponding to the new API version.

This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
PR information

[X] The title of the PR is clear and informative.
[X] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
[X] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
[X] If applicable, the PR references the bug/issue that it fixes.
[X] Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

[X] I have read the contribution guidelines.
[X] My spec meets the review criteria:

[X] The spec conforms to the Swagger 2.0 specification.
[X] The spec follows the guidelines described in the Swagger checklist document.
[X] Validation tools were run on swagger spec(s) and have all been fixed in this PR.

@kalyanaj,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

@kalyanaj
Can you fix this error:
{
"type": "Error",
"code": "XmsExamplesRequired",
"message": "Please provide x-ms-examples describing minimum/maximum property set for response/request payloads for operations.",
"id": "R2022",
"validationCategory": "SDKViolation",
"providerNamespace": null,
"resourceType": null,
"sources": [
"file:///home/travis/build/Azure/azure-rest-api-specs/specification/eventgrid/resource-manager/Microsoft.EventGrid/2017-09-15-preview/EventGrid.json:18:4 ($.paths)"
]
}

@sarangan12, Regarding the x-ms-examples, there's another active PR in review (#1648) to add x-ms-examples for Azure Event Grid (I had gotten an exception for this earlier). Once that PR gets merged, I will merge the x-ms-examples into the Swagger for the newer API version. The Swagger for the newer API version (2017-09-15-preview) is required to unblock the PRs for the .NET SDK / PowerShell etc., so it will be great if we can do them in parallel without blocking on it.

No modification for AutorestCI/azure-sdk-for-python

No modification for AutorestCI/azure-sdk-for-python

No modification for AutorestCI/azure-sdk-for-ruby

No modification for AutorestCI/azure-sdk-for-node

No modification for AutorestCI/azure-sdk-for-node

No modification for AutorestCI/azure-sdk-for-ruby


Fix for MICROPY_HW_ENABLE_CAN

https://github.com/micropython/micropython/commit/a7ebac2eaed7eb0da362568b9333339634f1da1d

Also applied here: https://github.com/mcauser/BLACK_F407ZE/commit/4024038e8bfeb4f45b467d492adcc62b65c519ef


Spread between other arguments in a function call call does not work

TypeScript Version:  3.1.0-dev.20180809

Search Terms: tuple spread function call
Code
function foo (a: 1, b: 2, c: 3) { }

const bar: [1, 2] = [1, 2];

foo(...bar, 3);

Expected behavior:
No error.
Actual behavior:
On the third line: Expected 3 arguments, but got 1 or more.
Notes:
If this is intended to work this way, or is simply not implemented yet, this issue can be edited into a feature request.
First use case I can think of is my Vector2/3 classes, which support xy: [number, number] and xyz: [number, number, number]. I have some methods which require x, y, and z values, and do not want a vector (legacy code). It would be nice to be able to spread into them.
Another use pertaining to my vector example is constructing a V3 from a V2, new Vector3(...v2.xy, z)
Also, this already works if the tuple exactly matches the method call, example:
const baz: [1, 2, 3] = [1, 2, 3];
foo(...baz);

This seems to be related to #26058 (at least the merging part of that proposal)

I saw that issue but wasn't sure how related it would be, because you can't spread into tuples at all, but you can spread into function calls when the arguments exactly match the tuple.
const x: [1, 2, 3] = [1, 2, 3];
const y = [...x]; // (1 | 2 | 3)[]
function foo(a: 1, b: 2, c: 3) {}
foo(...x); // works

It is currently working as intended, so I'm changing this issue to a suggestion. The compiler only flattens tuples into parameter lists when they occur in a spread parameter in the last parameter position. When a spread parameter occurs earlier than the last parameter position, the remaining parameters are considered to just be part of the spread, i.e. foo(x, ...y, z) is checked as foo(x, ...[...y, z]).

@ahejlsberg this still seems like a bug to me, it's not that uncommon to have a spread in an earlier position. As well the logic being applied seems to be affecting spread even without using tuples, see #28010

@ahejlsberg

When a spread parameter occurs earlier than the last parameter position, the remaining parameters are considered to just be part of the spread, i.e. foo(x, ...y, z) is checked as foo(x, ...[...y, z]).

I don't quite understand the problem or difference here. If y is a tuple of known fixed length 2 with types ty1 and ty2, then [...y, z] should be identifiable as tuple of known fixed length 3 with types ty1, ty2 and tz. In that case the signature is known and can be checked accordingly, no matter where the spread occurs.
What am I missing?

What am I missing?

It certainly is possible to do what you're suggesting, but it adds more complexity to the compiler logic that reasons about the effective argument list (i.e. the "flattened" argument list). Also, it assumes that the fixed length of the tuple can be trusted at run-time. For example, treating a longer array as a fixed length tuple doesn't lead to issues when it is in the last position, but would cause alignment bugs when more arguments follow.

I also have a use case for this: f(...tupleMaker(1), ...tupleMaker(2)).  The error is "Expected 4 arguments, but got 1 or more. An argument for 'firstArg' was not provided."

This issue was fixed by #39094 which is included in the 4.0 beta. Playground link:
https://www.typescriptlang.org/play/index.html?ts=4.0.0-beta#code/GYVwdgxgLglg9mABMOdEAoCGAuRBGAGkQCNcAmIiXAZgEpEBvRAXwFgAoDiBAZyhMwAnXAG1CiMgF1EAXkRiiUgNwcOKOOgB024kKJ0V7IA


Upgrade to PostGIS 2.5 made container incompatible with data volume

I was using a container using mdillon/postgis:9.6 when it had PostGIS 2.4. Recently I had to clean up disk space so deleted all docker images I had. When I tried to reinstantiate the container, it started giving the following error:
could not access file "$libdir/postgis-2.4": No such file or directory

I suppose this is happening because a new version of PostGIS (2.5) was pushed to the same tag. Now I'm trying to figure out a way to recover the data, probably using the Dockerfile that had 2.4 version.
I suggest to rollback the tag mdillon/postgis:9.6 to version 2.4 to avoid others face the same issue as me, and also pushing 2.5 into a specific tag, like mdillon/postgis:9.6-2.5.

Ok, thanks.

I would only add that if you're using this image in production or some other setting where you want reproducibility, you might want to consider retagging this image in your own namespace with your own tags as part of your provisioning/deployment process. This image was never intended to be a turn-key solution for anyone.

I understand, I'm not using it in production. Thanks very much for your help!


no-unnecessary-callback-wrapper: Handle non-identifier functions

PR checklist

[ ] Addresses an existing issue: #0000
[X] New feature, bugfix, or enhancement

[X] Includes tests

[ ] Documentation update

Overview of change:
#2510 is too simple; there are cases of non-identifier calls that are still an unnecessary callback, like x => f()(x). We can solve #2509 by looking for uses of the parameters in the called expression, so that x => x(x) is still not a failure.
CHANGELOG.md entry:
[enhancement] no-unnecessary-callback-wrapper: Handle non-identifier functions

I disagree with some changes made here. (x) => foo()(x) is no unnecessary wrapper, because foo() could have side effects. It would change the semantics of the program if the callback is never called or called more than once.
Every CallExpression whose expression is not an identifier should be allowed.
+1 for allowing (x) => x(x)

That's technically true... but that would be a pretty cruel place to hide a side effect. Most of the time code is better off evaluating foo() only once, instead of once per callback.

but that would be a pretty cruel place to hide a side effect. Most of the time code is better off evaluating foo() only once, instead of once per callback.

Agreed, but that's definitely not the responsibility of this rule.
What if the arrow function is not used as callback. It's totally valid to write all functions as arrow function. If that's the case, side effects are expected and it's not just an "unnecessary wrapper"

OK, I've reverted to only check for identifiers.

Updated changelog entry to reflect what this PR ended up actually doing.


Update examples

This pull request updates some of the files in the examples/ folder to work with the current version of Owl.  The changes are as follows:

Changed owl_zoo_cmd.ml such that the owl shell command automatically loads the owl-plplot package, so that plots can be made using the scripting system.
Changed computation_graph_01.ml and computation_graph_02.ml to work with the current functions for writing a computation graph to a dot file.
Changed test_log.ml to remove some type errors.
Changed svm.ml and regression.ml to load the Owl_plplot module to allow plotting.

Thanks very much for the comments @jzstark.  I'll fix the formatting issues and revert the changes to test_log and the zoo system.

Cool! The code looks good and the examples work fine now. Thanks for this PR!


Desactivate Jquery lib in vendor.js

Hi,
How can i desactivate Jquery Lib use in Vendor.js (because I already include it in my file) ?
When I use "noconflict" option, I can't use some tools in "noconflict" pragma like tooltip or dialog.
Ty

Instead of using vendor.js, you can manually add all the dependencies. Check bower.json for dependencies
https://github.com/dobtco/formbuilder/blob/gh-pages/bower.json#L21

Gonna try right now.
Ty

@Patatou Did it work for you? If yes, please close this issue.


How does one use the new project layout for building in Docker?

I see here that there is a new project layout:
https://github.com/operator-framework/operator-sdk/blob/56656cfb54ae38df108d4fe3dd453e530fe67b37/cmd/operator-sdk/build/cmd.go#L67
This appears to allow builds entirely in Docker, which is great. I would like to use it. Is there any documentation for how to migrate to this structure?
It looks like newly scaffolded projects don't yet use this structure, so I can't generate an example that way.
@camilamacedo86

I was able to get the new operator-sdk build working by adding these files to the project:

https://github.com/JoelColledge/piraeus-operator/blob/5a36aa996fcc08162fa59cc4fd2e3a62fc79157d/Dockerfile
https://github.com/JoelColledge/piraeus-operator/blob/5a36aa996fcc08162fa59cc4fd2e3a62fc79157d/PROJECT

But that created other problems. For instance operator-sdk generate crds disappeared. This is extremely unconventional. Usually the available subcommands and flags of a CLI program do not depend on the working directory.
I'm going to use a different solution to my problem, but I'll leave this ticket open, because the new structure will need documentation eventually.

Hi @JoelColledge,

This appears to allow builds entirely in Docker, which is great. I would like to use it. Is there any documentation for how to migrate to this structure?

It looks like newly scaffolded projects don't yet use this structure, so I can't generate an example that way.

Currently, the project has been in process to be integrated with Kubebuilder which means that a new layout of the project will be generated by SDK. To check this, you can run operator-sdk init to create the project.
See: https://github.com/operator-framework/operator-sdk/blob/master/cmd/operator-sdk/main.go#L43-L54

I was able to get the new operator-sdk build working by adding these files to the project:
{...}
But that created other problems. For instance operator-sdk generate crds disappeared.

The projects that will be scaffolded in the new layout will have the PROJECT file as you could check. And then, the command operator-sdk generate crds no longer is applied for the new layout. The structure changed and this operation will be done via target in makefile which brings more flexibility to its users.

I'm going to use a different solution to my problem, but I'll leave this ticket open, because the new structure will need documentation eventually.

In the https://master.sdk.operatorframework.io/docs/golang/ you are able to check the docs over the new layout. You need to choose master:

So, I am closing this issue. However, please feel free to raise new ones if you wish and if you need help.

Thanks @camilamacedo86 for the detailed description!


Any chance to have a release (or pre-release) for this project

I'd like to help with the automatic release via GitHub Actions if it's possible.

Thanks, I'm not an expert in GitHub Action, if you can do that, that would be wonderful.


fix NPE

If attibute value = null  you cannot save that data:
java.lang.NullPointerException: null value in entry: OutboundQueueError=null                 at com.google.common.collect.CollectPreconditions.checkEntryNotNull(CollectPreconditions.java:33)                 at com.google.common.collect.RegularImmutableMap.fromEntryArray(RegularImmutableMap.java:69)                 at com.google.common.collect.RegularImmutableMap.fromEntries(RegularImmutableMap.java:46)                 at com.google.common.collect.ImmutableMap.copyOf(ImmutableMap.java:354)                 at com.google.common.collect.ImmutableMap.copyOf(ImmutableMap.java:327)                 at com.googlecode.jmxtrans.model.Result.<init>(Result.java:65)                 at com.googlecode.jmxtrans.model.JmxResultProcessor.getNewResultObject(JmxResultProcessor.java:187)

:white_check_mark: Build jmxtrans 21 completed (commit https://github.com/jmxtrans/jmxtrans/commit/be8f44506b by @grolfcry)

:white_check_mark: Build jmxtrans 22 completed (commit https://github.com/jmxtrans/jmxtrans/commit/756ceb8ac2 by @grolfcry)

:white_check_mark: Build jmxtrans 23 completed (commit https://github.com/jmxtrans/jmxtrans/commit/fbbdd139b9 by @grolfcry)

@gquintana is working on refactoring code close to this PR (#614). I'd like him to at least have a look before merging this. And it might well be that his refactoring will fix that issue anyway.

This PR makes sense. It should be fixed in my PR as well as null values are handled uniformly.
Can you add a unit test for this case?

:white_check_mark: Build jmxtrans 24 completed (commit https://github.com/jmxtrans/jmxtrans/commit/eef9f23dd6 by @grolfcry)

Thanks @grolfcry


(DOCS) Update to sync with DITA source

Also removed Release Notes files. This information is not tracked in GitHub.

Waiting for CLA signature by @katelopresti
@katelopresti - We require a Contributor License Agreement (CLA) for people who contribute to Puppet, but we have an easy click-through license with instructions, which is available at https://cla.puppet.com/
Note: if your contribution is trivial and you think it may be exempt from the CLA, please post a short reply to this comment with details. http://docs.puppet.com/community/trivial_patch_exemption.html

CLA signed by all contributors.

@katelopresti we should pair on improving this.


chore: update namespace and assembly name.

Proposed Changes

Refactoring (no functional changes, no api changes)

What is the current behavior?

Chinook namespaces & assembly name

What is the new behavior?

Renaming namespace better reflecting what this package contains (AsyncWebView)

Checklist
Please check if your PR fulfills the following requirements:

[ ] Documentation has been added/updated
[ ] Automated Unit / Integration tests for the changes have been added/updated
[ ] Contains NO breaking changes
[ ] Updated the Changelog
[ ] Associated with an issue

Other information

The PR description mentions AsyncWebView?

The PR description mentions AsyncWebView?


support file operations in single threaded context

Objective

Fixes #10209
Assets should work in single threaded

Solution

In single threaded mode, don't use async_fs but fallback on std::fs with a thin layer to mimic the async API
file file_asset.rs is the async imps from mod.rs
file sync_file_asset.rs is the same with async_fs APIs replaced by std::fs
which module is used depends on the multi-threaded feature

I think this looks good.
I think there is the possibility of a future PR to make async-fs an optional dependency that only gets brought in when "multi-threaded" is enabled. Though that also requires either making the AssetProcessor work in single-threaded, or making it only build when "multi-threaded" is enabled.
I thought I saw somewhere Cart said that the AssetProcessor currently relies on being multi-threaded, but I can't find that comment, and the code doesn't seem to be gated on that feature.


Fix build break in SPDM-Responder-Validator

#1281 moved functions from internal common_lib to the Requester / Responder .c files and made them static. However the SPDM-Responder-Validator needs to access some of those functions and #1281 caused a build break.
This pull request moves function declarations that are needed by SPDM-Responder-Validator to the internal requester_lib and responder_lib libraries. The function definitions remain in the requester_lib and responder_lib .c files.
Signed-off-by: Steven Bellock<EMAIL_ADDRESS>

Merging now since this fixes a build break.


Where is Contributing Guidelines?

Hi.
I have checked the files inside of this repository but i didn't find anything that contains Contribution guidelines.
GitHub provides a special file for this named CONTRIBUTING, plus CODE_OF_CONDUCT.
You can add these files to the repository to let people contribute and collaborate with this project.
Thanks.

ill have a look (or anyone else, feel free to add)
https://help.github.com/articles/setting-guidelines-for-repository-contributors/

Contribution Guidelines Added. (Thanks to @unitycoder)


x/build/cmd/gomote: don't push gitignored files

Broken out from https://github.com/golang/go/issues/13834#issuecomment-272524137.
I have a lot of gitignored files in my GOROOT. (Don't ask, please.) gomote pushes them all, which is slow and pointless. I'd like gomote not to do this. I would implement by starting a git check-ignore process running concurrently and feeding it paths as part of the filepath walk.
This issue is to ask for approval before putting in the time to implement.
@bradfitz

Sure.


Oneof field written not by field number order

Message serialized by java:

Same with golang:

(Field 2 which declared as oneof{2,13} was written in the end)
The standard doesnt require the field order to be sequential, though i suggest implementing ordered field write in "deterministic mode" or by default to have more compatibility between languages.

As noted, the standard neither requires nor specifies a canonical field order. As such, all implementations must be prepared to receive fields in any order†.
There is no reason why this package needs to or should go out of its way to force a deterministic order that is not canonically specified.
†: repeated entries must remain in order relative to each other.

As @puellanivis says, protobufs do not have a canonical serialization form. Different implementations can and do produce different bytes to serialize the same message.
A deterministic, canonical serialization form is a common request, but this is a feature that would need to be added to all supported implementations in a coordinated fashion. The main protobuf issue tracker would be the place to request this.


Automatically scroll to the frontmost app when switching apps

This makes sure that the current app is always visible unless the user manually scrolls away.

@pigigaldi please merge. It's a very useful feature to have 😉


Attribute lazy initialization

[@matejonnet] Looking for a shorter way to initialize an object attribute on a first use,
and ability to use immutable attribute instead of variable
variable Foo? foo := null;
Foo getFoo() {
    if (exists f = foo) {
        return f;
    }
    foo := createFoo();
    if (exists f = foo) {
        return f;
    }
    throw;
}

I would like to write this as:
Foo? foo;
Foo getFoo() {
    if (!exists foo) {
        foo = createFoo();
    }
    return foo;
}

[Migrated from ceylon/ceylon-spec#438]

+1 for memoized
If someone unfamiliar with the concept encountered memoized in a piece of Ceylon code, they'd probably google it and the first result would be Memoization.  It might be considered a Term of Art, as I've only seen it used in relation to computer science.

@fwgreen I think I prefer lazy, also like cached, would be fine with memoized, but really dislike once.

Could we have this in the next version? It doesn't look like a big change to implement, once we all agree on a name.

@bjansen I don’t really like this feature that much. It would be convenient, but it isn’t something we can’t already do really easily.
Besides the name, there is another issue: = vs =>. When you start to think about this, you start to notice how this will break the nice regularity of the language that says = is eager and => is lazy, by adding an in‐between.

but it isn’t something we can’t already do really easily.

Thread safe initialization (if we go that route) would be something not currently possible without native("jvm").

cached value a => func(); would still be lazy, but its initial result would be reused in subsequent calls.

I propose the following syntax:
late Float pi = calculatePi();

Where I'm repurposing the late annotation to mean "initialized lazily" instead of just "initialized later". There's no ambiguity here, since currently a late field can't have an initializer, and the compiler enforces that.
Reasons why I think this is reasonable:

it seems to match the English meaning of "late",
the actual code generation is pretty similar: instead of throwing an exception, we initialize it to the given expression, and
it seems to me that issue #6721 applies equally to lazy fields as to late fields (they can both be placed in the declaration section).

+1

Even better +1

Would the type checker produce an error if you tried to assign to a late value? e.g.
shared late Float pi = calculatePi();
shared void run() {
    pi = 22.0/7; // error here?
}

I really dislike this idea. It seems to me like the late annotation is being used here for two completely different things simply because “it isn’t ambiguous”.
Either way, I don’t think we can have this feature without drastically changing the meaning of either = or =>, that’s why I really dislike it. If you guys introduced a new symbol for “memoized assignment” (maybe ~>) instead of an annotation I wouldn’t mind. But even then it might be a bad idea, because:

It might be too late to do such thing.
It’s very specific‐purposed.

Again, it’s not particularly hard to overcome the inexistence of this feature:
variable Integer? lazyVal = null;
shared Integer val => lazyVal else (lazyVal = computeVal());

By the way, if this was something I needed all the time, I wouldn’t mind a little bit of irregularity. But this is something I’ve never actually needed.

Would the type checker produce an error if you tried to assign to a specified late value?

Well, that's something I was wondering about, and I'm not sure, but I guess I think it should be an error, at least for shared, non-variable fields. But yeah, that's something that needs thinking-through.

Btw, this use of late we'll be able to use everywhere, right? I mean, even locally and such.

late fields can already be variable (and non-variable ones can only be assigned once), so I’d say disallowing that for non-variable late fields would be consistent.
Another question:
T printIt<T>(T t) { print(t); return t; }
late Integer i = printIt(1);
shared void run() {
    i = 2;
}

Does this print something? That is, if the value is assigned before ever being read, is the lazy initializer evaluated?

Btw, this use of late we'll be able to use everywhere, right? I mean, even locally and such

+1 on being able have memoized initialization for locals

I really dislike this idea. It seems to me like the late annotation is being used here for two completely different things simply because “it isn’t ambiguous”.

It might "seem" like that to you, but if you expect to be able to convince anybody else that these are two "completely different" things, then you need to present us with an argument for how and why they are semantically distinct and exhibit very different behaviors.
I've already presented a sketch of an argument for how the behavior is very semantically similar. How is my argument incorrect.

late fields can already be variable (and non-variable ones can only be assigned once), so I’d say disallowing that for non-variable late fields would be consistent.

Probably, yes.

Btw, this use of late we'll be able to use everywhere, right? I mean, even locally and such.

I guess. But we might not need that immediately.

@Zambonifofex By the way, to make my argument more explicitly:
The only difference between the two scenarios for late value foo is that in one scenario, some code has to explicitly assign foo = something, whereas in the other, = something is assigned implicitly when needed. This difference is reflected in the existence or nonexistence of an initializer in the declaration.
Otherwise, there is no difference in semantics AFAICT.

it seems to match the English meaning of "late"

Just because it makes sense in English doesn’t mean it makes sense in Ceylon.

the actual code generation is pretty similar: instead of throwing an exception, we initialize it to the given expression

~

Otherwise, there is no difference in semantics AFAICT.

What do you mean by there is no difference? late, in its former meaning, is used to tell the typechecker to shut up about the initialization of the value, allowing you to initialize (or to not initialize) the value whenever you want. This is completely different from what memoized would do.
I guess you are trying to say that late without the assignment would implicitly be equivalent of this pseudo‐Ceylon:
late String foo = assert(false);

But that’s not correct. As you guys have been discussing, late allows you to assign things to it whenever you want, memoized would not. That’s a very different change in semantics in my opinion. I honestly cannot see what you think is similar about these.

it seems to me that issue #6721 applies equally to lazy fields as to late fields (they can both be placed in the declaration section)

Yeah, the can both appear in the declaration section, sure, but for completely different reasons. memoized values can because they are lazy. late values can because they are not assigned yet, and don’t run any code. Supposedly, non‐late values that are assigned later also can appear in the declaration section:
class Foo()
{
    shared void foo() => ...;
    String bar;
    shared void baz() => ...;
    // end of declaration section
    bar = "hello";
}

Sorry, I forgot to at-mention you, @gavinking.

late, in its former meaning, is used to tell the typechecker to shut up about the initialization of the value, allowing you to initialize (or to not initialize) the value whenever you want.

In light of #6721, it's clear to me that late has this function in both cases.

Yeah, the can both appear in the declaration section, sure, but for completely different reasons.

They can both occur in the declaration section for exactly the same reason: because the field is not initialized at its point of declaration in the procedural flow of the code. Instead the field is initialized later.
The only difference is the precise means by which the field comes to be initialized. And there is already a very clear syntactic difference which distinguishes that.
It seems to me that your argument here is rather weak.
P.S. Your code example is completely wrong. The entire body of that class belongs to the initializer section, since the last statement is an assignment.

@gavinking

P.S. Your code example is completely wrong. The entire body of that class belongs to the initializer section, since the last statement is an assignment.

In light of #6721, it's clear to me that late has this function in both cases.

Sorry, I don’t follow.

They can both occur in the declaration section for exactly the same reason: because the field is not initialized at its point of declaration in the procedural flow of the code. Instead the field is initialized later.
The only difference is the precise means by which the field comes to be initialized. And there is already a very clear syntactic difference which distinguishes that.

I really like this argument, by the way :smile:. I think the difference in the means by which the field comes to be initialized is big enough for it to be a different annotation. I guess that that’s where we disagree, but at least now I understand your point‐of‐view.
I don’t want to repeat myself too much, but I want to at least repeat that the annotation here is not the only thing I dislike about this feature. I think it’d be great if you tried to argument against my other complaints!

I think the difference in the means by which the field comes to be initialized is big enough for it to be a different annotation.

But that difference is already captured syntactically. We don't need annotations when the syntax is already sufficient to disambiguate.

I agree with @Zambonifofex that late and memoized are fairly different, because: the fact that a value is memoized is irrelevant outside if it's definition, whereas 1.3.1's late matters externally.
AFAICT, from the type checker's perspective, much (all?) of the existing logic for late outside the value's declaration would be replaced by late && !specified.
This affects:

The ability to assign to non-variable late values, which I feel should be disallowed by the type checker (and I strongly feel that this should at least result in a runtime error, even for previously un-accesed values, otherwise I'd never use shared late)
Rules and behavior regarding inheritance of late members, which is currently under defined. There is currently a proposal to disallow default late (https://github.com/ceylon/ceylon/issues/6455), but this wouldn't be necessary for default late + specified.

But that difference is already captured syntactically. We don't need annotations when the syntax is already sufficient to disambiguate.

Unlike @Zambonifofex, I'm not totally arguing against reusing late, but I do think the rules regarding memoized values should not be unduly influenced by existing rules for late.

Another question:

T printIt<T>(T t) { print(t); return t; }
late Integer i = printIt(1);
shared void run() {
    i = 2;
    value j = i;
}

Does this print something? That is, if the value is assigned before ever being read, is the lazy initializer evaluated?
Please, don't let this be allowed!

Should initialization be thread safe, perhaps with volatile and synchronized? My thought is "yes".
Optionally, there could be an annotation to request thread-safe initialization, and perhaps even another idempotent to permit multiple evaluations of the specifier expression. But the downside is that Ceylon doesn't otherwise explicitly address thread safety.

Should initialization be thread safe

We so far haven't specified any of that anywhere yet in Ceylon. Why start now? :)
I still think we should not bother with low-level threading in Ceylon at all. If you need that just use Java directly. For Ceylon we should probably just go in the direction of actors or other similarly high-level constructs.

We so far haven't specified any of that anywhere yet in Ceylon. Why start now? :)

I think this feature is uniquely vulnerable to threading bugs.
Well, not totally unique. Toplevels are too, but the Java backend provides thread safety for them.

Here’s another interesting parallel of this feature to regular lazy.
Suppose we have the classic parent-child circularity problem. That is, this code is illegal:
class Child(name, parent) {
    shared String name;
    shared Parent parent;
}
class Parent(name, String childName) {
    shared String name;
    shared Child child = Child(childName, this); // error: leaks 'this' reference in initializer
}

The current recommended solution, as far as I’m aware, is to use late with a separate initialization method:
class Child(name, parent) {
    shared String name;
    shared Parent parent;
}
class Parent(name, String childName) {
    shared String name;
    shared late Child child;
    shared void init() {
        child = Child(childName, this);
    }
}

Alternatively, as @jvasileff suggested in chat, you can make child a lazily computed attribute backed by an optional variable that is initialized when null:
class Child(name, parent) {
    shared String name;
    shared Parent parent;
}
class Parent(name, String childName) {
    shared String name;
    variable Child? child_ = null;
    shared Child child => child_ else (child_ = Child(childName, this));
}

But that’s pretty much exactly what lazy in this proposal does for us! So we can abbreviate this to:
class Child(name, parent) {
    shared String name;
    shared Parent parent;
}
class Parent(name, String childName) {
    shared String name;
    shared late Child child = Child(childName, this);
}

@lucaswerkmeister wow, interesting!

I have implemented this idea in the 3544 branch. Over to you @chochos + @tombentley!

T printIt<T>(T t) { print(t); return t; }
late Integer i = printIt(1);
shared void run() {
    i = 2;
    value j = i;
}

Does this print something?
I think there might be some potential for unexpected results or surprise for developers if the lazy initializer expression in the declaration of the late item is never executed in some circumstances (like the one in the code sample above), but curious to know what the conclusion was for cases like the above.

I've just pushed JVM support for this to 3544 branch (also rebased into current master). If @chochos can  implement support on JS and we should be able to merge.

I couldn't compile this test for JVM (which I assume should be a proper test):
class LateAndLazy() {
  shared late Integer def = system.milliseconds;
  shared late Integer? opt = system.milliseconds;
  shared late variable Integer vardef = system.milliseconds;
  shared late variable Integer? varopt = system.milliseconds;
}

shared late Integer latedef = system.milliseconds;
shared late Integer? lateopt = system.milliseconds;
shared late variable Integer latevardef = system.milliseconds;
shared late variable Integer? latevaropt = system.milliseconds;

shared class LateStatic {
  shared static late Integer def = system.milliseconds;
  shared static late Integer? opt = system.milliseconds;
  shared static variable late Integer vardef = system.milliseconds;
  shared static variable late Integer? varopt = system.milliseconds;
  shared new(){}
}

shared void run() {
  value now = system.milliseconds;
  assert(now<=latedef);
  assert(now<=latevardef);
  if (exists x=lateopt, exists y=latevaropt) {
    assert(now<=x);
    assert(now<=x);
  }
  value i=LateAndLazy();
  assert(now<=i.def);
  assert(now<=i.vardef);
  if (exists x=i.opt, exists y=i.varopt) {
    assert(now<=x);
    assert(now<=y);
  }

}

@chochos thanks! Now fixed

Excellent! Thanks @tombentley!

🎉

@tombentley Here's an example that is accepted by the typechecker, but breaks the backend:
class Thing() {
    shared late String name = get();
    String get() => "Tom";
}

shared void run() {
    value thing = Thing();
    thing.name = "Gavin";
    print(thing.name);
}

Ah, so the semantics of this thing are what, exactly?

Even though it has a specifier in the declaration, because it's late it can still be assigned to?
And because it's not variable I can only assign to it once (not counting the specifier in the declaration)?
So if I access name before the assignment in run() I would get "Tom", and if I access it after that assignment I should get "Gavin"?

Even though it has a specifier in the declaration, because it's late it can still be assigned to?

Yeah, I think we may as well allow that. It makes the semantics a little simpler, easier to state.

And because it's not variable I can only assign to it once (not counting the specifier in the declaration)?

Right.
So if I access name before the assignment in run() I would get "Tom", and if I access it after that assignment I should get "Gavin"?
Yes but note that if you access it before assignment, and then try to assign it, you'll get an error.

@tombentley do you agree that those semantics are reasonable?

:-1: – this strikes me as weird, and I think it would make this feature significantly less useful. It would mean that I can’t use this to initialize any shared state, because anyone else could overwrite my own initialization (if only once).

@lucaswerkmeister Not correct. Re-read. A non-variable can still only be assigned once.

And because it's not variable I can only assign to it once (not counting the specifier in the declaration)?

Right.

If I understand this correctly, you’re saying that the value can be assigned once, in addition to the specifier in the declaration. I don’t want that.

@lucaswerkmeister
I guess the specifier in the declaration doesn’t really assign the value until it’s accessed at least once, but then if you access it before assignment, and then try to assign it, you’ll get an error.

If I understand this correctly

Isn't it more that whatever comes first happens? Meaning that if you read first the specifier gets used while if you write first that value gets used instead of the specifier?

By the way, I’m not saying that I agree with @gavinking here, I agree with @lucaswerkmeister in that this feels counterintuitive, and that I’d rather have that kind of code rejected by the type‐checker.
That’s exactly why I think there should be a different annotation: because the semantics are very different from each other.

Has it been determined if shared default late + specified will be allowed, and if allowed, the semantics?

@quintesse I would also strongly object to that interpretation.

@lucaswerkmeister not saying I don't agree with you, but a good reason as to why you strongly object would be nice :)

What @quintesse said is the interpretation I favor. That way the specifier defines a default value that is used if you never assign it anywhere else. Sorta but not exactly like defaulted parameters.

And the reason I favor this interpretation is that it gives 'late' a more consistent behavior between the two cases.

Which is fine, and I appreciate that. But @lucaswerkmeister has a good practical point which is that very often people want to lazily initialize a value without allowing the possibility for a client to overrule that value. So maybe it is a mistake to try to squeeze those semantics into late.

@quintesse well, I already said it above – I see this feature as a way to defer initialization while still remaining in control of it (my class doesn’t rely on someone else calling an init method anymore), whereas with that interpretation, people can completely sidestep the initialization I had in mind.

So maybe it is a mistake to try to squeeze those semantics into late.

Perhaps, but frankly I don't find it very appealing to introduce a new annotation that is in so many other respects so extremely semantically similar to late.

@gavinking
I honestly can’t see how it’s extremely semantically similar to late. I can see a faint connection, but I honestly don’t understand what you see so similar about those two behaviors. They do completely different things, are implemented completely differently, and would be specced differently aswell.
I don’t think trying to merge those two behaviors into one single annotation would be a good idea. If you want the behavior you are describing, you’d annotate the value as late memoized.

They're very similar in how they affect definite assignment checking and determination of where the initializer section ends. This is, of course, the most interesting thing about these annotations.

They do completely different things, are implemented completely differently, and would be specced differently aswell.

That's just not true at all.

[…] determination of where the initializer section ends

Sure.

[…] affect definite assignment checking

I don’t understand. By @lucaswerkmeister’s definition, memoized values would always be considered as assigned, while current late values would always be considered as assignable.

That's just not true at all.

I can’t speak for the implementation, but I definitely feel like they’d do completely different things. And if you could exemplify how you think the spec would be, and how the two behaviors would overlap, it’d great (I’m trying to convince myself that they are similar and failing; if you could do that, that’s what would be great).

By @lucaswerkmeister’s definition,

That is not the definition that I have implemented!

while current late values would always be considered as assignable.

No, that's just not the current semantics! late values can be assigned exactly once. This new feature just tells you what to do if the late value is accessed before it is assigned, i.e. instead of an exception, evaluate the initializer. That's an incredibly simple, localized change.

I can’t speak for the implementation

Here's how I implemented the typechecker part of this: @eb5b3b8ed5f6c36a7642e2511e1b63b7e09ab68f. Note that I deleted more code than I added. It made the typechecker simpler.

I definitely feel like they’d do completely different things.

I don't care about vague feelings. I care about objectively measurable things.

And if you could exemplify how you think the spec would be

The spec change is trivial as hell:

remove the restriction that a late value can't have an initializer (arguably more regular).
specify, that in the case of access to an uninitialized late value, if there is an initializer, use that to initialize the value instead of throwing an exception.

That's it, AFAICS.

@lucaswerkmeister

with that interpretation, people can completely sidestep the initialization I had in mind.

I understand this concern, and I'm sympathetic to it, but OTOH, it's quite trivial to get the behavior you're looking for:
late value _thing = Thing();
shared Thing thing => _thing;

This way, you avoid sharing the "assignability" of _thing.
Furthermore, if you happen to be implementing an interface, you don't even need to do that.

Note that what attracted me to this whole solution was how tiny of a change it was to the Ceylon language. I got to piggyback/reuse the existing behavior of something that already existed for a long time.

@gavinking

That is not the definition that I have implemented!

Well, I agree that, by your definition, it’s really similar to late today.

while current late values would always be considered as assignable.

late values can be assigned exactly once.

I’m saying that they are considered as assignable by the compiler. I know trying to assign them more than once would result in an error at run‐time.

This new feature just tells you what to do if the late value is accessed before it is assigned

The spec change is trivial as hell:

Under your definition. Under @lucaswerkmeister’s definition (the one I strongly prefer), this simply wouldn’t be the case.
I think your definition would simply not be that useful. When will someone actually prefer to allow their interface user to actually override their given memoized value? When will that actually be better than @lucaswerkmeister’s definition?

@gavinking fixed. If we want to change the semantics of late+specifier, that's another issue.

fixed.

Thanks Tom.

If we want to change the semantics of late+specifier, that's another issue.

Yeah, let me reflect on this. If we do, it's just a typechecker change.


Throttling upload's speed

I want to limit the speed of the upload stream to a certain bps.
I would normally do this when downloading files, using Throttle NPM, but how would I apply something similar for limiting the uploading speeds?

What I have tried is to replace
this._parser =  parser;
with
const throttledStream =  new Throttle(10000);
this._parser = throttledStream ;
throttledStream .pipe(parser);

inside plugins/multipart.js

as well as reducing the watermark on all request streams.

Closing since it is out of scope. But feel free to discuss, I think the best is to throttle on the http framework layer


[jvm-packages] xgboost4j: publishing sources along with bins

This code snippet publishes the sources to the maven local repo along with the binaries.
With this change it is possible to use Java IDEs functions like "jump to function" and see the actual source code - as they automatically get the sources from the maven repo.

Hi, thanks for the contribution
would you also add some words in https://github.com/dmlc/xgboost/blob/master/doc/jvm/index.md about how to publish to local maven with source-attached?

Just added a few lines there. Please let me know what you think.

will it also work for scala classes (xgboost4j,xgboost4j-spark)?

I thought it would, but it turns our that it doesn't publish Scala source, only Java. However, there's a simple fix for that (committing it now...)

LGTM, thanks


[Search] Close search results after setting the input value.

I'm trying to clear the input value from onResultsClose with $(search).search('set value', ''), but that gets overwritten since the callback is executed BEFORE the value is set internally and no other callback is available to do it after setting the value internally.
This pull request is to fix the issue.

One way would be  to do it with setTimeout, but that's not the most elegant way.


Two things to fix

Ceiling button currently affects trees, bushes and tables when should be under Obstacles button.
New closed container (red) should be excluded from ceiling because nobody can hide inside.

Thanks for report! Will check and fix.


Adding ip validation for primary ip file and new unitests

Adding ip validation for primary ip file if it will be changed in future
Adding internal folder to unitests
Adding new unitests

@tsorya it looks like your update triggers a change in the go.mod file, which isn't included in the commit. The ci-job test will run steps like "go mod tidy", and it looks like a dependency on github.com/pkg/errors went from indirect to direct

/lgtm
/cc @jc-rh

/approve


Make batch_size≠1 work

It didn't work because of some hardcoded parts, should work alright now, if you have enough pics in val/ directory.

Thanks for the PR!
I'm currently testing the results of this modification, will get back to you later.

Hello @syniuhin , I've tested it. Thanks a lot for the PR 😄


Connectivity refactor

With the introduction of the MetaGraph, the Connectivity struct has been stripped down a lot. In fact, I think the struct is obsolete and can be replaced by the MetaGraph altogether. For the remaining fields:

[ ] The flow data can be distributed over the EdgeMetadata instances. The problem with that however is that control edges do not have a flow associated with them, so this field would be redundant for control edges. Making separate metadata types for flow and control edges is probably also not nice since then MetaGraph.label_type is not fully typed. Perhaps the flow can be made a length 0 or 1 vector (that probably also works together more nicely with PreAllocationTools.jl and also makes them mutable). Or maybe the flow is a dense array in the graph_data and the edges contain only a reference to it. Thoughts @visr?
[ ] The AllocationModel vector can be moved to the graph_data.

Suggestion: distribute flow over edge metadata. Make EdgeMetadata mutable struct with everything exept flow constant (https://docs.julialang.org/en/v1/manual/types/#Mutable-Composite-Types). To make it work with ForwardDiff.jl, the flow field type must be a type parameter of the EdgeMetadata struct.


[FEATURE] Build Strategy from Tekton Task/Pipeline

Build strategy authors (ecosystem) will more than likely maintain a Tekton task and/or pipeline as well. Importing a Tekton task or pipeline (ex: from Tekton Hub or a Tekton bundle) as a Build Strategy can reduce duplicated efforts.
Originally posted by @cmoulliard in https://github.com/shipwright-io/build/issues/1280#issuecomment-2051208907

This feature should be discussed and formalized via a SHIP.
A potential concern is leaking our abstraction of Tekton. Tight coupling of Shipwright to Tekton is already a concern - most recently expressed by TAG App-Delivery in our CNCF Sandbox application.


docs(api): make |apiLevel| substitution a string constant

Overview
Make the |apiLevel| substitution used throughout the Python API docs a string constant, rather than dynamically using MAX_SUPPORTED_VERSION. This prevents the situation where a docs deployment after some pre-release features have been merged to edge would update code snippets across the docs site, making them unusable (without modification) in the current production release.
Speaking of such features, this PR also hides a couple of them in the API Reference so we don't have to use the docs hotfix procedure to deploy this.
Test Plan
Sandbox

Check that |apiLevel| is properly being substituted with 2.15.
Check that nothing pre-release or otherwise unusable is included in the API Reference.

Changelog

set apiLevel to a constant value in conf.py
excluded methods in autoclass

Review requests
Do we need to add an inline to-do to remove the API Reference exclusions later? Or are we content to track that elsewhere?
Risk assessment
v low, docs only.

If you want to be the one to remove the exclusions later, no preference from me. If we want someone on the software team to do it, I don't think any of us will remember it unless it's a Jira ticket tagged as v7.1.0. :)

Ticketed as RTC-362. Software doesn't have to worry about it though.


Fetch tree images from database tree data

I added the trees from the database to the data files as databaseTrees.json. The changes relate to fixing any issues that came up from doing this.

Was getting a duplicate key warning and needed to add a filter to ignore duplicate "vacant site" instances
Extracted functions normalizeNames and replaceIrregularNames to handle names with accented characters or other weird names.
After adding the database trees, the alphabetical sorting broke in the new tree dropdowns. Changed createTreeSorter to use Intl.Collator, which allows for more powerful sorting. It handles accented characters, punctuation, and letter case.

Yes, this is all the trees in the current db.
Intl.Collator is native to JavaScript, so it doesn't require any dependencies.


[Android][TextInput] onBlur doesn't work when clicking anywhere but another TextInput

Description
Using android, onBlur is never called when clicking outside of the TextInput.
It works when clicking on another TextInput though.
The problem is that I only have one TextInput on my page and that I need to know whether the text input is focused or not in order to change my view's layout.
By the way, pressing the back button hides the keyboard but doesn't blur either.
Reproduction
Create two TextInput, with only one having an onBlur handler.
Focus the one with the handler and then click anywhere but the second TextInput.
Your handler isn't called. Click on the other input, it is called.
Additional Information

React Native version: 0.37.0
Platform: Android
Operating System: MacOS

The only workaround I've found for now is to wrap my view in a TouchableWithoutFeedback and call my onBlur handler on the pressIn. Ugly but working.

Can you provide a minimal amount of code to reproduce this on rnplay.org? This is necessary for people to be able to see and debug the issue being reported.
Closing this issue as it is not actionable. Please open a new one with an rnplay link (preferred), or link to a GitHub repo with clear instructions how to repro.

I also have this issue. Here is the code on rnplay.org: https://rnplay.org/apps/inL0Dw

+1

@mkonicek please reopen the issue

I'm getting the same exact issue - would love any guidance on a sound solution!

Same issue here on iOS! Did anyone find a solution?

Same issue on iOS and Android. React-native 0.42 ;-/

This is happening for me as well!

+1 here,
btw, unfortunately the Scroll View solution did not work and onEndEditing also is not triggering anything.
Same behaviour on Android and iosSimulator.

This issue affects me too and has bad implication on my app's usability. None of the mentioned workarounds mention, work for me. Can't find any other one...
Any help? Please.

It will blur when you click a ScrollView

Also having the same issue on Android only. None of the work arounds are working for me.

FYI: for the unfortunate google search that lands here use this props to handle actions you would with onBlur  (android)
<TextInput onEndEditing={(e) => this.handleBlurCheck(e.nativeEvent.text, params)} />


fix: prevent concurrent deployments on the same pointers

We are now preventing concurrent deployments on the same pointers. These are EXTREMELY rare, but in the event they happen, the database could end up inconsistent.

@marcosnc, how would you test this?
I've tried making concurrent deployments, but they were not "concurrent enough" for the new mechanism to kick in


Support for docker login when using ACI on Windows

Cool. Thanks @mauroservienti
The dust index is auto generated and not really worth reviewing
I will have to do a follow up PR too because apparently something with the compose stuff is broken for a while and needs fixing


Figma Responsive Mobile Design

Originally posted by @jirawat94 in https://github.com/policytracka/policytracka/issues/1#issuecomment-1463360868

Figma Prototype
https://www.figma.com/file/A6nsR8M9XO03AD9FP9fHI1/PolicyTracker?node-id=0%3A1&t=pCZPWJf2akwvWvUw-1

Suggestion goes here


Race condition - Missing a barrier between data-dependent sections

Hello,
I realized that there is a race condition in the code.
Specifically, after line 141 in decomp.c , there should be a barrier since the next loop is data-dependant on the results of the previous function call "mm_unroll_1x8".
Thank you.
Best,
Dimitrios

Hi,
you're right, I've fixed it. Thank you!
Best,
Mattia


Input type select behaves different than regular select

This component:
<Input type="select" class="" name="parentCategory" id="parentCategory" bind:value={category.parent}
       on:change={reloadCategories}>
    {#each parentCategories as c, i}
        <option value="{c.id}">{c.id} - {c.name}</option>
    {:else}
        <option disabled>- no categories -</option>
    {/each}
</Input>

behaves differently than regular select:
<select name="parentCategory" id="parentCategory" bind:value={category.parent}
       on:change={reloadCategories}>
    {#each parentCategories as c, i}
        <option value="{c.id}">{c.id} - {c.name}</option>
    {:else}
        <option disabled>- no categories -</option>
    {/each}
</select>

when in reloadCategories there is a simple log:
console.log('Parent category', category.parent)
category value is printed as before binding.
In normal select this works properly, value is bind and function attached to on:change gets correct value.
Seams like Input calls on-change before value is bind.

Hi @konrad-pawlus , this is kind of intentional/unavoidable, and a side effect of the way Svelte handles custom components.
It works because you specified the order of the bind:value and on:change.  If you reversed it would be consistent.
Unfortunately we must specify some order in the custom component: https://github.com/bestguy/sveltestrap/blob/master/src/Input.svelte#L495
as Svelte does not allow you to pass on:events in restProps.
This is related to:  https://github.com/sveltejs/svelte/issues/4616

Hi @bestguy , I created reply and seams it is not issue of any order of bind and on change: https://svelte.dev/repl/5c77db352e4d442bb3206d4ea676f865?version=3.42.4
Please select any value from first select box, than do this once more, what I observe:

select Cat 2 - still null value is bound,
Select Cat 3 - value of 2 is bound,

Than do same with regular select. It works as expected.

Maybe changing order so bind happens first would be a temporary solution?

That is an option, however there are people who use the on:change to do validation prior to setting value, etc.
Might I ask what functionality you are trying to accomplish with on:change that requires the value and on:change to be in sync?

I am just developing 2 simple selects, 2nd one options are populated on 1st one change. This can be accomplished exactly as described with vanilla Bootstrap.

I'd normally use a computed that is derived from the first value, but can send a sample if that would help.

I solved it by workaround using basic select instead of component.


removed hardhat

@NoroMeb
I've set up the branch. All you needed to do was clone/fork this repo, then create the foundry project inside the packages folder, instead of creating an entirely different repo.
Here, check the branch, it includes your code, you can clone that branch and work with it: chore: foundry project

@NoroMeb once you've setup the branch locally let me know, so I can close this PR


Duplicated jobs for logs when using log_slots

Bug Description
When I am trying to use the log_slots for a snap that provides two slots, for example,
# in snapcraft.yaml
...
slots:
  ovn-logs:
    interface: content
    source:
      read:
        - $SNAP_COMMON/log/ovn
  ovs-logs:
    interface: content
    source:
      read:
        - $SNAP_COMMON/log/openvswitch
...

and in the charm, I used the slots:
# in ./src/charm.py
self._grafana_agent = COSAgentProvider(
    ...
    log_slots=["openstack-hypervisor:ovn-logs", "openstack-hypervisor:ovs-logs"],
    ...
)

The logs section of /etc/grafana-agent.yaml contains duplicated jobs:
logs:
    ...
    - job_name: openstack-hypervisor
      pipeline_stages:
      - drop:
          expression: .*file is a directory.*
      relabel_configs:
      - replacement: /openvswitch
        source_labels:
        - __path__
        target_label: path
      static_configs:
      - labels:
          __path__: /snap/grafana-agent/13/shared-logs/openvswitch/**
          job: openstack-hypervisor
          juju_model: controller
          juju_model_uuid: d451ba9f-c875-4845-8564-adc06a1880a7
        targets:
        - localhost
    - job_name: openstack-hypervisor
      pipeline_stages:
      - drop:
          expression: .*file is a directory.*
      relabel_configs:
      - replacement: /openvswitch
        source_labels:
        - __path__
        target_label: path
      static_configs:
      - labels:
          __path__: /snap/grafana-agent/13/shared-logs/openvswitch/**
          job: openstack-hypervisor
          juju_model: controller
          juju_model_uuid: d451ba9f-c875-4845-8564-adc06a1880a7
        targets:
        - localhost

To Reproduce
See bug description
Environment
N/A
Relevant log output
N/A

Additional context
No response

Hi @Abuelodelanada , I don't have the bundle to reproduce the situation, since we developing and building the charm locally. However, I created a simple snap and simple charm to reproduce it: https://github.com/chanchiwai-ray/grafana-agent-k8s-operator/tree/issue/234/grafana_agent_234. Following the "README.md" you should be able to reproduce the duplicated log configs.

The Postgresql VM charm also seems to be affected by this. We have  multiple sources in the logging slot:
slots:
  logs:
    interface: content
    source:
      read:
        - $SNAP_COMMON/var/log/patroni
        - $SNAP_COMMON/var/log/postgresql
        - $SNAP_COMMON/var/log/pgbackrest
        - $SNAP_COMMON/var/log/pgbouncer

We only get a single job in /etc/grafana.conf:
    - job_name: charmed-postgresql
      pipeline_stages:
      - drop:
          expression: .*file is a directory.*
      relabel_configs:
      - replacement: /postgresql
        source_labels:
        - __path__
        target_label: path
      static_configs:
      - labels:
          __path__: /snap/grafana-agent/13/shared-logs/postgresql/**
          job: charmed-postgresql
          juju_model: pg
          juju_model_uuid: 372cccb6-59f5-448b-8db6-93df5b88d48e
        targets:
        - localhost

And the contents of /var/lib/snapd/mount/snap.grafana-agent.fstab don't seem to be mounted on /snap/grafana-agent/13/shared-logs/.
It should be reproducible by deploying postgresql from channel 14/edge

The Postgresql VM charm also seems to be affected by this. We have multiple sources in the logging slot:
slots:
  logs:
    interface: content
    source:
      read:
        - $SNAP_COMMON/var/log/patroni
        - $SNAP_COMMON/var/log/postgresql
        - $SNAP_COMMON/var/log/pgbackrest
        - $SNAP_COMMON/var/log/pgbouncer

We only get a single job in /etc/grafana.conf:
    - job_name: charmed-postgresql
      pipeline_stages:
      - drop:
          expression: .*file is a directory.*
      relabel_configs:
      - replacement: /postgresql
        source_labels:
        - __path__
        target_label: path
      static_configs:
      - labels:
          __path__: /snap/grafana-agent/13/shared-logs/postgresql/**
          job: charmed-postgresql
          juju_model: pg
          juju_model_uuid: 372cccb6-59f5-448b-8db6-93df5b88d48e
        targets:
        - localhost

And the contents of /var/lib/snapd/mount/snap.grafana-agent.fstab don't seem to be mounted on /snap/grafana-agent/13/shared-logs/.
It should be reproducible by deploying postgresql from channel 14/edge

@Abuelodelanada ☝🏼

The MySQL and MySQLRouter VM charms are also affected by this bug. SImilar to postgres above:
slots:
  logs:
    interface: content
    source:
      read:
        - $SNAP_COMMON/var/log/mysql
        - $SNAP_COMMON/var/log/mysqlrouter

In /etc/grafana-agent.yaml
    - job_name: charmed-mysql
      pipeline_stages:
      - drop:
          expression: .*file is a directory.*
      relabel_configs:
      - replacement: /mysql
        source_labels:
        - __path__
        target_label: path
      static_configs:
      - labels:
          __path__: /snap/grafana-agent/16/shared-logs/mysql/**
          job: charmed-mysql
          juju_model: database
          juju_model_uuid: e14f3b7b-e352-4342-80c8-2d93c5ee2984
        targets:
        - localhost

The code is in PR form, but will soon be merged to release for edge


Implement recovery-backend service for RWX volumes' NFS servers

https://github.com/longhorn/longhorn/issues/2293
Signed-off-by: Derek Su<EMAIL_ADDRESS>

Update

Delete recovery backend deployment during unstallation
Add initialDelaySeconds: 3 and periodSeconds: 5 to longhorn-recovery-backend deployment.
sympton: Warning Unhealthy...: connection refused in  longhorn-recovery-backend pods due to insufficient time for the pod to start.

Waiting for https://github.com/longhorn/longhorn-share-manager/pull/36

https://ci.longhorn.io/job/private/job/longhorn-tests-regression/1934/


⚠ ClamAV has degraded performance

In 456c33d, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 94 ms

Resolved: ClamAV performance has improved in edade80 after 5 minutes.


Tests & Tested

Hi Tom, I was trying to locate and compare the historical data for the number tests issued (Tests) against the number of Tested samples. Yesterdays figures were 81,611 Tests with 54,575 Tested.
I can see the 54,575 in the CSV file but not the Tests column?

Hi @Simples80 - "tests" refers to "people tested" since that is what has been reported since the beginning, and I've been striving to maintain backwards compatibility (this is noted at https://github.com/tomwhite/covid-19-uk-data#data-files). More recently the number of tests performed has been reported, you can find these figures in covid-19-tests-uk.csv. Hope that helps.


Example code mislabels t_fine output as "Timestamp"

The Adafruit_BME280_Example.py code outputs the sensor.t_fine value with a label of "Timestamp", but from what I can tell this is actually a "fine temperature" value used in pressure and/or humidity compensation calculations. It doesn't appear to have anything to do with time and is probably of little value to anyone except in debugging. See for reference section 4.2.3 of the datasheet http://www.adafruit.com/datasheets/BST-BME280_DS001-10.pdf .

Fixed in https://github.com/adafruit/Adafruit_Python_BME280/commit/0c5024197fc736edae7f7342f852a99bff31182a


Can't use AVX-512 on X86-64 with openblas 0.3.6 version?

I found that in the latest version 0.3.6, the AVX512 DGEMM kernel has been disabled again due to unsolved problems.
It means that we can't use the avx512?
what about the 0.3.7-dev ?

DGEMM was disabled, what about the SGEMM ?

Indeed most of the AVX512 DGEMM optimizations had to be disabled in 0.3.6, and 0.3.7.dev disables the remaining ones that were originally thought to be safe. Unfortunately the person who contributed this code has not been active here since march, and I have been unable to track down the problem in his code.  There are no known problems with the AVX512 SGEMM kernel.

what about 0.3.5 or earlier release? Does it enable the avx512？

AVX512 DGEMM was added in 0.3.4 but it returns wrong results for some inputs. (#1955, #2029, #2168)
Actually disabling or enabling the AVX512 kernels is just a matter of (un)commenting a few lines in kernel/x86_64/KERNEL.SKYLAKEX, if you want to check if its affects your typical use cases.

Fixed now by wjc404's new AVX512 DGEMM kernel from #2286


go: 1.16.x -> 1.17.x

Motivation for this change
go 1.17 was released 16th August 2021
I dont mind if this PR doesn't get merged. Just raising that go 1.17 has been out for a while, and it very easy to upgrade to 1.17
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

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

[ ] Fits CONTRIBUTING.md.

Duplicate of https://github.com/NixOS/nixpkgs/pull/127519.

go_1_17 has problems (e.g. no x86_64-darwin) support so we can't change the default for now.


server port close after time out

How could a port be closed after a certain time has elapsed without receiving data. I am using the example server "example-tcp.ts"

What you could do is hook a onData handler on the socket and reset a timer you and controlling.


implementation details in the schema.org representation of articles

Hey @mfenner ,
Apologies if this really isn't the right place to discuss this, please direct me if there's a better thread.
I'm really looking for your input on the best implementation of an article citation in schema.org (I know so far it's only DataCite and not CrossRef that offers a schema.org format, but still).
In particular, I'm looking at the examples Schema.Org gives for ScholarlyArticle.  One of the fascinating but also complete nuisance elements of their implementation is the explicit enumeration of issue and volume through isPartOf.  Instead of something you might see in bibliographic formats (say, bibtex or csl) in which volume and issue would be 'top-level' attributes of an article, they've been careful with the more semantically precise definitions: the article isPartOf an issue with isPartOf a volume of a periodical.
Similarly, the datePublished is given not as a property of the article but as a property of the issue (again perhaps more semantically precise, at least as far as the publication-print date (to use the CSL term) is concerned, but not the most convenient or perhaps expected structure.  Also following this structure makes it harder to know what to do with online-only or entries otherwise missing volume/issue data.
Anyway, I guess these choices make sense, but wanted to get your thoughts. (I do note that schema.org shows two different versions, both of which use isPartOf, but the third is less explicit and simply indicates the ScholarlyArticle isPartOf both an PublicationIssue and a PublicationVolume / Periodical ... maybe this third example is the best compromise?)

Excellent point. You see similar issues with DataCite XML and Dublin Core, neither of which have direct support for periodical, volume, issues or pages.
The Bolognese gem handles Crossref DOIs, so you can see how I have implemented ScholarlyArticle, and suggest changes as needed. Use bolognese as command-line or do content negotiation at data.datacite.org. I for example always use datePublished as Property of the ScholarlyArticle.


DOC Add datasets section to website

Fix #621

This was resolved in the meantime by another PR, closing this one..


Uncaught TypeError: h.match is not a function

Error1:
GET http://mybaseurl/function (elm, attrs) {%2…   return 'theme/' + theme + '.html';      } 400 (Bad Request)
Error1 url decoded:
GET http://mybaseurl/function (elm, attrs) {%2…   return 'theme/'   theme   '.html';      } 400 (Bad Request)
Error2:
Uncaught TypeError: h.match is not a function
I have loaded libraries in my index.html file and included the dependencies ngsanitize,ngs3upload
in my module but i am getting the above errors and the directive template is not showing up in my page.

My App uses a very old version angular js lib. After upgrading, it worked.


Update travis setting to fix flaky java installation

This updates the travis setting to use pre-installed jdk8 directly and switch to Linux based build environment. This fixes flaky build issue due to brew install java being flaky.
It also saves about 5 minutes build time (~30%) per build.
This also prepares us to move to container based build once the thrift installation issue mentioned below be fixed. (which allows thrift installation and Java packages be cached and faster build startup time)
@jq  @deerzq

👍

LGTM


[rt.openssl.org #4640] Bug DLL is missing symbol after building with no-comp

Migrated from rt.openssl.org#4640 (status was 'new')
Requestors:

<EMAIL_ADDRESS>
From<EMAIL_ADDRESS>on 2016-08-05 22:45:41:
OpenSSL 1.0.2h, Windows 7 x64, building Win32, using Visual Studio 2010 build environment.

Â
perl Configure VC-WIN32 no-asm no-hw no-symlinks no-srp no-camellia no-idea no-seed no-gost no-gmp no-krb5 no-mdc2 no-rc5 no-rfc3779 no-shared no-zlib no-zlib-dynamic no-comp no-md2 no-rc2 no-sslv2 no-dso -DOPENSSL_NO_HEARTBEATS -DPURIFY

Â
perl util\mkfiles.pl > MINFO

perl util\mk1mf.pl no-asm VC-WIN32 > ms\nt.mak

perl util\mk1mf.pl no-asm dll VC-WIN32 > ms\ntdll.mak

Â
perl util\mkdef.pl 32 libeay > ms\libeay32.def

perl util\mkdef.pl 32 ssleay > ms\ssleay32.def

Â
Symbol âSSL_COMP_get_compression_methodsâ is excluded from ssleay32.def file. Â Even though the function still exists when no-comp is used.

Â
Leading to failure loading tools and utilities which call this function, but can operate without compression. (like apache mod_ssl.so)

Removing "COMP" from the prerequisites in util/ssleay.num did not result in mkddef.pl producing correct output, but it's unclear why.

Manually adding "SSL_COMP_get_compression_methods @276" to ssleay32.def and relinking the DLL resolves the issue.

This was fixed in a79a40a9fe136b63f19b6756cd2a3ce6bd170f54, which is 25 commits after 1.0.2h


delmit relation 1:1?

It's declared functional and inverse functional so 1:1.
Delimits:

An instance of Geopolitical Entity gpe1 delimits some Organization o1 iff gpe1 is the area within which o1 can legally operate.

Geopolitical entity:

A Geospatial Region that delimits the authority of a formally constituted Government to exercise its control within the bounded area.

The property's range is organization, though the definition of Geopolitical entity suggests it should be the more narrow govt.
If government, aren't there places which have shared control? In which case it wouldn't be inverse functional
If organization, couldn't several organizations be delimited by the same Geopolitical entity, in which case it wouldn't be functional?

This issue appears to have been addressed in a prior release as the property is not functional.


Bump version to 8.1.0-SNAPSHOT

@caponetto it seems like a great idea! Also, I would add an extra step for create the commit with a standard message (like "Bump version to < newversion>". Wdyt? :-)


Add support for Azure cloud storage

Description of changes:
Add support for Azure cloud storage.
Authentication with storage account shared key aka account key or access key
use environment variables AZURE_ACCOUNT_NAME and AZURE_ACCOUNT_ACCESS_KEY
test coverage is minimal, I didn't find a library to mock Azure, I suppose I can add more test coverage if absolutely required, but it does work
>>> import numpy as np
>>> from PIL import Image
>>> from streaming import MDSWriter
>>>
>>> # Local or remote directory in which to store the compressed output files
>>> data_dir = 'azure://test'
>>>
>>> # A dictionary mapping input fields to their data types
>>> columns = {
...     'image': 'jpeg',
...     'class': 'int'
... }
>>>
>>> # Shard compression, if any
>>> compression = 'zstd'
>>>
>>> # Save the samples as shards using MDSWriter
>>> with MDSWriter(out=data_dir, columns=columns, compression=compression) as out:
...     for i in range(10000):
...         sample = {
...             'image': Image.fromarray(np.random.randint(0, 256, (32, 32, 3), np.uint8)),
...             'class': np.random.randint(10),
...         }
...         out.write(sample)
...
>>>
>>> from torch.utils.data import DataLoader
>>> from streaming import StreamingDataset
>>>
>>> # Remote path where full dataset is persistently stored
>>> remote = 'azure://test'
>>>
>>> # Local working dir where dataset is cached during operation
>>> local = './test'
>>>
>>> # Create streaming dataset
>>> dataset = StreamingDataset(local=local, remote=remote, shuffle=True)
>>>
>>> # Let's see what is in sample #1337...
>>> sample = dataset[1337]
>>> img = sample['image']
>>> cls = sample['class']
>>>
>>> # Create PyTorch DataLoader
>>> dataloader = DataLoader(dataset)
>>> sample
{'class': 9, 'image': <PIL.JpegImagePlugin.JpegImageFile image mode=RGB size=32x32 at 0x2DACE9C55D0>}

Issue #, if available:
#254
Merge Checklist:
Put an x without space in the boxes that apply. If you are unsure about any checklist, please don't hesitate to ask. We are here to help! This is simply a reminder of what we are going to look for before merging your pull request.
General

[ ] I have read the contributor guidelines
[ ] This is a documentation change or typo fix. If so, skip the rest of this checklist.
[ ] I certify that the changes I am introducing will be backward compatible, and I have discussed concerns about this, if any, with the MosaicML team.
[ ] I have updated any necessary documentation, including README and API docs (if appropriate).

Tests

[ ] I ran pre-commit on my change. (check out the pre-commit section of prerequisites)
[ ] I have added tests that prove my fix is effective or that my feature works (if appropriate).
[ ] I ran the tests locally to make sure it pass. (check out testing)
[ ] I have added unit and/or integration tests as appropriate to ensure backward compatibility of the changes.

@hlky Thanks for creating a PR. Can you please re-base your branch since there is a conflicting files ? Thanks!