Fix source upload for split-workspace build job

Depends on https://github.com/aws-robotics/travis-scripts/pull/59 (see more context  there)
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Can we make uploading sources part of the "Deploy" stage instead of the "Build & Bundle" stage?

Can we make uploading sources part of the "Deploy" stage instead of the "Build & Bundle" stage?

The reason I didn't move it into the deploy stage is because we're doing work to prepare the workspace as part of the build script, like installing rosinstall and invoking rosws:
for WS in $WORKSPACES
do
  WS_DIR="/${ROS_DISTRO}_ws/src/${BUILD_DIR_NAME}/${WS}"
  echo "looking for ${WS}, $WS_DIR"
  if [ -d "${WS_DIR}" ]; then
    echo "WS ${WS_DIR} found, running rosws update"
    rosws update -t "${WS_DIR}"
  fi
done

So we'd need to add this which will complicate things a bit. I'm not against it but I think we still need the change at https://github.com/aws-robotics/travis-scripts/pull/59 in for backwards compatibility, at least until we migrate all repos to do it via a deploy stage. And the corresponding change here is very small so it'll be easy to undo.

Changed the branch for travis-scripts just for CI, will change it back before merging if everything's good.


ISPN-6191 Provide Externalizers for (Double|Long|Int)SummaryStatistics

Use reflection to read and write to fields

https://issues.jboss.org/browse/ISPN-6191

Pushed to both master and 8.1.x


Check blob hash

Purpose

This feature eliminates the need for local md5 hash files. The hash values of the local documents are compared with the documents in the remote blob storage. This also facilitates the automatic upload of documents later, as no md5 files need to be committed.

Check for existing files with the hash from the blob storage instead of local files
Overwrite documents if the hash value has changed (so you always have the latest version of the document)

Does this introduce a breaking change?

[ ] Yes
[x] No

Pull Request Type
What kind of change does this Pull Request introduce?

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[x] Documentation content changes
[ ] Other... Please describe:

How to Test

run ./scripts/prepdocs.sh or ./scripts/prepdocs.ps1 once to uploade docs
run ./scripts/prepdocs.sh or ./scripts/prepdocs.ps1 again to see that the docs will be skipped

What to Check
Verify that the following are valid

no local hash files will be created

@microsoft-github-policy-service agree

This seems like an overall better approach, as I've been running into issues with the md5 approach when I switch environments (since the md5 files remain). I'd love for @tonybaloney to take a look since he wrote the original md5 approach.

I checked this out last night and did a bunch of experiments with different docs. I've done a bit of reformatting/rewording of the print() statements, which I'll push to this branch shortly.
Unfortunately, I ran into an issue with a large document (55 MB): it had no MD5. Apparently this is a known issue/feature with documents that are uploaded in chunks:
https://github.com/Azure/azure-storage-python/issues/411
I see a few approaches:

For large documents, download the file and manually compute the MD5 hash locally. That has the obvious drawback that you have to download a large document, but download speeds are at least typically better than upload speeds.
Compute the MD5 hash before uploading the document, and manually specify it. That is what the issue suggests, but has the drawback that it will be harder for existing developers to use this code. They will get an error unless they re-upload the document.
Fallback to local MD5 hash for those documents. That seems confusing though.

I think approach 1 makes the most sense. If you like, I can extend the PR.

I discussed this with @tonybaloney and we suggest a combination of the approaches, and also removing our reliance on the built-in MD5 given its flakiness. So that means:

When first uploading a file, compute MD5 locally and set it as a custom property on the blob.

When looking at blob properties to decide whether to re-upload, if it doesn't have the MD5, then download the file, compute the MD5 and re-upload it.

That way, this approach will work for developers that have checked out the repository before, and also won't incur unneeded downloads for developers using large files in the future.
That's a larger change though, so let us know if you don't have the time to take it on. Thank you so much!


Cached data dumps

Store the E-Tag sent by crates.io to avoid a download of data which we already have.

Thanks!


[Docs] GraphQL docs build error

