[rbdl-orb] Adding RBDL-ORB to vcpkg

This PR adds the rbdl-orb library to vcpkg. Rbdl-orb is an updated version of rbdl, maintained by the robotics group at the University of Heidelberg.
RBDL-ORB has been tested on linux, windows and mac with x86 and x64.

Does your PR follow the maintainer guide?

Yes

Hey,
regarding your suggested updates.
Using the "vcpkg_from_github" to download the repository is not possible because it does not recursively clone the repository. We have put some dependencies that where previously directly vendored into the code base and moved them to a sub repository, to be better able to test them and keep the versions in sync.
I tried using the commands "vcpkg_cmake_configure" and "vcpkg_cmake_install" in both cases vcpkg tells me that it does not know these commands.
Building the tests is off by default, so it does not need to be specified explicitly ;) the boost dependencies are required by the urdfmodel addon. The luamodel and urdfmodel addons are regarded as quite important because they enable reading the models from these file types instead of having to construct the models using cpp code.
Moving to vcpkg.json should not be a problem.
Kind regards,
ju6ge

@ju6ge, thanks for clarifying this!

We have put some dependencies that where previously directly vendored into the code base and moved them to a sub repository, to be better able to test them and keep the versions in sync.

Do mean the https://github.com/ORB-HD/URDF_Parser repo? if so, generally, we'd recommend to add URDF_Parser to vcpkg firstly, and then let rbdl-ord depend on URDF_Parser.

I tried using the commands "vcpkg_cmake_configure" and "vcpkg_cmake_install" in both cases vcpkg tells me that it does not know these commands.

You need add vcpkg-cmake port to dependency, eg: https://github.com/microsoft/vcpkg/blob/master/ports/recast/vcpkg.json

Hey so I updated to use vcpkg.json as well as the new cmake commands.
Regarding creating a separate urdfparser library in vcpkg. I think I should clarify that the "we" mostly means me. I work for the robotics research group at the university of Heidelberg while completing my masters degree. The original RBDL was written by Martin Felis as his doctoral thesis in our group and since then we have maintained our own fork because other researchers have added functionality, while Martins version has mostly stayed the same. We also have some other tools building uppon rbdl-orb and the reason we are interested in having rbdl-orb in vcpkg is to be able to get our tools running on windows. But since I am the only person actively doing all this work as a part time job, separating out the urdfparser as its own library would just make my workload explode. I would need to write more build files to import urdfparser on all systems (linux, mac, windows) instead of just having it build with the project. Which also would mean updating the CI of all downstream tools. This just increases the complexity while adding no real value at the moment. If we had a bigger team to deal with this I think it would be a sensible thing to do. But given that it is just me, keeping urdfparser in sync between rbdl-orb and our downstream tools is just best handled by using a subrepository which is already a lot better than having the code replicated in each repository directly and having to manually apply the changes to all repositories.

Hey @JackBoosY, thanks for the suggested update. I updated the PR and ran the auto-formatter.

separating out the urdfparser as its own library would just make my workload explode. I would need to write more build files to import urdfparser on all systems (linux, mac, windows) instead of just having it build with the project. Which also would mean updating the CI of all downstream tools. This just increases the complexity while adding no real value at the moment.
But given that it is just me, keeping urdfparser in sync between rbdl-orb and our downstream tools is just best handled by using a subrepository which is already a lot better than having the code replicated in each repository directly and having to manually apply the changes to all repositories.

We recommend separating dependent libraries and establishing dependencies on their use, but this does not mean that we must do this.
Many ports in vcpkg use internal third-party dependencies, and their dependencies are also downloaded through the download method provided by vcpkg. As my suggestion.
We can set the dependency between their versions by setting the REF value in vcpkg_from_github.

Okay so now it should be correct. I am only using the vcpkg_ commands to download the sources and place the URDF_Parser repo into the correct subdirectory within rbdl-orb \o/

@ju6ge, rbdl-orb failed on our CI testing, do you test them locally, please let me know if you need the CI failure logs.

@PhoebeHui i have a windows server 2019 instance on which I tested the install of the port with vcpkg for x64-windows and x86-windows both install fine with the most resent commit. I looked into the CI logs for x64-windows which mentions that the hashes don't match after I updated the port to point to newest version v3.0.0 commit. It mentions running ./vcpkg x-add-version --all which I already did so I am not sure why that failed.
On my linux workstation the install of x64-linux it also is failing because of some lua error. I have not gotten around to debugging that.
The main reason I want rbdl-orb in vcpkg is to have it on windows though, so that is more of my focus now. Using rbdl-orb in linux and oxs already works for me without vcpkg.

@ju6ge rbdl-orb also failed with x64-uwp, arm_uwp, x64-windows-static, x64_linux, x64_osx and x64-windows_static_md.
It passed with x64-windows and arm64-windows.
For x86-windows, it needs execute './vcpkg x-add-version -overwrite-version rbdl-orb' after you committed all changes, it's used to update the baseline version, and should be updated when everything is done.

When building uwp:
     5>D:\installed\x64-uwp\include\eigen3\Eigen\src/Core/util/Meta.h(357,2): error C4996: 'std::equal_to<double>::result_type': warning STL4007: Many result_type typedefs and all argument_type, first_argument_type, and second_argument_type typedefs are deprecated in C++17. You can define _SILENCE_CXX17_ADAPTOR_TYPEDEFS_DEPRECATION_WARNING or _SILENCE_ALL_CXX17_DEPRECATION_WARNINGS to acknowledge that you have received this warning. (compiling source file D:\buildtrees\rbdl-orb\src\528962cc0b-f01583996e.clean\src\Joint.cc) [D:\buildtrees\rbdl-orb\x64-uwp-dbg\rbdl.vcxproj]

When building osx:
/Users/vagrant/Data/buildtrees/rbdl-orb/src/528962cc0b-f01583996e.clean/include/rbdl/rbdl_errors.h:40:23: error: exception specification of overriding function is more lax than base version
  virtual const char* what() const noexcept;
                      ^

When building uwp:
     5>D:\installed\x64-uwp\include\eigen3\Eigen\src/Core/util/Meta.h(357,2): error C4996: 'std::equal_to<double>::result_type': warning STL4007: Many result_type typedefs and all argument_type, first_argument_type, and second_argument_type typedefs are deprecated in C++17. You can define _SILENCE_CXX17_ADAPTOR_TYPEDEFS_DEPRECATION_WARNING or _SILENCE_ALL_CXX17_DEPRECATION_WARNINGS to acknowledge that you have received this warning. (compiling source file D:\buildtrees\rbdl-orb\src\528962cc0b-f01583996e.clean\src\Joint.cc) [D:\buildtrees\rbdl-orb\x64-uwp-dbg\rbdl.vcxproj]

That is just a warning, can you send me the entire log?

@ju6ge, I noticed that the cmake warning generated with  x64-uwp and arm-uwp in CI testing, does this expect?
I double checked there is no pdbs generated for release configuration, however, for debug configuration, it has these pdbs.
CMake Warning at scripts/cmake/vcpkg_copy_pdbs.cmake:69 (message):
  Could not find a matching pdb file
  for:D:/packages/rbdl-orb_x64-uwp/bin/rbdl.dll

      D:/packages/rbdl-orb_x64-uwp/bin/rbdl_geometry.dll
      D:/packages/rbdl-orb_x64-uwp/bin/rbdl_luamodel.dll
      D:/packages/rbdl-orb_x64-uwp/bin/rbdl_urdfreader.dll

Sorry for the delayed response, there where some other issues that needed my attention.
I checked and for release there where no pdbs generated. I am really not sure what would be required to get them, since they are present in the normal windows-x86/x64 builds.

@ju6ge, I can't repro this issue locally now, it seems the problem has been fixed. and the pdb files exist now.
E:\vcpkg\18883\vcpkg\packages\rbdl-orb_x64-uwp\bin>dir
 Volume in drive E is New Volume
 Volume Serial Number is B273-EF86

 Directory of E:\vcpkg\18883\vcpkg\packages\rbdl-orb_x64-uwp\bin

08/03/2021  02:13 AM    <DIR>          .
08/03/2021  02:13 AM    <DIR>          ..
08/03/2021  02:13 AM           673,280 rbdl.dll
08/03/2021  02:13 AM        50,507,776 rbdl.pdb
08/03/2021  02:13 AM            84,992 rbdl_geometry.dll
08/03/2021  02:13 AM         2,330,624 rbdl_geometry.pdb
08/03/2021  02:13 AM           203,264 rbdl_luamodel.dll
08/03/2021  02:13 AM         4,362,240 rbdl_luamodel.pdb
08/03/2021  02:13 AM           176,128 rbdl_urdfreader.dll
08/03/2021  02:13 AM         4,763,648 rbdl_urdfreader.pdb
               8 File(s)     63,101,952 bytes
               2 Dir(s)  338,876,710,912 bytes free

Great news 👏


BIGTOP-2476 Add Zookeeper Charm

Based on the vanilla apache-zookeeper charm, but utlizes Bigtop to
reduce complexity in the charm itself.
@juju-solutions/bigdata: Since I'm still a newb, I'm pushing one more PR w/ the team before submitting upstream. This, I think, is the final, actually working, following all the best practices version of this charm. If you agree, please +1. If I missed something, please let me know, and I'll fix it :-)

I have a couple issues with the status reporting

First, please make all status_set messages lowercase. hookenv.log is fine to have proper sentences with capitalization, but we want all our status_set messages to be lower.

Second, I thought the old charm's reporting of suboptimal (non-quorum) status was useful. Please consider adding this functionality back.  The old was of doing it was a very simple grep of zoo.cfg:

https://github.com/juju-solutions/layer-apache-zookeeper/blob/master/lib/charms/layer/zookeeper.py#L183
Followed by setting the appropriate message if we had a suboptimal quantity of peers:
https://github.com/juju-solutions/layer-apache-zookeeper/blob/master/reactive/zookeeper.py#L44
If you brought this back, you could add a reactive handler like this:
@when('zookeeper.started')
def update_status():
    num = <num_peers>
    if num is good:
        status_set('active', 'ready')
    else:
        status_set('active', 'suboptimal number of peers (num)')

Fixed the status messages.
I think that, with the messaging complexity we've introduced by not doing automatic restarts, I'd rather skip the notifications about inadequate numbers for quorum for now.
When we add the automated restarts back in, though, I like the idea of adding those messages back in as well.

@kwmonroe I lied about the messing being too complex. Functionality from the old charm ported over. :-)

I've opened a PR upstream, so closing out this PR.


Assessment - Freddy T Mercury Cost Summary

Cost Summary shows 1 Work Item Accepted and 1 Work Item in Review, even though there is only one Work Item showing and the Site Assessment was able to be marked Complete.

I believe I saw this in the doc and I mentioned it there. It may have to do with how work items were previously created for the site assessment for all work items included handle-it ones, but I am now seeing one work item in the cost summary in the assessment page for Freddy Mercury.

OK, now I'm seeing that too.


Dart plugin / Analyzer in IDE uses old/wrong/cached??? file for analysis and marks everything in red

