[path_provider] Path provider platform interface

Description
This PR is the first step in converting path_provider to use a federated plugin implementation.
It follows the first step in this article for creating federated plugins.
Though it's not determined yet what web should do for this package flutter/flutter #45296, I'm interested in creating a Linux implementation in Dart rather than C++ see google/flutter-desktop-embedding #674, and a federated interface would help with that.
Related Issues
Related: flutter/flutter#45296
Related: google/flutter-desktop-embedding#674
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
[x] All existing and new tests are passing.
[x] I updated/added relevant documentation (doc comments with ///).
[x] The analyzer (flutter analyze) does not report any problems on my PR.
[x] I read and followed the Flutter Style Guide.
[x] The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
[x] I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
[x] I updated CHANGELOG.md to add a description of the change.
[x] I signed the CLA.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
[x] No, this is not a breaking change.

I'm gonna switch to @amirh as the reviewer here because I'm not yet familiar with the plans for federated plugins.


September 2023 releases

Description

This is a large announcement so any help to review is much appreciated.

Is there any way we can attach an image to this blog post? We could re-use one of the previous announcement images, either the 🎉 or 🚀 emoji image.
Currently the default image is a giant conda "C", and it also looks like the other blog posts' images aren't showing up on the home page for some reason:


Adding fragments array to graphql function disables syntax highlighting in VS Code

Describe the bug
I have syntax highlighting and formatting for graphql enabled in VS Code. This works with gql.tada without problems. The contents of the graphql function are recognized as graphql and I get completion, suggenstions…
However, as soon as I add the fragment array as second argument, all language features are gone and it renders everything as simple template string.
So this is not recognized as graphql anymore
export const query = graphql(
  `
    query fetchCaseByTransactionPin($transactionPin: Int!) {
      case_byTransactionPin(transactionPin: $transactionPin) {
        id
        ...CaseByTransactionPin
      }
    }
  `,
  [caseByTransactionPinFragment]
);

I use the following extensions for VS Code:

Graphql: Syntax Highlighting
Graphql: Language Feature Support

Both from Graphql Foundation and I guess the most used extensions for gql. They do not provide any config to adjust detection, though. So I see no way to make this work.
Reproduction
No response
gql.tada version
v1.2.1
Validations

[X] I can confirm that this is a bug report, and not a feature request, RFC, question, or discussion, for which GitHub Discussions should be used
[X] Read the docs.
[X] Follow our Code of Conduct

This is being fixed in https://github.com/graphql/graphiql/pull/3518

Also not a bug in the library itself so closing 😅


Fail + weird error message with parameters positive=True+fit_intercept=True

Hello and congratulation for the awesome toolbox.
Not only it is the fastest one in the west but you allows us fun parameters such as weights that others do not.
Still I found a surprising behavior that in my opinion should be prevented.
hen i run the foollowing code
import numpy as np
import celer

n=6
d=9
X=np.random.rand(n,d)
y=np.ones(n)

w=np.random.rand(n)

alpha=0.1
model=celer.Lasso(alpha,weights=w,positive=True)
model.fit(X,y)

I get the following warnings:
/home/.../python3.8/site-packages/celer/homotopy.py:290: RuntimeWarning: invalid value encountered in true_divide
  theta /= scal
!!! Inner solver did not converge at epoch 49999, gap: 0.00e+00 > nan
...
!!! Inner solver did not converge at epoch 49999, gap: 0.00e+00 > nan
!!! Inner solver did not converge at epoch 49999, gap: 0.00e+00 > nan

This error disappears when I also pass the parameter fit_intercept=False that is actually the configuration i'm interested in so it's OK.
Still it feels as if someone want some positive coefficients and intercept it would be nice to have a working solution. If it is too hard to implement you should raise an error or force fit_intercept=False with a clear warning.

Hi Rémy,
Thanks for the kind words.
You use y = np.ones() and fit an (unpenalized) intercept, under the hood we will center y and thus fit with y = np.zeros(), hence  all sort of bad stuff can (and apparently, do) happen
Also be careful not to pass negative weights. I believe I should raise an error in that case, as this is easy to check
I tried with y = np.random.randn()   and the error disappears, but the solver does not converge (even without intercept and without positivity. I suspect a wrong screening), so I'll look into it in more details in the week
import numpy as np
import celer
n = 6
d = 9
X = np.random.rand(n,d)
y = np.random.randn(n)

w = np.abs(np.random.rand(n))

alpha = 0.1
model = celer.Lasso(alpha, weights=w, positive=True, verbose=True, max_iter=10).fit(X, y)

Now I get the problem, y know constant y is not common but that's what happens when you use a Lasso solver for unrelated stuff!
Still note the weights with np.random.rand(n) are positive ;)
Take your time I found a way to make it work it was just a suggestion issue.

The modification which still failed was:
import numpy as np
import celer

n = 6
d = 9
np.random.seed(0)
X = np.random.rand(n, d)
y = np.random.randn(n)

weights = np.abs(np.random.rand(n))

alpha = 0.1
clf = celer.Lasso(alpha, weights=weights, positive=True,
                  verbose=True, max_iter=10, p0=10, prune=False).fit(X, y)

which fails because weights is of shape (6,), not (9,) as it should be.
I will add a test that weights has shape (n_features,)


chore: use find to repalce forEach

Description
使用find代替forEach可以减少循环次数
Motivation and Context
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Enhancement (changes that improvement of current feature or performance)
[ ] Refactoring (changes that neither fixes a bug nor adds a feature)
[ ] Test Case (changes that add missing tests or correct existing tests)
[ ✓] Code style optimization (changes that do not affect the meaning of the code)
[ ] Docs (changes that only update documentation)
[ ] Chore (changes that don't modify src or test files)

Self Check before Merge

[✓] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[✓] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

find会终止继续执行
而forEach不会


Failed to load module script: The server responded with a non-JavaScript MIME type of "application/octet-stream". Strict MIME type checking is enforced for module scripts per HTML spec.

Failed to load module script: The server responded with a non-JavaScript MIME type of "application/octet-stream". Strict MIME type checking is enforced for module scripts per HTML spec.
I get this error while loading a javascript file as a module.

How to resolve this issue?

I realize this was months ago, but are you sure the file is there?  http-server should send the correct MIME type based on extension, so if js/app_vue.js exists then it should be served as application/javascript.  Try loading that file directly and watch the response in the developer tools network tab.

@devvpm could you make sure you're on the latest version of http-server, then try out
$ curl -v http://localhost:8080/js/app_vue.js

and see what http-server is saying the Content-Type is? I wonder if this may be due to the type="module"

This should be fixed on v13, please reopen if this is not the case


Observing parent doesn't observe children

Hi,
Looks like when you add an observer to a parent class, the children classes don't benefit from the observer.
It can be solved by adding the following to ReturnsChildModels on the parent class:
    public static function observe($classes)
    {
        parent::observe($classes);
        // register the observer on the children only if we're observing the parent
        if (static::class === self::class) {
            foreach ((new self)->childTypeAliases as $child) {
                $child::observe($classes);
            }
        }
    }

This way, adding an observer to the parent will add it to all the children, and adding an observer to a child will only add it to the child.

I think PRs are welcome ;)


⚠ Bofrost.de has degraded performance

In 29e8d5a, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1244 ms

Resolved: Bofrost.de performance has improved in cc8d598 after 9 minutes.


Add the ability to destroy a story

It would be great to enable the deletion of a story.

Looks great! what do you think about replacing the word "destroy" for "delete" ? We as developers are very used to the concept of destroying a record, but users are more used to "delete" their data.

You're right, this is done.


Custom exceptions

Check: https://github.com/nette/utils/blob/master/src/Utils/exceptions.php

Not required in this time.


Stop reordering

I have added the idlemembers.json file, since we don't have any idle members in staging.

@Pavangbhat after dropping task on successful assignation task status becomes assigned, as we are only showing unassigned task on page so any how that task gets out of list.

It gets out of the list once we refresh the page till then it is going to be present on the list, that is what I found when I ran the changes that you have made 🤔

It gets out of the list once we refresh the page till then it is going to be present on the list, that is what I found when I ran the changes that you have made 🤔

How?? after each drop action we are fetching new data, so the current task being dropped will be marked as assigned, and will not be displayed in the new list. No need for page refresh.

How?? after each drop action we are fetching new data, so the current task being dropped will be marked as assigned, and will not be displayed in the new list. No need for page refresh.

How?? after each drop action we are fetching new data, so the current task being dropped will be marked as assigned, and will not be displayed in the new list. No need for page refresh. @Pavangbhat

Sorry, @akshay1502 I think I have tested it new task workflow so it behaved like that, let me test it with the old task status.

How?? after each drop action we are fetching new data, so the current task being dropped will be marked as assigned, and will not be displayed in the new list. No need for page refresh. @Pavangbhat

Sorry, @akshay1502 I think I have tested it new task workflow so it behaved like that, let me test it with the old task status.


Revert test commit ( Update README.rst )

This reverts commit 7dce6d6d1f1293442c689ef198d868be24dfd010.
This commit seems to be a test. 🤔

gah, my bad!

Thanks! 😄


Ruby solutions for 45 problems, will slowly add all 150 Neetcode questions over time

Just adding this one to start to test out before addin' the others I've done

Never mind, I'll just add as many as possible.

19 so far, will add the other 26 completed in a bit if this is actually useful for anyone haha


Return list from tutorial query

While the data structure is a set, the tutorial code is designed to
simplify the use and understanding of the interfaces, not to be
correct from an API standpoint. Those who would use the library would
not presumably rely on a tutorial wrapper.

Um, retracting this for obvious reasons - not quite that simple :)


[Question] Is it possible to stop scrolling to top when hitting the bottom?

Hi @caseyjhol,
When using the up and down arrow key to navigate the items, it scrolls to the top when hitting the bottom and vice versa.
Is there any way to stop this behaviour or it's designed that way?

Not currently possible. Any reason specifically you don't want that? In the demo you posted your select has some custom styling which is why it's not scrolling all the way to the bottom.

@caseyjhol not really a issue but in my case, I wanted to use the arrow down key to navigate to the last item


Change System.Data.SqlClient to Microsoft.Data.SqlClient

I'm very new to C# but I was having issues using the System.Data.SqlClient listed in the docs page. Did some search and found that it was renamed: https://devblogs.microsoft.com/dotnet/introducing-the-new-microsoftdatasqlclient/
New package: https://www.nuget.org/packages/Microsoft.Data.SqlClient/
I think it might be useful to include a line like "dotnet add package Microsoft.Data.SqlClient --version 2.1.1" since as a beginner I don't understand how to install packages into a dotnet project.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 3e8486cc-40d4-7bca-84e0-e4156a28fe0d
Version Independent ID: d6e95100-d7fd-2951-366d-f4ed73ce5771
Content: Use .NET Core to connect and query a database - Azure SQL Database & SQL Managed Instance
Content Source: articles/azure-sql/database/connect-query-dotnet-core.md
Service: sql-database
Sub-service: development
GitHub Login: @stevestein
Microsoft Alias: sstein