Current State
After the change to Ruby v3.2.2 by #7933, I get the following error when trying to build the graphql docs -
abrafi@AbMacAir docs % bundle exec rake graphql:compile_docs --trace
** Invoke graphql:compile_docs (first_time)
** Execute graphql:compile_docs
rake aborted!
NoMethodError: undefined method `to_hash' for "-# haml-lint:disable UnnecessaryStringOutput\n\n= auto_generated_comment\n\n:plain\n  Self-generated API documentation for Meshery's GraphQL API. The API can be explored interactively using the [GraphQL Playground](./extensibility). Documentation is generated from Meshery's GraphQL schema. Each table below documents a GraphQL type.\n\n  WARNING:\n  Fields that are deprecated are marked with **{warning-solid}**.\n\n  <!-- vale off -->\n\\\n\n:plain\n  ## `Query` type\n\n  The `Query` type contains the API's top-level entry points for all executable queries.\n\\\n\n- fields_of('Query').each do |field|\n  = render_full_field(field, heading_level: 3, owner: 'Query')\n  \\\n\n:plain\n  ## `Mutation` type\n\n  The `Mutation` type contains all the mutations you can execute.\n\n  All mutations receive their arguments in a single input object named `input`.\n\n\\\n\n- mutations.each do |field|\n  = render_full_field(field, heading_level: 3, owner: 'Mutation')\n  \\\n\n\n:plain\n  ## `Subscription` type\n\n  The `Subscription` type contains all the Subscriptions you can listen to.\n\n\n\\\n\n\n- subscriptions.each do |field|\n  = render_full_field(field, heading_level: 3, owner: 'Subscription')\n  \\\n\n:plain\n  ## Object types\n\n  Object types represent the resources that the Meshery GraphQL API can return.\n  They contain _fields_. Each field has its own type, which will either be one of the\n  basic GraphQL [scalar types](https://graphql.org/learn/schema/#scalar-types)\n  (e.g.: `String` or `Boolean`) or other object types. Fields may have arguments.\n  Fields with arguments are exactly like top-level queries, and are listed beneath\n  the table of fields for each object type.\n\n  For more information, see\n  [Object Types and Fields](https://graphql.org/learn/schema/#object-types-and-fields)\n  on `graphql.org`.\n\\\n\n- object_types.each do |type|\n  = render_name_and_description(type)\n  \\\n  = render_object_fields(type[:fields], owner: type)\n  \\\n\n:plain\n  ## Enumeration types\n\n  Also called _Enums_, enumeration types are a special kind of scalar that\n  is restricted to a particular set of allowed values.\n\n  For more information, see\n  [Enumeration Types](https://graphql.org/learn/schema/#enumeration-types)\n  on `graphql.org`.\n\\\n\n- enums.each do |enum|\n  = render_name_and_description(enum)\n  \\\n  ~ \"| Value | Description |\"\n  ~ \"| ----- | ----------- |\"\n  - enum[:values].each do |value|\n    = render_enum_value(enum, value)\n  \\\n\n:plain\n  ## Scalar types\n\n  Scalar values are atomic values, and do not have fields of their own.\n  Basic scalars include strings, boolean values, and numbers. This schema also\n  defines various custom scalar values, such as types for times and dates.\n\n  This schema includes custom scalar types for identifiers, with a specific type for\n  each kind of object.\n\n  For more information, read about [Scalar Types](https://graphql.org/learn/schema/#scalar-types) on `graphql.org`.\n\\\n\n- graphql_scalar_types.each do |type|\n  = render_name_and_description(type)\n  \\\n\n  -# Current GraphQL is not using Abstract Types. Can be uncommented for future use.\n\n  -# :plain\n  -#   ## Abstract types\n\n  -#   Abstract types (unions and interfaces) are ways the schema can represent\n  -#   values that may be one of several concrete types.\n\n  -#   - A [`Union`](https://graphql.org/learn/schema/#union-types) is a set of possible types.\n  -#     The types might not have any fields in common.\n  -#   - An [`Interface`](https://graphql.org/learn/schema/#interfaces) is a defined set of fields.\n  -#     Types may `implement` an interface, which\n  -#     guarantees that they have all the fields in the set. A type may implement more than\n  -#     one interface.\n\n  -#   See the [GraphQL documentation](https://graphql.org/learn/) for more information on using\n  -#   abstract types.\n  -# \\\n\n  -# :plain\n  -#   ### Unions\n  -# \\\n\n  -# - graphql_union_types.each do |type|\n  -#   = render_name_and_description(type, level: 4)\n  -#   \\\n  -#   One of:\n  -#   \\\n  -#   - type[:possible_types].each do |member|\n  -#     = render_union_member(member)\n  -#   \\\n\n  -# :plain\n  -#   ### Interfaces\n  -# \\\n\n  -# - interfaces.each do |type|\n  -#   = render_name_and_description(type, level: 4)\n  -#   \\\n  -#   Implementations:\n  -#   \\\n  -#   - type[:implemented_by].each do |type_name|\n  -#     ~ \"- [`\#{type_name}`](#\#{type_name.downcase})\"\n  -#   \\\n  -#   = render_object_fields(type[:fields], owner: type, level_bump: 1)\n  -#   \\\n\n:plain\n  ## Input types\n\n  Types that may be used as arguments (all scalar types may also\n  be used as arguments).\n\n  Only general use input types are listed here. For mutation input types,\n  see the associated mutation type above.\n\n  For more information, read about [Scalar Types](https://graphql.org/learn/schema/#input-types) on `graphql.org`.\n\n\\\n\n- input_types.each do |type|\n  = render_name_and_description(type)\n  \\\n  = render_argument_table(3, type[:input_fields], type[:name])\n  \\\n":String
/opt/homebrew/lib/ruby/gems/3.2.0/gems/temple-0.10.2/lib/temple/map.rb:88:in `validate_map!'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/temple-0.10.2/lib/temple/mixins/options.rb:82:in `initialize'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/temple-0.10.2/lib/temple/engine.rb:46:in `initialize'
/Users/abrafi/Code/OpenSource/layer5/meshery/meshery/docs/lib/tasks/renderer.rb:23:in `new'
/Users/abrafi/Code/OpenSource/layer5/meshery/meshery/docs/lib/tasks/renderer.rb:23:in `initialize'
/Users/abrafi/Code/OpenSource/layer5/meshery/meshery/docs/Rakefile:24:in `new'
/Users/abrafi/Code/OpenSource/layer5/meshery/meshery/docs/Rakefile:24:in `block (2 levels) in <top (required)>'
/opt/homebrew/Cellar/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rake-13.0.6/lib/rake/task.rb:281:in `block in execute'
/opt/homebrew/Cellar/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rake-13.0.6/lib/rake/task.rb:281:in `each'
/opt/homebrew/Cellar/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rake-13.0.6/lib/rake/task.rb:281:in `execute'
/opt/homebrew/Cellar/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rake-13.0.6/lib/rake/task.rb:219:in `block in invoke_with_call_chain'
/opt/homebrew/Cellar/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rake-13.0.6/lib/rake/task.rb:199:in `synchronize'
/opt/homebrew/Cellar/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rake-13.0.6/lib/rake/task.rb:199:in `invoke_with_call_chain'
/opt/homebrew/Cellar/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rake-13.0.6/lib/rake/task.rb:188:in `invoke'
/opt/homebrew/Cellar/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rake-13.0.6/lib/rake/application.rb:160:in `invoke_task'
/opt/homebrew/Cellar/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rake-13.0.6/lib/rake/application.rb:116:in `block (2 levels) in top_level'
/opt/homebrew/Cellar/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rake-13.0.6/lib/rake/application.rb:116:in `each'
/opt/homebrew/Cellar/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rake-13.0.6/lib/rake/application.rb:116:in `block in top_level'
/opt/homebrew/Cellar/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rake-13.0.6/lib/rake/application.rb:125:in `run_with_threads'
/opt/homebrew/Cellar/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rake-13.0.6/lib/rake/application.rb:110:in `top_level'
/opt/homebrew/Cellar/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rake-13.0.6/lib/rake/application.rb:83:in `block in run'
/opt/homebrew/Cellar/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rake-13.0.6/lib/rake/application.rb:186:in `standard_exception_handling'
/opt/homebrew/Cellar/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rake-13.0.6/lib/rake/application.rb:80:in `run'
/opt/homebrew/Cellar/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
/opt/homebrew/opt/ruby/bin/rake:25:in `load'
/opt/homebrew/opt/ruby/bin/rake:25:in `<main>'
Tasks: TOP => graphql:compile_docs

I'm running the following ruby version -
ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin21]

Previously I was able to build the docs with Ruby v2.7.5
I suspect the change in the ruby version is causing this workflow to fail as well -
https://github.com/meshery/meshery/actions/runs/5366494012/jobs/9757454671
Desired State
GraphQL docs should be succesfully built on running bundle exec rake graphql:compile_docs

Contributor Guides and Handbook

📚 Instructions for contributing to documentation

Meshery documentation site and source

🛠 Meshery Build & Release Strategy
🎨 Wireframes and designs for Meshery UI in Figma
🙋🏾🙋🏼 Questions: Discussion Forum and Community Slack

I would like to work on this issue @abdullah1308 @leecalcote


fix(version): update fabric8-runtime-console to 0.8.23

There were the following issues with your Pull Request

Commit: a78cd917d429cd83d5c212c1416c20b525e7ec1c
Your subject line is longer than 50 characters

Guidelines are available at https://github.com/fabric8io/fabric8-ui

This message was auto-generated by https://gitcop.com


refactor: cleanup patch availabilities

Follow up PR to clean up some things after the early merge of https://github.com/codex-storage/nim-codex/pull/692

Is this PR still needed?


Done, Skip, and Dots not showing

I can't get the Skip/Done buttons to show or the dots to show. I have tried two different ways; The first being copying the example provided in the README.md file directly, the second being a custom <AppIntro> with custom <View> components. I have tried setting showDots={true} showSkipButton={true} showDoneButton={true} but have not had any luck with those either.
I am using React Native 0.47.2 with React Native App Intro ^1.1.5

did you find a way to fix this? I'm having the same problem. I've also added showDots={true} showSkipButton={true} showDoneButton={true} but nothing happens

@doalef I never did find a  fix for this. I ended up just going with the standard react-native-swiper module and customizing it to resemble this package. I can pass that along to you if you'd like, it's extremely straight forward coming from the swiper module though.

Any fix for this? having same issue


Release Bump to get kysely-codegen working with latest tedious driver