If I open a file (test) in IJ it marks almost all classes as "not defined" but if I modify the file by adding a new line it recognized the change and removes the error messages.
Analyzer cmdline works (as always in such cases)
Made a video to demonstrate the problem
IntelliJ IDEA 2017.1.1
Build #IU-171.4073.35, built on April 6, 2017
Licensed to Mike Mitterer
Subscription is active until December 3, 2017
JRE: 1.8.0_112-release-736-b16 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Mac OS X 10.11.6
Dart plugin: 171 4424
analyzer-bug-ide.mp4.zip

@scheglov In case you have any thoughts.

I don't know why this might happen.
One possibility is a bug with updating errors in the Dart plugin for IDEA.
Another - is a bug in Analysis Server or analyzer.
Was the file events.dart recently added?
Was pubspec.yaml recently changed?

Had the same thing today in the morning. Nothing changed from yesterday evening to today in the morning. After pressing enter (editing the file) the error disappears.

I just copied (internal file) ApiKeyService_test.dart to UploadServericeSecure_test.dart - the same situation. All the imports were red. After adding a newline they became valid again. The weird thing is that I've modified the ApiKeyService_test.dart secs before...


feat: add ng-add schematic

Issue or need
See #961

Proposed changes

Quick reminders

🤝 I will follow Code of Conduct
✅ No existing pull request already does almost same changes
👁 Contributing docs are something I've taken a look at
📝 Commit messages convention has been followed
💬 TSDoc comments have been added or updated indicating API visibility if API surface has changed.
🧪 Tests have been added if needed. For instance, if adding new features or fixing a bug. Or removed if removing features.
⚙ API Report has been updated if API surface is altered.

#962  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @davidlj95 and the rest of your teammates on  Graphite


Pass Session parameter to AccessControl

Pass Session parameter to AccessControl

Can you describe the use case for this?   We have discussed this in the past a few times and always decided to not expose session to access control.

Can you describe the use case for this? We have discussed this in the past a few times and always decided to not expose session to access control.

There are access control implementations that are logging information about access checks to audit service. That way it is possible to audit what user accessed what database resources. Along storing information about resource (table, column etc), action (select, insert) and user (identity), it is also useful to log what was the actual query that was executed, the client ip etc.
I see that passing Session might be not a best option because:

it passes to much information to access control
leads to a chicken-egg-problem, see https://github.com/prestosql/presto/pull/171#discussion_r254231730 (session is needed to create session o_O)

Maybe instead of passing Session, we could pass some SessionContext with information required for audining but not leaking information like session properties etc.
@electrum @dain @findepi @sopel39 Thoughts?

Maybe instead of passing Session, we could pass some SessionContext with information required for audining but not leaking information like session properties etc.

SecurityContext is a better name.

Can you describe the use case for this? We have discussed this in the past a few times and always decided to not expose session to access control.

There are access control implementations that are logging information about access checks to audit service. That way it is possible to audit what user accessed what database resources. Along storing information about resource (table, column etc), action (select, insert) and user (identity), it is also useful to log what was the actual query that was executed, the client ip etc.

Interesting use case.  We have always used the QueryCompletionEvent to log this information.  Maybe @martint or @electrum remember exactly how you extract the read and written tables (partitions?) in the events.

I see that passing Session might be not a best option because:

it passes to much information to access control
leads to a chicken-egg-problem, see #171 (comment) (session is needed to create session o_O)

Do you have a list of information that is necessary for this?

Interesting use case. We have always used the QueryCompletionEvent to log this information. Maybe @martint or @electrum remember exactly how you extract the read and written tables (partitions?) in the events.

@dain for security audit purposes, you want to log before query execution.

Do you have a list of information that is necessary for this?

Not much today, however I assume the list may grow once it will be more widely used. Today, besides currently available information (resource, user, access type) I use sql query and client ip.

Interesting use case. We have always used the QueryCompletionEvent to log this information. Maybe @martint or @electrum remember exactly how you extract the read and written tables (partitions?) in the events.

@dain for security audit purposes, you want to log before query execution.

Interesting.  How will you know if the user actually accessed the data?  For example, if write a query over table A, which I have permissions, and B, which I don't, you will get an access control check for A, which will work , and B, which will fail, but in the end no data was accessed because the query failed during analysis.
Anyway, I believe you are going with the SecurityContext approach above.  If so, let me know when it is ready, and I'll take a look.

@dain @electrum I changed this to pass SecuritySession (new entity) to ConnectorAccessControl. Currently SecuritySession so far wraps only ConnectorIdentity.
PS. This PR needs some more polishing, I will take care of it once you approve the direction.

@dain, @electrum ping

Thanks for updating this. The overall direction looks good, but I still have concerns.
We should also update SystemAccessControl so that the interfaces are consistent.
I like the originally proposed name SecurityContext better, although I'm struggling to articulate why. It would give us a place to put additional information needed in the future, even if that information doesn't seem to be part of a "session".
Related, we could make ConnectorTransactionId a part of that interface to simplify the argument list. Though we'd need ConnectorSecurityContext and SecurityContext. But that might be a good idea if there will be additional connector-specific information in the future (that wouldn't be appropriate for SystemAccessControl).
Another problem I have is passing Session into all the internal AccessControl methods. It seems bad to widen the interfaces to such as huge object as Session. Creating the session twice for checkCanSetCatalogSessionProperty() is one example of a problem this causes.

We should also update SystemAccessControl so that the interfaces are consistent.

Agreed, but can you do that as a second commit.... that first one is already pretty long

I like the originally proposed name SecurityContext better, although I'm struggling to articulate why. It would give us a place to put additional information needed in the future, even if that information doesn't seem to be part of a "session".

I agree.  The information isn't really a "session" but a feels to me like additional context information to make security decission.  The naming also aligns with ConnectorContext passed to ConnectorFactory#create

Related, we could make ConnectorTransactionId a part of that interface to simplify the argument list. Though we'd need ConnectorSecurityContext and SecurityContext. But that might be a good idea if there will be additional connector-specific information in the future (that wouldn't be appropriate for SystemAccessControl).

I think we should split the interface regardless.  I'm not confident about ConnectorTransactionId, but it seems it seems better than not putting it in the context.

please reassign when this is ready to be reviewed again.

We should also update SystemAccessControl so that the interfaces are consistent.

Let me do it once we are all good with ConnectorAccessControl and AccessControl. I do not want to do it too fast to avoid commit conflicts solving in case we change our mind.

I like the originally proposed name SecurityContext better

Sounds good to me. 👍

Related, we could make ConnectorTransactionId a part of that interface to simplify the argument list. Though we'd need ConnectorSecurityContext and SecurityContext.

That was a good idea. Code of AccessControlManager got simplified a lot.

Another problem I have is passing Session into all the internal AccessControl methods.

To solve that we would need to have yet another SecurityContext class. Do you suggest to have ConnectorSecurityContext, SystemSecurityContext and SecurityContext?

@electrum and @dain I updated the pull request. Please take a look.

Agreed, but can you do that as a second commit.

I would even go further with that and handle that as separate pull request. Maintainance of such big refactorings is very time consuming.

@kokosing please update the commit message and PR title (one refers to SecuritySession, the other to Session; but neither is being used)

@dain @electrum ping

I'm confused about this change now.  It appears to be simply refactoring the following:

Change AccessControl and the main implementation AccessControlManager to take Session instead of TransactionId and Identity.
Change ConnectorSecurityContext to take ConnectorSecurityContext instead of ConnectorTransactionHandle and ConnectorIdentity.
No change to SystemAccessControl which still takes just Identity.

I'm confused because I thought we needed new information.
Anyway, does the above correctly summarize the point of this change?  Are there plans to add a SystemSecurityContext?

I'm confused because I thought we needed new information.

You are right. This is only a refactor, that should allow us easily add (or remove) information that are passed to connector and system access control.

does the above correctly summarize the point of this change?

Yes.

AccessControl takes Session. But my plan is to pass SecurityContext there. I have made that change because I wanted to make sure that you agree with this.
ConnectorAccessControl takes ConnectorSecurityContext.
SystemAccessControl will take SystemSecurityContext. Not implemented yet, also I would like to hear your opinion first.

This seems fine to me.  I don't have any further comments.

This seems fine to me. I don't have any further comments.

@dain Thanks!

@dain @electrum @findepi Implemented all the pending comments, please review.


Remove the previous execution when reset a workflow

Hello,
We would like to remove the previous failed/timeout executions when we reset a workflows, for us it is not right to have two workflows ids(businees id) with two diferent status in cassandra and ES.
Thanks

Multiple runs can happen even if you don't do reset (e.g. you do continueAsNew or do cron). So it is a valid case and you should expect to see multiple runs (but with different status).
Cadence guarantees that there's only one run that is open at any given of time.

Then it is imposible to manage the failed or timeout workflows because always they are to be in the same status and it is not possible to do anything, the only thing that can we do is to create new executions instead of manage the fai/timeout ones?


[1/2 Day] Investigate tools for creating End to End tests.

As a user I don't want the site to be down when I visit it.
As an engineer I want an easy way to tell if users can perform basic user flow tests to make sure basic interactions are available to users
Outcome is cards to implement end to end tests for PeopleMover

Team had meeting and discussed. Action Item for Malcolm or Jenny: Come up with main work flows of what the user should be able to do.

https://ui.vision/

How do these workflows sound?:

Change date –> create new product –> drag person onto it
Create new person –> create new role for them –> assign them to product
Open “My Roles” Modal –> Edit Role –> Change color and name
Open “My Tags” Modal –> Edit Product Tag –> Edit Location Tag
Edit Product –> Create new Product Tag –> Change Start Date


Dereference iterator via get_value(derived_cast(exec),iterator)

Fixes https://github.com/thrust/thrust/issues/776
This allows peeking into the device data when exec is device policy
and the iterator is a raw device pointer, thus fixing
{min,max,minmax}_element in such setup.

Thanks, it looks good. Could you also please include a note in the CHANGELOG about this fix (as well as your previous fix which I think we forgot to mention).


nomidot-app-server: nested query resolvers returning null?

the logs
Error: Cannot return null for non-nullable field TotalIssuance.blockNumber.
    at completeValue (/server/node_modules/graphql/execution/execute.js:560:13)
    at completeValueCatchingError (/server/node_modules/graphql/execution/execute.js:495:19)
    at resolveField (/server/node_modules/graphql/execution/execute.js:435:10)
    at executeFields (/server/node_modules/graphql/execution/execute.js:275:18)
    at collectAndExecuteSubfields (/server/node_modules/graphql/execution/execute.js:713:10)
    at completeObjectValue (/server/node_modules/graphql/execution/execute.js:703:10)
    at completeValue (/server/node_modules/graphql/execution/execute.js:591:12)
    at completeValueCatchingError (/server/node_modules/graphql/execution/execute.js:495:19)
    at /server/node_modules/graphql/execution/execute.js:618:25
    at Array.forEach (<anonymous>)
Error: Cannot return null for non-nullable field TotalIssuance.blockNumber.
    at completeValue (/server/node_modules/graphql/execution/execute.js:560:13)
    at completeValueCatchingError (/server/node_modules/graphql/execution/execute.js:495:19)
    at resolveField (/server/node_modules/graphql/execution/execute.js:435:10)
    at executeFields (/server/node_modules/graphql/execution/execute.js:275:18)
    at collectAndExecuteSubfields (/server/node_modules/graphql/execution/execute.js:713:10)
    at completeObjectValue (/server/node_modules/graphql/execution/execute.js:703:10)
    at completeValue (/server/node_modules/graphql/execution/execute.js:591:12)
    at completeValueCatchingError (/server/node_modules/graphql/execution/execute.js:495:19)
    at /server/node_modules/graphql/execution/execute.js:618:25
    at Array.forEach (<anonymous>)