@Ethan-Arrowood Thank you for the feedback. We are actively investigating and will get back to you soon.

@Ethan-Arrowood Sorry for the trouble you are facing. As per the article System.Data.SqlClient would work fine if we add the below entry on the proj file.
<ItemGroup>     <PackageReference Include="System.Data.SqlClient" Version="4.6.0" /> </ItemGroup>
I tried using the same code and was able to run the project successfully. Could you please share the error message to understand it more?

@Ethan-Arrowood Awaiting your response on this.

@Ethan-Arrowood Due to lack of response , we will now proceed to close this thread. If there are further questions regarding this matter, please comment and we will gladly continue the discussion.


Adding support for cleaning up staging data when Gobblin is cancelled via the Azkaban UI

Here is the first version. I still need to do some cleanup, add some comments, and write a test. Making this pull request to see what everyone thinks of the approach.
Azkaban only lets the cancel method run for 5 ms, before doing a hard kill on the process. This isn't enough time to cleanup staging data, but should be enough time to kill the Hadoop job (at least based on historical behavior). The OutputCommitter allows the user to hook into the lifecycle of the task and the jobs, so when killJob is called by the client, the AM will call OutputCommitter.abortJob() method. I have over--ridden this method, and added logic to clean up the staging data. Since the AM is in a different process than the client (running on Azkaban), the code de-serializes the WorkUnit files written to HDFS in order to obtain the writer output folder locations. Once it constructs the writer output paths, it deletes them.
@liyinan926 what do you think of this approach?

I think it's the right approach to rely on OutputCommitter to do the cleanup. There's an easier way to get the MR job working directory. Do the following in MRJobLauncher:
GobblinOutputFormat.setOutputPath(mrJobDir);

Then in the OutputCommitter, you can get the path using:
Path mrJobDir = new Path(GobblinOutputFormat.getOutputPath(context).toUri.getPath());

I also think we should put the writer staging and output directories to under the MR working directory by default, and only allow users to specify the data publisher output directory. This way we have full control to all the staging/temporary data in one place, and deleting the working directory deletes everything.

Apparently, NullOutputFormat doesn't have a .setOutputPath() method.
I agree with the comment on task-staging directories. Should we make the changes for moving the location of task-staging and task-output in a different pull request? It will probably require changes to AbstractJobLauncher and AvroHdfsDataWriter.

Addressed the comments above, updated the java docs, and wrote a test

Updated

Merged


Can't access element from array with named type

Repro is with Zed commit 332fb2c.
This works:
$ zq -version
Version: v1.5.0-34-g332fb2cd

$ echo '["foo","bar"]' | zq 'yield this[0]' -
"foo"

But this does not:
$ echo '["foo","bar"](=baz)' | zq 'yield this[0]' -
error("missing")

@mccanne's take upon seeing this:

Probably the type check isn't looking under the named type.

Verified in Zed commit 6889ec5.
Now we can access the element from the array with the named type successfully.
$ zq -version
Version: v1.5.0-36-g6889ec58

$ echo '["foo","bar"](=baz)' | zq 'yield this[0]' -
"foo"

Thanks @mccanne!


xplat implementation of WriteCodeFragment doesn't escape input

By code inspection, it appears that the inputs to WriteCodeFragment inputs aren't escaped in the xplat (non-CodeDOM) implementation.
See https://github.com/nguerrera/msbuild/blob/71bf8112fbb1ec2115631c9d2e8db3412004ff5e/src/XMakeTasks/WriteCodeFragment.cs#L360
I believe this will fail if _ParameterN has text that needs to be escaped. (e.g. imagine if there are embedded quotes in the value.)
I also don't understand the non-string side of that ?: expression because the CodeDOM equivalent casts uncoditionally to string and why do we expect non-strings to be quoted in their ToString() output?
Spotted while investigating #935

At this point I think we should remove the non-CodeCOM implementation; we should be able to use CodeDOM everywhere now, right?

Yes, do we already use the CodeDom implementation everywhere? Should this track removing the dead code or do we have something else tracking that?

Ah, fat-fingered the button. Yeah, we should track removing the ifdef here.

This turns out to not be trivial:
WriteCodeFragment.cs(142,41): error CS0234: The type or namespace name 'ConfigurationException' does not exist in the namespace 'System.Configuration' (are you missing an assembly reference?) [S:\msbuild\src\Tasks\Microsoft.Build.Tasks.csproj]
GenerateResource.cs(3471,35): error CS0103: The name 'StronglyTypedResourceBuilder' does not exist in the current context [S:\msbuild\src\Tasks\Microsoft.Build.Tasks.csproj]

For the latter, I think we might need to resurrect #3819.
I think we should do it. There's joy and security in deleting code. Penciling in for 16.4.

Triage note: a customer hit this in https://github.com/dotnet/core/issues/3205

Changing title back to customer visible impact. The fix will be to use CodeDOM everywhere and remove ifdefs, but that's not the bug.

Looks like #1369 fixed the escaping for the most part. Embedded quotes now work, but the remaining bug is when there are braces.

Fixed the title once more, and added repro steps.

@rainersigwald Am I following right that this should become easy once https://github.com/microsoft/msbuild/pull/4588 is in?

Yeah, I think so. I will have already seen a bunch of the same errors and know how to deal with them.

Nice! Thanks @nguerrera !  I didn't realize it was an escaping issue.


LookupImpl.lookupAnalysis is O(N) wrt classpath length

In projects with long classpaths, I've seen this show up in profiles, as called by memberRef => binaryDependency => externalDependency => getExternalApi.
https://github.com/sbt/zinc/blob/b125d8295cea2c0afc3c3686c1853edf93c4c934/zinc/src/main/scala/sbt/internal/inc/LookupImpl.scala#L43
Could we maintain an index of the package heirarchy to the JARs that contribute to the package?

Yes, I'll submit a PR with this solution.

c.c. https://github.com/sbt/zinc/pull/1279#issuecomment-2406060705 need to investigate which build tools are already passing in an optimized implementation of perClasspathEntryLookup


Connection timeout during proving-key downloading

Hello. When I first run the wallet it started downloading proving key, but after a few minutes, I saw a dialog with timeout error.
I try it three times and then downloaded this file with wget, it supports continuation of the download. I think that it is necessary to add the continuation of the download after the connection timeout.

Accepted as an enhancement to be implemented - resumption of proving key download.

This is technically more of an infrastructure challenge than a wallet problem and not directly related to zencash-swing-wallet-ui.
I would anticipate that now Sphere By Horizen is available, this functionality will likely not be built into Swing going forward.
I would suggest adding this a feature request in the Sphere By Horizen Repo
https://github.com/ZencashOfficial/Sphere_by_Horizen


Update network_create.md

- What I did
- How I did it
- How to verify it
- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)
minor typos and punctuation.

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "patch-4" git@github.com:cloojure/docker.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

LGTM, thanks!

LGTM 🐭


Update Stage column with correct capitalization

Fixes #27539

I've obviously lost the plot with this PR lol I'll open a new, clean one.


Add support for Prime mice

This adds support for the SteelSeries Prime mice (#166).
Supported features:

sensitivity
led color
led brightness
polling rate

What is not supported:

button mapping

By looking at the SSE3 database, it seems like the Prime and Prime+ support a new color handler. Instead, I was able to reuse the regular color handler by using the command and command_suffix fields to build a valid packet (but different from my captures). In short, the RGB color value is present twice in the data, at the start and at the end. Sending only at the start also works. But this means supporting the Prime+ will most likely require to correctly implement this new color handler.
There were a few changes to the core code, mainly:

added support for variable size in the range handler (new option range_length_byte)
added support for zero based indexing of the multidpi_range handler

added support for zero based indexing of the multidpi_range handler

Hum that's annoying, I have already an implementation for this in the aerox3-wireless branch... Maybe I can merge this part of the branch on master to allow you to use it in your PR?
Except this ↑ your PR looks great :)

added support for zero based indexing of the multidpi_range handler

Hum that's annoying, I have already an implementation for this in the aerox3-wireless branch... Maybe I can merge this part of the branch on master to allow you to use it in your PR?
Except this ↑ your PR looks great :)

I had a look at the first_preset option and it seems fine to me. If you want to put that part now in master, I'll rebase on top of it, no problem for me.

The updated multidpi_range is on master :)

OK I updated the code to use the new multidpi_range, everything seem a-ok on my side! Let me know if there are any other issues.

Thank you, the Prime support will be released in the next Rivalcfg version :)


nested form inside list

Hi,
Is there any way to nest a form inside of a list?
For example:
schema: {
people:  {
type: 'List',
'LISTFIELDS' => 'firstname, lastname, city, state'?
}
}
Is there any way to do something like the above?
Thanks a bunch!

Yes, you can use Object or NestedModel types with the List editor.  When you click to edit an item it will open the nested form in a modal dialog. When that is saved the row in the list editor will be updated.
Check the readme for the List, Object and NestedModel editors but here's a simple example:
schema: {
  list: { type: 'List', listType: 'NestedModel', model: NestedModel, sortable: false }
}


Added ChatWork service

Internal working branch based on: https://github.com/crashlytics/crashlytics-services/pull/88


Update helium-typescript to use async/await pattern

Type of PR

[ ] Documentation changes
[x] Code changes
[ ] Test changes
[ ] CI-CD changes
[ ] GitHub Template changes

Purpose of PR
Swap out promises for async/await
Review notes
Issues Closed or Referenced

Closes #78 (this will automatically close the issue when the PR closes)
References # (this references the issue but does not close with PR)

We have some things to work out with throwing but will tackle under a different issue


Bias conversion

The support for mixed-biases are not that well developed, beyond the IEEE-case. I think this is the way to convert general biases.
Two numbers with bias b1 and b2 and exponent bits e1 and e2, converted to e3 exponent bits.
b3 = ((b1 + 1)/(2**e1) + (b2 + 1)/(2**e2))*(2**(e3))/2 - 1

If e3 >= max(e1, e2)
b3 = ((b1 + 1) << (e3 - e1) + (b2 + 1) << (e3 - e2)) >> 1

This should lead to that numbers with IEEE-biases are kept the same and other combinations will get the "average" bias, which is most likely the best we can do. In this case it is rounded downwards, which I think is as good as the other option.

Seems like the second expression should be this?
((((b1 + 1) << (e3 - e1)) + ((b2 + 1) << (e3 - e2))) >> 1) - 1

I think your suggestion makes sense but it can lead to some unexpected results. Consider adding a large number with zero as
x = APyFloat(sign=0, exp=21, man=0, exp_bits=5, man_bits=2, bias=5)
y = APyFloat(sign=0, exp=0, man=0, exp_bits=5, man_bits=2, bias=25)
# APyFloat(sign=0, exp=31, man=0, exp_bits=5, man_bits=2)
x+y