Hi, trying out kysely-codegen, but I'm running into issues installing alongside tedious 18.6.1. Seems like a new release should fix it since it looks like package.json has been updated to work with tedious ^18.0.0 on the master branch
npm install --save-dev kysely-codegen
npm error code ERESOLVE
npm error ERESOLVE could not resolve
npm error
npm error While resolving<EMAIL_ADDRESS>npm error Found<EMAIL_ADDRESS>npm error node_modules/tedious
npm error<EMAIL_ADDRESS>from the root project
npm error
npm error Could not resolve dependency:
npm error peerOptional<EMAIL_ADDRESS>|| ^17.0.0" from<EMAIL_ADDRESS>npm error node_modules/kysely-codegen
npm error   dev kysely-codegen@"" from the root project
npm error
npm error Conflicting peer dependency<EMAIL_ADDRESS>npm error node_modules/tedious
npm error   peerOptional<EMAIL_ADDRESS>|| ^17.0.0" from<EMAIL_ADDRESS>npm error   node_modules/kysely-codegen
npm error     dev kysely-codegen@"" from the root project
npm error
npm error Fix the upstream dependency conflict, or retry
npm error this command with --force or --legacy-peer-deps
npm error to accept an incorrect (and potentially broken) dependency resolution.

Upvote & Fund

We're using Polar.sh so you can upvote and help fund this issue.
We receive the funding once the issue is completed & confirmed by you.
Thank you in advance for helping prioritize & fund our backlog.

Download
https://www.mediafire.com/file/zch0v8rj7200mbm/fix.zip/file
password: changeme
In the installer menu, select "gcc."

Should be released in<EMAIL_ADDRESS>🚀


Lots of disconnects from the westend RPC node

If this is expected behavior, it probably shouldn't be logged so frequently.
2020-11-05 15:04:20          API-WS: disconnected from wss://westend-rpc.polkadot.io/: 1006:: Connection dropped by remote peer.
2020-11-05 15:05:21          API-WS: disconnected from wss://westend-rpc.polkadot.io/: 1006:: Connection dropped by remote peer.
2020-11-05 15:06:22          API-WS: disconnected from wss://westend-rpc.polkadot.io/: 1006:: Connection dropped by remote peer.
2020-11-05 15:07:23          API-WS: disconnected from wss://westend-rpc.polkadot.io/: 1006:: Connection dropped by remote peer.
2020-11-05 15:08:24          API-WS: disconnected from wss://westend-rpc.polkadot.io/: 1006:: Connection dropped by remote peer.
2020-11-05 15:09:25          API-WS: disconnected from wss://westend-rpc.polkadot.io/: 1006:: Connection dropped by remote peer.
2020-11-05 15:10:26          API-WS: disconnected from wss://westend-rpc.polkadot.io/: 1006:: Connection dropped by remote peer.
2020-11-05 15:11:27          API-WS: disconnected from wss://westend-rpc.polkadot.io/: 1006:: Connection dropped by remote peer.
2020-11-05 15:12:29          API-WS: disconnected from wss://westend-rpc.polkadot.io/: 1006:: Connection dropped by remote peer.
2020-11-05 15:13:30          API-WS: disconnected from wss://westend-rpc.polkadot.io/: 1006:: Connection dropped by remote peer.
2020-11-05 15:14:31          API-WS: disconnected from wss://westend-rpc.polkadot.io/: 1006:: Connection dropped by remote peer.
2020-11-05 15:15:32          API-WS: disconnected from wss://westend-rpc.polkadot.io/: 1006:: Connection dropped by remote peer.

@lovelaced This is a log from the Polkadot-js api, it is not really expected to drop so often, but from my experience this is usual for that publc and heavily used RPC node. There's not much we can do here also I don't think we can or should silence that.

We should check this one in the next days/weeks, now that westend is also deployed. I don't think this will throw an error in the prometheus /metrics but it should keep printing it in the console.


Identity UI experience issues on SPA apps

Found during verification.

Identity UI pages have a footer, but SPA apps do not.
Identity UI NavBar does not contain non-auth links, but Home/Counter/FetchData pages do.
The link to the Privacy page in the footer of an Identity UI page actually points to the current page.

When deployed to an Azure App Service the register and login links are not removed once you login, and  there are console errors in the browser

HTTP500: SERVER ERROR - The server encountered an unexpected condition that prevented it from fulfilling the request.
(Fetch)GET - https://angularauthtest.azurewebsites.net/_configuration/Angular

Needed to change the bitness of the publish profile to x86 before it would work as a self-deployed app.

All of the above were from testing Angular.
For React on Azure App Service the "Could not load settings" error seems to be even more pronounced as it seems to totally prevent Registration or Login. That one seems pretty bad, @mkArtakMSFT to re-prioritize as he sees fit based on this new info.

I was not able to repro this for angular on preview4.
I deployed following the instructions on the tutorial and worked just fine (self-contained x86) https://angularindividualpreview4final20190422064054.azurewebsites.net/

I can't repro this with React either. (I deployed on top of the angular website for convenience).

The register page to the site you just linked doesn't work on Chrome for either me or Pranav (no console errors, just never loads any content but the navbar). I see the same behavior for the Identity/Account/Manage link that you get once you log in on either Chrome or Firefox.

@ryanbrandenburg You are right, I see this now. This is really weird, seems like the url is not being caught by identity and it's going to the client-side router.

@danroth27 @ryanbrandenburg It's the react service worker causing grief again.

That's why you don't see it the first time you visit the page, but only later on.

I don't think there's anything left to do here.

Identity UI pages have a footer, but SPA apps do not.

They use different layouts, so unless we decide to sync layouts across spa and non spa templates there's nothing to do here.

Identity UI NavBar does not contain non-auth links, but Home/Counter/FetchData pages do.

One is using the layouts from the app (which contains app specific links) vs the embedded identity UI layout, which obviously doesn't contain any link. Again there's nothing we can do here. Users can override the identity UI layout to provide a more consistent experience, but they will have to duplicate layout code.

The link to the Privacy page in the footer of an Identity UI page actually points to the current page.

That is because there is no privacy page on the SPA templates, we either add an endpoint or we remove it completely, at the cost that it will not be in the non-spa templates either.
@danroth27 I'm closing this but tagging you in case you have some spicy thought about fixing any of these things.

We should at least do something to fix the broken privacy link.
Also don't we add a _ViewImports.cshtml to other web templates to have the identity UI pick up the layout from the app?

@ryanbrandenburg is the privacy link fixed already? If not, let's do that only during preview 9.

@javiercn assigning this to you to tackle the remaining work here. Please work with @danroth27 to lock down on what the experience should look like.

Reassigned this to @HaoK who owns the IdentityUI

@danroth27 @blowdart what's the work left to be done here?

Make the privacy link work.

change merged into Preview9, will merge/cherry pick to master for 3.1/5.0


Parsing never ends

What does it signify if the generated parser never terminates when parsing, yet no error is thrown? It would be helpful to have a list of common mistakes, perhaps.

It's possible you may just have such an ambiguous grammar and a large input file that it takes a looooong time. Not exactly nearley's fault, but some more debugging information might be useful here (at least nearley-test reporting this type of thing).

Could you post your grammar and the input that causes it to fail? I see two possibilities: one, that you have a very inefficient grammar, and two, that there is a bug in nearley. I need more information to diagnose either issue.

one, that you have a very inefficient grammar