Error: GraphQL Error: {
  "0": "T",
  "1": "h",
  "2": "e",
  "3": " ",
  "4": "s",
  "5": "e",
  "6": "r",
  "7": "v",
  "8": "e",
  "9": "r",
  "10": " ",
  "11": "w",
  "12": "a",
  "13": "s",
  "14": " ",
  "15": "n",
  "16": "o",
  "17": "t",
  "18": " ",
  "19": "a",
  "20": "b",
  "21": "l",
  "22": "e",
  "23": " ",
  "24": "t",
  "25": "o",
  "26": " ",
  "27": "p",
  "28": "r",
  "29": "o",
  "30": "d",
  "31": "u",
  "32": "c",
  "33": "e",
  "34": " ",
  "35": "a",
  "36": " ",
  "37": "t",
  "38": "i",
  "39": "m",
  "40": "e",
  "41": "l",
  "42": "y",
  "43": " ",
  "44": "r",
  "45": "e",
  "46": "s",
  "47": "p",
  "48": "o",
  "49": "n",
  "50": "s",
  "51": "e",
  "52": " ",
  "53": "t",
  "54": "o",
  "55": " ",
  "56": "y",
  "57": "o",
  "58": "u",
  "59": "r",
  "60": " ",
  "61": "r",
  "62": "e",
  "63": "q",
  "64": "u",
  "65": "e",
  "66": "s",
  "67": "t",
  "68": ".",
  "69": "\r",
  "70": "\n",
  "71": "P",
  "72": "l",
  "73": "e",
  "74": "a",
  "75": "s",
  "76": "e",
  "77": " ",
  "78": "t",
  "79": "r",
  "80": "y",
  "81": " ",
  "82": "a",
  "83": "g",
  "84": "a",
  "85": "i",
  "86": "n",
  "87": " ",
  "88": "i",
  "89": "n",
  "90": " ",
  "91": "a",
  "92": " ",
  "93": "s",
  "94": "h",
  "95": "o",
  "96": "r",
  "97": "t",
  "98": " ",
  "99": "w",
  "100": "h",
  "101": "i",
  "102": "l",
  "103": "e",
  "104": "!",
  "status": 503
}
    at BatchedGraphQLClient.<anonymous> (/server/node_modules/http-link-dataloader/src/BatchedGraphQLClient.ts:59:13)
    at step (/server/node_modules/http-link-dataloader/dist/src/BatchedGraphQLClient.js:40:23)
    at Object.next (/server/node_modules/http-link-dataloader/dist/src/BatchedGraphQLClient.js:21:53)
    at fulfilled (/server/node_modules/http-link-dataloader/dist/src/BatchedGraphQLClient.js:12:58)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
FetchError: request to http://<IP_ADDRESS>:4466/ failed, reason: read ECONNRESET
    at ClientRequest.<anonymous> (/server/node_modules/cross-fetch/node_modules/node-fetch/lib/index.js:1393:11)
    at ClientRequest.emit (events.js:210:5)
    at ClientRequest.EventEmitter.emit (domain.js:478:20)
    at Socket.socketErrorListener (_http_client.js:407:9)
    at Socket.emit (events.js:210:5)
    at Socket.EventEmitter.emit (domain.js:478:20)
    at emitErrorNT (internal/streams/destroy.js:84:8)
    at processTicksAndRejections (internal/process/task_queues.js:80:21)

https://www.prisma.io/tutorials/a-guide-to-common-resolver-patterns-ct08/#scenario:-implementing-relations-with-prisma-client


Middle-click Pour it Again

It would be nice if the Pour it Again button used ui-sref instead of ng-click so it was middle-clickable.

Waiting for #34 to finish before resuming work on this one.


I don't know how to do it.

gtx-16@gtx16-Lenovo:~/Detectron-Cascade-RCNN$ sudo nvidia-docker run --rm -it detectron:c2-cuda9-cudnn7 python2 detectron/tests/test_batch_permutation_op.py
No handlers could be found for logger "caffe2.python.net_drawer"
net_drawer will not run correctly. Please install the correct dependencies.
E0929 07:30:17.760017     1 init_intrinsics_check.cc:54] CPU feature avx is present on your machine, but the Caffe2 binary is not compiled with it. It means you may not get the full speed of your CPU.
E0929 07:30:17.760035     1 init_intrinsics_check.cc:54] CPU feature avx2 is present on your machine, but the Caffe2 binary is not compiled with it. It means you may not get the full speed of your CPU.
E0929 07:30:17.760040     1 init_intrinsics_check.cc:54] CPU feature fma is present on your machine, but the Caffe2 binary is not compiled with it. It means you may not get the full speed of your CPU.
Found Detectron ops lib: /usr/local/caffe2_build/lib/libcaffe2_detectron_ops_gpu.so
..
Ran 2 tests in 0.726s
OK

I closed it after I finished the command. How can I see the file?
The difference between tools/infer_simple.py and test_batch_permutation_op.py

may be you don't need install caffe2 by compiling the source code, just install pytorch, the caffe2 will be installed automatically.


Updated B.Moore and W.McWilliams info

Hi UrLeaka, I'm looking at this branch and can't tell what changes were made. I know Brandes has a new gig, should she have the "hire me" flag? What about Will?

Hi @landrybutler .  yes, it was a very small change.  I took the banner off of Brandes picture and fixed Will's quote

Thanks for checking @landrybutler . Sorry I'm just seeing this.


RdKafka nuget>0.9.1-ci-111 no longer copies native librdkafka binaries

Hello,
After the release of nuget package 0.9.1-ci-116, RdKafka stopped creating x64, x86 folders when you build the project. This means that RdKafka can no longer find the native dll at runtime. Can you please bring that feature back?
I can confirm that this was introduced with (0.9.1-ci-116).
Related issue:
[https://github.com/ah-/rdkafka-dotnet/issues/34]

Do you think you will be able to fix that? Or will you leave it as is and we should handle the native binaries ourselves?

Will fix, just haven't had the time to do it. I'll have a look this weekend.

Fixed now in RdKafka.0.9.1-ci-132 / RdKafka.Internal.librdkafka.0.9.1-ci-16.
There's a .props file in RdKafka.Internal.librdkafka (https://github.com/ah-/librdkafka-package/blob/master/src/RdKafka.Internal.librdkafka/build/RdKafka.Internal.librdkafka.props) which does the copying automatically but it stopped getting picked up due to a package name change.

Thank you!


Wrong block type generated for "false" in typeblocking?

PS from Ralph:
Actually, it looks to me like the blocktyping cases are correct -- i.e  assuming the correct type should be "logic_boolean".   I assume the blocktyping code covers when you type on the workspace background.  Everything is fine in those cases.
The only anomalous case is when you pull the false block out of the drawer.  In that case its type is "logic_false".

This seems to be by design in the drawers (typeblocks behaves correctly).
If you have a look at the types for 'and' and 'or', they behave in the exact same way (types
are logic_boolean and logic_or). They seemed to be used on blocks that use dropdowns, to have two (or more) blocks appear in the flyout, and the generator function just calls the 'generic' one as in https://github.com/mit-cml/appinventor-sources/blob/master/appinventor/blocklyeditor/src/generators/yail/logic.js#L22
It isn't pretty, especially because the types do not change when you use the dropdown, so you end up with a 'true' block of type 'logic_false', or an 'and' block of the type 'logic_or', but they are
properly handled in the YAIL translation.
It might be possible to change the design, but I don't think this is a high priority (and would affect many other blocks... pretty much anything that uses a dropdown!).
I would close this issue, at least for now @halatmit

@josmas @ram8647 @jis @afmckinney
From Paul:
These blocks were added before Blockly had the ability to customize the toolbox (ie the drawers) like you can today. Back then, blocks appeared in the order that they were in the file, so to get a "true" and "false" block, we needed two different block definitions. The blocks shared the same yail definitions since they generated the exact same code.
The long term fix is 1) have a better way of specifying the blocks in the toolbox (it should be independent from the order of the blocks in the block definition files), and 2) use the project upgrader to remove blocks that have different block types, but are the same block with a different default value for a field (and/or, true/false, all of the color blocks, etc).

Given the comments here, we'll hold it for future work.

I think that the important thing here is that the semantics of the language are correct. The block types could easily be SHA256 hashes of the names and it wouldn't change anything so long as the YAIL that is generated is correct. We can't ever remove the existing definitions anyway because it would break loading older projects. If there's a strong objection, we can reopen this, but I think we should leave this as is.


Update README

It seems the README is outdated, but the look of it I would think I need to have a Zookeeper server and use Flume.
Also it would be very helpful to have a small "Getting started" section

I cleaned up the README.md in the meanwhile but "Getting started" section would still be useful indeed!

readme is completely rewritten now


Minor improvements

This PR:

adds .yml to the base-image/condarc filename so that it gets proper syntax highlighting
copies configuration files in a new layer for clarity
silences the apt-utils warning (see: https://github.com/phusion/baseimage-docker/issues/319)
uses the default name for the Conda lock file to make it consistent with upstream examples
updates and fixes a few typos in README.md

Hopefully this is helpful! More ideas coming. Thanks @scottyhq.

Thanks @tjcrone ! This all looks good. I originally went with the 'spec-file.txt' name to match conda documentation, but I also like the more explicit conda-linux-64.lock name - see https://github.com/mariusvniekerk/conda-lock/issues/10. I'll go ahead and merge and retag with todays date.


VERY IMPORTANT, I CANT THROW MONEY AT YOU

come one man, is it too hard to leave a paypal link so i can throw $10 your way for making the best chrome plugin on earth?
seriously man. come one...

https://github.com/YePpHa/YouTubeCenter/wiki/Donate


Workflow execution list cannot be automatically updated

Describe the bug

Workflow execution list cannot be automatically updated
Steps to reproduce

Create a workflow.
Click on the workflow name and run.
Watch the execution list.

Result

The execution list is not automatically updated.

After refreshing the page manually.

Check the watch api. It should call the workflow api not the execution ones.

Expected behavior

Workflow execution list can be updated automatically.
Environment

Walrus version: a3e5c0343d3e831ca30e4fd76a160212bc5bba7f
UI version: dev-61bd325

Additional context
Add any other context about the problem here.

Environment

Walrus version: 6eafc9f0ef146f3559f5b6469df2d2c4ca90e1fe
UI version: dev-2d30728

Test Result: pass


bump luet-cosing + cosign

Signed-off-by: Itxaka<EMAIL_ADDRESS>

@Itxaka master seems back to failing on publishing signatures, maybe the luet-plugin in the tree is incompatible with cosign 1.3.x?

@Itxaka master seems back to failing on publishing signatures, maybe the luet-plugin in the tree is incompatible with cosign 1.3.x?

weird, the fulcio-url is in 1.3.1 .... and the TUF_ROOT as well...
https://github.com/sigstore/cosign/commit/d401496d12bb592c5247d9414faea4985696e00c
https://github.com/sigstore/cosign/commit/bfd42e554d60b732a6403b7111ac840942e84572

force merged https://github.com/rancher-sandbox/cOS-toolkit/pull/999 to get the logs

That is still using 0.8 thougth, so it may have the same issue of parallel stuff accessing the same TUF_ROOT

Makes no sense to wait for this anymore as it wont affect anything in this pipeline once it passes the build target.


Allow validations messages to be localized out of the box.

Original message: Copied from https://github.com/adonisjs/discussion/issues/62
I wonder if validator messages will looking for translation (if available) by default. For example, if we have unique, required or any validations error it will looking for available translation first, otherwise use default message.
The translation file would be located in resources/locales/<locale>/validations.json & should contains the following
// resources/locales/<locale>/validations.json
{
  "unique": "The {field} should be unique",
  "required": "The {field} is required",
  "range": "The {field} should between {0} and {1}"
}

I've done this by creating simple helper that dump all validation keys from indicative like this:
Helpers.validationMessages = () => {
  const formats = {}
  const rules = require('indicative/builds/validations')

  for (let rule of Object.keys(rules)) {
    rule = rule.split(/(?=[A-Z])/).join('_').toLowerCase()

    formats[rule] = (field, type, args) => {
      const params = { field, ...args }
      try {
        return Antl.formatMessage(`validations.${type}`, params)
      } catch (err) {
        Logger.debug('Validation translation not found', { err })
      }
    }
  }

  return formats
}

That way I could simply use validate(data, rules, Helpers.validationMessages), so I don't have to translate each form manually.
I thought it would be great if adonis could handle this kind of functionality by default.
P.s. Hope you guys get the idea even tho my english was so poor 😁

It will be nice if you can answer following questions.

What will be the convention to store validation messages. For example: In which file, should they be stored.
How to handle cascading messages. For example: Validator allows custom messages for rule <required> or field+rule <username.required>
How to handle messages, which are different at runtime. For example

New user registers
I want to show following error message, if email is missing
{
   'email.required': 'Email address is required to create an account'
}

When user change their email address
{
   'email.required': 'Enter your account email address'
}

When user logins
{
   'email.required': 'Email address is required to login to your account'
}

I'm not sure if there's any convention about this, but I believe especially for those who come from laravel world would find it's useful to have sort of built-in functionality

Let's just keep it simple, the default validation message should only handle common validation rules, not for specific one. If there <field>.<rule> inside the translation file, that should be for all <field> that have <rule>. For example if we have email.required that will implies to all email field that have required rule.
You might need to take a look this repo to see my full implementation also please take a look at the following files

resources/locales/id/validations.json
providers/Saf/Controller.js at validate() method & validationMessage property.
providers/Saf/Helpers.js

For specific runtime, we should be able to override the default by usage. for example : For my repo I could simply

// SomeController.method()
const rules = {
  field1: 'required|number',
  field2: 'otherRules'
}
const messages = {
  'field1.require': 'Y U No Fill the field'
  'field1.number': 'Man, this field require a number value'
}
const data = await this.validate(request, rules, messages)

It should also support internationalization then, if there are defaults defined.

Kind of makes less sense to me, that for default messages, it will work fine and as I will try to customizes things a bit, it will just fall apart.
Also majority of apps, does have a slight variation in their messages, based upon the action. So it is simply not usable for them

hi @thetutlage . validation messages i18n and default back to the english i18n messages .
and for the action veriations make the route validation class overwrite the global i18n messages .
simply :
check for route validation messages
if found return them to the user
else check i18n global messages
else return english validation messages

I'm not sure I could describe it clearly but in my case

Validator will check validation message for current action (or route) if provided
otherwise will use glbal validation message depends on app.locales.locale config

That's it, i guess

I have added this to the list of enhancements.

Any updates on that?

@thetutlage
Hello, and thank you for providing a way to localize the custom messages.
Is there any way to achieve this using Route validators? I already created a Validator for each model so I don't use the .validate() function. Instead I use:
Route.post('my-route', 'MyController.store').validator('StoreItem')

@thetutlage
Hi, same question. Any updates for localized error messages from Route validators?

After exploring a lot, the following is the best I can come up with.
Messages for Rules
They are defined within the localization file as follows:
{
   "required": "{field} is required"
}

Messages for Field + Rule
{
   "username.required": "{field} is required"
}

Custom message for a specific action or route
Here one can prefix the messages with an identifier and then use that identifier within the Route validator.
{
   "register.username.required": "{field} is required"
}

and the validator will have an additional property
class StoreUser {
   get localizationIdentifier () {
       return 'register'
   }
}

@thetutlage , but then how would I internationalize the field name?

@thetutlage , but then how would I internationalize the field name?

I believe, you would know the field name before hand
{
  "username.required": "Username is required"
}

Is this feature ready?
If not, how should I localize my validation messages?

I do localization on frontend. Just use the error key received from server as an indicator for message, i18n allows you to keep all the messages in plain objects. I do it like this:
{
  email: {
    required: 'Email cannot be blank',
    unique: 'Email should be unique'
  }
}

This way you can differ messages for different situations and use any i18n library without the need to bloat validator files.


ghcide 0.2.0 started to fail sometimes with interface-file errors

I have a project that compiles with cabal and often works without a problem with ghcide.
But sometimes I see issues like this:
 [typecheck] [E] • Can't find interface-file declaration for data constructor SortPosition
    Probable cause: bug in .hi-boot file, or inconsistent .hi file
    Use -ddump-if-trace to get an idea of which file caused the error

I have seen this at different positions in my code, but sadly, also because of the heisenbugishness of this bug, I couldn‘t construct a minimal failing example yet.
This issue didn‘t happen on ghcide 0.1.0.
On thing of note: I have only met this issue on data constructors that where called like the Type they inhabit. Renaming the Type fixed the problem for me. But that might just have been luck.
EDIT: The Type is generated via Template Haskell.

Thanks for the bug report. It would certainly be helpful to have a minimal repro case, as well as details of your setup, including:

cradle
GHC version
Editor
OS

I am very sorry, but condensing down to a minimal repro case might take me a while.
I just thought I'll put this out here, so that you‘ve heard about this.
I can tell you my setup right away:

cradle: None configured. It works out of the box without hie.yaml file but I think it uses the cabal cradle, as that is how I configure my project. Also the issue remained with an explicit cabal cradle configured.

ghcide version: 0.2.0 (GHC: 8.6.5) (PATH: /nix/store/pc7y00g83kaisw2y6psahhhd3438xjaa-ghcide-0.2.0/bin/ghcide)

neovim + coc.nvim

nixos (This is running in a nix-shell based on reflex-platform, which means it's based on nixpkgs 19.09).

I have forgotten to mention a very important point. The Type in question is generated via TemplateHaskell. Sorry, about that …

I have a very minimal testcase that produces this kind of error: https://gist.github.com/tomsmeding/326fa7361ee19af34c06cb6f7ad7d20e
This project can be successfully built by both Cabal and Stack, but running ghcide fails with the "Can't find interface-file declaration" error.
The problem here is that the TemplateHaskell splice refers to a module-local binding that is not in scope in the module where the TH splice is used. If glorifiedID is added to the export list of Error.hs, ghcide loads the project successfully.

@tomsmeding's reproducer looks identical to the repro in https://github.com/haskell/haskell-language-server/issues/149.

@tomsmeding thanks for the repro. Could you do a little bit further analysis to help us understand the issue?

stack/cabal cradle. Is it stack specific or does it repro also with Cabal?
ghc 8.8 / 8.10. Is it specific to 8.8 or does it repro also with 8.10?
ghcide 0.2.0 / HEAD. What versions have you tested with?

My setup at home with Nix, ghc 8.10, ghcide HEAD and the default cradle (which seems to use stack) does not seem to reproduce the issue.

Good news, I gave it another go and managed to reproduce it both with 8.8 and 8.10.

I think I know what the problem is: when writing interface files for TH modules, type checking is not enough. We must extract the interface file after running the desugarer/simplifier.
Fixing this will take some staring at the ghc-api to figure out how/where to extract the ModIface objects from, followed by a significant refactoring to lift the assumption that interface files are the output of type checking, which is not the case when TH is involved. See also #672

Given that none of my personal projects (nor my employer) use template haskell, there's little motivation for me to fix this. It's up for grabs, and I'm happy to provide more directions and review merge requests

Sadly I have too admit, that I fixed a bug, but not my bug. So this cannot be closed.
I have a test reproducing my bug in this commit: https://github.com/digital-asset/ghcide/commit/985268dec97783b44d0339bf32d0cf084b903410

Just a quick heads-up as to where we stand.
This issue has now served as a discussion for two different bugs leading to very similar error messages.

The first bug happens when symbols need to be exported because they occur in a TH splice. (or something). That is fixed in #741, which just needs a tiny bit of compatibility fixes before it can be merged.

The second bug occurs in some situations where a data constructor is generated with template haskell. We are right now working on finding a solution for that. The failing test is on the fix-more-th branch (which does not yet contain a fix sadly) on my fork.

The current result of investigation is, that Template Haskell sometimes triggers a retypechecking of a loaded module and when this occurs we observe that the unique id assigned to the data constructor apparently is not stable, which leads to inconsistencies and the error-message.
Example:
First typecheck gives value: fake_uid:B.A{d a46h} second typecheck gives: fake_uid:B.A{d a46I}, error message is Can't find interface-file declaration for data constructor fake_uid:B.A{d a46h}
(Everytime I write "We" I mean "I" in the sense of trying to push this forward, but say "We" because I couldn‘t do anything without the ton of help I receive on IRC.)

Th error happens because the TypeEnv for module B gets into an inconsistent state after two typechecks.
After the first typecheck, we get the following TypeEnv:
[a46h :-> Data constructor Ã¢fake_uid:B.A{d a46h}Ã¢,
 r45p :-> Type constructor Ã¢fake_uid:B.A{tc r45p}Ã¢,
 r46i :-> Identifier Ã¢fake_uid:B.$tc'A{v r46i}Ã¢,
 r46t :-> Identifier Ã¢fake_uid:B.A{v r46t}Ã¢,
 r46u :-> Identifier Ã¢fake_uid:B.$tcA{v r46u}Ã¢,
 r46w :-> Identifier Ã¢fake_uid:B.$trModule{v r46w}Ã¢]

After the second typecheck, the TypeEnv becomes:
[a46I :-> Data constructor Ã¢fake_uid:B.A{d a46I}Ã¢,
 r45p :-> Type constructor Ã¢fake_uid:B.A{tc r45p}Ã¢,
 r46i :-> Identifier Ã¢fake_uid:B.$tc'A{v r46i}Ã¢,
 r46t :-> Identifier Ã¢fake_uid:B.A{v r46t}Ã¢,
 r46u :-> Identifier Ã¢fake_uid:B.$tcA{v r46u}Ã¢,
 r46w :-> Identifier Ã¢fake_uid:B.$trModule{v r46w}Ã¢]

Finally, the TypeEnv that is found in the ModDetails generated in loadDepModuleIO (and thus the one stored in the HPT) is
a mangled version of the previous two:
[a46I :-> Data constructor Ã¢fake_uid:B.A{d a46h}Ã¢,
 r45p :-> Type constructor Ã¢fake_uid:B.A{tc r45p}Ã¢,
 r46i :-> Identifier Ã¢fake_uid:B.$tc'A{v r46i}Ã¢,
 r46t :-> Identifier Ã¢fake_uid:B.A{v r46t}Ã¢,
 r46u :-> Identifier Ã¢fake_uid:B.$tcA{v r46u}Ã¢,
 r46w :-> Identifier Ã¢fake_uid:B.$trModule{v r46w}Ã¢]

This failure only happens when the name for the data constructor A is generated via newName. If we use mkName instead, all the occurrence of A{d} get the same unique, and so the final TypeEnv is in a consistent state.
The failure happens when GHC fails to look up the unique a46h for the datacon A in the final TypeEnv

I can confirm that the testcase works if we only typecheck the file once.
Perhaps its time to revive https://github.com/mpickering/ghcide/pull/43


Comments not different enough.

I know that much of a user's preference when it comes to a theme can be driven by small changes in the settings of their display. So if others aren't experiencing the same, I apologize.
I find that on my display, and many of my coworkers' displays, the different between comments and the background color is not substantial which causes the comments to be difficult to read when the lighting in the office isn't perfect.
I know that it's not as simple as lightening up the comment (and token) color as that might interfere with the line highlight color but I hope you can find a solution that would make it just a little easier to read.

It is not easy to improve this when the theme engine is limited to defined JSON attributes only. In other port projects it is possible to improve this by using advanced theming features like Sass/LESSCSS/CSS.
It would be nice if VS Code supports custom theme settings per JavaScript classes which would allow to implement a setting to increase percentage contrast of the comment color like the one in the Nord Atom UI.

Really like this theme, but the comment color forces me to switch back to another theme after a while. 😢

Same here, only issue with this theme.

Customize a theme via settings and impement a API for theme authors are one of the most requested VS Code features as you can see in Microsoft/vscode #11556 and Microsoft/vscode #459.
It seems like the team is going to refactor the current JSON format again as seen in the proof on concept PR Microsoft/vscode #21981.

I hope they implement it the great way like the Atom team did which may allow me to implement accessbility settings or at least users can adjust themes to their personal needs.

Comment color is my only issue with this theme, everything else is fantastic.  While certainly not the best way, you can also change the comment color in nord.json in 0.2.0 Search for "Comment" (with the quotes) and change the foreground value (~line 150).  I use #717C96

Can we get a temporary fix for this?

Can we get a temporary fix for this?

My fix is to switch to another theme every once in a while .. :|

Sorry for my late reply, haven't got the time to work on any private projects the last months.

Can we get a temporary fix for this?

Honestly there is nothing that needs to be "fixed", it's a personal preference. The color has been chosen to keep the focus of the user on the code by "fading out" comments/docs. The color works find if the settings of the monitor are correct regarding the contrast and brightness based on environment.
I've got a lot of requests in other ports projects too, but unfortunately VS Code is still not able to provide custom settings per extension compared to other editors which allowed me to implement a "accessibility" setting where the user can increase the contrast using percentage values.
Anyway, I've added this card regarding Microsoft/vscode #27894 which finally allows users to override syntax (token) colors using a editor.tokenColorsCustomizations setting object.
This way everyone how'd like to increase the contrast of the comment color can do it on it's own. I hope they implement it extension-scoped so this override rule doesn't effect other themes.

I just want to clarify that I don't want to blame anyone for having bad monitor settings or general setup, just the fact that the used color is adjusted to the theme.
I understand that it might be too dark (low contrast) for some users which are familiar with brighter comment colors, but like I said before that this is a personal preference.
I'd really like to solve this to make this theme usable for all kind of personal preferences, but it relies to the VS Code development team to implement a way for theme authors to provide customization settings or at least allow to override theme settings.
There is a PR which implements the new token color override feature which I'll keep track of.
Regarding to this  official VS Code team member comment in the PR they plan to push it to the July insiders version.
The backlog card now also links to the PR which I'll track.

Microsoft/vscode#29393 has been merged and can be tested with the latest Insiders build!
This means you can now override token colors defined by the syntax theme and customize it to fit your needs.
To change the color of all comments for the Nord theme you can add this to your settings.json...
  "editor.tokenColorCustomizations": {
    "textMateRules": [
      {
        "name": "Comment",
        "scope": "comment",
        "settings": {
          "foreground": "#4C566A"
        }
      }
    ]
  }

...and replace the current comment color #4C566A with your preferred one.
This is a reference table if you'd like to use the same increased contrast values as provided by the Nord Atom Syntax accessibility custom comment contrast theme setting feature which are calculated using the LESSCSS lighten function.

Increased by
Calculated value

1%
#4e586d

2%
#505b70

3%
#525d73

4%
#556076

5%
#576279

6%
#59647c

7%
#5b677f

8%
#5d6982

9%
#5f6c85

10%
#616e88

11%
#63718b

12%
#66738e

13%
#687591

14%
#6a7894

15%
#6d7a96

16%
#6f7d98

17%
#72809a

18%
#75829c

19%
#78859e

20%
#7b88a1

Just a small update, Microsoft/vscode#29393 is now available also in stable channel, release 1.15.

Making this change in my own version since release 1.15 has been a marked increase in usability for me! Thanks for a great color scheme.

I still wish for 5% #576279 to be the default one. Everyone's issue with this theme is just this.

@ajitid I've researched the API documentations and maybe there's a way to implement a theme settings to provide a way for users to set a percent value the comment colors will be increased by.
Changing the default color would affect all Nord port projects since I've to adapt the change to all of them. Maybe I'll start a vote poll for it and if most users would like to see the comment color to be increased by default I'll adapt it.

@arcticicestudio Lighten by 15% is perfect!

@arcticicestudio https://github.com/equinusocio/vsc-material-theme has a setting you can access by Cmd + Shift + P -> Material Theme: Settings. Users can use it to change color accents and color variants. Maybe you can also do something similar.

I've researched the API documentations and maybe there's a way to implement a theme settings to provide a way for users to set a percent value the comment colors will be increased by.

@octref Thanks for the link, the Material Theme uses the same way of the API I've also found, it's a bit "hacky" and I think not meant to be used this way, but until they extend the theme API to provide this functionality it might be the only way to implement such a feature.

I've increased the comment color by 5% up to 8% locally for all port projects I use every day and finally came to the decision that it should be fine to increase the current comment color by default.
I'll open a vote thread in the Nord repository within the next weeks to get some feedback from all users of all port projects and to decide the value which should be between 5 and 8 percent.

This reminds me of an Emacs function I wrote many years ago to darken/light Javadoc, also fold/unfold all Javadoc in a file, because Javadoc tended to be very verbose.
I believe the motivation for the default is (was?) precisely something in that line, to deemphasize docs and comments and let the code get the focus. Problem is sometimes you need to read the comments, sometimes you need to read the docs, and sometimes you are the one writing comments and docs! You need to see them clearly in those use cases.
Thanks for the table with %s above!

Note that starting with version 1.20 of VS Code, the customization can be scoped to the theme:
"editor.tokenColorCustomizations": {
  "[Nord]": {
    "textMateRules": [
      {
        "name": "Comment",
        "scope": "comment",
        "settings": {
          "foreground": "#5d6982"
        }
      }
    ]
  }
}

@arcticicestudio Thanks for the settings.json instructions and the color table override.  Nord is perfect now.  Love the theme

I didn't have to use the "textMateRules" thing any more.
I could change the comment color just with this:
"editor.tokenColorCustomizations": {
        "[Nord]": {
            "comments": "#717c96"
        }
    }

I'm not sure if I should open another issue, but one big problem for me is in diff view I literally can't read the comments:

@octref There's #105 that I'd like to merge before deploying the next version, but I'm currently also stuck at solving this problem. If there would be theme scopes that would allow to explicitly style elements that are highlighted in a diff-view I could simply adjust all colors, but there's no good style that creates a nice coloring for both diff and normal views.
By the way, the long-time problem with comments has been solved in #118 (#117) and will also be included in the next release :tada:

I opened https://github.com/Microsoft/vscode/issues/71663.

@octref Thanks :green_heart
This will definitely help a lot of theme authors to fix this contrast issue.

Alright, its finally time to close this long.time issue :tada:
PR #118 (implementing https://github.com/arcticicestudio/nord/issues/94 through #117) has been merged and version 0.8.0 has been release and deployed to the VS Code Marketplace :rocket:
The comment's color brightness (nord3) is now increased by 10% from a lightness level of ~35% to ~45%.
Feel free to let me know what you think about this change!
➜ Please see https://github.com/arcticicestudio/nord/issues/94 for all details about this design change decision.
Before

After


"Requester pays" artifact buckets result in UserProjectMissing error code

Hi Team,
We're exploring whether GCR could be used with "requester pays" artifact buckets, so that users in other projects could pull from our public GCR repos, but pay for the requests and network charges.
To this end, we've enabled "requester pays" option on one of our artifact buckets (e.g. us.artifacts.<project-id>.appspot.com), and tried to pull from it to another project after authenticating with GCR:
$ docker-credential-gcr configure-docker
/home/<user>/.docker/config.json configured to use this credential helper for GCR registries

$ docker pull us.gcr.io/<project-id>/<image>:<tag>
<tag>: Pulling from <project-id>/<image>
f2b6b4884fc8: Pulling fs layer
...
error pulling image configuration: error parsing HTTP 400 response body: invalid character '<' looking for beginning of value: "<?xml version='1.0' encoding='UTF-8'?><Error>UserProjectMissing<Message>Bucket is a requester pays bucket but no user project provided.</Message></Error>"

This is the same error as when we try to run gsutil without -u option on that bucket. It seems like docker-credential-gcr could enable a similar option here - are there any plans or technical limitations on doing that?
EDIT: For an example implementation of it with Docker credential helper protocol, the project ID could be specified through
"Username": "oauthaccesstoken@project_id"

Then, if no @project_id is specified, GCR would use the regular bucket access mechanism.
Thank you!

GCR's most request features can't naturally be implemented on top of GCS. For that reason, we most likely will not be expanding our feature parity with it.


Add some guards to prevent view errors when using custom emit values

This PR adds some defence against couch errors with the changes I made in #209. It guards against null values in the custom emit options by default, and also removes the default _sum reduce function if an emit option has been specified (to guard against the emit value being non-numeric, leading to the _sum function failing). To use the same example as I did in the original pull request:
class Invoice < CouchRest::Model::Base
  property :client_id
  property :date
  property :total_amount

  design do
    view :by_client_id_and_date, emit: :total_amount
  end
end

Generated map function:
function(doc) {
  if ((doc['type'] == 'Invoice') && (doc['client_id'] != null) && (doc['date'] != null) && (doc['total_amount'] != null)) {
    emit([doc['client_id'], doc['date']], doc['total_amount']);
  }
}

This example would also no longer have a reduce function.

Looks great again! I'm always slightly worried about modifying the view generation methods incase it causes a regeneration of our indexes, but this looks okay.
Also not too keen on the length of the View.define method... will need a refactor at some point so it is easier to read.


BUG: when calling client.list_task() the output type depends on the type of the backend

What are you trying to do?
I am calling client.list_task() after having run compute plans using different backends.
Issue Description (what is happening?)
I get different output types with different backend:
subprocess:
list[Task]
docker
list[Task]
remote
list[SummaryTask]
Expected Behavior (what should happen?)
The remote backend should return a list of Tasks as well
Reproducible Example
No response
Operating system
MacOsX
Python version
3.9.16
Installed Substra versions
substra==0.43.0
substrafl==0.35.1
-e git+https://github.com/Substra/substra-tools.git@ed471f633feaaed90c834c0aed65c2e2e6db55aa#egg=substratools

Installed versions of dependencies
No response
Logs / Stacktrace
No response

Thanks for the bug report ❤
It's not a bug, it's working as "intended".
The SummaryTask  type was introduced to solve some performance issues on the backend, and we had to introduce a matching type in Substra SDK. We are aware that the naming is not good, but we are in the process of refactoring that part, and it should revert to having only Task type in the SDK very soon 🙂


Responsive sizes handling min-width

Describe the bug
Hi, I would like to load a bigger image on mobile and smaller on desktop. Normally I would define on img HTML tag a min-width or if needed both min and max like so:
sizes="
  ((min-width: 50em) and (max-width: 60em)) 50em,
  ((min-width: 30em) and (max-width: 50em)) 30em,
  (max-width: 30em) 20em"

But the component accepts only max-width and it won't work in my case, where the bigger images should be loaded on smaller screen. Currently my code looks following (smaller images are loaded on both mobile and desktop):
responsive={[
  {
    size: {
       width: Math.round(cover.width / 2),
       height: Math.round(cover.height / 2),
     },
     maxWidth: 768,
  },
  {
     size: {
      width: Math.round(cover.width / 4),
      height: Math.round(cover.height / 4),
    },
    maxWidth: 1200
  },
]}

Am I missing something or it can work as I expect it with the current implementation of Remix-Image?
Your Example Website or App
No response
Steps to Reproduce the Bug or Issue
Define in responsive prop two image sizes: for mobile bigger images should be displayed and for desktop smaller ones.
Expected behavior
I would like to defined also a min-width to display images.
Screenshots or Videos
No response
Platform

OS: [e.g. macOS, Windows, Linux]
Browser: [e.g. Chrome, Safari, Firefox]
Version: [e.g. 91.1]

Additional context
No response

@kwiat1990 That is how the library works, we can use maxWidth only. In your scenario:
sizes="
  ((min-width: 50em) and (max-width: 60em)) 50em,
  ((min-width: 30em) and (max-width: 50em)) 30em,
  (max-width: 30em) 20em"

You need to reverse the order:
sizes="
  (max-width: 30em) 20em,
  (max-width: 50em) 30em,
  50em,
  "

A browser will pick first image which meets the conditions. I believe it is quite readable.

The above example comes from MDN page for sizes docs.
I have played with sizes and maxWidth (I have also tried to omit) but I can't really achieve what I want: load smaller images on desktop and bigger on mobile. Instead, smaller images are loaded on both.
The real code I use is following:
responsive={[
  {
    size: {
       width: Math.round(cover.width / 2),
       height: Math.round(cover.height / 2),
     },
     maxWidth: 768,
  },
  {
     size: {
      width: Math.round(cover.width / 4),
      height: Math.round(cover.height / 4),
    },
  },
]}

@kwiat1990 I see it now. You are right, something is wrong here, the order of sizes="400px, (max-width: 769px) 800px" is wrong, it should not be sorted.

I think that too. If the original order would be kept, then it should work as I wanted.

I found sorting helped resolve a bug that occurred when the screen was larger than any of the sizes, but we can definitely remove sorting.

Maybe we need to sort by maxWidth instead? From the smallest to largest and values without maxWidth at the end?
I created pull request: https://github.com/Josh-McFarlin/remix-image/pull/34/files

@tomekrozalski Thanks for the PR! Currently relocating for work, so I'll review it later today and hopefully push out a new release.


Added mode property to requests on wasm target

Closes #51

Add Mode to Request on wasm builds;
Add Mode::Cors as default;

need cargo fmt


reactor config env for worker builds

Signed-off-by: Robert Cerven<EMAIL_ADDRESS>

Updated release notes draft:

orchestrate_build uses 'reactor_config_override' when creating worker builds


Store events

Add ability to store events for outbound messages in the outbound message store.

Ready for review.

@justinvdm Changes made (wrt making extracting the events clearer)

:+1:


Incorrect assumption for empty blocks on mocha

Currently, when creating the extended header, we're making the assumption that the square is empty if there are no transactions. Most of the time this is the case, but when there is evidence, this is not the case as evidence (in v0.11.1 of celestia-app and below) is also included in the square.
https://github.com/celestiaorg/celestia-node/blob/534ec0df88fd885d69c04daf41c0ba10e4e1512f/header/header.go#L45-L77
one simple solution to this is to simply always split the block into shares and create the extended data square, instead of conditionally using the minimum data availability header function (which should likely only be used for unit testing purposes).

@evan-forbes, Was there an evidence to cause such bug?
Do I understand correctly that evidence won't be included in the block in 0.12? Can we still avoid recomputing empty eds for 0.12 and further?

So we should take https://github.com/celestiaorg/celestia-node/pull/1678 and make a 0.6.4 with it to fix syncing for Bridges, but do not merge it main.
Cc @renaynay

@evan-forbes, also out of curiosity, have you already investigated why evidence was produced?  We might even want to ditch that change and use the one that checks for evidence

we decided to cherry-pick your https://github.com/celestiaorg/celestia-node/pull/1678 for 0.6.4 only

yeah, that makes the most sense. We might even want to ditch that change and use the one that checks for evidence

also out of curiosity, have you already investigated why evidence was produced?

yeah, some small validator did actually double sign

yeah, that makes the most sense. We might even want to ditch that change and use the one that only adds one additional condition for evidence

Your PR is OK as long as it works. Does not have to be super clean as it's temporary.

yeah, some small validator did actually double sign
Some one is playing games its seems 😁

closing as completed then, pls reopen if needed


Log the underlying panic in runMigrateTask (#13096)

Backport #13096
If there is a panic during runMigrateTask we should capture and log the underlying
panic error.
This PR ensures that the panic is logged and captured as part of the task message.
Fix #13095
Signed-off-by: Andrew Thornton<EMAIL_ADDRESS>

pull to main need lgtm ... | this is ready to :rocket:


Update Turkish translations

coverage: 61.022%. remained the same
when pulling 32615a395cc7d4aa9caf4ec46f00b88567d0c72c on bitigchi:l10n
into 66244c4e8d9faf270d0e801d66ee5d150c8cb1dd on newsboat:master.

Thanks!


Registries doesn't link with Factories-and-Member-Injectors

First line of https://github.com/stephanenicolas/toothpick/wiki/Factory-and-Member-Injector-registries should link to https://github.com/stephanenicolas/toothpick/wiki/Factories-and-Member-Injectors

Thx


Link to style guide on CONTRIBUTING.md is broken

Problem description
CONTRIBUTING.md contains broken link to style guide: https://github.com/docker/docker.github.io/blob/master/opensource/doc-style

"Docker does not currently maintain a style guide. Use your best judgment, and try to follow the example set by the existing documentation."
Closing ticket.

@L-Hudson there was a style-guide, but looks like it was accidentally removed when removing the contributing guides for the open-source projects;
https://github.com/docker/docker.github.io/pull/5232
This is the one that was removed; https://github.com/docker/docker.github.io/blob/v17.06/opensource/doc-style.md

Broken link was removed with merging of PR #7663. Thanks.


Price cap doesn't support setting price cap limits under 1p (such as 0.1, or -3)

What happened?
When trying to set the price cap to under 1p, (such as 0.1p, 0p, or -3p) the value is rejected as being out of range:

Failed to call service number/set_value. Value 0.1 for number.ohme_price_cap is outside valid range 1 - 100

To Reproduce
In the Price Cap field, try to enter any value less than 1
Expected behavior
Tiny and/or negative values should be accepted (matching the behaviour of the Ohme app, which is perfectly happy with this)
Home Assistant Version
Core
2024.4.1
Supervisor
2024.04.0
Operating System
12.1
Frontend
20240404.1
Integration Version
v0.8.0
Additional context
Such small and/or negative price cap values are very useful for the Octopus Agile tariff (enables charging only at free/nearly-free times or times when you will be paid).
Worth noting the integration does seem to support reading values <1 from the Ohme charger if set in the official Ohme app (if you set 0.1p or -1p via the Ohme app, for instance, it will show up correctly in the integration shortly after).

I've adjusted the bounds to -100 to 100 (from 1 to 100). Would you mind testing out v0.8.1-beta.1? (HACS beta instructions)

Works flawlessly! Thank you very much, that's perfect.

Good news - I've released that under v0.8.1


Save VBA flow information as users type

Users should have their VBA flow information saved as they type, so if they accidentally closed the pane or refresh the page, the data should show up again.
cc @marcaaron
Fixed Issues
$ https://github.com/Expensify/App/issues/5035
Tests

Login to NewDot with an account that has a Workspace, but no bank account setup.
Navigate to Settings > Select your Workspace > Get Started
Go through the flow typing in your information. You can use this SO to get to the later steps.
Close the right pane or refresh the page periodically (before clicking on Save & Continue in each step).
Verify that information is not lost and all data is still there when you reopen the flow.

Testing potential Onyx race condition

When you get to the Beneficial owners step, check Somebody else owns more than 25% of <companyName>. Add 3 additional beneficial owners.
Open the browser console, select the Application tab and search for the reimbursementAccountDraft key under localStorage.
Back in the app, click Remove this beneficial owner and verify that the beneficialOwners array display the 2 remaining beneficialOwners and not null. Repeat the step until you are left with just one owner left.

QA Steps
Steps above.

Updated!

Updated!

@luacmartins conflicts, will review once resolved!

Updated!

Updated!

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

Thanks for all the feedback @Jag96 and @marcaaron! I really appreciate it!

🚀 Deployed to staging by @marcaaron in version: 1.0.96-1 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


[zh-cn] sync api-concepts admission-controllers node

content/zh-cn/docs/reference/access-authn-authz/admission-controllers.md
content/zh-cn/docs/reference/access-authn-authz/node.md
content/zh-cn/docs/reference/using-api/api-concepts.md

/approve

/lgtm


[BUG] Missing results causes AssertionError

Missing results causes AssertionError: Qrels and Run query ids do not match
You should make check_keys optional in evaluate because sometimes queries do not return any results for lexical-based systems.
https://github.com/AmenRa/ranx/blob/da0aa5246513acb87ec7ac7f516194fea464a2c1/ranx/meta/evaluate.py#L128

Hi, I've added the make_comparable function to Run in v0.3.7.
run.make_comparable(qrels)

The run will be modified based on the qrels passed as an argument.
Query results not appearing in qrels will be removed from run to avoid unpredictable behavior or other bugs.
For convenience, I also added the boolean parameter  make_comparable  to evaluate and compare (it defaults to False).
Please, consider giving ranx a star if you like it.
Best,
Elias


Payara Micro configuration is not most optimal one

The Payara Micro configuration is not the most optimal configuration.  By default, it is optimized for a clustered setup as in Kubernetes.
Please add also --noCluster as key (https://github.com/rmh78/quarkus-performance/blob/master/demo-payara/pom.xml#L44)
And even then, it is not the most optimal and even further tuning is possible.

For sure there are many tuning options for all configurations and all java runtimes too. In my comparison I use the default behavior.
For the Payara Micro configuration the --noCluster argument is already set at start-time of the uber-jar. See https://github.com/rmh78/quarkus-performance/blob/master/test-all.sh#LL23


[Snyk] Security upgrade golang from 1.22.4 to 1.22.5

Snyk has created this PR to fix 4 vulnerabilities in the dockerfile dependencies of this project.
Keeping your Docker base image up-to-date means you’ll benefit from security fixes in the latest version of your chosen image.
Snyk changed the following file(s):

tool/codegen/Dockerfile

We recommend upgrading to golang:1.22.5, as this image has only 89 known vulnerabilities. To do this, merge this pull request, then verify your application still works as expected.
Vulnerabilities that will be fixed with an upgrade:

Issue
Score

Link Following SNYK-DEBIAN12-GIT-6846203
  500

Link Following SNYK-DEBIAN12-GIT-6846203
  500

Integer Overflow or Wraparound SNYK-DEBIAN12-ZLIB-6008963
  500

CVE-2024-37370 SNYK-DEBIAN12-KRB5-7411314
  364

CVE-2024-37371 SNYK-DEBIAN12-KRB5-7411315
  364

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
Max score is 1000. Note that the real score may have changed since the PR was raised.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Learn about vulnerability in an interactive lesson of Snyk Learn.

https://github.com/pipe-cd/pipecd/pull/5138 is newer.


explicitly mocking 'fs' module

should  explicitly mock node module from  0.3.0  ?
Get this information from example.

Thank you! I'm currently rewriting all docs fort he 0.9.0 release so I can't merge this right now but I'll include your suggestions.

@cpojer  Its cool, im try to learn jest these days. When will the new docs release?
Thank you ,this is really a great news!

whenever 0.9.0 is ready :) It'll be soon!

:D


Determine how to manage public keys on CNS

Questions/considerations:

Should we store signatures or directly store public keys?
Should they be stored as text records, or in dedicated record types?
Make sure the approach is compatible #29

Superseded by #88


Proper doc about packaging the apps and deployment

Is this a bug report?
This is not an issue.
There is a ton of example how to use the react native components but there is no doc how to package the code and deploy it. Mainly there is no doc about
react-native bundle
So please add doc for it or if anybody knows good resource for it then please share it

Have you read the Contributing Guidelines?
Yes I read it
Environment

Steps to Reproduce
Expected Behavior
Actual Behavior
Reproducible Demo

Hey! Thanks for the feedback. Our docs are now over at https://github.com/facebook/react-native-website, would you mind moving the suggestion over there?


Question. use For Bot Mod?

I wanna just use this with friends now adays and that means using for bot overhaul mod, But since i open it, it lauches default tf2. I was wondering if there was a way to change what it opens/ Aka the launcher for the overhaul mod.

the fedoraware dll does not open tf2, if you're using fedoraloader and dont want it to launch tf2 then why are you using fedoraloader?

I do use it with tf2. I just wanna goof around time to time


[logstash] fix version in security test

This commit fixes the expected version in security goss test.

jenkins test this please


Merge tag 'swift-DEVELOPMENT-SNAPSHOT-2019-10-31-a' into tensorflow

@swift-ci Please clean test tensorflow

I just launched a toolchain build for this branch. Let's see what happens with that. Otherwise, looks good!

I just launched a toolchain build for this branch. Let's see what happens with that. Otherwise, looks good!

./swift/utils/build-toolchain-tensorflow -t on Ubuntu failed for me during LLDB tests:
Failing Tests (35):
    LLDB :: Reproducer/Swift/TestBridging.test
    LLDB :: Reproducer/Swift/TestModule.test
    LLDB :: Reproducer/Swift/TestSimple.test
    LLDB :: Swift/No.swiftmodule.test
    LLDB :: Swift/astcontext_error.test
    LLDB :: Swift/cond-breakpoint.test
    LLDB :: Swift/global.test
    LLDB :: SwiftREPL/Basic.test
    LLDB :: SwiftREPL/Class.test
    LLDB :: SwiftREPL/ComputedProperties.test
    LLDB :: SwiftREPL/CrashArgs.test
    LLDB :: SwiftREPL/Deadlock.test
    LLDB :: SwiftREPL/Dict.test
    LLDB :: SwiftREPL/ErrorReturn.test
    LLDB :: SwiftREPL/ExclusivityREPL.test
    LLDB :: SwiftREPL/GenericTypealias.test
    LLDB :: SwiftREPL/Generics.test
    LLDB :: SwiftREPL/MetatypeRepl.test
    LLDB :: SwiftREPL/Optional.test
    LLDB :: SwiftREPL/OptionalUnowned.test
    LLDB :: SwiftREPL/PropertyWrapperPrivate.test
    LLDB :: SwiftREPL/PropertyWrapperPublic.test
    LLDB :: SwiftREPL/PropertyWrapperTopLevel.test
    LLDB :: SwiftREPL/RecursiveClass.test
    LLDB :: SwiftREPL/Redefinition.test
    LLDB :: SwiftREPL/SimpleExpressions.test
    LLDB :: SwiftREPL/Struct.test
    LLDB :: SwiftREPL/Subclassing.test
    LLDB :: SwiftREPL/SwiftInterface.test
    LLDB :: SwiftREPL/SwiftInterfaceForceModuleLoadMode.test
    LLDB :: SwiftREPL/SwiftTypeLookup.test
    LLDB :: SwiftREPL/UninitVariables.test
    LLDB :: SwiftREPL/ZeroSizeStruct.test
    LLDB :: SwiftREPL/enum-singlecase.test
    LLDB :: SwiftREPL/one-char-string.test

Full log for building LLDB here.
Many tests are unresolved with this error:
UNRESOLVED: lldb-Suite :: lang/swift/anytype_array/TestAnyTypeArray.py (29 of 300)
******************** TEST 'lldb-Suite :: lang/swift/anytype_array/TestAnyTypeArray.py' FAILED ********************
Unable to find 'RESULT: PASSED' in dotest output (exit code 1):

lldb version 7.0.0 (https://github.com/apple/llvm-project.git revision bd31d693aabf94c5d68480408d9a1752ed900ea4)
Swift version 5.1.1-dev (Swift 012b9929e5)
LLDB library dir: /home/danielzheng/swift-merge2/build/buildbot_linux/lldb-linux-x86_64/bin
LLDB import library dir: /home/danielzheng/swift-merge2/build/buildbot_linux/lldb-linux-x86_64/bin
Traceback (most recent call last):
  File "/home/danielzheng/swift-merge2/lldb/test/dotest.py", line 7, in <module>
    lldbsuite.test.run_suite()
  File "/home/danielzheng/swift-merge2/llvm-project/lldb/packages/Python/lldbsuite/test/dotest.py", line 941, in run_suite
    import lldb
  File "/home/danielzheng/swift-merge2/build/buildbot_linux/lldb-linux-x86_64/lib/python3.7/site-packages/lldb/__init__.py", line 38, in <module>
    from . import _lldb
ImportError: dynamic module does not define init function (init_lldb)

I won't investigate these LLDB issues further, but I will report results for macOS:

./swift/utils/build-toolchain-tensorflow --pkg
./swift/utils/build-toolchain-tensorflow -t --pkg

Downstream repo tests reveal some additional errors that I'll investigate.
swift-apis:
[91/93] Compiling FastaiNotebook_07_batchnorm 07_batchnorm.swift
/fastai_dev/swift/FastaiNotebook_07_batchnorm/Sources/FastaiNotebook_07_batchnorm/07_batchnorm.swift:209:26: error: circular reference
    @noDerivative public var delegates: [(Self.Output) -> ()] = []
                         ^
/fastai_dev/swift/FastaiNotebook_07_batchnorm/Sources/FastaiNotebook_07_batchnorm/07_batchnorm.swift:209:30: note: through reference here
    @noDerivative public var delegates: [(Self.Output) -> ()] = []
                             ^
/fastai_dev/swift/FastaiNotebook_07_batchnorm/Sources/FastaiNotebook_07_batchnorm/07_batchnorm.swift:209:30: note: through reference here
    @noDerivative public var delegates: [(Self.Output) -> ()] = []
                             ^
/fastai_dev/swift/FastaiNotebook_07_batchnorm/Sources/FastaiNotebook_07_batchnorm/07_batchnorm.swift:219:6: note: through reference here
    @differentiable
     ^
/fastai_dev/swift/FastaiNotebook_07_batchnorm/Sources/FastaiNotebook_07_batchnorm/07_batchnorm.swift:154:19: warning: 'Raw' is deprecated: 'Raw' has been renamed to '_Raw' to indicate that it is not a guaranteed/stable API.
        let ret = Raw.fusedBatchNormV2(
                  ^
/fastai_dev/swift/FastaiNotebook_07_batchnorm/Sources/FastaiNotebook_07_batchnorm/07_batchnorm.swift:154:19: note: use '_Raw' instead
        let ret = Raw.fusedBatchNormV2(
                  ^~~
                  _Raw
/fastai_dev/swift/FastaiNotebook_07_batchnorm/Sources/FastaiNotebook_07_batchnorm/07_batchnorm.swift:175:27: warning: 'Raw' is deprecated: 'Raw' has been renamed to '_Raw' to indicate that it is not a guaranteed/stable API.
                let res = Raw.fusedBatchNormGradV2(
                          ^
/fastai_dev/swift/FastaiNotebook_07_batchnorm/Sources/FastaiNotebook_07_batchnorm/07_batchnorm.swift:175:27: note: use '_Raw' instead
                let res = Raw.fusedBatchNormGradV2(
                          ^~~
                          _Raw
<unknown>:0: error: type of expression is ambiguous without more context

swift-quotes:
Test Case 'StructureTests.testThrow' started at 2019-11-05 20:35:47.228
/swift/Tests/QuoteTests/StructureTests.swift:449: error: StructureTests.testThrow : XCTAssertEqual failed: ("Closure(
  [],
  [Throw(
    Conversion(
      Call(
        Name(
          "X",
          "<unstable USR>",
          FunctionType(
            [],
            [],
            TypeName("X", "<unstable USR>"))),
        [],
        [],
        TypeName("X", "<unstable USR>")),
      TypeName("Error", "s:s5ErrorP")))],
  FunctionType(
    [],
    [],
    TupleType(
      [])))") is not equal to ("Closure(
  [],
  [Throw(
    Conversion(
      Call(
        Name(
          "X",
          "",
          FunctionType(
            [],
            [],
            TypeName("X", "<unstable USR>"))),
        [],
        [],
        TypeName("X", "<unstable USR>")),
      TypeName("Error", "s:s5ErrorP")))],
  FunctionType(
    [],
    [],
    TupleType(
      [])))") -
Test Case 'StructureTests.testThrow' failed (0.0 seconds)

@swift-ci please test tensorflow

@swift-ci please test tensorflow

@swift-ci please clean test tensorflow


Fix "contributing" link in README.md

We fix a broken link in the toplevel README.md,  namely the one to the CONTRIBUTING.md
Fixes #321

Approved as by this comment in the original issue.


Add staging signing config

closes #27

The release build type is now signed with the keystore added to the org secret
Added another unsigned build type so we still have an unsigned artifact

You can this this in your own repo when using the same keys like this:

Can be tested locally when adding e.g. the following to the local.properties:
release.keystore.path=.android/debug.keystore
release.keystore.key.alias=androiddebugkey
release.keystore.key.password=android
release.keystore.store.password=android
Docs for composite action:
https://docs.github.com/en/actions/creating-actions/creating-a-composite-action
Added GitHub action for decoding the base64 keystore file:
https://github.com/timheuer/base64-to-file

@SebastianSchildt
PR can be merged


x/pkgsite: Functions grouped under type even though not methods

What is the URL of the page with the issue?
https://pkg.go.dev/github.com/maragudk/gomponents
What is your user agent?
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.1 Safari/605.1.15
Screenshot

What did you do?
Just visited the page.
What did you expect to see?
I expected to see package-level functions like Attr and Map (under Node) and El (under NodeFunc) listed as separate functions for the package. I would expect the functions with the receivers to be shown as methods, and the other functions shown under package-level functions.
What did you see instead?
The functions are grouped with the methods of the types, even though they are not methods themselves, but just return the type.

Duplicate of #39813


Add telemetry for rule_types

Please describe the enhancement
Currently we only have telemetry for the number of profiles with the entity types as labels. It would be nice to get telemetry for rule_types too to see what rules are being used, but for that it would be nice to distinguish between those that we support and "others".
Solution Proposal
The rules that we support are in a separate repository. We could read them and have a go-generate script that populates a slice of the supported rule_types. Then any that would be in that slice could be added as labels, others would be marked as others.
Describe alternatives you've considered
No response
Additional context
No response
Acceptance Criteria
As a minder administrator, I want to get an overview of what rules types are being used.

I think this use case was better covered by telemetry


[BUG] Docker image jre-jammy contains Berkeley DB

Describe the bug
The switch to Docker base image "eclipse-temurin:17-jre-jammy" introduced in #3355 adds BerkeleyDB to the image (libdb5.3_5.3.28+dfsg1-0.8ubuntu3_amd64.deb). Berkeley DB is dual license, either Oracle commercial license or GNU AGPL v3 [1]. Both licenses types are problematic for distribution and SaaS deployments.
To Reproduce
Either use a package scanning tool e.g Mend or ssh into a running container and use the package tool.
Environment (please complete the following information):

Version 2.5.0

Additional context
The change was introduced by #3355.
[1] https://en.wikipedia.org/wiki/Berkeley_DB#Licensing

@KarstenSchnitter , Thank you for reporting this. We are looking to move toward Amazon Linux in 2.6.0. I'd appreciate your thoughts on this. Please see #3505.

This is fixed by #3671 which changes the base image to Amazon Linux 2023.


Update to .Net 6.0 and clean up code style violations

Summary
Change .Net version to 6.0 and cleanup all the code style issues exposed by Visual Studio 2022

Thank you


Make intersphinx useful

Currently intersphinx is added in conf.py but it is pretty useless as packages cannot configure it.
Possible solution:
Packages can provide an optional file conf_ext.py which gets appended at the end of conf.py before building the documentation.
In this file, packages can provide their intersphinx config.
It would also allow adding other configuration or overwrite existing values if needed, so it would add quite a bit of flexibility.

As support for a TOML config file is added in #14, rather use that instead of a conf_ext.py (see also proposed config structure in #13).


Split feature flags into multiple files

Description
To reduce unnecessary manual conflict resolving during rebases/merges, the idea is to split the feature flags into files, one feature flag per file.
WDYT?
The same method could also be applied to pkg/centralsensor/caps_list.go.

We could also sort the feature flags alphabetically instead of appending to the end of the file. This way new changes don't clump at the bottom of the file. Then merge conflicts would only arise if feature flags are next to each other.


Android: Text ellipsizeMode="clip" crashes on Android

[x] I have reviewed the documentation
[x] I have searched existing issues
[x] I am using the latest React Native version

Environment
Environment:
OS:  macOS High Sierra 10.13.3
Node:  9.0.0
Yarn:  1.3.2
npm:  5.5.1
Watchman:  4.7.0
Xcode:  Xcode 9.2 Build version 9C40b
Android Studio:  3.0 AI-171.4408382
Packages: (wanted => installed)
react: 16.2.0 => 16.2.0
react-native: ^0.54.2 => 0.54.2
Steps to Reproduce

Use a <Text /> component
Set ellipsizeMode to "clip"

Expected Behavior
While the documentation clearly states clip is working only for iOS I assumed this will have no effect on Android.
Actual Behavior
Causes an exception manifesting as a crash inside the app:
RuntimeException com.facebook.react.bridge.JSApplicationIllegalArgumentException: Error while updating property 'ellipsizeMode' of a view managed by: RCTText
com.facebook.react.bridge.ReactContext in handleException at line 313
com.facebook.react.uimanager.GuardedFrameCallback in doFrame at line 33
com.facebook.react.modules.core.ReactChoreographer$ReactChoreographerDispatcher in doFrame at line 136
com.facebook.react.modules.core.ChoreographerCompat$FrameCallback$1 in doFrame at line 107
android.view.Choreographer$CallbackRecord in run at line 909
android.view.Choreographer in doCallbacks at line 723
android.view.Choreographer in doFrame at line 655
android.view.Choreographer$FrameDisplayEventReceiver in run at line 897
android.os.Handler in handleCallback at line 790
android.os.Handler in dispatchMessage at line 99
android.os.Looper in loop at line 164
android.app.ActivityThread in main at line 6494
java.lang.reflect.Method in invoke
com.android.internal.os.RuntimeInit$MethodAndArgsCaller in run at line 438
com.android.internal.os.ZygoteInit in main at line 807

We should make this clearer in the docs. Can you open an issue at https://github.com/facebook/react-native-website instead?
Closing as clip is a iOS-only prop.

I strongly disagree. Setting a property on a component should not crash the app in the first place.

Let us know if you have a PR that changes this behavior.

Hi there! I just sent a PR with the fix for this issue, hope it helps!

@t4deu maybe just ignoring the property is the more 'expected' behavior.

Hi @borisyankov, the default tail is applied even if the value be ignored, I think the change just made the result more explicit instead of another if else block. But we can change that :wink:.

Is this fixed? I still get error
Environment:
OS: macOS High Sierra 10.13.5
Node: 8.9.4
Yarn: 1.6.0
npm: 5.6.0
Watchman: 4.9.0
Xcode: Xcode 9.4.1 Build version 9F2000
Android Studio: 3.1 AI-173.4720617
Packages: (wanted => installed)
react: 16.3.1 => 16.3.1
react-native: 0.55.4 => 0.55.4

@codler it was fixed in master three months ago. You’re using 0.55 which does not have this fix. Try the 0.56 release.

@hramos When is 0.56 going to be released?

Today 👍

@codler: https://github.com/facebook/react-native/blob/master/Releases.md#release-schedule


E4-Standard shape is sometimes failing for free account

Currently, the shape is set to VM.Standard.E4.Flex and I get an "out of host capacity" error.
While the same works for VM.Standard.E3.Flex.
It is not a quota issue (at least not from the quota screen). It looks like a limit that is reached by the datacenter.

Current WA, back to the default of E3.Flex


Waffle Switch appears to toggle on/off during page refreshes

We have implemented a basic waffle switch and have used waffle_tags in the html to show/hide a form question.
What we are experiencing is that when the switch is toggled there is a period of time that when you F5/refresh the page the question shows/hides. My assumption is that something is caching the switch but this seems like odd behaviour.
Our AWS setup using the same conifg as found here http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create-deploy-python-container.html
We have been using the admin screen to toggle the switch on/off.
We have no custom waffle settings.
Django version : 1.10.1
Waffle version : 12.0
Any ideas?

What kind of cache setting are you using?

These are the two settings which we have tweaked:
waffle = Settings(
    WAFFLE_OVERRIDE=False,
    WAFFLE_READ_FROM_WRITE_DB=True
)

I have tried changing WAFFLE_READ_FROM_WRITE_DB with no change either way

Thanks for the info 👍

Sure thing, hope that helps!


Finish flag

Flag Interaction Finished
Task Level: Easy
Detail:
1.When player reach the fFlag triggers the player winning state
2.Defining the behaviours of player wining state
3.text info for getting to next level


Fixes bugs causing tests in PlaintextAsyncConsumer to flake or fail

This change fixes several tests in PlaintextAsyncConsumer that were flaky, allowing the @Disabled annotation to be removed for the following:
A lot of the changes in this commit are due to the FetchConfig and FetchBuffer no longer needing type parameterization. Thus all the type parameters in the users of either of these classes needed to be changed to omit them as well.

testHeaders
testHeadersSerializerDeserializer
testPositionAndCommit
testConsumeMessagesWithLogAppendTime
testPerPartitionLeadWithMaxPollRecords
testQuotaMetricsNotCreatedIfNoQuotasConfigured
testConsumingWithNullGroupId

There were three causes for the flakiness:
Use of the incorrect deserializer
Since the background thread doesn't perform deserialization, it doesn't need a Deserializer. So the background thread includes a "dummy" Deserializer in the FetchConfig that it creates. However, when the background thread created  CompletedFetch instances based on fetches, it stored a reference to the FetchConfig that includes the dummy Deserializer instance. When the CompletedFetch later converted its data into the ConsumerRecord, it attempted to use the dummy Deserializer, which threw errors.
The fix here is to remove the reference to the FetchConfig (which includes the Deserializer) and pass in the config at the point when we're creating the ConsumerRecord instances.
Node reconnection was not attempted for offsets
The testPositionAndCommit test had a timing issue where it would enter an infinite loop, unable to fetch any data. The reason for this boiled down to a difference between the offset management in OffsetFetcher and OffsetsRequestManager. When a given node did not have a NodeApiVersions object, the former class would attempt to connect to the node, whereas the latter did not. Without this node reconnection attempt, the OffsetsRequestManager forever considered the broker node down, never attempting to connect to it to handle the offset logic needed for fetch. Thus fetch would never be attempted for that node.
The fix was to reuse the node reconnection logic from OffsetFetcher in OffsetsRequestManager. One minor difference is that the latter doesn't immediately attempt to reconnect; it notes the reconnect attempt and it is performed before the next call to NetworkClient.poll().
This only affected the testPositionAndCommit test as it uses multiple Consumer instances and there was no previous network activity on the consumer to the node.
Fetch timeout issues
At the end of PrototypeAsyncConsumer.pollForFetches, a blocking call for a FetchEvent is issued. This is an attempt to load any buffered fetch data that was previously retrieved for the poll() call. However, if no data is available within the timeout, another pass should be made to wait for the data. However, the error was that the timeout was not caught, causing the exception to propagate all the way up to the user.
The fix is to surround the FetchEvent call with a try/catch block that catches the timeout and lets processing continue. It's OK to catch the timeout as the calling method (poll()) checks that there is remaining time on the timer before looping again.

Thanks for the PR, very good improvements. LGTM. Just to double check, with these changes do all the previously flaky integration test pass consistently?

Yes.


AttributeError: module 'config' has no attribute 'cid'

Hello, @shreyaspj20
There was an error in code. please help me to solve this. why it is saying module 'config' has no attribute 'cid'

Traceback (most recent call last):
File ".\run.py", line 15, in
client_credentials_manager = SpotifyClientCredentials(client_id=config.cid, client_secret=config.secret)
AttributeError: module 'config' has no attribute 'cid'

@shreyaspj20 bro Thanks it's working fine now ❤❤