The resulting bias will be $15$ so the exponent of $x$ will be increased by $10$ and thus become infinity.
I think in general one should side with the format representing numbers with greater magnitude, but I'm not sure how that would be formulated. Perhaps something like this:
b3 = min((b1 + 1) << (e3 - e1), (b2 + 1) << (e3 - e2)) - 1

Won't a similar thing happen for small numbers? Adding zero will turn the reault into zero?

Yes that's true.. I think both make sense but in different ways


Update README

https://github.com/galaxypi/galaxy
Great example project

Bootstrap - https://github.com/twbs/bootstrap

Made a very quick update to @faddat's README.md update.. https://github.com/galaxypi/galaxy/pull/9

Add new branding hero image to README

Working on this now..

configured git flow

Complete


1467905 - Added error handling for images with improper APB spec

ACK.

Are you sure? this doesn't compile for me:
$ git checkout -b dymurray-bz1467905 release-0.9
$ git pull git://github.com/dymurray/ansible-service-broker.git bz1467905
$ make clean
$ make build
go build -ldflags="-s -w" ./cmd/broker
# github.com/openshift/ansible-service-broker/pkg/apb
pkg/apb/rhcc_registry.go:70: syntax error: unexpected =, expecting comma or }
make: *** [Makefile:13: build] Error 2


Fix tutorials to accommodate new batching semantics

The following tutorials need fixing with recent distribution broadcasting changes. You are highly encouraged to add your tutorials to the smoke test (refer to #694 for an example on how to do this). If you do so, @fritzo and I can help maintain these with any changes to the API, as we did with the AIR, gmm, and gp tutorials.

[x] ss_vae_M2.py. cc - @karalets, @rohitsingh0812 - #725
[x] dmm.py - #721
[ ] dmm.py #711 - Throws NAN loss after one epoch. Once this is resolved, I'll make a change so that tutorials throwing warnings (like this one) will fail the test on travis.
[x] bayesian_regression.py - Possibly related - #717 @jpchen

#717 is an issue with traceelbo and is not related to the new batching semantics. i tested regression with the current dev and it is fine, so marking that as complete and will address the other issue separately


Bug 1907309: Add APF StorageVersionMigration manifest

This PR updates the StaticResourceController to use a new
StorageVersionMigration manifest to manage APF resource storage version
migration.
This PR is dependent on https://github.com/openshift/library-go/pull/1091.
Signed-off-by: Ivan Sim<EMAIL_ADDRESS>

This matches expectations, but I think you need a resourcread.

/retest

if this worked, release the hold on the library-go PR

Updated go.mod to vendor https://github.com/openshift/library-go/commit/abe9feaede8b357ced33bf3ba2606434f6235700.
Retested storage version migration with a 4.7 -> 4.8 cluster upgrade:
$ oc -n openshift-kube-apiserver-operator logs kube-apiserver-operator-64f8bb6d4d-6fkkn | grep "flowcontrol"
I0607 18:24:50.328181       1 event.go:282] Event(v1.ObjectReference{Kind:"Deployment", Namespace:"openshift-kube-apiserver-operator", Name:"kube-apiserver-operator", UID:"3531372e-c99a-4e55-b94f-94a6c6594cae", APIVersion:"apps/v1", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'StorageVersionMigrationCreated' Created StorageVersionMigration.migration.k8s.io/flowcontrol-flowschema-storage-version-migration because it was missing
I0607 18:24:50.335725       1 event.go:282] Event(v1.ObjectReference{Kind:"Deployment", Namespace:"openshift-kube-apiserver-operator", Name:"kube-apiserver-operator", UID:"3531372e-c99a-4e55-b94f-94a6c6594cae", APIVersion:"apps/v1", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'StorageVersionMigrationCreated' Created StorageVersionMigration.migration.k8s.io/flowcontrol-prioritylevel-storage-version-migration because it was missing

$ oc -n openshift-kube-storage-version-migrator logs migrator-68b46b456d-4tf4x | grep flowcontrol
I0607 18:24:50.966161       1 kubemigrator.go:110] flowcontrol-flowschema-storage-version-migration: migration running
I0607 18:24:51.146760       1 kubemigrator.go:127] flowcontrol-flowschema-storage-version-migration: migration succeeded
I0607 18:24:52.156875       1 kubemigrator.go:110] flowcontrol-prioritylevel-storage-version-migration: migration running
I0607 18:24:52.256543       1 kubemigrator.go:127] flowcontrol-prioritylevel-storage-version-migration: migration succeeded

/retest

/retest

/retest

/retest

/retest

/retest

/retest

/lgtm
/approve


Trigger runtime builds

Description
Changes proposed in this pull request:

Bump images in serverless component to use newest builds

Related issue(s)

/test all


Improve Developer Guide - how to contribute to tools and specs

[ ] Tools
[x] General architecture - what components are there to a full "Data Package" stack
[x] Pointers to specific languages e.g. Python, R, ...
[x] How to start on a platform integration (what type of platform: publishing, consuming etc)
[ ] Specs
[x] Where to find the main specs
[ ] Where to raise issues
[ ] Test suite

This issue was moved to frictionlessdata/frictionlessdata.io#45


This package depends on MoveIt Python Library

The moveit2 python library is not yet backported to humble but it acts as a dependency. Alternative is to install debian however, usual install of debian sets up /opt/ros/<version>/....
Backporting may take some work, instead scope a basic debian install the works with humble rather than having to build from scratch.

Alternative is to build the package at the highest level of the ros2 robotics research toolkit.


[backport] Support skipping tests decorated by condition or parametize

Backport of #1757

[automatic post] Jenkins, test this please.

Jenkins CI test (for commit a0e25c48b30e06539fe2698aaf96a8fc76ed3550, target branch v5) succeeded!


How to get Sources/Coverage Tab's datas of Chrome DevTools

Component
Version

Operating system
Windows 7 Ultimate

Node.js
LTS

Chrome/Chromium/...
Chrome 69

chrome-remote-interface
0.62 LTS

Is Chrome running in a container? NO
Hello, I'm trying to do used/unsued CSS/JS etc. application. How can I get datas of Coverage fully? Which Domain and Methods, should I use?
In this:

What do you mean by fully? Anyway, did you take a look at #170 and #285?

What do you mean by fully? Anyway, did you take a look at #170 and #285?

You nailed it! Thansk for help @cyrus-and :) Have a good day!


Class Meanbee\CSSPreload\Block\Head\string does not exist

Hi,
When running setup:di:compile against Magento 2.1.6 I'm getting the following:
[ReflectionException]
Class Meanbee\CSSPreload\Block\Head\string does not exist
Please Advise.
Thanks,
Dan

Unfortunately, this is because the extension is only compatible with PHP 7.0+. The problem is caused by us using a scalar type declaration in https://github.com/meanbee/magento2-csspreload/blob/master/src/Block/Head/Preload.php#L11

@tgerulaitis I'd like to get rid of the scalar type hint and unlock support for 5.6+. Thoughts? Regardless, we should but a platform req in the composer.json.

Thanks Guys! 5.6 support would be great as not all sites are yet on php 7 due to code compatibility issues under certain site setup configurations.

@punkstar Agreed. I'm happy with getting rid of it, assuming the rest of the code works on PHP 5.6 :) I've not tested it! But yeah, should have put a platform req.

In two months time it will be two years since 2.1 was released making 2.2 the latest supported version (source). The minimum supported version for 2.2 is 7.0.2.
It's for this reason that I'm going to close this ticket and the PR without merging.


Bump k8s.io deps to v0.26.0

What this PR does / why we need it:
Bumps k8s.io dependecies from v0.25.2 to v0.26.0

@lucacome can you rebase this?

@mattfarina done!


Add sender search functionality to explorer

Integrate the sender address being stored in the indexer with search functionality in the UI


CASMCMS-8398: Remove CRUS

Summary and Scope
This PR removes CRUS from the charts manifest, since CRUS is being removed in CSM 1.6.
Issues and Related PRs

Part of the CRUS removal epic.

Testing
None. Not feasible to test outside of doing an install.
Risks and Mitigations
Low risk -- on installs, it just means we won't install that chart, which is what we want.
For upgrades, there will be other tickets to handle making sure it gets removed when upgrading to 1.6.
Pull Request Checklist

[X] License file intact
[X] Target branch correct
[X] CHANGELOG.md updated
[X] Testing is appropriate and complete, if applicable
[X] HPC Product Announcement prepared, if applicable

Replacing this with a combo PR, to reduce likelihood of further merge conflicts.
https://github.com/Cray-HPE/csm/pull/1734


objects.has method, tests, docs

Ref: #133

pathArray = String(path).replace(/\[(\w+)\]/g, '.$1').split('.');
Creative solution to normalize the path input. Looks better than anything I would've come up with.


Overall TODOs

[ ] Matrices in CallRender3D
[x] Powerwall-Lua-Test
[x] Special instantiation templates to Lua projects
[ ] Parameter files must be deprecated: replace by lua "projects" (they can be loaded on top of each other anyway). core should serialize these scripts instead
[ ] Camera as a Module
[ ] NGPF 0.1 serial
[ ] VTK Data
[x] Showcase / In Situ
[ ] Core cleanup
[ ] New test case for core
[ ] Shader Factory based on snippets only
[ ] Reworked Sphere Shader (less goo, deferred, ray setup in vertex shader)
[ ] New HTML-based GUI
[ ] OpenGL state (observer?)

We should use projects/milestones for this kind of stuff. Close?


[CSDiag] Remove obsolete ArgumentMatcher from FailureDiagnosis

All of the argument diagnostics have been ported to the new diagnostic
framework, so now is the time to remove ArgumentMatcher and the only
place where it was used - diagnoseSingleCandidateFailures.

@swift-ci please smoke test


Publish v0.5.2

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (0e32e0d) 100.00% compared to head (ec526e1) 100.00%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff            @@
##              main       #40   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           21        21
  Lines          239       239
=========================================
  Hits           239       239

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


pa test infra: move functionality over to docker_cluster

Move methods that provide general docker functionality over to
docker_cluster.py.
Make the local and remote mount dirs instance variables. This prevents
mismatches when the docker cluster is started with one mount point and then
some other method specifies another mount point.

Task: SWARM-790

@cawallin & @rschlussel please review


Compile for esp32 S3 no error but constant reboot after start basic example

Context

Which example sketch are you using
basic
Which changes to the code did you make (if any)?
none
Which sensor are you using?
sx1276 connected to esp32 S3

Describe the bug
A clear and concise description of what the bug is.
wrong spi pins I suppose, s3 have other then esp32, perhabs Radiolib will handle that
To Reproduce
Steps to reproduce the behavior:

Step1 '...' load
Step2 '....' compile
Step3 '....' run
Reboot after start.