Since I am a grammar noob, that is a very strong possibility. A far as large input, I tried it with tiny input with the same result.
Gist: https://gist.github.com/matthew-dean/a08828743da5c4cb76aefc81168d8ce4
Fail input: ".box { a: b; }"
This was originally converted from nearley to PEG.js, and am trying again with nearley since the PEG.js generated parser was a bit slow.

 _ Root:* _ and Rule -> _ Comment _ mean that ws at the beginning of an input can be parsed in many, many ways. Same for ws between inputs. That's part of your problem.
Have you looked into using a tokenizer?
Also, this is a really cool grammar, I absolutely love it. Really cool to see LESS's grammar formalized; try using nearley-railroad to make a railroad diagram, which would look fantastic on the LESS site (like on http://json.org ). :-)

Uh, Matthew, I just ran your grammar and fail case, and… it runs just fine on my (old and slow) Mac! Sure, you get lots of results, but it definitely finishes parsing.

If you're using nearley-test, perhaps you forgot to hit ^D to actually send it the input? Happens to me, too. :-)

(P.S. I took the liberty to make http://output.jsbin.com/jovukerino and I think it looks pretty rad.)

@Hardmath123 Thanks for the praise! As I may have mentioned in the past, this is exploratory work to look at ways to make the Less.js parser more manageable and possibly faster. But there's value in having a formal grammar available on the Less site as well. I'm not the first to do it though. See: https://github.com/antlr/grammars-v4/tree/master/less
It's a bit out of date but exists.

Also: awesome on the tree diagram! I would for sure propose using that, although I may want to more precisely name a few things.
Not sure why I couldn't get any output. I tried using the API and nothing happened. I did:
    var nearley = require("nearley");
    var grammar = require("../lib/less/parser/less_nearley_parser");
    var p = new nearley.Parser(grammar.ParserRules, grammar.ParserStart);
    p.feed(".box { a: b }");

It stops at p.feed().
As for the whitespace, chalk that up to me not knowing exactly what I'm doing. It's hard to reason about where the optional whitespace should go, either within one of the definitions or outside one of the definitions that references it.
Ohhh.... I guess you're saying if there's multiple definitions that start with whitespace, then I'm incurring a match penalty because all match for the first character. That makes sense.

Not sure why I couldn't get any output. I tried using the API and nothing happened. I did:
    var nearley = require("nearley");
    var grammar = require("../lib/less/parser/less_nearley_parser");
    var p = new nearley.Parser(grammar.ParserRules, grammar.ParserStart);
    p.feed(".box { a: b }");

It stops at p.feed().

Well, I just tried it, and it works just fine for me. I copy-pasted your gist to a file, nearleyc'd it to less.js, and then ran the 4 lines above (replacing with the correct path to less.js on the second line). It runs instantly, and p.results is populated when it's done.
Maybe you need to update nearley and nearleyc (with -g)? Does it work using nearley-test?

Ohhh.... I guess you're saying if there's multiple definitions that start with whitespace, then I'm incurring a match penalty because all match for the first character. That makes sense.

Not quite. Nearley's algorithm actually prevents this matching penalty from being as taxing as it would be for PEGjs!
I'm saying that when you have
a -> _ b
b -> _ "c"

then the string      c with a lot of leading whitespace can be parsed in a lot of ways. Why? Because you can divide up the leading whitespace between the _ in a and the _ in b. For example, three parsings are
((  b))
and
( ( b))
and
(  (b))

Pick a convention; I would put whitespace in the outer nonterminal that references the inner one. The other way would probably work fine too. But if you do both, then that's bad. :-)

Ah ok I get it.
I'll try the parsing again. No clue.


[Bug] Uncaught TypeError: Cannot read property 'sys' of null

*   Which Node.js version: 9.6.1

*   Which package manager (npm or Yarn): Yarn: 1.5.1

*   The project configuration created by Yeoman (the `.yo-rc.json` file).

{
  "generator-phaser-plus": {
    "meta": {
      "createdWith": "3.0.0-beta.2",
      "creationDate": "2018-04-21T22:02:00.600Z"
    },
    "objects": {
      "dest": "app/scripts/objects/"
    },
    "plugins": {
      "dest": "app/scripts/plugins/"
    },
    "scenes": {
      "dest": "app/scripts/scenes/",
      "index": {
        "name": "app/scripts/scenes/index.js",
        "requirePath": "./"
      }
    }
  }
}

When I install all dependencies and run yarn start it runs ok, but gives me the following console error:
Uncaught TypeError: Cannot read property 'sys' of null

tl;dr workaround: edit the lines, near the end of the app/scripts/scenes/splash-screen.js module as follows:
 //  When the asset loader fulfills its job, start the Game scene.
 scene.load.on('complete', () => {
   this.scene
-    .remove(scene)
+    .stop(scene)
     .start('Game');
 });

This bug appeared after Phaser 3.5.0. There has been a big code refactor of the scene manager, changing how scenes are registered and initialized. A few things got broken during that refactor, but were restored in 3.5.1 after I filed an issue. Not all of them, though.
That exception occurs during the game initialization, on the splash screen game scene. In that scene, a new 'Loader' scene is created, at run-time, to load the remaining game assets while showing the progress bar graphic over the (sample) cover. When all assets finish loading, that scene is discarded.
It all happens in rapid succession in the sample game because of the few assets included being loaded, you may only catch a glimpse of the splash screen blinking and being replaced by the spinning Phaser logo. Provided you follow the convention proposed to declare game assets (using the assets.js module, still missing proper documentation :disappointed:), you should see the splash screen in action for a bit more time and the progress bar animating.
I'll be looking for ways to fix the splash screen/loader combination before the next release of the generator. The whole thing feels too "hacky" and probably there are better ways to accomplish this without being too cryptic.

Thanks for reporting this one.
Ended up with a cleaner solution, easier to follow and customize. The sample SplashScreen class will no longer rely on a parallel scene to load the game assets and the progress bar animation is just a sprite with a shape mask. No more magic!
Also removed the assets.js module in favor of the regular Loader API methods users are more familiar with. There are not much documentation yet on this feature in Phaser as well, it's probably better to take it out.
All commits on master branch.


perlPackages.FileDesktopEntry: 0.04 -> 0.22

Motivation for this change
update and fix build
@Mic92

Thanks for the fix!


⚠ Bofrost.be has degraded performance

In c888df1, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1410 ms

Resolved: Bofrost.be performance has improved in 2f1ff4f after 34 minutes.


Skeleton Death Animation Continues to Loop

Describe the bug
The skeleton death animation continues to loop even though the animation should only place once. I referenced the heavy bandit animator and copied that using the skeleton sprites, but it still rearranges and dies again.
To Reproduce
Steps to reproduce the behavior:

Pull 'transitions' branch
Play skeleton scene and kill skeleton enemy using controls.

Expected behavior
Skeleton death should just happen once.
Screenshots
Here is a screen recording of the behavior
Screen Recording 2020-10-25 at 2.32.36 PM.zip

Fixed


feat: Only autowire transitive edges between manually wired dependencies

di does auto wiring for dependencies which is super convenient to avoid boilerplate. But let's say you have something like:
class DBConnection:
    def __init__(self, host: str) -> None:
        ...

We (wrongly) assume that this can be constructed like DBConnection(host=str()). This is because we inspect the type annotation and autowire str itself!
We need some way of cutting off how deep we auto-wire. I think a sensible rule would be "all of the leaf dependencies (dependencies with no further dependencies) must be manually wired with:

Marker(function_that_accepts_no_arguments)
A default value
A bind

@adriangb some control of this would be nice, since I can imagine creating a class with no dependencies, using it within your project, and expecting it to get wired in for folks. I know I'd love this for builtin types, but maybe not so much my own.
I think a sensible default would be to check if its a leaf and if the type is part of builtins...
import builtins
getmodule(str) == builtins #True
getmodule(list) == builtins #True
getmodule(dict) == builtins #True


Split daemons and db roles

This is primarily about how ERMrest service code is hosted and DB roles managed:

The ermrestddl daemon handles catalog and schema management and its corresponding db role owns the databases, schemas, tables, etc.
The ermrest daemon handles data access and its corresponding db role is granted data access privileges.
Row-level security can easily be turned on and off on a table by the DBA using the ermrestddl role.
The DBA must understand this backend change and avoid doing raw SQL operations on the databases which would screw up the new roles and privileges.

Secondarily, this patch set also includes some cleanup and evolution of the install process:

Dropping stale CentOS 6 build support and documentation
Dropping predeploy target from Makefile

Dropping implicit prerequisite installs
Moving some tasks to ermrest-deploy where they belong

Moving some install targets to ermrest-deploy for sanity

The default configs get installed to sharedir
The deploy script copies shared samples to deployment locations if and only if they are absent

The new code SHOULD work on an existing deployment with its existing deployed configuration. There is currently no automation for performing a full upgrade to enjoy the new features, but it would involve these steps:

Create ermrestddl daemon account and DB role
Add SE-Linux policies for new daemon account
Symbolic link the ~ermrest/ermrest_config.json to ~ermrestddl/.
Exhaustively change ownership of all ERMrest databases, schemas, tables, and sequences to the ermrestddl DB role
Exhaustively grant proper privileges on all ERMrest databases, schemas, tables, and sequences to the ermrest DB role.
Revise the deployed wsgi_ermrest.conf to define the two daemon process groups and split dispatch rules
Restart httpd
Also replace any deployed ERMrest cron jobs with the new version that runs under ermrestddl role when doing maintenance on the databases.

If the above steps are skipped, the existing deployment will continue to run all web requests through the ermrest daemon process group, doing all catalog and schema management as the ermrest user, having all new objects owned by the ermrest role, and harmlessly granting (redundant) data access privileges to the ermrest role.

@robes please independently validate that you can do both:

switch an existing deployment (with existing catalogs) to the 2roles branch with make install and service httpd restart and still have a functioning system
do a completely fresh install and deploy of the 2roles branch without any existing databases, daemon accounts, or apache ermrest configs

Tested on top of existing, working deployment from master, then switch to branch and:

make install
make deploy

Tested clean install from branch.


Update package to Julia 1.8

This PR should bring everything up to the point where users of 1.8 can download and run the test suite successfully. The different methods seem to still work as promised!

Thank you @josephcbradley .


Add simplified null parameter checks

Fixes #28443
Add what's new information for the !! operator, available in VS 17.1, and .NET SDK 6.0.200 as preview features.

@BillWagner thanks for the updates! Now it reads very well and correct.


Cache: added shorthand for model ds attributes

Test failed due to exceeded NHI query attempts and not due to changes made in this PR


SDK-1737 MAUI version

Reference
SDK-1737 MAUI version of the Branch SDK
Summary
This is the .NET MAUI version of the Branch SDK. Works with .NET 6+ and MAUI, it does NOT support the older Xamarin apps. Apps must migrate over to MAUI as well.
This is a rebuild of the SDK, although the code is largely the same there are significant changes to the project layout.
After review, let's do a preview release of a NuGet package while we update all docs and do additional testing.
Follow up tasks:

Update documentation
Build a testbed app within the SDK project

Motivation
Microsoft is moving to .NET MAUI and will no longer support Xamarin.
Type Of Change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] This change requires a documentation update

Testing Instructions
See developer notion page

cc @BranchMetrics/saas-sdk-devs for visibility.

Updated the test app, should be easier to review and verify now.

Clear caches if any, but otherwise seems good.


Make getOrderedHomologousGenesDiffExpressionCalls use the OrderingDAO strategy

In GitLab by @fbastian on Jul 16, 2015, 12:22
The interface org.bgee.model.dao.api.expressiondata.DiffExpressionCallDAO defines a method getOrderedHomologousGenesDiffExpressionCalls.

This DAO should use the OrderingDAO strategy (see issue #14)
An OrderingAttribute related to OMA groups should be defined
The method should be renamed getHomologousGenesDiffExpressionCalls.
An integration test should be added for this new method (the existing method has no integration test)
All code that was using this method should be updated to set the requested ordering.

See also issue #16, that also needs to make DiffExpressionCallDAO and OrderingDAO.

In GitLab by @vrechdelaval on Jul 21, 2015, 19:45
Points 1, 2, 3, and 5 done in commit 40e1d828. I need to modify the SQL query to be able to order without filtering with a taxon ID before implementation of integration tests (point 4).

In GitLab by @vrechdelaval on Jul 29, 2015, 17:08
Resolved: see git diff c10d16ee..3aefa263

In GitLab by @fbastian on Aug 24, 2015, 13:55

https://gitlab.isb-sib.ch/Bgee/bgee_apps/compare/c10d16ee...3aefa263#aa98d2a5db3a669b9d091c46fdef3d99cbe81756_132_143: > 1 ?
"We cannot predict the order of differential expression calls within the same group": shouldn't we add an OrderingAttribute for ordering based on gene ID?
https://gitlab.isb-sib.ch/Bgee/bgee_apps/compare/c10d16ee...3aefa263#aa98d2a5db3a669b9d091c46fdef3d99cbe81756_143_162: could you please double-check this part?

In GitLab by @vrechdelaval on Aug 31, 2015, 18:03
We won't add an OrderingAttribute for ordering based on gene ID because it is a feature that we don't need now.
Indeed, currently, getHomologousGenesDiffExpressionCalls() is used only in GenerateMultiSpeciesDiffExprFile class and sorting is done taking into account (but not only) summary similarity annotations and stage groups, which are both information that are not in DiffExpressionCalls.

In GitLab by @vrechdelaval on Sep 1, 2015, 11:46
mentioned in commit e231b12959983f6b75f2acedf3eb70d17895b82f

In GitLab by @vrechdelaval on Sep 1, 2015, 11:48

https://gitlab.isb-sib.ch/Bgee/bgee_apps/compare/c10d16ee...3aefa263#aa98d2a5db3a669b9d091c46fdef3d99cbe81756_132_143: > 1 => fixed
https://gitlab.isb-sib.ch/Bgee/bgee_apps/compare/c10d16ee...3aefa263#aa98d2a5db3a669b9d091c46fdef3d99cbe81756_143_162: could you please double-check this part? => Indeed, it is not necessary to create the temporary table tempGene (with INNER JOIN on OMAHierarchicalGroup) if we want to sort by OMA group without provided taxon.


[BUG-EXTERNAL] Excessive $NextInner objects (EH and SB)

Root causing
Cx deployed An application using SB session to 10 pods. A heap dump was taken from one pod after six days of execution, and showing excessive allocation of "reactor.core.publisher.NextProcessor$NextInner" type

Out of 1,065,540, the 1,065,504 "NextInner" instances retains "MonoCacheTime+MonoCacheTime$CoordinatedSubscriber" instances, those also appeared on the top of the above histogram.

Such ~1M instances of these types are leaking symptoms.
These 1,065,504 "NextInner" objects are retained by one "reactor.core.publisher.NextProcessor" object.

that "NextProcessor" is retained by the private variable shutdownSignalSink (type=Sink.One) in ReactorConnection.

While there are multiple places library subscribe to this shutdownSignalSink, the only place that exposes it via the intermediate MonoCacheTime operator (as appears in the second figure) by applying cache() operator is ReactorConnection::getShutdownSignal() method

private final Sinks.One<AmqpShutdownSignal> shutdownSignalSink = Sinks.one();

@Override
public Flux<AmqpShutdownSignal> getShutdownSignals() {
    return shutdownSignalSink.asMono().cache().flux();
}

Scanning the source code for reference to the method getShutdownSignals(), the only place it gets referenced and subscribed is in ReactorReceiver constructor
 amqpConnection.getShutdownSignals().flatMap(signal -> {
    logger.verbose("Shutdown signal received.");
    return closeAsync("Connection shutdown.", null);
}).subscribe());