Expected behavior
A clear and concise description of what you expected to happen.
to run as with sx1276 with esp32 wroom, there no problems
Debug Log
If applicable, add log file to help explain your problem.

Build log file (enable verbose output in the Arduino IDE: File->Preferences - "Show verbose output during: compile")
Serial console log file (see Debug Output Configuration in Arduino IDE)

Embedded Device (please complete the following information):

Arduino IDE Version: [e.g. 1.8.19]
ESP32/ESP8266 Board Support Package Version: [e.g. ESP32 2.0.7]
Library Version [e.g. 0.6.1]
Your Board: [brand/model/version] (if unsure, attach a photo)
Selected Board in the Arduino IDE: [brand/model/version]
Your Radio Transceiver Module (if external): [brand/model/chipset/frequency]
Pinning/Wiring

Additional context
'#pragma message: Pin config: RST->32, CS->27, GD0/G0/IRQ->21, GDO2/G1/GPIO->33'
550 | #pragma message("Pin config: RST->" STR(PIN_RECEIVER_RST) ", CS->" STR(PIN_RECEIVER_CS) ", GD0/G0/IRQ->" STR(PIN_RECEIVER_IRQ) ", GDO2/G1/GPIO->" STR(PIN_RECEIVER_GPIO) )
ESP S3 has not these pin, so CS-> 27, nor pin 32 or 33 is possible

See https://github.com/jgromes/RadioLib/discussions/1051, add to this library

Put this before #elif defined(ESP32), the pins are chosen, still constant reboot ESP32 S3, any Help?
#elif defined(CONFIG_IDF_TARGET_ESP32S3)
// Generic pinning for ESP32 S3 development boards
#pragma message("Pin config: ESP32 S3")
#define PIN_RECEIVER_CS   10
// CC1101: GDO0 / RFM95W/SX127x: G0
#define PIN_RECEIVER_IRQ  21

// CC1101: GDO2 / RFM95W/SX127x: G1
#define PIN_RECEIVER_GPIO 8

// RFM95W/SX127x - GPIOxx / CC1101 - RADIOLIB_NC
#define PIN_RECEIVER_RST  9

The good news is that my hardware and testings are accepted in using the Radiolib library. Tested with the examples RadioLib SX127x Settings Example and RadioLib SX127x Blocking Receive Example (SX1278 radio = new Module(10, 21, 9, 8);) So Matthias what part in your library must be adapted besides the cfg file, see above?

But #define PIN_RECEIVER_CS   10
// CC1101: GDO0 / RFM95W/SX127x: G0
#define PIN_RECEIVER_IRQ  21

// CC1101: GDO2 / RFM95W/SX127x: G1
#define PIN_RECEIVER_GPIO 8

// RFM95W/SX127x - GPIOxx / CC1101 - RADIOLIB_NC
#define PIN_RECEIVER_RST  9

SX1278 radio = new Module(PIN_RECEIVER_CS, PIN_RECEIVER_IRQ, PIN_RECEIVER_RST, PIN_RECEIVER_GPIO);
// or using RadioShield
// https://github.com/jgromes/RadioShield
//SX1278 radio = RadioShield.ModuleA;
void setup() {
Serial.begin(9600);
// initialize SX1278 with default settings
Serial.print(F("[SX1278] Initializing ... "));
//int state = radio.beginFSK();
int state = radio.beginFSK(868.3, 8.21, 57.136417, 250, 10, 32);
if (state == RADIOLIB_ERR_NONE) {
Serial.println(F("success!"));
} else {
Serial.print(F("failed, code "));
Serial.println(state);
while (true);
fails with [SX1278] Initializing ... failed, code -12
replace with only
int state = radio.beginFSK();
�)[SX1278] Initializing ... success!
[SX1278] Waiting for incoming transmission ... timeout!
[SX1278] Waiting for incoming transmission ... timeout!

Hi @tonbor,
I have a few questions:

Which board did you select in the Arduino IDE?
Which radio module are you using?

PIN_RECEIVER_CS is used as GPIO pin, so you can select any available GPIO pin, i.e. you are not restricted to a dedicated CS pin (according to the pinout drawing).

Here is a draft config assuming you are selecting "ESP32S3 Dev Module" in the Arduino IDE:
https://github.com/matthias-bs/BresserWeatherSensorReceiver/tree/feat-esp32-s3-devkitc-1
Please let me know which radio module you are using (see above).

The problem with ESP32 S3 or even Espressif ESP32-S3-DevkitC-1 is that this is just one of a hundred quite generic boards. There is nothing specific such as an integrated radio module or an interface for easy integration of a radio module (such as Adafruit Feather or FireBeetle Cover) or an outstanding power management which would make it preferable over any other board.
If anyone chooses such a board, I would expect him to integrate it by himself. Otherwise I would be permanently busy integration some board or other.

Hi @tonbor,
I have a few questions:

Which board did you select in the Arduino IDE? ESP32S3 Dev Module
Which radio module are you using? Hoperf RFM95W

PIN_RECEIVER_CS is used as GPIO pin, so you can select any available GPIO pin, i.e. you are not restricted to a dedicated CS pin (according to the pinout drawing).

https://github.com/matthias-bs/BresserWeatherSensorReceiver/tree/feat-esp32-s3-devkitc-1

great it compiles, no reboot, and I get readings...
Id: [    ABB9] Typ: [1] Ch: [0] St: [0] Bat: [OK ] RSSI: [ -83.5dBm] Temp: [ 18.1C] Hum: [ 94%] Wmax: [ 0.0m/s] Wavg: [ 0.0m/s] Wdir: [312.0deg] Rain: [  692.9mm] UVidx: [0.0] Light: [0.0klx]
Id: [72181262] Typ: [2] Ch: [4] St: [0] Bat: [OK ] RSSI: [ -99.5dBm] Temp: [ 24.2C] Hum: [ 67%] Wmax: [44.4m/s] Wavg: [44.4m/s] Wdir: [1221.0deg] Rain: [-----.-mm] UVidx: [44.4] Light: [--.-klx]
Id: [    ABB9] Typ: [1] Ch: [0] St: [0] Bat: [OK ] RSSI: [ -96.5dBm] Temp: [ 18.1C] Hum: [ 94%] Wmax: [ 0.0m/s] Wavg: [ 0.0m/s] Wdir: [354.0deg] Rain: [  692.9mm] UVidx: [0.0] Light: [0.0klx]

Which radio module board (brand, model or link) are you using? HopeRF RFM95W is just the radio chip

https://www.tinytronics.nl/nl/communicatie-en-signalen/draadloos/lora/modules/hoperf-rfm95w-lora-module-868mhz

See https://github.com/matthias-bs/BresserWeatherSensorReceiver/compare/main...feat-esp32-s3-devkitc-1 for comparison (lines 91ff are not related).
I just selected the ESP32 board in the Arduino IDE, compiled with verbose output and copied the define set for this board into the preprocessor command. You already set the correct pin numbers.

https://www.tinytronics.nl/nl/communicatie-en-signalen/draadloos/lora/modules/hoperf-rfm95w-lora-module-868mhz

Thanks for the link. This is again a generic module, meaning you may or may not be able to buy or use this part without any changes if you try again half a year later. Therefore I hesitate to add this variant to the source code.

Well they are all over Aliexpress https://nl.aliexpress.com/item/1005006440269881.html?spm=a2g0o.productlist.main.13.5d081ca11n0bRV&algo_pvid=9366666f-1dbe-4ac2-ac11-c984bcb5ca0a&algo_exp_id=9366666f-1dbe-4ac2-ac11-c984bcb5ca0a-6&pdp_npi=4%40dis!EUR!36.17!10.49!!!278.23!80.69!%40211b61a417253889860347119ea330!12000037173992052!sea!NL!102390509!X&curPageLogUid=9mPHzbACEnaK&utparam-url=scene%3Asearch|query_from%3A

Well you find them at Aliexpress, and

Well for Lora use perhabs not ideal, but for scanning Bresser nodes at home ok, and I got a antenne soldered tot ant and GND

It depends on the range to your sensors. If works for you - fine by me. I'd rather not use it as an example for reasons mentioned above.

But adding the use of ESP32 S3 would be desireable because of using this with a cc1101, sx1276 or sx1268. Still I do not understand why I got a rebooting S3 with my changes.

Adafruit sells a shielded one https://www.adafruit.com/product/3072

Adafruit sells a shielded one https://www.adafruit.com/product/3072

This is one of the boards I'd recommend, but it's not cheap. There others at https://www.tinytronics.nl which are similar and made/sold by some established brands which also provide more or less helpful documentation.

But adding the use of ESP32 S3 would be desireable because of using this with a cc1101, sx1276 or sx1268. Still I do not understand why I got a rebooting S3 with my changes.

Okay, I will add it as a generic ESP32 S3 target.

But adding the use of ESP32 S3 would be desireable because of using this with a cc1101, sx1276 or sx1268. Still I do not understand why I got a rebooting S3 with my changes.

Okay, I will add it as a generic ESP32 S3 target.

Thanks

Implemented in https://github.com/matthias-bs/BresserWeatherSensorReceiver/pull/192

Perhabs

Define
Radio Module
Configuration

ESP32
user-defined
generic, used for ESP32 boards if none of the above is defined

ESP32 S3
user-defined
generic, used for ESP32 S3 boards if none of the above is defined

ESP8266
user-defined
generic, used for ESP8266 boards if none of the above is defined


0.8 regression: namespace error : Namespace prefix xsi for schemaLocation on MPD is not defined

0.8 introduced a regression with our DASH example in GStreamer.
$ xmllint -format dash_stream/manifest.mpd
dash_stream/manifest.mpd:2: namespace error : Namespace prefix xsi for schemaLocation on MPD is not defined
:mpeg:dash:profile:isoff-on-demand:2011" mediaPresentationDuration="PT1M23.333S"

With 0.7 the XML was
<MPD xmlns="urn:mpeg:dash:schema:mpd:2011" type="dynamic" schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" profiles="urn:mpeg:dash:profile:isoff-live:2011" availabilityStartTime="2023-04-26T13:35:15.546317603Z">

which changed to this with 0.8:
<MPD xmlns="urn:mpeg:dash:schema:mpd:2011" type="dynamic" xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd" profiles="urn:mpeg:dash:profile:isoff-live:2011" availabilityStartTime="2023-04-26T13:34:24.374770165Z">

The XML parser does not seem happy with prefixing schemaLocation with xsi:.

Probably related: https://github.com/emarsden/dash-mpd-rs/commit/5a568d3dfed923dfa77c493b7ce178b71b672bc2

I didn't realize the crate was used in a GStreamer example; that's cool!
Thanks for pointing this out. Indeed, if a namespace prefix is used in the XML manifest, it should be declared first. I've pushed a change which serializes default values for the namespaces that we potentially use; are you able to test HEAD?
(This change is not fully desirable because it serializes these namespace declarations whether we use them or not. I don't see how to avoid this with the existing serde-based serialization machinery, however.)

I didn't realize the crate was used in a GStreamer example; that's cool!

I started using it last week. ;)

are you able to test HEAD?

Yes, that solves it, thanks!
Any chance you could push a release with the fix?

OK, v0.8.1 is released.


add a multiple-prompt for interactive password input

this helps protect against a class of typos, bad entries, etc. that is otherwise time-consuming to detect
NOTE: Cannot be tested effectively until the PR in #7 is landed, which catches errors in this lambda

Loong overdue, but finally addressed feedback 😅


Cleanup of instruction set detection and defines.

Clean up SSE42 vs SSE42_CRC_ASM defines
Simplify native arch handling in CMake
Improve native arch handling in Configure
Move cmake macro to only place it is used.

I recommend reviewing these commits separately.

I also noticed that configure --native builds on arm are broken, since for some reason it sets ARCH=native early on, and that effectively makes configure never activate any of the arch-specific optimizations, making the build only use basic C functions.
I attempted to make a go at fixing this, but it is relatively involved and better suited for a separate PR after this one has been merged. Also it would better if someone who knows the ARM parts of the build/code better, as it might take me a few tries to fix it properly without screwing something up.

Redid some of the first commit, since I now have a better idea of what all the code does and this fixes some of the remaining corner cases.

I think I'll re-do this PR to make it more organized and incorporate feedback.


Wrong error message in shared folders

Your Windows build number:  (Type ver at a Windows Command Prompt)

Microsoft Windows [version 10.0.16199.1000]

What you're doing and what's happening:

gpotter@COMPUTER:~$ cd /mnt/shared_drive
gpotter@COMPUTER:/mnt/shared_drive/$ echo "hey" > test.txt
-bash: tst.txt: No such file or directory
gpotter@COMPUTER:/mnt/shared_drive/$ cat > tst.txt
-bash: tst.txt: No such file or directory

I don't have the permissions to write in those folders, but the error message should be the proper one.

This was fixed


Implement "artifact dependencies" (RFC-3028)

Tracking issue: #9096
Tasks

[x] -Z unstable option called bindeps
✅ (config) allow parsing of newly introduced 'artifact' fields

[x] into TomlManifest
[x] into Manifest

[x] abort warn if artifacts are used on stable

✅ resolver : assure artifact dependencies are part of the resolution process and unified into the dependency tree
🔬compiler: make it understand 'artifact' dependencies and pass new environment variables to the crate being build

[x] lib=false should not be considered a rust library for the dependent, in unit and possibly resolve graph
[x] assure profile settings are applied correctly
[x] target overrides work

[x] target = "target" in build deps
[x] other targets on build deps
[x] other targets on non-build deps
[x] 'no-cross doc tests' seems like a constraint we should apply as well maybe

[x] more confidence with resolver = "2"
[x] assure artifact placement is correct (bin and various forms of lib)

✅ serialization: rewriting manifests (i.e. for publishing) does not discard artifact information

[x] publishing keeps artifact and lib values

Other cargo subcommands

[x] cargo metadata

[x] draft of packages.dependencies.artifact
resolve.nodes.deps.dep_kinds

[x] add extern_name field
add artifact information which have

[x] compile_target field
[x] bin_name field
[x] add lib=true representation to dep_kinds
[x] bin-only artifacts are not ignored

[x] artifacts work with cargo check
[x] artifacts work with rustdoc, such that it doesn't document them unless lib=true
[x] cargo tree maybe?
[x] cargo clean should clean artifacts - even though it's more complex, ultimately it deletes the target directory.
[x] artifacts work with cargo test (and dev-dependencies)

[x] doctests
[x] try reproducible repository as well.

🧪 tests for more subtle RFC constraints

[x] build scripts cannot access artifact environment variables at compile time, only at runtime)
[x] assure 'examples' which also support crate-type fields like [[lib]] won't become artifacts themselves.
[x] assure --out-dir does not leak artifacts - tested manually, it seemed to niche to add a test.
[x] try target="foo" in artifact and assure it sees a decent error message
[x] Assure RFC 3176 doesn't work