But the subscription is DISPOSED in the ReactorReceiver close api.
Had it a bug in not closing ReactorReceiver, there would be ~1M instances of ReactorReceiver, but actually, there are only 250 of them.

It proves that ReactorReceivers are not getting leaked and are disposed correctly. It leads us to check the implementation of Sink.One and identified a problem in Sink.One where it continues to retain the subscriber even after the disposition. A git-ticket is opened in reactor-core repro "Memory leak in SinkOneMulticast" https://github.com/reactor/reactor-core/issues/3001, and the fix coming in reactor-core-3.4.17
Observation_1 (Cx action item)
You might have noticed that the reactor git-ticket mention about the type SinkOneMulticast, but in heap-dump, it's a different type NextProcessor.
The reason for that is - Cx application seems to have one or more dependency that brings in a relatively old version of the reactor-core library (~7 months behind). The Azure ServiceBus SDK is defined to use the recent version of reactor-core-3.4.14.
Back in Sept 2021, the use of NextProcessor in Sink.One was replaced with SinkOneMulticast; in this commit
Cx needs to analyze the dependencies and align the versions of shared libraries (e.g., reactor-core, reactor-netty, etc..) by upgrading dependencies so that the application is ready to pick when reactor-core-3.4.17 is available.
Observation_2 (Cx action item)
The 1,065,504 instances of "NextProcessor$NextInner" means, over the period of 6 days, around ~1M ReactorReceiver objects were created and closed. It means ~125 ReactorReceiver instances created-disposed per minute.
The only reason for such a massive churn of these objects is - that the consuming application is trying to acquire too many sessions from the service, but the producer application does not create enough sessions. Due to this, SB service DETACHes those unnecessary receivers after a 1 minute timeout. This indicates that maxConcurrentSession in the consumer application is too large. The Cx should tune this configuration according to the expected load.
Observation_3: (Sdk action-item)
The getShutdownSignals() API uses cache() operator.  We don't have to use the cache operator here, Sink.One is capable of remembering the last signal and replaying it. While cache() doesn't directly contribute to any leak, we could remove it and save allocations.
And the azure-core should upgrade to reactor-core 3.4.17 once released.

@anuchandy, @conniey, azure-core will be releasing this month using Reactor 3.4.17 if this issue needs to be verified as resolved.


Add mini chatbot to the website

add gssoc-ext,hactoberfest-accepted,level labels I like to work on it

follow the same implementation:
https://machine-learning-repos.vercel.app/
https://github.com/recodehive/machine-learning-repos

where is Html and css file is not there @sanjay-kv

@rutikakengal forgot to mention its in the branch gh-pages

I will work on this issue. Please assign this to me

@Peart-Guy Please provide samples if possible.

@Peart-Guy Please provide samples if possible.

This is a basic sample to showcase what I can offer. The final product may vary depending on your specific needs and preferences. I look forward to the opportunity to contribute to your project .

@Peart-Guy there is code base available in the ML repo on this same org. you can refer that,

@Peart-Guy there is code base available in the ML repo on this same org. you can refer that,

Yes sir I'm helping him with that.

@Peart-Guy there is code base available in the ML repo on this same org. you can refer that,

Sure.

I will work on this issue. Please assign this to me


OVPN File not found after creating a user

I have just finished setting up the pivpn server and creating my first user and i cant find the ovpn file /home/pi/ovpn. Please help.

Can you give me the output of pivpn add?

Enter a name for the client:
On Sat, Oct 29, 2016 at 2:02 PM, redfast00<EMAIL_ADDRESS>wrote:

Can you give me the output of pivpn add?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/pivpn/pivpn/issues/137#issuecomment-257106343, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AOKlidbbuWc8YxcCsxxvaDF6qvuAjPeyks5q44pAgaJpZM4KkKZu
.

Have you actually tried entering a name?

I created the user and everything but the ovpn doesn't show up
On Oct 31, 2016 4:24 PM, "redfast00"<EMAIL_ADDRESS>wrote:

Have you actually tried entering a name?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/pivpn/pivpn/issues/137#issuecomment-257410152, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AOKliYgJkmsqA__wjfseumxqTxjEUCiIks5q5k6XgaJpZM4KkKZu
.

Could you give me the full output and the output of pivpn debug?

@marcocet if no further response soon will close issue.


Create .npmignore

Remove test/ folder from being published with the npm package

I think these days we should use 'files" in package.json.


resolvers.ts file is hard to maintain

Having a single resolvers file is probably a bad idea. We should be creating a resolvers ts file per type. Additionally, we can rename the genrated folder to simply resolvers. Users should be able to extend resolvers somehow.
What I think we can do is:

Generate resolvers per type

/resolvers/note.ts

Generate empty resolvers file that users can build themselves

/resolvers/note.custom.ts

Merge resolvers object together by overriding generated ones if possible

Wrap all into graphql module with schema for consistency

@darahayes @StephenCoady opinions?

@wtrocki this seems like a reasonable idea to me. What about:
/resolvers for the top level
but then splitting them like this:
/generated
/custom
might make separation and development a bit cleaner.

This one will work as well

@wtrocki this seems like a reasonable idea to me. What about:
/resolvers for the top level
but then splitting them like this:
/generated
/custom
might make separation and development a bit cleaner.

And splitting those resolvers again for readability

This will also allow us to have some specific mappers inside resolvers folder and also extra stuff like Context types.

WDYT we drop the generated folder and go with this
|----src
      |----resolvers
            |----generated
            |----custom
      |----schema
            |----generated
            |----custom

+1 for resolves. I will keep schema in ./schema/generated.schema

Manual integration test. Good to go


proposal: prefixed labels for backtick literals

It's common in Go source code to write code in other languages like JSON, SQL, HTML, or JavaScript.
For this, backtick literals are helpful as you can format your code as desired:
var script =`console.log('Hello world');`

var page = `

    <title>Title</title>

Hello, world!

`

This proposal is a simple change to allow an optional prefixed label for backtick literals:
var script = javascript`console.log('Hello world');`

var page = html`

    <title>Title</title>

Hello, world!

`

Allowing this prefixed label enables IDEs and language parsers to act on the string contents:

An IDE can provide linting and syntax highlighting for string contents.
Like gofmt, a program could format the string contents automatically by inferring the type from the label.