🧹cleanup and finalization

[x] assure no TODO(ST) markers are left in code
[x] assure no tests are ignored
[x] use resolver = "1" once to assert everything also works with the previous resolver, but leave it on "2".

Implementation and review notes

artifacts and unstable options are only checked when transforming them from TomlManifest to Manifest, discarding artifact information if the unstable flag is not set. Nowhere else in code will the CLI options be checked again.
If no binaries are specified, all the binaries in the package will be built and made available. - this should only refer to [[bin]] targets, not examples for instance.
artifact binaries won't be uplifted, hence won't be present outside of their output directory
❗We don't know how package links will affect artifacts for build dependencies. Should probably be thought through.
❗The location of artifacts is only tested roughly to avoid having to deal with different output names on the four platforms that seem to matter (gnu, macos, windows msvc, windows gnu).
cargo tree doesn't handle artifacts specifically, and it might be interesting to make clear if an artifact is only an artifact, or both artifact and dependency.
Most error and warning messages can probably be more cargo-matic.

Questions

Does cargo without the feature enabled have to complain about the "artifact" field in a dependency, like it does right now?  It doesn't look like machinery for that exists in do_read_manifest().

✔It warns now

Should parsing of artifact values, like "bin" be case sensitive?

✔ It's case sensitive now, which should help with serde roundtripping.

Review Progress

[x] address Josh's review notes one by one

[x] introduce IsArtifact (see this answer) (76cd48a2d62d74e043a1a482199c5bb920f50311)
[x] prefer uplifting artifact deps that were written into the deps directory, but prefer to do that in this PR instead
[x] add extra-tests as described in Josh's comment: " features get unified between a Rust library and a binary, and one that confirms features don't get unified between a Rust library and a binary for a different target?"
[x] Make target-based artifact splitting work by porting parts of RFC-3176

[x] test-support/cross-compile
[x] namespace separation

[x] re-create RFC-3176 what's not in RFC-3028, namely multidep support and all related tests
[x] Address Eh2406 's review comments
[ ] assure current set of tests works consistently, also on windows

Sponsored by Profian

Finally, a breakthrough, and the key for that was something I didn't use in what feels like a decade: a debugger. Looking at the complex cargo code while imagining what might be in there at runtime based on some manifests can only get you so and so far, and was seriously reducing my progress.
Everything cleared up quickly after the first few debugging sessions, and seeing actual data being handled by the code is just changed the game.
Hence, build scripts are now able to receive artifact dependencies at runtime, which are also placed in the correct directories. Thus far I appear to have been minimally invasive, too, which might indicate the changes where made in a not too far off place.
Next steps are making artifact environment variables available at build time and writing many more tests to validate more subtle behaviors, and I don't think there is going to be more roadblocks on the way.

@Byron Congratulations! Does this work for cross-target compiles too? Or is this just homogeneous targets so far?

🎉It's just homogenous thus far, and there aren't even tests yet to see how different target types interact. However, from what I see the target can freely be specified so I expect no resistance there.

r? @joshtriplett

@joshtriplett I am now at a point where artifact deps are created both for build script runs as well as for libraries. However, the limitation of what looks like a race condition is reproducible on my machine at all times, meaning that the binary artifact isn't actually present (yet) when the build is executed, causing include_bytes!(env!(<ARTIFACT>)) to fail even though the file is present right after (and will become available a little later as build scripts are able to wait for it).
Oddly enough, the last time I checked everything seemed to have run exactly as expected, and I concluded it's impossible for Cargo to start a job if its dependencies aren't yet ready. Maybe, just maybe, it's related to rmeta though which is able to kick-off the dependents before the final artifact is produced, but a quick look didn't yield any evidence for that.
Maybe it's possible that edges are removed too eagerly which allows starting jobs too early. Will look into this a little more as it appears to be a lead.

It looks better by the day and now build-scripts at runtime as well as libs at build time have access to artifacts as described in the RFC. Besides plenty of missing tests for edge-cases the big topics to look at next is to get targets and profile settings right. I don't expect issues there and hope it will be as straightforward as I can predict based on my current knowledge of the inner workings.

https://github.com/Hezuikn/reproduceable

@Hezuikn I think the best way to post questions/issues during development is by providing a cargo test, using its excellent test framework, to reproduce the issue. From what I can tell in the linked repository is that the environment variable used in build.rs isn't anything that would be set by artifact dependencies.

the build.rs forwards the artifact env var to the cargo test of the root crate; everything works as expected but only when any of the two lines in ./Cargo.toml are uncommented but they shouldnt be needed

i also forgot to say that it gives me ICE: [hezuikn@harch reproduceable]$ cargo test
thread 'main' panicked at 'activated_features for invalid package: features did not find PackageId { name: "test", version: "0.1.0", source: "/home/hezuikn/reproduceable/test" } false', src/cargo/core/resolver/features.rs:296:14
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

Now I see! I will be sure to add cargo test tests and see if both issues can be made reproducible in the test suite.

@Hezuikn Maybe you could try the test again with the latest version of this - I now have a test that runs cargo test and fixed a shortcoming that should affect it. Please note that doctest doesn't work yet.

cargo check, cargo build, cargo test all still ice with the same err; ive further minimized reproducible

@Hezuikn I have added the setup from reproducible to the test suite and fixed the issue with resolver = "2". resolver = "1" works because it handles build features differently, and adding another dependency to the same package that isn't a build dependency will put just the right entry into the map that is queried there, preventing it to bail out.
Also, is it common to call a cargo error ICE, which seems to be an internal compiler error? I am asking because I would think these would be panics if a precondition isn't satisfied, and in this case I am not sure if recovery is possible. Hence my fix is to 'give it the flag that it wants' because it seems the right thing to do judging from the flags documentation, yet I am not quite sure if the code should bail in the first place or have that desired entry in the map. 6584917 shows the fix in case you have deeper insight into this.

no thats just me; reproduceable has new breakage!

Nice one! It's reproducible and was fixed in the moment I passed the correct -L flag which currently points to the brand new artifact output directory. It should be possible to instead point it to deps directory. Will tackle this tomorrow, probably to start the next round ;). Your work is much appreciated, @Hezuikn , as I didn't yet get out of the sandbox with the implementation, and would probably miss a ton of cases if it wasn't for you.

@Hezuikn Reproducible isn't broken anymore. Maybe you would like to change that ;)?
As I will now add 'target' handling there should soon be even more surface to break and despite my best attempt I might not get it right the first time.

I added a note about supporting cargo metadata. We talked in today's Cargo meeting what it should look like; there should be one entry in "dep_kinds" for each dependency type (either an artifact dep, or a normal library dep).
                    "dep_kinds": [
                    {
                        "artifact": "cdylib",    // ADD THIS
                        "extern_name": "my_library", // ADD THIS
                        "kind": null, // dev, build, or null
                        "compile_target": "x86_64-unknown-none", // ADD THIS
                        "target": null,
                    },
                    {
                        "artifact": "bin",    // ADD THIS
                        "bin-name": "my-binary",        // ADD THIS
                        "extern_name": "my_binary", // ADD THIS
                        "compile_target": "aarch64-unknown-linux-musl", // ADD THIS
                        "kind": "build", // dev, build, or null
                        "target": null,
                    },
                    {
                        // normal Rust library - no "artifact" field
                        "extern_name": "my_rustdep", // ADD THIS
                        "kind": "dev", // dev, build, or null
                        "target": "cfg(windows)",
                    }]

While I continue with the resolve part of the data structure I discovered that artifacts currently are not reflected in the packages.dependencies tree. This example shows that artifact information is missing entirely. While this is not surprising I wonder if you had an idea for how to represent them there.
Here is a few assumptions I am making about the resolve part and I hope this can be clarified where needed:

"compile_target": "target" will not appear in the metadata, instead it will be the resolved target triple.
each effective build target becomes its own entry in dep_kinds, e.g. artifact = "bin" with two binaries being built will have two entries.
somewhat similar to the above, if lib=true, there will be a dep_kind that looks like a normal dependency, even though it originated from an artifact dependency. It won't be distinguishable to a normal dependency that was added. This might be a problem so instead it could be more like an artifact dependency with the type being "rlib".

@joshtriplett There is a test for "resolve" data which could serve as an example for the current metadata implementation and I am curious to learn how close it is to the desired state.
Please note that a few assumptions and limitations currently apply as indicated in my edited comment right above this one.

:umbrella: The latest upstream changes (presumably #10081) made this pull request unmergeable. Please resolve the merge conflicts.

I'll review in parallel (this isn't a blocker for review, only merging), but it looks like there's a test failure on Windows that looks related to artifact dependencies.

Thanks for taking a look.
The linker error is probably about it being unable to open the output executable for writing, sometimes. This test failure is only occasionally happening on win-msvc exclusively, which indicates a race of sorts.
I have found something similar which is deactivated on msvc (and apple even), which seems to indicate that the filename clash warnings are to be taken seriously and that this particular issue could be worked around using -j 1 to prevent concurrent creation of the same artifact.
Looking at the manifest, concurrent creation of the same artifact is exactly what's happening here:
                [package]
                name = "foo"
                version = "0.0.1"
                authors = []

                [build-dependencies]
                bar = { path = "bar", artifact = "bin" }

                [dependencies]
                bar = { path = "bar", artifact = "bin" }

                [profile.dev.build-override]
                opt-level = 1

                [profile.dev]
                opt-level = 3

Both artifacts are similar and leaf nodes which will run right away. Because it's not built yet, the freshness check for both indicates they need to be built. Cargo's collision check successfully detects this, too.
Since cargo is unable to deal with this inherently, I don't think the artifact code should try to do anything special here either. Instead it should be enough to rename one of these packages to prevent the issue. This unfortunately doesn't work yet without RFC-3176, so I have deactivated the test for now with the intention to reactivate it in RFC-3176 with one dependency renamed.

So, I tested this with our (profian) requirements for the enarx project.
As minimal test setup, I created https://github.com/haraldh/multitarget and it works, if I use a rust compiler with the x86_64-unknown-none target compiled in.
Without manually compiling rust with the x86_64-unknown-none target, I can't propagate -Z build-std-features=compiler-builtins-mem -Z build-std=core,compiler_builtins to the multitarget/shim crate.
Specifying -Z build-std requires setting a --target, which of course does not work here as expected.
I tried per-package-target, but this does not work also.

That's good news, overall, despite apparently not being quite there yet.
Without claiming to understand in full how this should work, after looking at the build-std related configuration I do remember having seen a special code-path in Cargo for building the standard library.
Right now I have no idea how that is supposed to interact with artifacts and would hope for clarification if this is a lead.

Without manually compiling rust with the x86_64-unknown-none target, I can't propagate -Z build-std-features=compiler-builtins-mem -Z build-std=core,compiler_builtins to the multitarget/shim crate.

I don't recall having seen anything about propagation of -Z flags, or have not touched them while handling this RFC or the RFC 3176.
This leaves me at requiring pointers on how this build-std interaction is supposed to work in cargo.

This leaves me at requiring pointers on how this build-std interaction is supposed to work in cargo.

I'm not sure there is a good answer here since build-std isn't really on the fast track to stabilization. Our best strategy is probably to get x86_64-unknown-none into tier 2.