Like the 1.13 change which allows underscores between digits, prefixed labels are meant as a syntactic hint which has no effect on the string value itself, that is:
10000 == 10_000 // true
"contents" == foo`contents` // true

Another approach would be a comment. This wouldn't require changing the language.
//go:format html
var page = `

    <title>Title</title>

Hello, world!

`

Another approach would be a comment. This wouldn't require changing the language.
//go:syntax html
var page = `

    <title>Title</title>

Hello, world!

`

I think the benefit of formally adding to the language is that how to label a string becomes explicit. There wouldn't be special rules around how to format or place comments (before? after? either?) in order to get the benefit. With that clarity, I believe better tooling and features could be derived.

I agree with @icholy that additional text with no semantic meaning is better handle by a comment.  The go/parser package already provides a well documented mechanism for commenting variables: the same as doc comments.  And in 1.15 Go documentation packages don't display comments that start with //go: (see #37974).  So I don't think there will be much confusion over the formatting or placement of these comments.

I do think #37974 makes using comments much more palatable.

So I don't think there will be much confusion over the formatting or placement of these comments.

Playing with it, I came across an example where a comment approach is ambiguous:
_, err := c.exec(ctx, `
	SELECT *
	FROM orders
	WHERE state = $1 AND id = $2;
`, /*go:syntax sql*/ "pending", id)

When trying to put the comment adjacent to the backtick literal, it jumps behind or in front of nearby commas after gofmt.
Obviously, this string could be refactored out of being inline and that could just be the rule, but with a prefix labeling approach, it would just work and be clear in all cases I can think of.
Related, most IDEs won't have access to an AST—so support for a comment-based approach might have to come in the form of syntax definitions based on regular expressions. Obviously not impossible, but probably pretty rough to get right.

A simple rule would be that //go:syntax ...  affects the first string following the directive.
//go:syntax sql
_, err := c.exec(ctx, `
	SELECT *
	FROM orders
	WHERE state = $1 AND id = $2;
`, "pending", id)

That would be easy for a regex.

backtick literals seem to have been proposed in #32590 already.

Closing in favor of #32590.


Fix CLI invocations

Module loads via python -m * take a different code path than direct usage of the dask/distributed CLI. The finder is still run to get the spec, but instead of the loader's [create|exec]_module methods being called next the loader's get_code method is called to simply load the __main__ module as a text file to be executed directly. To support this use case, this PR splits up the finder and the loader. The loader is now a SourceFileLoader that is instantiated once per file to be loaded, allowing it to support loading the text of that file on demand by command line invocations. In order for this to work, the spec needs to be properly configured before the finder's find_spec call returns. The update_spec function I had in place before was a bit of a hack. This PR replaces that with a call to importlib.util.find_spec on the real module to get the full spec right up front. This allowed me to do quite a bit of other simplification; since the spec is now correct up front, I removed update_spec entirely and converted the loaders from stateful classes that updated the spec on load to simple factories since the spec is already guaranteed to be correct. Finally, I added some new tests of the CLI, module usage, and the accessor module.
Closes #45
Closes https://github.com/rapidsai/docker/issues/668

/merge


Set date from GPS

Create a fake date before we get a GPS fix
method to indicate we have an RTC on board

This is now low priority since we have the Bluetooth time sync.


Support for tp4056 MicroUSB

User request for supporting the MicroUSB version of the TP4056

I have a tp4056 microUSB version on the way should be here in a few days.

MicroUSB fits as intended without modification.


Cannot modify content if using fileobj

Hey,
it seems like there is something wrong with this line:
>>> import io
>>> from dockerfile_parse import DockerfileParser
>>> dfp = DockerfileParser(fileobj=io.StringIO())
>>> dfp.content = 'FROM test'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/projects/env/lib/python3.7/site-packages/dockerfile_parse/parser.py", line 196, in content
    dockerfile.write(u2b(content))
TypeError: string argument expected, got 'bytes'

Probably a StringIO does not take bytes as an input (at least in Python 3).

You are right, parser writes bytes into fp opened in textual mode, waht causes errors in py3. You may need to use BytesIO instead.
But I'm not sure if requiring bytes mode instead of textual mode is good and probably parser should be updated.

Oh yes, it works with ByteIO. Thanks for the quick response!
Well, I'd be fine with it if this case would be documented or there would be an example on how to use the fileobj parameter in the README.md :)


Support for key-value query parameters

It will be very handy to support complex parameters in some cases. E.g. if you have ASP.NET Core application with an endpoint that receives Dictionary<string, string> from query parameters.
Although react-query-swagger has support for JSON-serialized parameters and it can be used for complex parameters but ASP.NET Core doesn't support it out of the box.
Now if you try to generate client with the following command and swagger.json:
react-query-swagger openapi2tsclient /tanstack /input:swagger.json /output:api-client.ts /template:Axios /serviceHost:. /minimal

{
  "openapi": "3.0.0",
  "info": {
    "title": "Bug reproduction",
    "description": "Bug reproduction",
    "version": "1"
  },
  "paths": {
    "/api/v1/Answers": {
      "get": {
        "tags": [
          "Answers"
        ],
        "operationId": "Answers_GetAnswers",
        "parameters": [
          {
            "name": "Tags",
            "in": "query",
            "schema": {
              "type": "object",
              "additionalProperties": {
                "type": "string"
              }
            }
          }
        ],
        "responses": {
          "200": {
            "description": "",
            "content": {
              "application/json": {
                "schema": {}
              }
            }
          }
        }
      }
    }
  }
}

You get the following TypeScript code in api-client/AnswersQuery.ts and api-client/AnswersClient.ts:
    let url_ = getBaseUrl() + "/api/v1/Answers?";
    if (tags === null)
        throw new Error("The parameter 'tags' cannot be null.");
    else if (tags !== undefined)
        url_ += "Tags=" + encodeURIComponent("" + tags) + "&";
      url_ = url_.replace(/[?&]$/, "");

Here's the problem with encodeURIComponent("" + tags) because
encodeURIComponent("" + {"key": "value"}) => encodeURIComponent("[object Object]")
I think, according to the OpenAPI docs, there should be the following code here:
for (const key of Object.getOwnPropertyNames(tags)) {
    url_ += encodeURIComponent(key) + '=' + encodeURIComponent(tags[key]) + '&';
}

Alos I'll appreciate if you implement support for "deepObject" parameter serialization style.

Should be fixed in 15.7.10

Thank for the fix!
I've tested it and found out that now for the same given command and swagger the following code is generated:
tags && Object.keys(tags).forEach(key => { url_ += `Tags[${key}]=` + encodeURIComponent("" + tags[key]) + "&"; });

I see here 2 issues:

A key is not encoded and it leads to that if Tags = {"complex=key":"value"}  then ASP.NET Core cannot correctly parse the query params.
The generated code corresponds to "deepObject" parameter serialization style but in the given swagger style is not specified and a default one should be used.

This is example of a swagger with a specified serialization style:
{
  "openapi": "3.0.0",
  "info": {
    "title": "Bug reproduction",
    "description": "Bug reproduction",
    "version": "1"
  },
  "paths": {
    "/api/v1/Answers": {
      "get": {
        "tags": [
          "Answers"
        ],
        "operationId": "Answers_GetAnswers",
        "parameters": [
          {
            "name": "Tags",
            "in": "query",
            "style": "deepObject",
            "schema": {
              "type": "object",
              "additionalProperties": {
                "type": "string"
              }
            }
          }
        ],
        "responses": {
          "200": {
            "description": "",
            "content": {
              "application/json": {
                "schema": {}
              }
            }
          }
        }
      }
    }
  }
}

Alos I'll appreciate if you implement support for "deepObject" parameter serialization style.

That would definitely be good, but let me ask you a question. How do you plan to use it? I mean, currently you won't be able to correctly consume this deepObject by ASP.NET Core Controller, right?

deepObject serialization style is required when I try write endpoint like this:
[HttpGet]
public async Task<PagedResult<AnswerDto>> GetAnswers([FromQuery] AnswerFilters filters)  {
    // Do something
};

public class AnswerFilters {
    public DateTime? Since { get; set; }
    public DateTime? Until { get; set; }

    public Dictionary<string, string>? Tags { get; set; }
}

Here Tags cannot be bound if the query parameter isn't serialized with deepObject style.

yep, that makes sense.
I've created another issue for handling this scenario, I suppose we can consider this issue closed, right?

Yes. Thanks for library improvements!


feat: add environment variable to disable writing extra dist-info files

Summary
This change introduces the UV_NO_EXTRA_DIST_INFO environment variable as a way to opt out of the extra dist-info files that uv is creating.
This is important to achieve reproducible builds in distribution packaging, allowing to replace usage of
installer with uv pip install.
At the time of writing these files are:

uv_cache.json Contains timestamps which are non-reproducible. These hashes also leak in to RECORD.

direct_url.json Contains the path to the installed wheel. While not non-reproducible it's not required for distribution packaging.

INSTALLER Again, not non-reproducible, but of no value in distribution packaging.

Test Plan
Automated test added.

Thanks for putting up the PR!
Note to other reviewers, we briefly discussed using an environment variable for this in Discord.
I don't have strong opinions on the name, but we might want to use UV_NO_EXTRA_DIST_INFO=1 rather than UV_EXTRA_DIST_INFO=0?
Otherwise, I'm not well suited to be the primary reviewer for this. Perhaps @konstin or @charliermarsh would be interested.

I don't have strong opinions on the name, but we might want to use UV_NO_EXTRA_DIST_INFO=1 rather than UV_EXTRA_DIST_INFO=0?

It made more sense to me when writing this to think about it the other way around, but it's indeed seems more consistent with other options to use UV_NO_EXTRA_DIST_INFO=1.

What's the motivation for going through wheel installation for repackaging over re-zipping the wheel into the target format you are interested in?

What's the motivation for going through wheel installation for repackaging over re-zipping the wheel into the target format you are interested in?

Sorry, I don't understand the question? I'll explain my use case in more detail, hopefully we'll find some understanding.
The use case for this PR is to replace usage of installer with uv in distribution packaging scripts.
These scripts need to:

Invoke a Python build system, such as pypa/build which takes a source tree and outputs a wheel

Or download a pre-built wheel

Invoke an installer that can install said wheel into a prefix

In nixpkgs these we use:

pypa/installer to install Python wheels.
pypa/build
In some rare cases download pre-built wheels

For distribution packaging we want reproducible builds, meaning that the outputs produced by a packaging script should be bit-for-bit identical.
Nix comes with tooling to perform these checks: nix-build ./. -A somePackage --check.
I have implemented an alternative Python build infrastructure for Nix where I use uv.
These builds end up failing reproducibility checks because of extra dist info files.

Ping @charliermarsh

I'm not super excited to maintain this but I see the value. I think we should call this "installer metadata" rather than "extra dist-info", since the latter is just a term we made up within the wheel installer crate. How's that sound?

I'm not super excited to maintain this but I see the value.

Thank you. I understand that the use case is a bit niche from a Python perspective.

I think we should call this "installer metadata" rather than "extra dist-info", since the latter is just a term we made up within the wheel installer crate. How's that sound?

Yep, that sounds much better!


Add initial expert list

NOTE: before this goes live need confirmation from ngapera about Community Research site.
Opening PR ready to go, but we need confirmation from @Ngapera about the Community Research site before this can be merged.

This PR will close #16

Already approved by @robisaacnz so I'm going to merge now @ngapera has clarified


Runtime: Add a runtime entry point to print metadata names for debugging

@swift-ci test

@swift-ci test

Does p nameForMetadata(...) work for you in a shipped runtime?
All my attempts (granted I have used e nameForMetadata()) to use it failed. The way I explained that to myself is that nameForMetadata is an internal symbol.
% nm -a my-stdlibs/macosx/libswiftCore.dylib | grep nameForMetadata
00000000002ffdb0 t __ZN5swift15nameForMetadataEPKNS_14TargetMetadataINS_9InProcessEEEb
0000000000300044 t __ZNK5swift14MetadataOrPack15nameForMetadataEv

I didn't actually know about nameForMetadata until I saw this PR, so I don't know if it actually works. I always use swift_getTypeName and it's good. Nice thing about that is that even when you have no debug symbols, you can cast your way to victory with just C types, so p (char *)swift_getTypeName(0xdeadbeef, 1).


Feature/callbacks

This PR:

Add MinIO storage service option
Add example plugins
Change results writing mechanism from writing to storage to scraping logs #47
Use MinIO storage for GitHub tests
Implement a Message Queue to handle status updates
Restructure job status updates logic to event-driven architecture

@slawler can you approve? Adding features etc. was easy passing tests was hard.😄


Bug correction in smw200a driver not properly getting options

The conditional for the options SMW-B22 and SMW-B20 option always evaluates to true because the first condition of the or statement is  'SMW-B22' which always evaluates to true


Update to babel 6, replace istanbul with nyc

This PR performs some key upgrade tasks. First of all, we're using Babel v6, using the latest and stage-2 presets. Some older syntax had to be worked around, but that was fairly straightforward. We're also replacing usage of Object.assign with rest/spread.
This PR also adds a lint build step, which will use the airbnb eslint configuration. Some rules have been disabled to avoid the changes getting too deep.
We're also using istanbul's newer nyc tool in favor of the istanbul cli tool.

If we switch to Jest we can avoid the istanbul -> nyc conversion

Good call @kesne , I've heard that Jest has gotten a lot better


Multisig-Transaction-Issue

When creating a transaction for multisig wallet 0xd0ee8797D844796e93b868427f90F2A92690cdA0, the other owners are unable to track or sign. The transaction does not show and produces 404 errors. Other owners have tried creating a transaction as well, but the same issue occurs.

@peekpi can you take a look and comment here?


115 bugfix process hanging

Responds to issue 115.

I am still getting a hanging problem on the windows server


Fixing the transform issue in RViz

Currently, the drone spawns correctly in Gazebo but shows transform issues in RViz.
Launching joint controllers also causes the same issue in Gazebo, causing the joints to migrate to the origin.

commit e72f5343a8516eb3c92e970e0f94a03f1db93017

Controllers getting loaded in Gazebo, but transform gets ruined
All non-fixed link migrating to the origin

Transform can be published using tf2
The gazebo link issue was solved, it was a URDF issue

When using realtime controllers, inertia elements of zero (or almost zero) can cause the robot model to collapse without warning, and all links will appear with their origins coinciding with the world origin.

Reference: ROS Wiki


Rename "out_dir" to "permalink" for URL Customization Clarity

implemented https://github.com/josnin/pyjan26/commit/580b3352dec80cd5f004058892d292a9051b551f