:umbrella: The latest upstream changes (presumably #10172) made this pull request unmergeable. Please resolve the merge conflicts.

:umbrella: The latest upstream changes (presumably #10201) made this pull request unmergeable. Please resolve the merge conflicts.

I think this is ready for others to look at. I did a detailed code review, and already posted comments for the handful of things I would like to see changed. (And, of course, the couple of test failures need fixing.)
I think it'd be appropriate to go ahead and gauge consensus, in parallel with the last few details getting fixed; I think the overall structure of this looks correct.
@rfcbot merge

I think this is ready for others to look at. I did a detailed code review, and already posted comments for the handful of things I would like to see changed. (And, of course, the couple of test failures need fixing.)
I think it'd be appropriate to go ahead and gauge consensus, in parallel with the last few details getting fixed; I think the overall structure of this looks correct.
@rfcbot merge

@rfcbot concern address-review-comments

This is significant enough that I'll probably defer to reviewing this in the new year myself, but I'll get around to this!

Thanks a lot for the review, @joshtriplett.
I have addressed the tiny changes and posted a couple of question on the bigger ones for direction.
There is also a new Review Progress section with tasks I plan to resolve in order to complete the first review.

@Byron I've responded to all your questions on the review comments.
I hope that test failure is unrelated, yeah. You might check that it exists without your patches, as well; if it does then see if it exists on current HEAD, and if it doesn't then try bisecting to see where your PR introduces it.

Apart from those, could you please add a test that confirms features get unified between a Rust library and a binary, and one that confirms features don't get unified between a Rust library and a binary for a different target? (You don't have to run the binary; just arrange for the depended-on binary and Rust library to check their feature flags and fail to compile if they don't get exactly what they expect.)

@joshtriplett This is a great catch, because for whichever reason I think I entirely ignored the second part which means that a binary with a different target lives in its own namespace for features. Most of the changes from RFC-3176, where this is addressed and tested, be ported over to this branch which is definitely helpful in slimming it down. This will probably result in a 'remake' of RFC-3176 which should then add only capabilities to have multiple targets to the same version of an artifact dependency.
In other words, bringing this functionality here will allow me to bring most of the changes here, fix RFC-3176 and reduce it to what it should have been in the first place.

@joshtriplett Two tests were added (and the respective capability ported from RFC-3176) to show how build targets now act as namespace for features, similarly to how it already works for build dependencies. 07619f2 is probably a good entry point for the tests themselves, whereas the commit prior at 5f5ac57 is all changes to add target-support for feature resolution.
I am looking forward to hearing what you think.

Looks reasonable to me! PackageFeaturesKey looks like a nice cleanup.
@rfcbot resolved address-review-comments

@rust-lang/cargo I think this is now ready for review.

I am happy to announce that the work related to @joshtriplett review is now completed, and caused the toppling patch queue of #10061 to be rebuilt to fit cleanly onto this PR.
That way maintaining both related PRs until this one is done with all review rounds should be much simpler, as I would expect far less conflicts when rebasing.
Overall, a nice start into 2022 and I am looking forward to learn how to make this PR better with the help of the other reviewers.

There was a lot here to look over, I was only able to give it the briefest of reviews.

Thanks a lot, @Eh2406 , for taking the time. Both issues were addressed and particularly the changes to the storage of environment variables (HashSet -> HashMap) make a huge difference for maintainability.

:umbrella: The latest upstream changes (presumably #10269) made this pull request unmergeable. Please resolve the merge conflicts.

While rebasing against master to resolve a conflict I took the liberty to squash the commits into a more manageable number. Tomorrow I plan to do another pass to assure all tests work (or are ignored) in each commit which should facilitate commit-by-commit reviews.
Thanks to @joshtriplett for the hint.

I tracked down a couple of commits which with failing tests and squashed them, bringing the total commit count down to 52. Please note that all commits addressing review comments have also been squashed into one.

Sorry for the noise, but the previous stashing operation managed to hide a critical feature that was added, namely the ability to unify features by target as well. This happened because I somewhat blindly squashed all commits that didn't pass the tests, and this one was among them.
With the new squash-resolution there is only 5 commits more, while retaining more useful information I believe.
Thanks again, @joshtriplett, for the feedback.

Thanks for putting in the large amounts of work for this!
This is just a partial review. I'll keep reviewing over the next few days.
Unstable features need to be documented in unstable.md.

Thanks for putting in the undoubtedly huge effort to review this as well!
I plan to address the comments in multiple sessions, each probably resulting in at least one commit. Once resolved, these can probably be squashed once again as basis for the next review round.

:umbrella: The latest upstream changes (presumably #10324) made this pull request unmergeable. Please resolve the merge conflicts.

I'm a bit nervous making any changes to the index format.  Instead, would it be possible to fetch the needed information from the PackageSet in a fashion similar to how is_proc_macro works?  If it requires an index update, that means this feature can't be tested on crates.io.

BTW, I'm not sure if you saw the other review comments, there's about 8 of them that weren't addressed.  In the GitHub UI, you have to click the "Load More" to see all comments (I don't know why they do that).

For RustcTargetData, would it be possible to make target_config and target_info be populated in a lazy fashion?  It seems like it will be challenging to get all the information up-front.

BTW, I'm not sure if you saw the other review comments, there's about 8 of them that weren't addressed. In the GitHub UI, you have to click the "Load More" to see all comments (I don't know why they do that).

Thanks so much for the hint, indeed these managed to hide from my view. The small change requests have now been addressed, and I plan to address everything else in the course of the day.

Thanks, @ehuss, for the notes and having taken another look. Now all left open should be handling the target field correctly in a variety of situations. Maybe this is related to the forced-target as well.
All the details about this can be found in a comment higher up, which I write here just to not forget about it myself.

I'm a bit nervous making any changes to the index format. Instead, would it be possible to fetch the needed information from the PackageSet in a fashion similar to how is_proc_macro works?

I share that sentiment and would be happy to get it to work without. The index change was only required to pick up target information from crates outside of the workspace, but I will try hard to make it work with PackageSet.

If it requires an index update, that means this feature can't be tested on crates.io.

Do I understand correctly that the modified code does indeed run on crates.io, so if changes are made to the data structure these won't make it into published crates until they are stable as the code isn't rolled out there yet?

For RustcTargetData, would it be possible to make target_config and target_info be populated in a lazy fashion? It seems like it will be challenging to get all the information up-front.

I'd hope that this is kind of what I am doing already here and would hope that once there is a version of this that depends on PackageSet this problem is solved. Maybe I am missing something though.

I think there are good news, @ehuss. First of all, I removed the modification to the registry data structure, and now perceive registry data as the data required to resolve the dependency graph. Since artifact dependencies and forced-targets don't influence dependency resolution, they shouldn't be included.
This also means that data from the PackageSet (after downloading the packages that matter) has to be transferred to the resolve graph after it was created from registry information so that the unit-graph can be created with artifact information (and forced-target information) available.
5a0fe0d942eaca3f62b92774de1b0b4779b69dde implements this, while 5a0fe0d942eaca3f62b92774de1b0b4779b69dde probably helps with picking up forced-targets. This one I just added for completeness sake without having a test that would validate it. Since it's somewhat out of scope, the commit could certainly be removed, but it might serve as an example on how to deal with cases like this as the mechanism is indeed new.
The failed tests seem unrelated and are a bit surprising, will investigate.

EDIT: The failed tests are due to a new clap-version which probably fixed the way it outputs multi-value flags. I'd wait for a fix in master and then rebase. After running cargo update it is reproducible locally.

You should be able to rebase now to fix the tests.

Do I understand correctly that the modified code does indeed run on crates.io, so if changes are made to the data structure these won't make it into published crates until they are stable as the code isn't rolled out there yet?

Cargo doesn't share any code with crates.io.  The way things flow into the crates.io index is:

User runs cargo publish.  Cargo creates a .crate file, and uploads it with some JSON information (documented here and implemented here).
crates.io updates the git repository based on the JSON data (that code lives around here).  crates.io also stores a bunch of stuff in its Postgres database for the website.

If the index format is changed, the change to write to the index needs to happen in the crates.io code.  The cargo code only handles reading the index.  Since modifying the index is a permanent decision, we don't have an easy way to experiment with it.  We need to be very careful about that decision, and it would be good to try to avoid it if possible (or defer it to later).

For RustcTargetData, would it be possible to make target_config and target_info be populated in a lazy fashion? It seems like it will be challenging to get all the information up-front.

I'd hope that this is kind of what I am doing already here and would hope that once there is a version of this that depends on PackageSet this problem is solved. Maybe I am missing something though.

The feature resolver needs to have access to the RustcTargetData in order to evaluate cfg(...) expressions (like [target.'cfg(windows)'.dependencies]).  For example, imagine this scenario:
# my_package Cargo.toml
[dependencies]
foo = "1.0"

# foo Cargo.toml (from crates.io)
[dependencies]
embedded-thingy = {version="1.0", target="wasm32-wasi", artifact=["bin"]}

# embedded-thingy Cargo.toml (from crates.io)
[target.'cfg(target_family="wasm")'.dependencies]
bar = "1.0"

Here when the feature resolver is evaluating the bar dependency, it needs to know if the target matches the cfg expression.  However, that target only comes from the target=... dependency declaration (not the --target CLI option).  RustcTargetData needs to be filled out with the information for wasm32-wasi for the feature resolver to work.
Another problem is that pkg_set.download_accessible also needs to have that target information available to download only what is needed. However, I realize there is a cyclic problem here. If the target information is not in the index, then download_accessible won't know what to download.
If possible, I'd like to break this problem off into a separate work item from this PR. For now I think it is OK for this to be a little buggy. I'll try to review the current state of the PR and keep that in mind.

However, I realize there is a cyclic problem here.

If possible, I'd like to break this problem off into a separate work item from this PR. For now I think it is OK for this to be a little buggy. I'll try to review the current state of the PR and keep that in mind.

That would be my preference too, this PR is big enough as is. At some point I remember there was a version that altered what's published to the registry already which worked well, but it certainly wasn't more than a proof of concept of something we know will work.
The current implementation is limited and a test with a setup like the one you presented here would certainly bring that to light. I could imagine adding it with #[ignore] so that it can't be forgotten about and can be fixed in a separate effort.

You should be able to rebase now to fix the tests.

I did rebase and double-checked these tests manually. Locally they do work pass now, so I am a bit puzzled the clap-related errors are still present. The CI logs clearly show that clap-v3.0.13 is being compiled as required by the cargo manifest.

I did rebase and double-checked these tests manually. Locally they do work pass now, so I am a bit puzzled the clap-related errors are still present. The CI logs clearly show that clap-v3.0.13 is being compiled as required by the cargo manifest.

That link looks to be from a run 7 days ago.  The most recent one that just ran seems to have passed https://github.com/rust-lang/cargo/actions/runs/1788114623

:umbrella: The latest upstream changes (presumably #10341) made this pull request unmergeable. Please resolve the merge conflicts.

That link looks to be from a run 7 days ago. The most recent one that just ran seems to have passed https://github.com/rust-lang/cargo/actions/runs/1788114623

🤦♂, indeed, I should have spammed that refresh button more. Sorry for the noise.

Following up on this: based on discussions in the @rust-lang/cargo meeting today, we came to the conclusion that we will definitely need changes to the index format, and that we shouldn't work around that. That said, that could happen incrementally, and possibly in another PR if it's a challenge to include in this one, as @ehuss suggested in a comment above.

Sorry the reviews are coming through slowly. I'm still working through, but here's another batch of comments.

A German expression seems quite applicable here: "Gut Ding will Weile haben" - good things take time. Every batch of comments is most welcome as it inevitable increases the quality of a tool that deserves no less than the highest standards, while bringing the PR a step closer to the finishing line. Thank you for the incredible effort you are putting in to get this right!
From what I can tell, this batch of comments is addressed and I am looking forward to the next round.
Related to the index format change, I left some notes about the commits to look at in case some of the prior work should be restored as an index-based solution did exist at some point. That may help to follow through on a format change for index data. Since that is more involved I would certainly prefer to leave it out of this PR as it would be another dependency to wait on, further delaying merging this one while increasing the chance for conflicts with master.

I was able to address most comments in a way I would find satisfactory, except for the ones related to the filtering of dependencies also in conjunction with build dependencies. I have a hunch that the need for custom filters would go away if the special handling of artifacts for build dependencies could be moved to calculate_deps(). Unfortunately I was unable to do that, but could try again if you @ehuss  think it could work at all.

After rebasing against master to fix CI I did my best to update all comments with the rewritten commit IDs. Even though I did my best, in case there is a mistake I leave the commit mapping here which should allow to sort things out with the help of looking at older versions of commit messages.

78f0add -> 78213ea1ea8c1ab7160b786b283de3d65c46070f
f84309f79be6d089faa4437f06aaeae22cf4fcdd -> 3de579992cdaf76cf7090033e84108c6cb6c9202
61b285cdd4a2ff45a5d830b3a95f6496f9fa4601 -> b4783702f9c02667ee78c1245423eb43e504fbe2
c0e6abe384c2c6282bdd631e2f2a3b092043e6c6 -> 0cf581e5e4bda41c51f1f36cadb609795b5c9530
9ebc4e156f0efa60751ae2199cd70dc71b90f769 -> 25218d25dd99a094f2a5ec6a54d30572253b3b95
64aa29e61b809db9a84c876d56a5a9a0da9fb3000 -> cd25256437b1db0783b581feec60815a5b550ac6

Regarding the filtering, the following diff is roughly what I was thinking: https://github.com/ehuss/cargo/commit/41d85cc7d369c0ae1dab936f9622d4c5e26cad5c
Essentially, that keeps state.deps() as a single way to fetch dependencies, and all filtering is the same in all scenarios. It also tries to simplify the interface with calc_artifact_deps.
I think that cuts about 40 lines of code, and makes the filtering of deps a little more straightforward.  What do you think?

Thanks so much, @ehuss, for the all the help!

I think that cuts about 40 lines of code, and makes the filtering of deps a little more straightforward. What do you think?

I think it's something I would have loved to come up with the first time around, and believe it's a great improvement. I couldn't find anything to add or change so pushed the commit into this PR as is.

❤❤❤
Due to recent events I feel the need to once again commend the reviewers and @ehuss in particular for their amazing communication skills when reviewing PRs like this. I can only imagine how much work it means and how silly some of the changes proposed here might look to a seasoned cargo developer, yet you maintain a constructive, upbeat, and friendly spirit at all times. It's a style that I am aspiring when reviewing PRs myself, and is a prime example for the accessibility and friendliness of the Rust community as a whole.
Thank you!
❤❤❤

Okay, I think this is probably ready to go.  Can you squash the commits?  I think it would be fine to just have one commit, but I'll leave it up to you if you want to keep a few extras.

Awesome! I have squashed everything into one commit, but will leave the original patch queue available in my fork at https://github.com/byron/cargo/tree/rfc-3028-unsquashed .
I was wondering if I did that correctly as now one would have to compare both diffs to validate they are still the same as the original and reviewed history is lost.
That seems to be the case for me.
➜  cargo git:(rfc-3028) ✗ git diff $(git merge-base rfc-3028-unsquashed master) rfc-3028-unsquashed | shasum
04a4fa88a4009e624c55d13c9894e4f9c5b5d8b3  -
➜  cargo git:(rfc-3028) ✗ git diff $(git merge-base rfc-3028 master) rfc-3028 | shasum
04a4fa88a4009e624c55d13c9894e4f9c5b5d8b3  -

🎉 Looks good!  🎉
Yea, it would be nice if git made it easier to squash a branch and be confident it does the right thing.
I'm going to go ahead and merge.  I'll follow up with some issues for followup work, and will try to provide some guidance in them. It may take time for me to cover all the things I'm thinking of, though.
@bors r+

:pushpin: Commit 7248f4b70da464b9ed7839e0f26110b6664b6ee6 has been approved by ehuss

:hourglass: Testing commit 7248f4b70da464b9ed7839e0f26110b6664b6ee6 with merge 5aad9b302adc2f4cf1f184315f497fb3e3256b78...

:sunny: Test successful - checks-actions
Approved by: ehuss
Pushing 5aad9b302adc2f4cf1f184315f497fb3e3256b78 to master...


Do not Merge Just Debug.

Look this log line https://github.com/hyperledger-labs/fabric-operator/actions/runs/4421826309/jobs/7753027299#step:3:305
The test failed, but the display is correct.


virtual.projects.iamMemberBinding does not work when performing a DM update

What is the problem?
When trying to update the iam policy using DM/iam_member template, deployment manager update fails with the error:
ERROR: (gcloud.deployment-manager.deployments.update) Error in Operation [operation-1561961486052-58c987f876cdb-81d930b3-b1a4913f]: errors:
- code: NO_METHOD_TO_UPDATE_FIELD
  message: No method found to update field 'role' on resource 'get-iam-policy-iam-member-test-0-0'
    of type 'cloudresourcemanager-v1'. The resource may need to be recreated with
    the new field.
- code: NO_METHOD_TO_UPDATE_FIELD
  message: No method found to update field 'role' on resource 'get-iam-policy-iam-member-test-1-0'
    of type 'cloudresourcemanager-v1'. The resource may need to be recreated with
    the new field.

How to reproduce?
Prerequisite -

have an existing project
have an existing service account (with or without exist iam-binding)

create the initial binding using something like the following template: (make sure the target service account does not have the roles you are applying.
my_iammember.yaml
imports:
  - path: templates/iam_member/iam_member.py
    name: iam_member.py

resources:
  - name: iam-member-test
    type: iam_member.py
    properties:
      roles:
        - role: roles/owner
          members:
            - serviceAccount:<service_account_email>
        - role: roles/viewer
          members:
            - serviceAccount:<service_account_email>
        - role: roles/editor
          members:
            - serviceAccount:<service_account_email>

Create the deployment using gcloud:
gcloud deployment-manager deployments create <deployment name> --config my_iammember.yaml --project <project_id>
The fingerprint of the deployment is YDDe0jcBvNsZoSuymtHQ0A==
Waiting for create [operation-1561961867754-58c989647bc92-41977b01-1cd6e20f]...done.
Create operation operation-1561961867754-58c989647bc92-41977b01-1cd6e20f completed successfully.
NAME                                TYPE                                                                 STATE      ERRORS  INTENT
get-iam-policy-iam-member-test-0-0  gcp-types/cloudresourcemanager-v1:virtual.projects.iamMemberBinding  COMPLETED  []
get-iam-policy-iam-member-test-1-0  gcp-types/cloudresourcemanager-v1:virtual.projects.iamMemberBinding  COMPLETED  []
get-iam-policy-iam-member-test-2-0  gcp-types/cloudresourcemanager-v1:virtual.projects.iamMemberBinding  COMPLETED  []

Now update my_iammember.yaml and remove the FIRST role in the list so it becomes:
imports:
  - path: templates/iam_member/iam_member.py
    name: iam_member.py

resources:
  - name: iam-member-test
    type: iam_member.py
    properties:
      roles:
        - role: roles/viewer
          members:
            - serviceAccount:<service_account_email>
        - role: roles/editor
          members:
            - serviceAccount:<service_account_email>

Run an update on the existing deployment
gcloud deployment-manager deployments update <deployment_name> --config my_iammember.yaml --project <project_id>
The fingerprint of the deployment is Z5uddsi6wYlQcGGH_70W-w==
Waiting for update [operation-1561962108307-58c98a49e46ff-137a8ee4-355f5448]...failed.
ERROR: (gcloud.deployment-manager.deployments.update) Error in Operation [operation-1561962108307-58c98a49e46ff-137a8ee4-355f5448]: errors:
- code: NO_METHOD_TO_UPDATE_FIELD
  message: No method found to update field 'role' on resource 'get-iam-policy-iam-member-test-0-0'
    of type 'cloudresourcemanager-v1'. The resource may need to be recreated with
    the new field.
- code: NO_METHOD_TO_UPDATE_FIELD
  message: No method found to update field 'role' on resource 'get-iam-policy-iam-member-test-1-0'
    of type 'cloudresourcemanager-v1'. The resource may need to be recreated with
    the new field.

Expected result.
Deployment manager update should succeed. The Owner role that was assigned to the service account should have been revoked.
NOTE: I have found that if you instead the my_iammember.yaml to remove the second or third role in the list (i.e. not Owner) the deployment manager update is successful.

Thank you for reporting. Can you please clarify what is your code commit version and branch?

hey @ocsig, i'm testing on the latest commit(53e3141) on the master branch.
I did some testing on the cft-dm-dev branch (commit - 9c31921) gh the error is gone but the result does not align to the deployment manager update.
i.e.
i started with my DM template defining my service account should have the following roles:
owner
viewer
editor
(note: this is the order that it was defined in the DM template)
now i remove 'owner' from my DM template and perform a DM update. I expect there to be still viewer and editor binded to the serviceAccount. However, the actual result is that only editor is still binded to the serviceAccount.

@ocsig I can confirm that the same is true for folders.

@jsun6383 We found the issue and patched it. Please do a git pull, delete your current deployment and create a new one. ( If you would do an update, all resources would be deleted anyway but race conditions may exists because of the old code.)

thanks @ocsig - i can confirm the issue is resolved.

@jsun6383 @ocsig Any idea how to define a "condition" here for a role assignment? Like say I want to provide access to only those VMs with a prefix of "test-". How do I do that here?

+1 regarding the role assignment with condition, is there a way to accomplish this using the type gcp-types/cloudresourcemanager-v1:virtual.projects.iamMemberBinding ?


"Si vis pacem, para bellum" relevance

What is the relevance of the quote

"Si vis pacem, para bellum" - (Vegetius 5th century)

From the README.md document ?
As I understand it, it means "If you want peace, prefer for war", but I don't understand the relevance between the quote and the library...

Disclaimer: I'm not a native speaker so probably what follows is an ugly translation.
That latin sententia can be interpreted as "one of the most effective means to ensure peace is to be armed and able to defend itself".
Nerdy meaning: we are naked and helpless in front of the dynamic nature of the enemy (JavaScript). We need sentries (runtime type-checking) all over the places to protect us from aggressions (type errors). Once (tcomb's) armies are in place, there's no way invaders can cross the (IO) walls of our reign (code).

Wow thanks for explaining - that is one clever use of the phrase! :fireworks: :8ball:


Meet-up: London, 21st March 2018, 6:30pm at The Porcupine, near Leicester Square

Based partly on how well the planned Paris meet-up next month goes, I'm planning some form of London equivalent for the many UK-based users of sharp and libvips.
This will be an informal gathering to meet other users, ask questions, get advice and perhaps learn more about how you can contribute.
I expect it to take place on a Wed or Thurs evening mid to late March in central London, most likely in a relatively quiet pub.
If you're available and would like to meet up, subscribe to this "issue", add a comment or send me an e-mail and we can sort something out.

In case you've not met @kmartinez, he was one of the original vips authors way back in the 1990s. He's now a prof at Southampton and uses libvips for some of his research.

21st please if possible...

Wednesday 21st is good for me. Shall we say from about 6pm onwards?

Super!

21st is good for me too.
I'm rather out of the pub scene sadly :( Do you have any good ideas, Lovell? Kirk and I met at the Round Table by Leicester Square last time, but only because of familiarity. It's quiet and horrible.

I'm still intending to come - anywhere central good for me.

@kmartinez Are you heading back to Southampton afterwards? If so, somewhere near Waterloo would make sense as you've got the furthest to travel. The Kings Arms on Roupell Street is excellent but can get a bit busy so unsure it meets the "quiet" criteria.

Really sad I will not be able to make this, hope it goes well

Incidently I'll actually be in London this week, and would gladly pop by to say hi and grab a quick beer if I'm not imposing!

@Jondeen Are you in London for QCon? I'm not attending but might be meeting up with some people that are, possibly on Wednesday evening. Drop me an email or DM if you're interested.

I might also be in London around this time - if I am, I'd love to stop by and have a chat! Let me know if you come up with a more specific time and place :)

This is actually very relevant to current work interests, will definitely try to come.

Is this still happening? If so, what's the location?

yes it is - we're just waiting for confirmation of the venue - central somewhere

I had a 'mo so I've booked a table at The Porcupine from 6:30pm on Wednesday 21st March:
https://www.nicholsonspubs.co.uk/restaurants/london/theporcupineleicestersquarelondon
Under the code name "john". The table's for 8, but I'm sure more/fewer is no problem, so all are very welcome.

I had a slight cognitive fumble and thought it was this Thursday! I'm afraid I won't be able to join you guys after all. My apologies, I do hope I'll get the chance to meet you all at a later occasion!

Sorry, not going to make it in the end, got caught up with (non-image-related) work

We're upstairs in The Porcupine.

Great to see you yesterday, thanks for coming along! Thank you also to the anonymous sponsor for the food and drinks.
For those who couldn't make it this time, we'll do another event in London later in the year. I'm usually in central London at least a couple of times a week so drop me an e-mail if you're in town and otherwise at a loose end.

Yes it was good to meet up!
If there was sufficient interest we could do a short hackathon-type event in London beforehand - I'm sure I could find a room in the University somewhere...

Great to learn a bit about libvips and sharp, thanks for organising.

That webgl game: https://github.com/jcupitt/argh-steroids-webgl if your daughter needs a programming project.

Is there another one of these planned? I'd like to catch up and ask some questions.

@tomgallagher There's nothing planned in London right now but we should definitely organise another gathering soon, perhaps early in the new year. Feel free to open a new issue with any question(s).

@lovell @jcupitt That sounds good. I don't really have any specific Sharp questions but I was wondering how easy it was to extract in JS to extract image file type and dimensions from incoming chunks of an http request? Maybe this is better brought up elsewhere...

Please see https://github.com/libvips/libvips/issues/1222 for details of the March 2019 London meetup.


fix: Whole card clickable

Thank you for your contribution to the KodaDot - One Stop Shop for Polkadot NFTs.
👇 __ Let's make a quick check before the contribution.
PR Type

[x] Feature

Needs Design check

@exezbcz please review

Context

[x] Closes #8985

Did your issue had any of the "$" label on it?

[x] My DOT address: Payout

Screenshot 📸

[x] My fix has changed UI

Copilot Summary
copilot:summary
copilot:poem

Nice screenshot XD, will check soon

thanks!
pay 20 usd

😍 Perfect, I’ve sent the payout
💵 $20 @ 7.59 USD/DOT ~ 2.635 $DOT
🧗 16SjUbGKSdjCdWTy3NNT3JxbRVGGqD4mwkHpc6BD9U2Rp29Z
🔗 0x2408f23478b5c89ea8cb1cfd40efcd592ac02afca6167dd060419bfcc5455ae7
🪅 Let’s grab another issue and get rewarded!
🪄 github.com/kodadot/nft-gallery/issues


Set target folder?

there is the --assetPath flag, but there is no --targetPath. My android project is not at the root of web project folder. It is located somewhere else. How can I get the logos / icons to be placed in the correct place?

Can certainly add more options here. Where do you place your android app folder?

The main/cli/data folder contains generated app icons. The main/source/android folder contains the android project.

Thank you 🍻


example/darkmode: add darkmode example

This PR reproduces theme flickering to understand what needs to change in bud:

[ ] Fix SSR flickering
cookie.get(...) uses document.cookie under the hood. document.cookie should be accessible by V8 on the server-side. We'll need to take care exposing APIs though. We shouldn't try to polyfill the DOM on the server.

cc @vito in case you have any thoughts!


autop inserts wrong br line breaks after dd definition list definitions

Title says all... reproduction:

Blabla

Here goes the text which will be followed by an unnecessary br

Blabla after an unnecessary br

Here goes the text which will be followed by another unnecessary br

Also goes for dt when the dt and the dd parts are separated by a newline.

This issue was moved to habari/autop#1