Send bulk events from Eth -> Sub on header finalization

This PR makes the necessary changes to Substrate and the relayer to forward all messages in a block once the block is finalized.
Key parts of this PR:

Substrate bridge module gets a submit_bulk dispatchable that accepts multiple message for multiple app IDs
Substrate verifier module gets a verify_bulk function for the sake of efficiency, e.g. we only have to query storage once per header to check finality
Relayer message channel changes from type chain.Message to []chain.Message. Additionally, the messages are forwarded in chunks (Substrate will reject an extrinsic that's too large)

Nice, thanks @Rizziepit 🎉
There is one bigger concern if I'm not mistaken: The current design does not maintain order of messages across and also not within blocks, it only maintains order within applications. This means that messages from one app could be executed before messages from earlier blocks in another app are executed. If those apps interact, this could lead to indeterministic and unexpected behaviour.
If we wanted to maintain order of messages across, but also within blocks, the MessageBatch data structure does not give us many efficiency gains. You could only batch messages that are in the same block and all talk to the same target app.
What is the reason to batch messages by app?

I'm not sure the benefit of batching messages by app either, but ordering and inclusion of messages is guaranteed only by going through specific channels, not by the bridge as a whole. If apps or users expect guarantees around ordering and inclusion, they need to send their messages through a channel that guarantees this, so I don't see this as a problem at the bridge submission stage in this PR.
Follow up PR will add channels which can deal with that.
Related question though (@Rizziepit @vgeddes @philipstanislaus ): A channel can basically be implemented as an app too, ie, it's just an app that adds some guarantees on ordering/replay protection, and then a second time routes its payload to a second app.
eg: bridge -> channelapp -> otherapp
There are a some considerations for implementing channels in the design:
1 - Are they the same thing as apps or not? Essentially, do we REQUIRE all apps to send/receive their messages via a channel, or can apps opt to send their messages directly, as in the current implementation?
2 - Do we implement them in their own pallets, or here in the bridge pallet?
I'd say it's probably simplest to implement our channels within the bridge pallet and require all apps to route their messages through a channel such that our chain and relayer only watches channel smart contract events and no direct app events. Then we disconnect the ETHApp and ERC20App from the bridge once channels are implemented. Thoughts?

Nice, thanks @Rizziepit 🎉
There is one bigger concern if I'm not mistaken: The current design does not maintain order of messages across and also not within blocks, it only maintains order within applications. This means that messages from one app could be executed before messages from earlier blocks in another app are executed. If those apps interact, this could lead to indeterministic and unexpected behaviour.
If we wanted to maintain order of messages across, but also within blocks, the MessageBatch data structure does not give us many efficiency gains. You could only batch messages that are in the same block and all talk to the same target app.
What is the reason to batch messages by app?

I'm not sure the benefit of batching messages by app either, but ordering and inclusion of messages is guaranteed only by going through specific channels, not by the bridge as a whole. If apps or users expect guarantees around ordering and inclusion, they need to send their messages through a channel that guarantees this, so I don't see this as a problem at the bridge submission stage in this PR.
Follow up PR will add channels which can deal with that.
Related question though (@Rizziepit @vgeddes @philipstanislaus ): A channel can basically be implemented as an app too, ie, it's just an app that adds some guarantees on ordering/replay protection, and then a second time routes its payload to a second app.
eg: bridge -> channelapp -> otherapp
There are a some considerations for implementing channels in the design:
1 - Are they the same thing as apps or not? Essentially, do we REQUIRE all apps to send/receive their messages via a channel, or can apps opt to send their messages directly, as in the current implementation?
2 - Do we implement them in their own pallets, or here in the bridge pallet?
I'd say it's probably simplest to implement our channels within the bridge pallet and require all apps to route their messages through a channel such that our chain and relayer only watches channel smart contract events and no direct app events. Then we disconnect the ETHApp and ERC20App from the bridge once channels are implemented. Thoughts?

I'm not sure the benefit of batching messages by app either, but ordering and inclusion of messages is guaranteed only by going through specific channels, not by the bridge as a whole. If apps or users expect guarantees around ordering and inclusion, they need to send their messages through a channel that guarantees this, so I don't see this as a problem at the bridge submission stage in this PR.
Follow up PR will add channels which can deal with that.

I remember now in the arch docs you envisioned channels doing things like ordering.  How do you envision it to work? 🤔
I'm thinking the relayer is in a very good place to perform cheap message ordering, That ordering can then be verified by the on-chain Receive channel. So they can work together to ensure that ordering takes place.

Related question though (@Rizziepit @vgeddes @philipstanislaus ): A channel can basically be implemented as an app too, ie, it's just an app that adds some guarantees on ordering/replay protection, and then a second time routes its payload to a second app.

I don't have any immediate answers or thoughts yet. Now that Rococo/parachain stuff is mostly out the way, my plan is to focus on these implementation details.

I'm not sure the benefit of batching messages by app either, but ordering and inclusion of messages is guaranteed only by going through specific channels, not by the bridge as a whole. If apps or users expect guarantees around ordering and inclusion, they need to send their messages through a channel that guarantees this, so I don't see this as a problem at the bridge submission stage in this PR.
Follow up PR will add channels which can deal with that.

I remember now in the arch docs you envisioned channels doing things like ordering.  How do you envision it to work? 🤔
I'm thinking the relayer is in a very good place to perform cheap message ordering, That ordering can then be verified by the on-chain Receive channel. So they can work together to ensure that ordering takes place.

Related question though (@Rizziepit @vgeddes @philipstanislaus ): A channel can basically be implemented as an app too, ie, it's just an app that adds some guarantees on ordering/replay protection, and then a second time routes its payload to a second app.

I don't have any immediate answers or thoughts yet. Now that Rococo/parachain stuff is mostly out the way, my plan is to focus on these implementation details.

There is one bigger concern if I'm not mistaken: The current design does not maintain order of messages across and also not within blocks, it only maintains order within applications. This means that messages from one app could be executed before messages from earlier blocks in another app are executed. If those apps interact, this could lead to indeterministic and unexpected behaviour.
If we wanted to maintain order of messages across, but also within blocks, the MessageBatch data structure does not give us many efficiency gains. You could only batch messages that are in the same block and all talk to the same target app.
What is the reason to batch messages by app?

Batching by app made processing a bit easier in the parachain, but it's not necessary. Your concern makes sense @philipstanislaus. I didn't take ordering guarantees into account when implementing this.
My proposal for this PR: make the relayer batch by block and maintain the event ordering within the block - parachain doesn't enforce this though, nor are there any guarantees of ordering across blocks
Follow-up PR: When I implement the in-channel in Substrate, the parachain starts enforcing ordering by using the nonce @musnit added in https://github.com/Snowfork/polkadot-ethereum/pull/208. This would enforce ordering in and across blocks.

I remember now in the arch docs you envisioned channels doing things like ordering.  How do you envision it to work?

I share @vgeddes' concern. I want the ordering to be a channel concern, but implementation will be quite complicated unless we have a strict ordering where nonces in blockx < nonces in blockx+1. @musnit is it possible to implement the nonce that way?

There is one bigger concern if I'm not mistaken: The current design does not maintain order of messages across and also not within blocks, it only maintains order within applications. This means that messages from one app could be executed before messages from earlier blocks in another app are executed. If those apps interact, this could lead to indeterministic and unexpected behaviour.
If we wanted to maintain order of messages across, but also within blocks, the MessageBatch data structure does not give us many efficiency gains. You could only batch messages that are in the same block and all talk to the same target app.
What is the reason to batch messages by app?

Batching by app made processing a bit easier in the parachain, but it's not necessary. Your concern makes sense @philipstanislaus. I didn't take ordering guarantees into account when implementing this.
My proposal for this PR: make the relayer batch by block and maintain the event ordering within the block - parachain doesn't enforce this though, nor are there any guarantees of ordering across blocks
Follow-up PR: When I implement the in-channel in Substrate, the parachain starts enforcing ordering by using the nonce @musnit added in https://github.com/Snowfork/polkadot-ethereum/pull/208. This would enforce ordering in and across blocks.

I remember now in the arch docs you envisioned channels doing things like ordering.  How do you envision it to work?

I share @vgeddes' concern. I want the ordering to be a channel concern, but implementation will be quite complicated unless we have a strict ordering where nonces in blockx < nonces in blockx+1. @musnit is it possible to implement the nonce that way?

Batching by app made processing a bit easier in the parachain, but it's not necessary. Your concern makes sense @philipstanislaus. I didn't take ordering guarantees into account when implementing this.
My proposal for this PR: make the relayer batch by block and maintain the event ordering within the block - parachain doesn't enforce this though, nor are there any guarantees of ordering across blocks
sounds fine, though the relayer will be enforcing this so may as well make the default behaviour of the relayer follow the enforced ordering. I think it should actually naturally, because the order in which events are stored and emitted with new blocks/subscriptions should match the order of nonces in #208, though ideally the relayer does keep track of what it's submitting, whether those submissions succeed or not, and what nonce it should be sending based on that.

Follow-up PR: When I implement the in-channel in Substrate, the parachain starts enforcing ordering by using the nonce @musnit added in #208. This would enforce ordering in and across blocks.
yep sounds good

I remember now in the arch docs you envisioned channels doing things like ordering.  How do you envision it to work?

I share @vgeddes' concern. I want the ordering to be a channel concern, but implementation will be quite complicated unless we have a strict ordering where nonces in blockx < nonces in blockx+1. @musnit is it possible to implement the nonce that way?
there won't be any reordering happening on chain, nor anything dynamic. the relayer MUST submit events in order based on the ordering from the channel, and the channel will enforce on the ethereum side, when events are created, that nonces in blockx < nonces in blockx+1. The implementation in #208 already should do this.

Batching by app made processing a bit easier in the parachain, but it's not necessary. Your concern makes sense @philipstanislaus. I didn't take ordering guarantees into account when implementing this.
My proposal for this PR: make the relayer batch by block and maintain the event ordering within the block - parachain doesn't enforce this though, nor are there any guarantees of ordering across blocks
sounds fine, though the relayer will be enforcing this so may as well make the default behaviour of the relayer follow the enforced ordering. I think it should actually naturally, because the order in which events are stored and emitted with new blocks/subscriptions should match the order of nonces in #208, though ideally the relayer does keep track of what it's submitting, whether those submissions succeed or not, and what nonce it should be sending based on that.

Follow-up PR: When I implement the in-channel in Substrate, the parachain starts enforcing ordering by using the nonce @musnit added in #208. This would enforce ordering in and across blocks.
yep sounds good

I remember now in the arch docs you envisioned channels doing things like ordering.  How do you envision it to work?

I share @vgeddes' concern. I want the ordering to be a channel concern, but implementation will be quite complicated unless we have a strict ordering where nonces in blockx < nonces in blockx+1. @musnit is it possible to implement the nonce that way?
there won't be any reordering happening on chain, nor anything dynamic. the relayer MUST submit events in order based on the ordering from the channel, and the channel will enforce on the ethereum side, when events are created, that nonces in blockx < nonces in blockx+1. The implementation in #208 already should do this.

Also batching by app may still be valuable once channels are fully implemented, as our different channels will essentially be our apps, so we'll effectively be batching by channel.

Also batching by app may still be valuable once channels are fully implemented, as our different channels will essentially be our apps, so we'll effectively be batching by channel.

Updated it so that we're not batching by block or app ID. Technically, the relayer batches by block, but it's not explicit in the data structure. I think this is best - ordering enforcement will be done in another PR

Updated it so that we're not batching by block or app ID. Technically, the relayer batches by block, but it's not explicit in the data structure. I think this is best - ordering enforcement will be done in another PR

So for a relay chain node running our wasm validation function (which
includes pow verification), will it run successfully even with this flag?
On Wed, 20 Jan 2021, 08:44 Vincent Geddes<EMAIL_ADDRESS>wrote:

@vgeddes commented on this pull request.
In parachain/config.json
https://github.com/Snowfork/polkadot-ethereum/pull/203#discussion_r560712813
:

@@ -22,7 +22,16 @@
"wsPort": 9988,
"port": 31200,
"balance": "1000000000000000000000",

	"flags": ["--rpc-cors=all", "--enable-offchain-indexing", "--discover-local", "--", "--execution=wasm"]

	"flags": [

		"-lbasic_authorship=trace,import_header=trace,runtime=debug",

		"--execution=native",

The parachain node on its host can execute either using its native or WASM
runtime (both are builtin to the node executable). Note this is all after
the WASM has been compiled and registered on the relay chain. Even if
running natively, the node can only execute blocks that were validated on
the relay chain using the registered WASM validation function.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Snowfork/polkadot-ethereum/pull/203#discussion_r560712813,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFVTOPIVAKFCFV5EBMPZ53S2Z3T5ANCNFSM4V637WKA
.

So for a relay chain node running our wasm validation function (which
includes pow verification), will it run successfully even with this flag?
On Wed, 20 Jan 2021, 08:44 Vincent Geddes<EMAIL_ADDRESS>wrote:

@vgeddes commented on this pull request.
In parachain/config.json
https://github.com/Snowfork/polkadot-ethereum/pull/203#discussion_r560712813
:

@@ -22,7 +22,16 @@
"wsPort": 9988,
"port": 31200,
"balance": "1000000000000000000000",

	"flags": ["--rpc-cors=all", "--enable-offchain-indexing", "--discover-local", "--", "--execution=wasm"]

	"flags": [

		"-lbasic_authorship=trace,import_header=trace,runtime=debug",

		"--execution=native",

The parachain node on its host can execute either using its native or WASM
runtime (both are builtin to the node executable). Note this is all after
the WASM has been compiled and registered on the relay chain. Even if
running natively, the node can only execute blocks that were validated on
the relay chain using the registered WASM validation function.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Snowfork/polkadot-ethereum/pull/203#discussion_r560712813,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFVTOPIVAKFCFV5EBMPZ53S2Z3T5ANCNFSM4V637WKA
.

So for a relay chain node running our wasm validation function (which includes pow verification), will it run successfully even with this flag?

Doubtful. That might explain this issue I'm seeing: https://snowfork.slack.com/archives/G01C5QC3D4M/p1611125308034600?thread_ts=1611124625.034400&cid=G01C5QC3D4M

So for a relay chain node running our wasm validation function (which includes pow verification), will it run successfully even with this flag?

Doubtful. That might explain this issue I'm seeing: https://snowfork.slack.com/archives/G01C5QC3D4M/p1611125308034600?thread_ts=1611124625.034400&cid=G01C5QC3D4M

In addition to fixing ethash in WASM, I added a few things to this PR:

The wasm-bindgen-test crate lets us run unit tests in WASM using --target wasm32-unknown-unknown. Note that you have to be in the crate dir. This works because of configuration at parachain/primitives/ethereum/.cargo/config:

cd parachain/primitives/ethereum
cargo test --target wasm32-unknown-unknown

Substrate logging to target submit_messages to verify that message batches are received and processed (see screenshot)

cc @vgeddes

In addition to fixing ethash in WASM, I added a few things to this PR:

The wasm-bindgen-test crate lets us run unit tests in WASM using --target wasm32-unknown-unknown. Note that you have to be in the crate dir. This works because of configuration at parachain/primitives/ethereum/.cargo/config:

cd parachain/primitives/ethereum
cargo test --target wasm32-unknown-unknown

Substrate logging to target submit_messages to verify that message batches are received and processed (see screenshot)

cc @vgeddes


Make inspiry bot more gender-neutral

Currently, inspiry bot assumes that all quote authors are males. I updated the bot with more gender-neutral language.

:+1:


Asana producing 504 Gateway Time-out Error within the Station App

Application version: 3.3.0
OS: Windows 10

Steps to Reproduce:
Attempt 1:

Sign-in to a Asana (for both google sign-in and email sign-in it works initially for the first instance, but if I try to add another email
Click on account drop-down menu in the top right corner.
Click on settings
Select Account
Click "add new email" - forces you to reauthenticate
Select same email again
504 Gateway Time-out error appears

Attempt 2:

Select Asana app
504 Gateway Time-out error appears
Quit and restart Station
Sign-in to Asana with email - takes you to sign-up page (but I already have an account with that email so...)
Select "log-in" (located on bottom of page)
504 Gateway Time-out error appears

Attempt 3:

Select Asana app
504 Gateway Time-out error appears
Select "Help"
Select "reset current application"

Attempt 3.1:
Repeat of Attempt 1 OR
Repeat of Attempt 2 Steps 1-3 and then 504 Gateway Time-out error appears again
Screenshots

Hi @bednarz5 , I would recommend you to add another Asana app to Station and login with a different account instead of adding second account to the single Asana app.
Like this:


Local instance: InlineQueryResultPhoto WEBDOCUMENT_URL_INVALID

Bot API 6.7.1
I'm running the API with --local,
This request:
{
  "inline_query_id": "xxxxxxxxxxxxxxxx",
  "results": [
    {
      "type": "photo",
      "id": "my_id",
      "photo_url": "http://localhost:8000/12345.jpg",
      "thumbnail_url": "http://localhost:8000/12345.jpg"
    }
  ],
  "cache_time": 0
}

Results in
{
  "ok": false,
  "error_code": 400,
  "description": "Bad Request: WEBDOCUMENT_URL_INVALID"
}

Also with photo_url using file://

The URL must be public and globally available as described in https://core.telegram.org/bots/api#inlinequeryresult, therefore you can't use a URL, which is valid only locally.

It applies to the cases when the file is uploaded during the request, i.e. the parameter is documented as InputFile.


make error : process.hpp not found

jucipp-master/src/terminal.h:11:23: fatal error: process.hpp: No such file or directory
compilation terminated.
src/CMakeFiles/juci.dir/build.make:62: recipe for target 'src/CMakeFiles/juci.dir/config.cc.o' failed
make[2]: *** [src/CMakeFiles/juci.dir/config.cc.o] Error 1
CMakeFiles/Makefile2:157: recipe for target 'src/CMakeFiles/juci.dir/all' failed
make[1]: *** [src/CMakeFiles/juci.dir/all] Error 2
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2

What is your OS?

ubuntu 16.04 any solution ?

Did you use —recursive when you cloned this repository?

ahhh,, i see.. sorry my fault.
SOLVED


Added ability to change legend_style and legend_text

@dmadeka, @ssunkara1
First stab at customizing legend and legend text

Thanks @madridnick
I notice a small issue. When I set legend_style, it applies the style to the rectangle added on top of the legend entries. Because of this, when we set the fill property of legend_style , the legend is no longer visible.

To handle this, I think you can add the rectangle initially, before the marks add their legend entries, and set the properties of this rectangle later.

@madridnick This looks great. Just needs one or two more commits, do you want me or @ssunkara1 to push to your branch?

@ssunkara1, @dmadeka
Fixed the fill property issue. Big thanks to to @cquah for her JS expertise.

Thanks @madridnick There is one minor fix that I just suggested. After that I think this is good to merge.


Tray-Application

Thanks for this nifty project (there was an attempt a while ago by the apache foundation building such a thing using Cordova https://cordova.apache.org ) but that stalled.
Your approach is pretty good and works really well.
Since the application size comes way down, it seems as the project is also pretty good predestined to create tray/menubar-extra applications. But as far as I can see, there's no support for that - is that right?

You can use systray in the main process. I just tried it out and seems to be working as expected

Yes, I know I can do that (and I did), but it would be a great addition to this nice (but dead?) project.


Add automatic light/dark mode

Adds light theme as well as automatic switch based on users' browser/OS preference

Given that there was no comment on this, I assume it's fine to merge ^^


Prevent the entire viewer from zooming, when quickly switching from scrolling to zooming using the mousewheel (PR 7097 followup)

This is a regression from PR #7097.
(Also, out of scope for this PR, but I think that a setTimeout value of 1000 ms is too large. Switching from scrolling to zooming can fell sluggish, and give the impression that nothing happens.)

Thanks.


Remove the version check in have_http_status

The successful?, server_error?, and not_found? methods for ActionDispatch::TestResponse have existed in Rails for a very long time. It isn't necessary to check for Rails 5.2 or greater in order to use them.
This is an improvement on https://github.com/rspec/rspec-rails/pull/1951 which has been merged.

@JonRowe So happy to be able to do this.

Thanks, sorry this slipped through the cracks

Thanks!


Support alternate transitions for belt-items

When I'm working with belts, I very rarely want to grab a different tier of belt. I much more frequently want to change from a belt to a splitter, or something else within the same tier.
With that in mind, I added support for three new transition approaches for belts for a total of four:
- Tier (belt <-> fast belt <-> express belt)
- Category (belt <-> underground <-> splitter)
- Tier then Category (belt <-> fast belt <-> express belt <-> underground <-> fast underground ...)
- Category then Tier (belt <-> underground <-> splitter <-> fast belt <-> fast underground ...)

The player can choose the transition strategy via a setting. It's implemented in a mod-agnostic way, so it should work out of the box with any mods that add belt-like items (eg bobs, miniloaders [edit: not actually a belt item], etc), though I haven't tested this with anything other than vanilla. This is achieved by grouping belts by their speed to determine the tier, and by using the item's order property to determine how to order items of the same tier.
Vanilla loaders are omitted unless cheat mode is on, since there's no legitimate way to get them.

Thank you for the contribution! However, it doesn't seem to work correctly in the following cases:

In tiers then categories mode, it will scroll up to the first loader, but then stop without letting me scroll to the other loader types
It doesn't appear to work with miniloader

If you can fix these, then I'll be happy to merge it. Thank you again!

The vanilla loader issue is because vanilla doesn't set the next upgrade info for the loaders :( I'll probably solve this by adding some default overrides, unless you have an alternate approach?
I'll have to take a look at mini-loaders and see what's gone wrong there. According the the prototypes, the loaders should be returned with the rest of the belt entities.

So the issue with miniloaders is that the miniloader belt entities are "fake" entities returned by mining. No items can build them, so they're ignored. The miniloaders that are built when you place an item are actually categorized as inserters, not belts.
I'm not sure if or how the mod should re-categorize these - it seems like a more involved task that's orthogonal to this PR.

While I like the idea of this PR, the reason why I never merged it was because I don't really have a problem without it. There are 100 hotbar slots now so reserving four of them for belt things isn't that bad. And the current implementation is super simple and elegant. :)


merge package template from Kronos-Tools/npm-package-template

LICENSE

fix: update LICENSE

Codecov Report

Merging #106 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #106   +/-   ##
=======================================
  Coverage   84.61%   84.61%
=======================================
  Files           1        1
  Lines          13       13
=======================================
  Hits           11       11
  Misses          2        2

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b81679c...8df8ad3. Read the comment docs.


Consider using bors to test and merge PRs

bors is what https://github.com/rust-lang/rust uses to merge PRs since it makes sure that changes are tested as they will appear on the master branch instead of just testing the the PR branch.
Since a while back bors appear to be a lot easier to setup for other repos so we may want to consider using it in gluon as well.
Advantages

No risk of breaking master due to merging subtly conflicting PRs
Can approve PRs without waiting for the PR testing to conclude (can be useful to approve changes that are minor, Currently I may get pinged about a PR and after reviewing and approving it I still have to come back in 30minutes to merge)

Disadvantages

Non-standard way to merge changes on github

Even though I am fairly new to contributing to repos in general (and thus git/travis/etc too), it only took a moment to adjust enough thanks to the contributing guidelines. Although it isn't a github standard, I imagine it would only take a moment for someone to adjust to, especially if noted in the guidelines.
It appears to work quite well for maintaining rust, and as another advantage, It would be consistent for anyone making PR's to large language projects written in rust.
Most of all, if it gives you more time to focus on features without juggling PRs, it sounds invaluable.

@memoryruins  Thanks for the input! I think I will try and add it fairly soon, if it does not work out it should be simple to remove so no big loss there.


fix: use non-dsl arq variant in pipeline

WIP, do not merge, if the PR job fails.

@jludvice self-merging this one now!


Game instantly crashes on 1.14.2 with Fabric

When I add Blur into the mix of mods, the game can't even get to the loading screen. Any suggestions? I was really looking forward to this mod. :\

#28


tests.test_client.TestClientBuild.test_build_min_free_space is unreliable

Sometimes the test passes sometimes it doesn't...
The three tests below are all for the same commit (develop, master and tag). To passed and one failed. Whatever part is unreliable needs to be found and fixed.
OK https://travis-ci.org/Storj/dataserv-client/builds/92306748
FAIL https://travis-ci.org/Storj/dataserv-client/builds/92306822
OK https://travis-ci.org/Storj/dataserv-client/builds/92306844

@littleskunk @F483 Are we doing anything about this issue?

No it will not be relevant for storjnode.


[Feature Request] Provide real toggle group button for asset/table manager view

It's more intuitive.

Part of other ticket.


Issue: Adding policy statements to the CDK boilerplate creates a resolution error: statement.freeze is not a function

Hey there, just wanted to drop a note with a problem I ran into and how I fixed it, considering Google has zero hits for this particular error.
Given I am hosting a DB in AWS RDS, I wanted to deploy the lambda function to a VPC with connectivity to it, whitelisting inbound traffic from the VPC it's attached to. I got the VPC attachment figured out by adding the following config to the lambdaFunction const in appsync.ts:
            vpc: ec2.Vpc.fromLookup(this, "default_vpc", {vpcId: "<VPC_ID>"}),
            allowPublicSubnet: true,
            allowAllOutbound: true,

However, when CDK tried to deploy it, it runs into an issue where it cannot create network interfaces.
In order to fix this, the correct policy has to be added to the lambda execution role. Conveniently, the creators of this package added a policies field in the AppSyncStackProps.function to facilitate this.
HOWEVER, this interface doesn't work properly, as it is passing raw objects to new iamPolicyDocument here. The statement prop this is being passed to expects PolicyStatement[]; -- I believe the fact the AppSyncStackProps.function.policies field lacking a type results in this finding the following weird runtime error: resolution error: statement.freeze is not a function..
What I discovered is that the CDK boilerplate needs to be creating new iam.PolicyStatement and pass that to statements like so:
                 inlinePolicies: {
                    customApiFunctionPolicy: new iam.PolicyDocument({
                        statements:  this.props.function.policies.map((statement) => {
                            return new iam.PolicyStatement(statement)
                        })
                    })
                },

My parameters to AppSyncStackProps in index.ts now looks like this:
function: {
        code: join(process.cwd(), 'handler.ts'),
        policies: [
            {
                actions: [
                    "ec2:DescribeNetworkInterfaces",
                    "ec2:CreateNetworkInterface",
                    "ec2:DeleteNetworkInterface",
                    "ec2:DescribeInstances",
                    "ec2:AttachNetworkInterface"
                ],
                resources: ["*"]
            }
        ],

After implementing this cdk synth now outputs a lambda execution role with the proper permissions and deployment succeeds.
I don't have time at the moment to make a PR for this, but like I said, figured this might be helpful to someone else down the line.
Keywords:
resolution error: statement.freeze is not a function.

Thanks, @yourbuddyconner! Will look into fixing this on the next release.

Fix released in 1.0.0-rc.4.


Marathon SD assumes all applications have a port.

The following line is throwing a panic:
https://github.com/prometheus/prometheus/blob/b5bfb502df63e97d421264898d0417fb31287bef/retrieval/discovery/marathon/marathon.go#L229
This is because task.Ports[0] assumes a length greater than 0,  but the marathon configuration for the app is as follows:
  "portDefinitions": [
  ],

There appears to be a bad assumption that all apps will have ports.
The app that is causing this error is marathon-lb.
The work around is to add a random port definition, but this isn't ideal.

This is fixed in https://github.com/prometheus/prometheus/releases/tag/0.19.3


style guide

We have a module authors guide in the docs, it might be a good idea to have an overall style guide if we start getting significant contributions outside the team.  It would be a nice way to capture things like we prefer to use pkg.errors or how we decide what log level something should be.

Part of this is fixed by http://converge.aster.is/resource-authors-guide/ - is there anything you think is missing?

The only other things I had in mind were things like how to decide what error level is appropriate (e.g. CantChange vs Fatal), and then other sort of procedural things for a PR like using gofmt, linting, and rebasing on master.

The resource authors guide covers the status levels by linking to Godoc. Could you have a look at the contribution guide with an eye to the other things?

On Sep 30, 2016, at 7:13 AM, Rebecca Skinner<EMAIL_ADDRESS>wrote:
The only other things I had in mind were things like how to decide what error level is appropriate (e.g. CantChange vs Fatal), and then other sort of procedural things for a PR like using gofmt, linting, and rebasing on master.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.


Network status indicator

A component that will show network status, it will be visible if you are disconnected.

Thanks @gufranmirza ! amazing work!


JsonSimpleConverter throws java java.util.NoSuchElementException: head of empty list

It seems that arr can be an empty list. So I add these lines and it seems to fix the problem:
    if (arr.isEmpty) {
      return new SchemaAndValue(Schema.STRING_SCHEMA, null)
    }

Is that the right correct fix?

@ryan2x  Please provide the error stack and the context.
the above looks like a hack. you have an array and you return a Schema of String

There are many reasons why arr can be empty. It would be good to understand the context. Avoid hacks without providing the why it happens

Thanks for your fast response. Here is the crash stack. I was wondering why the array is empty. The message is from MQTT.
java.util.NoSuchElementException: head of empty list
at scala.collection.immutable.Nil$.head(List.scala:431)
at scala.collection.immutable.Nil$.head(List.scala:428)
at com.datamountaineer.streamreactor.connect.converters.source.JsonSimpleConverter$.convert(JsonSimpleConverter.scala:76)
at com.datamountaineer.streamreactor.connect.converters.source.JsonSimpleConverter$$anonfun$2.apply(JsonSimpleConverter.scala:95)
at com.datamountaineer.streamreactor.connect.converters.source.JsonSimpleConverter$$anonfun$2.apply(JsonSimpleConverter.scala:94)
at scala.collection.immutable.List.map(List.scala:288)
at com.datamountaineer.streamreactor.connect.converters.source.JsonSimpleConverter$.convert(JsonSimpleConverter.scala:94)
at com.datamountaineer.streamreactor.connect.converters.source.JsonSimpleConverter$.convert(JsonSimpleConverter.scala:70)
at com.datamountaineer.streamreactor.connect.converters.source.JsonSimpleConverter.convert(JsonSimpleConverter.scala:37)
at com.datamountaineer.streamreactor.connect.mqtt.source.MqttManager.messageArrived(MqttManager.scala:73)

JsonSimpleConverter is a best effort to convert from an incoming JSON to a Connect Struct which leads to Avro records into your Kafka topic if you are using AvroConverter for your connector instance.  Your suggested fix is not applicable to this generic converter, but more over you should plug in your own converter for best performance but also because of the following scenario:

Json payload 1: {... "value":10,...}
Json payload 2:{... "value":999999999999,...}
For the two entries above two different schemas will end up being created. You are know your domain so you know your payload best therefore you should write a converter to match that. We have users and customers who have done that. All you need to do is reference com.datamountaineer:kafka-connect-common: and implement com.datamountaineer.streamreactor.connect.converters.source.Converter. And the resulting jar needs to be part of your plugin.path location. Part of our services we do client engagements like this should you require.

I did exactly what you said: I patched empty array situation in the original JsonSimpleConverter and created my own "JsonPatchedSimpleConverter", and use this class as a customized convert, and it works well. Problem solved.
You guys are doing a wonderful job by providing the community source/sink adaptors. Thanks!


YIELDONE docs - add media_types

We would like to add media_types to YIELDONE docs.
This is the code: prebid/Prebid.js#3227

released with 1.31


Phishing and or scam

In OSINT Framework, under people search, engines, general people search, there's a link for the new ultimates. The URL https://www .newultimates.com has either been compromised with a scam or it redirects to https://www.shieldsofisrael com or https://ww7.newultimates.com

Removed. Thanks for the heads up!


add an easy way to find yard plugins

Description
Add an easy way to find yard plugins.
See issue #1139
Completed Tasks

[x] I have read the Contributing Guide.
[x] The pull request is complete (implemented / written).
[x] Git commits have been cleaned up (squash WIP / revert commits).
[x] I wrote tests and ran bundle exec rake locally (if code is attached to PR).

Coverage remained the same at 93.502% when pulling bac35d8c2883925e11108e92e3054edd41b9eba2 on noraj1337:patch-2 into 9fcfe09cc1ea322defaea465c64d870cc6050493 on lsegal:master.

Coverage decreased (-0.01%) to 93.491% when pulling fd3dff03615ddf8e4dda321f62d90153c168de9b on noraj1337:patch-2 into 9fcfe09cc1ea322defaea465c64d870cc6050493 on lsegal:master.

Coverage decreased (-0.01%) to 93.491% when pulling fd3dff03615ddf8e4dda321f62d90153c168de9b on noraj1337:patch-2 into 9fcfe09cc1ea322defaea465c64d870cc6050493 on lsegal:master.

Coverage remained the same at 93.502% when pulling 6aecb5551b7444c9df00c0eb9860f9a34bdeea24 on noraj1337:patch-2 into 9fcfe09cc1ea322defaea465c64d870cc6050493 on lsegal:master.

Thanks for the doc update!

I hope you squashed that :D


added merge completion date: sept 15

half of this warning has been alleviated due to the Eth merge successfully executing on sept 15 2022, so I updated the warning to reflect that

:+1:


Feature Request: Ability to report when test started

Hi, I am trying to create a custom reporter using the karma plugin mechanism.
I can see the specSuccess, specFailure, etc. functions which I can override.
But I wasn't able to find any way to know when a test started.
Would be great to add a hook for that.

Duplicate of https://github.com/karma-runner/karma/issues/501


Get Previous Time Node Bug Fix

Description

Checklist

[x] The code is understandable and maintainable to people beyond the author.
[x] Tests have been added/updated to verify that the new or changed code works.
[x] There is no commented out code in this PR.
[x] The commit message follows good practices.
[x] All docstrings are still up-to-date with these changes.

If user exposed functionality was added/changed:

[ ] Documentation added/updated in the doc folder.
[ ] New or updated dependencies have been added to setup.py.

@onufer I think you need to run black on your files?

Otherwise the changes look good. I'll approve when the tests pass.


Edit Draw will result in a "Loading..." endless Draw.io sceen

Hello,
with your new version (0.6.0) i facing the issue that when I click on "Edit Draw" it will load the draw.io window but the only thing what i see is an "Loading..." circle. See here:

If i go to draw.io and paste my "Source Content" directly via "Extras" -> "Edit Diagram" it will load the draw without any problems and within one second.
What could be the issue?

Hi,
Can you try with the original draw of flowcharting with a new panel ?
Have you an error in console (ctrl+shift+i)

Same issue with a new "panel" (original data) within the same "dashboard". See here:

There are some issues in the Console, see here:

I get the same problem as well. with 6.5. I was in the middle of a presentation too, did not realize it had broken, I just recently upgraded. ah bork.

I have the same problem

I have the same problem.
This function was ok until I upgraded the plugin. I forgot what was my old plugin version. I tried multiple computers the problem is the same.

Reverted to 0.5.0 solved the problem.
sudo grafana-cli plugins install agenty-flowcharting-panel 0.5.0

Can't reproduce,
Can you try with version 0.7.0 in download section ?
algenty.github.io/flowcharting-repository/

@gliu93
You can also copy/paste source into draw.io until next fix

Same with 0.7.0, endless loading. Cutting and pasting the xml does work.


Port Universe to 0.2/Europa

Universe packages must be ported to the Europa syntax. This is a tracking issue for the entire collection of Universe.
For each, we should:

Determine whether it should be ported or not
If it requires further discussion, create a dedicated issue (do not discuss individual packages here)
Have an assignee
And finally, an implementation status ❓🚧 ✅

Before we can start porting these, we must finalize reference packages #1359

Package
Needed by (real configs only)
Should be ported?
Dedicated Issue
Assignee
Status

alpine
changelog.com
✅

@talentedmrjones
✅

argocd
?
:question:

aws
?
✅
https://github.com/dagger/dagger/issues/1388
@talentedmrjones
✅ #1622

aws/cloudformation
?
?

@talentedmrjones

aws/ecr
?
:question:

aws/ecs
?
:question:

aws/eks
?
:question:

aws/elb
?
:question:

aws/rds
?
:question:

aws/s3
?
:question:

azure
?
:question:

azure/resourcegroup
?
:question:

azure/staticwebapp
?
:question:

azure/storage
?
:question:

bats
Dagger CI
:question:

docker
changelog.com, Dagger CI
:question:

docker/compose
?
:question:

gcp
?
:question:

gcp/cloudrun
?
:question:

gcp/gcr
?
:question:

gcp/gcs
?
:question:

gcp/gke
?
:question:

gcp/secretmanager
?
:question:

git
Changelog.com, Todoapp example, Dagger CI
:question:

go
?
:question:

graphql
?
✅

@slumbering

http
?
✅

@slumbering

io
“Dagger classic”?
❌ Deprecated by dagger.io/dagger and universe.dagger.io/docker

java
?
:question:

java/maven
?
:question:

js/yarn
Todo app example
:question:

kubernetes
?
:question:

kubernetes/helm
?
:question:

kubernetes/customize
?
:question:

netlify
Todo app example
:question:

os
“Dagger classic”?
❌ Deprecated by dagger.io/dagger and universe.dagger.io/docker.

random
?
❌ Feels like it should be a future engine feature instead.

terraform
?
:question:

trivy
?
:question:

K8s issue: https://github.com/dagger/dagger/issues/1951

I started working on porting the Terraform package. Any feedback is welcome. Issue #2109, WIP PR #2110

@aluzzardi @shykes Is this issue still useful?

I personally think we should close it, since we're not actively working to port all universe packages. wdyt @aluzzardi @samalba @helderco @jpadams ?

I agree.

I agree as well, the initial plan was to port all of them, but we should instead focus on user requests.


Create pl.json

Add polish translation.

Thank you for the PR! The translations were added in version 2.2.0. :)


Seems awesome, but is it still in active development?

Hi, guys, I am trying to develop a free and public service via api. I am trying to set some rate limit to my APIs. Your repo seems awesome.
But I couldn't help noticing that it's been 2 years since the last commit. So, is this repo still in active development? Thanks.

Hey @medmin! Thanks for your interest.
At the moment there are no bugs or other major issues that are outstanding. With that in mind, the project should work as promised. We are not planning on adding new features at the moment though.
If you are looking for alternatives Kong seems promising when paired with the Rate Limiter plugin. This would decouple your service implementation from the general request handling pipeline that Kong implements.

Thanks.


Fix/gdext v0.1.1

What have been done:

Fixing a compilation error

error[E0004]: non-exhaustive patterns: `godot::prelude::VariantType { ord: i32::MIN..=-1_i32 }` and `godot::prelude::VariantType { ord: 38_i32..=i32::MAX }` not covered
   --> dijkstra-map-gd/src/lib.rs:623:19
    |
623 |             match t {
    |                   ^ patterns `godot::prelude::VariantType { ord: i32::MIN..=-1_i32 }` and `godot::prelude::VariantType { ord: 38_i32..=i32::MAX }` not covered
    |

Specified a specific version of gdext. They released on crates.io and now we can use tags instead of master branch.

Thanks, I was able to build it locally again after updating my rustup install. I always prefer pinned versions where possible, so I'm glad to see this change!

Just rebased the addtional samples branch with these changes.


Saving not working

When I click on "save to gallery", I get an error. Pls fix

Hi! Can you provide some information about your phone? (e.g., version of android)

Android Q, a OnePlus 7T


Segmentation fault in ModelicaStandardTables

Reported by jsten on 27 May 2015 07:10 UTC
When we run the following model ModelicaTest.Tables.CombiTimeTable.Test5 in Valgrind we get the following error:
==15768== Invalid write of size 8
==15768==    at 0x1E44B473: akimaSpline1DInit (ModelicaStandardTables.c:3320)
==15768==    by 0x1E4404F7: ModelicaStandardTables_CombiTimeTable_init (ModelicaStandardTables.c:503)

ModelicaTest.Tables.CombiTimeTable.Test5 uses ModelicaStandardTables_CombiTimeTable_init from ModelicaStandardTables.c which in turn calls akimaSpline1Dinit.
The index of the spline variable on line 3318 is off by one in the last iteration for the loop (double* cc = spline[IDX(i + 1, col, nCols)];).
Relevant inputs from the model are nRow=5, nCol=3, nCols=2.

Migrated-From: https://trac.modelica.org/Modelica/ticket/1723

Modified by dietmarw on 27 May 2015 13:59 UTC

Modified by dietmarw on 27 May 2015 14:16 UTC

Modified by beutlich on 22 Jul 2015 21:14 UTC

Comment by beutlich on 3 Aug 2015 13:29 UTC
Resolved by 461234d4484f516fbf105c54631ba78023e987bb. Thanks for reporting.

Comment by beutlich on 29 Oct 2015 15:19 UTC
Do no longer hide development tickets. Instead leave the Release Notes empty.


Configure external source for release info page

Knocks off another item on the release launch list
ref: https://github.com/kubernetes-sigs/contributor-site/issues/129
ref: https://github.com/kubernetes/sig-release/pull/1115

/lgtm


Beaker 2.1.0 fails on creation of Docker containers with RHEL6 image

Since upgrading to Beaker 2.1.0 I have been unable to successfully provision Docker containers using a Redhat 6 docker image.
It looks like it fails when trying to restart the sshd service.
beaker::Hypervisor, found some docker boxes to create
Provisioning docker
provisioning beaker4
Creating image
Dockerfile is         FROM vrtstdkr001:8080/lightfa/beaker
          RUN yum clean all
          RUN yum install -y sudo openssh-server openssh-clients curl ntpdate
          RUN ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
          RUN ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key
        RUN mkdir -p /var/run/sshd
        RUN echo root:root | chpasswd
        EXPOSE 22
        CMD /usr/sbin/sshd -D
post
/v1.12/build
{:rm=>true}
Dockerfile0000640000000000000000000000061300000000000013245 0ustar00wheelwheel00000000000000        FROM vrtstdkr001:8080/lightfa/beaker
          RUN yum clean all
          RUN yum install -y sudo openssh-server openssh-clients curl ntpdate
          RUN ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
          RUN ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key
        RUN mkdir -p /var/run/sshd
        RUN echo root:root | chpasswd
        EXPOSE 22
        CMD /usr/sbin/sshd -D

Creating container from image 137049ceb16c
post
/v1.12/containers/create
{}
{"Image":"137049ceb16c","Hostname":"beaker4"}
Starting container cc75e9c3e4a56ae509f15144f32a075dc160634b66782fbd5fe3f3ed65380a25
post
/v1.12/containers/cc75e9c3e4a56ae509f15144f32a075dc160634b66782fbd5fe3f3ed65380a25/start
{}
{"PublishAllPorts":true,"Privileged":true}
get
/v1.12/containers/cc75e9c3e4a56ae509f15144f32a075dc160634b66782fbd5fe3f3ed65380a25/json
{}

get
/v1.12/containers/cc75e9c3e4a56ae509f15144f32a075dc160634b66782fbd5fe3f3ed65380a25/json
{}

node available as  ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no<EMAIL_ADDRESS>-p 49233

beaker4 10:23:57$ rpm -q curl
Created ssh connection to <IP_ADDRESS>, user: root, opts: {:password=>"root", :port=>"49233", :forward_agent=>false, :user=>"root"}
curl-7.19.7-37.el6_5.3.x86_64

beaker4 executed in 0.20 seconds

beaker4 10:23:57$ rpm -q ntpdate
ntpdate-4.2.6p5-1.el6.x86_64

beaker4 executed in 0.02 seconds

beaker4. 10:23:57$ echo "/usr/bin"
/usr/bin

beaker4 executed in 0.01 seconds

beaker4 10:23:57$ echo "/opt/puppet-git-repos/hiera/bin"
/opt/puppet-git-repos/hiera/bin

beaker4  executed in 0.01 seconds

beaker4 10:23:57$ echo "/opt/puppet-git-repos/hiera/lib"
/opt/puppet-git-repos/hiera/lib

beaker4 executed in 0.01 seconds

beaker4 10:23:57$ echo "/opt/puppet-git-repos/hiera-puppet/lib"
/opt/puppet-git-repos/hiera-puppet/lib

beaker4 executed in 0.01 seconds
setting local environment on beaker4

beaker4 10:23:57$ echo '
PermitUserEnvironment yes' >> /etc/ssh/sshd_config

beaker4 executed in 0.01 seconds

beaker4  10:23:57$ /sbin/service sshd restart
Stopping sshd: /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/ruby_compat.rb:30:in `select': closed stream (IOError)
        from /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/ruby_compat.rb:30:in `io_select'
        from /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/transport/packet_stream.rb:73:in `available_for_read?'
        from /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/transport/packet_stream.rb:85:in `next_packet'
        from /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/transport/session.rb:178:in `block in poll_message'
        from /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/transport/session.rb:173:in `loop'
        from /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/transport/session.rb:173:in `poll_message'
        from /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/connection/session.rb:460:in `dispatch_incoming_packets'
        from /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/connection/session.rb:221:in `preprocess'
        from /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/connection/session.rb:205:in `process'
        from /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/connection/session.rb:169:in `block in loop'
        from /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/connection/session.rb:169:in `loop'
        from /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/connection/session.rb:169:in `loop'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/ssh_connection.rb:96:in `try_to_execute'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/ssh_connection.rb:107:in `execute'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/host.rb:271:in `block in exec'
        from /usr/local/lib/ruby/2.0.0/benchmark.rb:296:in `realtime'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/host.rb:270:in `exec'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/host_prebuilt_steps.rb:489:in `block in set_env'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/shared/host_manager.rb:74:in `run_block_on'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/shared/host_manager.rb:71:in `block in run_block_on'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/shared/host_manager.rb:70:in `map'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/shared/host_manager.rb:70:in `run_block_on'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/dsl/patterns.rb:32:in `block_on'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/host_prebuilt_steps.rb:471:in `set_env'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/hypervisor.rb:111:in `configure'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/network_manager.rb:71:in `block in configure'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/network_manager.rb:70:in `each_key'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/network_manager.rb:70:in `configure'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-rspec-4.0.0/lib/beaker-rspec/beaker_shim.rb:43:in `configure'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-rspec-4.0.0/lib/beaker-rspec/spec_helper.rb:42:in `block in <top (required)>'
        from /usr/local/lib/ruby/gems/2.0.0/gems/rspec-core-2.14.7/lib/rspec/core.rb:120:in `configure'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-rspec-4.0.0/lib/beaker-rspec/spec_helper.rb:5:in `<top (required)>'
        from /usr/local/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require'
        from /usr/local/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-rspec-4.0.0/lib/beaker-rspec.rb:5:in `<module:BeakerRSpec>'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-rspec-4.0.0/lib/beaker-rspec.rb:1:in `<top (required)>'
        from /usr/local/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:110:in `require'
        from /usr/local/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:110:in `rescue in require'
        from /usr/local/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:35:in `require'
        from /etc/puppet/environments/dev/modules/varnish/spec/spec_helper_acceptance.rb:2:in `<top (required)>'
        from /usr/local/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require'
        from /usr/local/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/cli.rb:44:in `block in initialize'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/cli.rb:43:in `each'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/cli.rb:43:in `initialize'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/bin/beaker:6:in `new'
        from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/bin/beaker:6:in `<top (required)>'
        from /usr/local/bin/beaker:23:in `load'
        from /usr/local/bin/beaker:23:in `<main>'
``

If I comment out line 132 of beaker/hypervisor.rb
i.e. # set_env(@hosts, @options)

Then it will successfully provision the Docker container, but it doesn't find any tests to run.

The command I am using to run the tests is
beaker --log-level trace  --hosts spec/acceptance/nodesets/default.yml --helper /etc/puppet/environments/dev/modules/varnish/spec/spec_helper_acceptance.rb --tests /etc/puppet/environments/dev/modules/varnish/spec/acceptance/standard_spec.rb

The host yaml file is as follows

```yaml
HOSTS:
  beaker4:
    roles:
      - master
      - agent
    platform: el-6-x86_64
    image:  vrtstdkr001:8080/lightfa/beaker
    hypervisor: docker
    docker_preserve_image: false
CONFIG:
  type: foss
  log_level: verbose

It looks like restarting the ssh service closes the connection to the image and this causes the process to fail? I am missing something?
Thanks
Andy

@lightfa Here's a Centos Docker image that works for me:
HOSTS:
  centos-6-x64:
    roles:
      - master
      - database
      - dashboard
    platform: el-6-x86_64
    image: electrical/centos:6.4
    hypervisor: docker
    docker_cmd: '["/sbin/init"]'
    docker_image_commands:
      - 'yum install -y wget ntpdate rubygems ruby-augeas ruby-devel augeas-devel'
      - 'touch /etc/sysconfig/network'
    docker_preserve_image: true
CONFIG:
  type: foss

Does that work for you if you change the image to the one you want?

Thanks Peter.
Unfortunately that doesn't seem to work for me either.
It fails with the same error as before when performing the sshd restart.
Is there a dependency on a specific version of Docker? (I'm running 1.1.2)
beaker4 15:14:22$ /sbin/service sshd restart
Stopping sshd: /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/ruby_compat.rb:30:in select': closed stream (IOError)         from /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/ruby_compat.rb:30:in io_select'
from /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/transport/packet_stream.rb:73:in available_for_read?'         from /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/transport/packet_stream.rb:85:in next_packet'
from /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/transport/session.rb:178:in block in poll_message'         from /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/transport/session.rb:173:in loop'
from /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/transport/session.rb:173:in poll_message'         from /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/connection/session.rb:460:in dispatch_incoming_packets'
from /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/connection/session.rb:221:in preprocess'         from /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/connection/session.rb:205:in process'
from /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/connection/session.rb:169:in block in loop'         from /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/connection/session.rb:169:in loop'
from /usr/local/lib/ruby/gems/2.0.0/gems/net-ssh-2.9.1/lib/net/ssh/connection/session.rb:169:in loop'         from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/ssh_connection.rb:96:in try_to_execute'
from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/ssh_connection.rb:107:in execute'         from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/host.rb:271:in block in exec'
from /usr/local/lib/ruby/2.0.0/benchmark.rb:296:in realtime'         from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/host.rb:270:in exec'
from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/host_prebuilt_steps.rb:489:in block in set_env'         from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/shared/host_manager.rb:74:in run_block_on'
from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/shared/host_manager.rb:71:in block in run_block_on'         from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/shared/host_manager.rb:70:in map'
from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/shared/host_manager.rb:70:in run_block_on'         from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/dsl/patterns.rb:32:in block_on'
from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/host_prebuilt_steps.rb:471:in set_env'         from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/hypervisor.rb:111:in configure'
from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/network_manager.rb:71:in block in configure'         from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/network_manager.rb:70:in each_key'
from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/network_manager.rb:70:in configure'         from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-rspec-4.0.0/lib/beaker-rspec/beaker_shim.rb:43:in configure'
from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-rspec-4.0.0/lib/beaker-rspec/spec_helper.rb:42:in block in <top (required)>'         from /usr/local/lib/ruby/gems/2.0.0/gems/rspec-core-2.14.0/lib/rspec/core.rb:120:in configure'
from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-rspec-4.0.0/lib/beaker-rspec/spec_helper.rb:5:in <top (required)>'         from /usr/local/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in require'
from /usr/local/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in require'         from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-rspec-4.0.0/lib/beaker-rspec.rb:5:in module:BeakerRSpec'
from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-rspec-4.0.0/lib/beaker-rspec.rb:1:in <top (required)>'         from /usr/local/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:110:in require'
from /usr/local/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:110:in rescue in require'         from /usr/local/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:35:in require'
from /etc/puppet/environments/dev/modules/varnish/spec/spec_helper_acceptance.rb:2:in <top (required)>'         from /usr/local/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in require'
from /usr/local/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in require'         from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/cli.rb:44:in block in initialize'
from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/cli.rb:43:in each'         from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/lib/beaker/cli.rb:43:in initialize'
from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/bin/beaker:6:in new'         from /usr/local/lib/ruby/gems/2.0.0/gems/beaker-2.1.0/bin/beaker:6:in <top (required)>'
from /usr/local/bin/beaker:23:in load'         from /usr/local/bin/beaker:23:in '

I'm on 1.4.1, and from looking at the docker API docs it looks like they expect 1.3
Can you try upgrading and seeing if that helps?

Yes that sound like a good idea I'll try a later version of docker. Will update with results.
Thanks again

dupe of #567 ?

Maybe it's different.
What is happening is that docker container is running sshd as the main process, and when beaker executes the ssh restart the container is stopped/killed with the main process

A workaround, add to the hosts config:
    docker_image_commands:
      - "sed -ri 's/^#?PermitRootLogin .*/PermitRootLogin yes/' /etc/ssh/sshd_config"
      - "sed -ri 's/^#?PasswordAuthentication .*/PasswordAuthentication yes/' /etc/ssh/sshd_config"
    docker_cmd:
      - 'sh'
      - '-c'
      - 'service ssh start; tail -f /dev/null'

The workaround is working (with a slight amendment to use service sshd instead of service ssh) and the docker container can be provisioned by beaker.
Thanks for your help with this.

We're tracking docker ssh restart issues in PRs so I'm going to close this out.


Do not check if key is present before removing item in AuthenticationProperties

Do not check if key is present before removing item, this eliminates double lookup.
Use Nullable<T>.GetValueOrDefault() instead of Nullable<T>.Value when it is known to have a value. See #1063 for more info.
Add some unit tests.

Eliminating the extra lookup yields the following result:
Before:

Method
Mean
Error
StdDev
Op/s
Gen 0
Allocated

NullValue_KeyPresent
123.84 ns
2.1405 ns
1.8975 ns
8,074,763.9
0.0036
328 B

NullValue_KeyNotPresent
41.63 ns
0.5963 ns
0.5577 ns
24,022,181.2
0.0021
192 B

After:

Method
Mean
Error
StdDev
Op/s
Gen 0
Allocated

NullValue_KeyPresent
107.04 ns
0.9192 ns
0.8598 ns
9,342,589.5
0.0038
328 B

NullValue_KeyNotPresent
39.53 ns
0.5507 ns
0.4882 ns
25,300,109.1
0.0021
192 B

Benchmark is available here.

@poke That's knowledge you gain for free by aging :-)

@Tratcher I just happened to stumble upon it. I didn't come up in profiling session or anything.

@Tratcher I would assume that this was motivated by the Value to ValueOrDefault() change and then the key checks were seen in the code.. 😄


use ioutil package to support go1.16

@ZQHcode whilst we obviously could do this, and on the face of it it seems like a small change, as I mentioned on https://github.com/Shopify/sarama/issues/2062#issuecomment-962046996 — k8s.io/client-go and others have similarly moved towards a minimum of Go 1.16 in recent months and we only test and maintain Sarama on the most recent two major releases of Go. Unfortunately we don’t have a large enough pool of maintainers to cover more. Go 1.15 and earlier no longer receive security updates and are unsupported by the Go team so I’d strongly recommend that you update your toolchain

@ZQHcode whilst we obviously could do this, and on the face of it it seems like a small change, as I mentioned on https://github.com/Shopify/sarama/issues/2062#issuecomment-962046996 — k8s.io/client-go and others have similarly moved towards a minimum of Go 1.16 in recent months and we only test and maintain Sarama on the most recent two major releases of Go. Unfortunately we don’t have a large enough pool of maintainers to cover more. Go 1.15 and earlier no longer receive security updates and are unsupported by the Go team so I’d strongly recommend that you update your toolchain


Clarify Pre-requisites

The steps to create the app package asks user to run npm install and gulp, however there are no mentions of installing NPM or Gulp in pre-requisites.
Running latest version of NPM was resulting in failures when running npm install. Only using Node 10.24 from https://nodejs.org/en/download/releases/ fixed that issue.
To install gulp, I had to run npm install -g gulp .
The pre-requisites should provide reference to appropriate node.js version and download links as well as reference to command to install gulp so the steps don't fail and create confusion for someone who doesn't have developer background and is relying on instructions.

@bhargavshukla  Updated pre-requisites

Thanks for updating this @eshwarmsft and for the feedback @bhargavshukla


WIP: Expose kubeconfig (staging)

Same as https://github.com/kube-hetzner/kube-hetzner/pull/28, just for the staging branch

@mysticaltech I think this was not supposed to be closed. It happened because the target branch has been deleted.

Oh my bad! Sorry folks, just cleaned up the staging branch! Did not mean to close that one!

Please @phaer, just rebase on master. Looking forward to it.

Yeah no worries, the branch is intact and I've got everything locally anyways.
Feel free to take over if you've got the time, I am running a bit low atm so I could take me a week or two until everything is done and tested

No worries @phaer, me too, kind of short on time, just wanted to make sure we have something stable ASAP with MicroOS. Keep up the good work man!


CCDB GE/030 - Section 2.5.3 / cPP

Comment:
In the PP the threat T.HW_ATTACK is defined as: "An individual with physical access to the TOE may apply hardware attacks such as probing, physical manipulation, fault-injection, side-channel analysis, environmental stress, or reactivating blocked test-features or other pre-delivery services to manipulate the behavior of the TOE to disclose SDOs."  Some relevant HW Attacks for AVA_VAN.1 (9 Points) are missing. Many of these aspects are not covered by the objectives or the SFRs claimed in the PP. OE.Physical covers most of the attacks, but not all relevant attacks. Since FPT_PHP.3 is claimed, possible attack Scenarios with a Proficient (3 Points) with an Specialized Equipment (3 Points) or an Expert (6 Points) with Standard Equipment (0 Points) should be considered. In the JIL Document „Application of Attack Potential to Smartcards and Similar Devices“ you can find a list of Equipment and Expertise description for HW Attacks.
Proposal:
Relevant HW Attacks should be included in the supporting document. Perhaps an update of the PP is necessary.
Priority: 1

I think this is well outside the scope of a TD, but should definitely be reviewed for v1.1.

https://www.sogis.eu/documents/cc/domains/sc/JIL-Application-of-Attack-Potential-to-Smartcards-v3.2.pdf as reference

Thinking about this, it seems like we should state explicitly that the AVA_VAN check is on exploitation and not investigation. I don't think that realistically we are looking at a combined ID + Exploit total for an attack.
In trying to see how this would play out, I think this is reasonable at the basic attacks we are looking at, that the attack is already identified, so we are looking to prevent things that can be exploited (and anything that is so easy to ID, is likely easy to exploit anyway).
This may not be correct, but it seems reasonable for the iteration we are looking at right now.

Another thought about this is that I am not sure I agree with OE.PHYSICAL not covering all the attacks. Since these are physical attacks, preventing physical access would seem to do so. The real question is simply how long it needs to be protected against (is the attack something that can be done in minutes, or does it take hours?).  I think the real issue is that the second paragraph description talks more about ways to wipe the TOE, and I think that actually is too focused on what would seem to be the mobile device use case. I think that paragraph should be removed from 5.2 (it could be moved into the intro section if it is useful, but I think it is only adding confusion here).

Perhaps the 2nd para might be moved. Yet, considering all different types of physical attacks IMHO is not warranted.  Then an attacker may not try to perform a complex hardware attack, but rather pulls out his gun, holds it at the owners temple and asks politely for the passcode.
If the attack is not targeted to the specific user, but rather to take possession of the device, the remote wipe operation as outlined is sufficient.
The mentioned JIL refers more to smart cards which cannot be wiped and this has to have a strong hardware security. This is aggravated by the problem that some smart cards have a trust anchor that rests on security by obscurity where hiding of that anchor via hardware means is necessary as otherwise the entire product range may be compromised. This all is not applicable here where each device has its own trust anchor that is unrelated to the next device's trust anchor.

My proposal for this is to reject the specific suggestion to change the threat but to move the paragraph with OE.PHYSICAL into the introduction (that will be updated) as additional content to include. I think that is good overview (maybe, anyway) information but doesn't need to be added.
As a general consideration, I normally don't like to see additional text with the SDP since if the statement itself isn't clear enough, then maybe it needs to be reconsidered (such as rewritten, or maybe it is actually more than a single thing).

Summary of discussion on 9-14 call
The DSC is not intended as a standalone product, but something integrated into a broader product. Side channel attacks against smart cards are not as simple when multiple separate processors exist within the device (or the board, or maybe even within the chip), making the likelihood of pulling out usable data from the DSC component difficult.
If independent vulnerability testing can see how to perform this type of test within the overall attack potential, then it would be fine to include in that testing, but this is outside the scope of what can be reasonably managed within the confines of the requirements in the DSC cPP. As the proposed scores are already 6 out of 9 points, this would limit the timeframe and knowledge of the product to perform an attack. It seems unlikely that an embedded component as the DSC would be will lend itself to attacks within 2 weeks without non-public knowledge. Similarly since the attack would require disassembly of the product, it would seem unlikely that unlimited access or easy access would be used in the calculation.
The extra paragraphs will be moved out which will help some on the clarity, but no specific activities or claims will be made on side channel protection.

Maybe to take out the side channel mention, and then to add in some description into the introduction that makes it clear that this is not a stand alone component, but part of a larger system.


Inconsistent styling of forum icon buttons

Describe the bug
The following icon buttons of the of the new topic / reply dialog don't have their colors inverted on hover:

enter full screen composer
minimize the composer panel
toggle preview

To Reproduce
Steps to reproduce the behavior:

Go to the forum: https://forum.freecodecamp.org/
Click on + New Topic
Hover over the icon buttons on the right

Expected behavior
I expect colors of the buttons to be inverted - so that I can see what button I'm hovering over.
Screenshots
Incorrect behaviour:

Expected:

If someone will confirm that it is actually a bug, I'd be happy to fix that as my first contribution :)

I see, this is a bug. the icon color should be inverted.
Please make selector as specific as possible to avoid unwanted changes in other areas of the UI.
Our theme repo is here: https://github.com/freeCodeCamp/forum-theme/
And you could test your changes using theme creator: https://meta.discourse.org/t/beginners-guide-to-using-theme-creator-and-theme-cli-to-start-building-a-discourse-theme/108444
Best of luck and let me know if you need further assistance.

Okay, thanks for the tips, I'll get on with it then :)

I've found a way to invert the colors:

Do you think the following selector will be specific enough?
#reply-control .btn-mini-toggle:hover {
  .d-icon {
    color: $secondary;
  }
}

If so, I should send a PR to the theme repo, right? :)

Hey @sitek94,
Please do open a PR so we can look at your solution.
If changes are needed we can discuss them there.

@sitek94, Yes and yes :)
Also feel free to audit the rest of the theme for similar inconsistencies.

We have enabled the /styleguide path on the forum for you all to debug things better. It's available here: https://forum.freecodecamp.org/styleguide


[QA] Chat messages can be seen globaly

Explorer Alpha build version:
0.3.250-main-08f208c
Issue Description:

It's possible to read chats of players that are in different coordinates than our own avatar.
Steps to reproduce:

Be with more than one player in the same place and chat
Go to different coordinates (far away)
Observe

Expected behaviour:
We can only read chat and chat with people that are close to us
Current behaviour:
The chat can be read globaly

@olavra isn't there 2 types of chat? Global and the local one

Nope, for now is only local

Ok, island chat will be removed

@NickKhalow lets chat about this I do not think we should remove the island chat. There may be an issue with archipelago and how we are reporting the positions and its managing the clusters of users.

@m3taphysics I don't think we should the island chat either, moreover it may affect User experience pretty badly


Enhancement: final sanity check plot

Let's make a final cell which compares the synphot expected count rate (y) with the measured count rate (x), with a 1:1 line over plotted; perhaps with two subplots – one for APO, another for Kepler.

Done! Let me know if there's a way you think I could improve it.

Looks good!


Endcap asymmetry

There is something causing asymmetry in the endcaps. When generating photons with WCSimLIGen, I found asymmetry when plotting charge maps (diffuser open angle 40 degrees):

Top endcap, central diffuser at (0,0,+3305.82)

Bottom endcap, central diffuser at (0,0,-3305.82)

Bottom endcap, centre edge diffuser
I have checked amongst other things:

Using hard-coded diffuser angles in WCSimLIGen in case there was an error reading in the angles.
Generated photon angles - these are in line with the diffuser angles e.g. injector angles of theta = 0, phi = 0, with a direction (0,0,-1) sets all photon directions to (0,0,-1) as expected.
Deactivating WLS plates

Photon visualisation looks fine:

If I set the injector open angle to zero and point it straight down, I get the same asymmetry. However if I use the old geometry it looks pretty symmetrical:

I can't find any obvious overlaps in the new geometry but will continue to investigate.

For detector visualization, I am usually using the OGLSX option, like macros/visOGLSX.mac. This requires GEANT4_USE_OPENGL_X11=ON and relevant libraries be available in geant4 installation.
For the histograms, can you check whether each bin contains the same number of PMTs? It could be a plotting artifact if some bin contains more PMTs than others.

Thanks @kmtsui, I'll try to get the visualisation working with the PMTs and WLS plates. For the histograms, each bin represents a single PMT so it's not an artefact of binning. I've looked quite carefully for bugs in the plotting code but there's nothing obvious and since I get a symmetrical distribution in the plots of sims using the old geometry I think I can rule out an issue with the plotting but I'll keep checking.

Resolved by PR #486 :

Bottom endcap diffuser


TypeScript helpers suggestion.

Hello,
I have used feathers-vuex with TypeScript in a project and I made a set of helpers that I think could be really useful to other developers, here you can see the source code and below is an example of usage:

import Vue from 'vue'
import { Component } from 'vue-property-decorator'
import { namespace, Action } from 'vuex-class'
import { ActionGet, ActionCreate, ActionPatch } from '../types/feathers'
import { Person } from '../types/models'

const PeopleAction = namespace('people', Action)

@Component
export default class CreateEditPeople extends Vue {
  @PeopleAction('get') getPerson: ActionGet<Person>
  @PeopleAction('create') createPerson: ActionCreate<Person>
  @PeopleAction('patch') patchPerson: ActionPatch<Person>
  // some extra here
}

TypeScript reads it really well and all suggestions and autocomplete helps a lot.

Cool!
@nickmessing how would one use your feathers-vuex-helpers.ts file in their project?  This looks like something that ought to go into the docs in a "Using with TypeScript" section.  We can link to your helpers gist.

@marshallswain, I could finalize the typings and make a PR to make them universal so people can use them with bot class-component definition and classic component definition if you want to support that.

I know absolutely nothing about TypeScript, but I know that a lot of people
will appreciate this. I might even learn something, here, so I’d like to
support it, yeah. :) please make a PR when you have time. That would be
terrific!
On Sun, Apr 22, 2018 at 3:25 AM Nick Messing<EMAIL_ADDRESS>wrote:

@marshallswain https://github.com/marshallswain, I could finalize the
typings and make a PR to make them universal so people can use them with
bot class-component definition
https://gist.github.com/nickmessing/f206056cb0eb8879b068f727a1aaecbb
and classic component definition
https://gist.github.com/nickmessing/dfc8264ecc17d68ed5aaa82bd253d4e5 if
you want to support that.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/feathers-plus/feathers-vuex/issues/114#issuecomment-383367639,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAH3WTT3-Bo75lv1FXsC0p0WseLN8_0xks5trEx5gaJpZM4TcmIA
.

@NickBolles I just removed my client side project that used TypeScript, just to regenerate it as a JavaScript project.
Steps I tried to add typings to feathers-vuex:

Check if a @types/feathers-vuex definition exist, it does not.
Add my own typings directory to 'typeRoots' in tsconfig, specify a directory with the name feathers-vuex, with in it a index.d.ts with your code in it.
Renamed the 'declare module 'vue/types/vue' in your file to 'feathers-vuex' since that is what the cli told me to do (create a .d.ts file with a 'declare module "feathers-vuex";' in it. I then get an error that it can not be augmented. I delete all the code above 'declare module "vue/types/vue" in your file (which is "feathers-vuex" in my file). Then the error goes away. But it would still not recognize the typings.

Finally, I did what I said in the beginning and removed TypeScript just so I can follow along with a tutorial using this library.

@bartduisters There are probably other ways to achieve this without built in typings (which I believe are coming in v2), but here's how I have it setup
I have a folder @types/feathers-vuex with an index.d.ts in it with that content from my post above (which I just updated). Then I have a file @types/feathers-vuex-app.d.ts with the following content in it.
import { Services } from "../store";
import { FeathersVuexGlobalModels } from "feathers-vuex";

declare module "vue/types/vue" {
  interface FeathersVuexPluginType extends FeathersVuexGlobalModels<Services> { }
}

This will extend the Vue prototype typings with
This file is picked up by typescript by declaring it in the "typeRoots" in the tsconfig.json.
{
  "compilerOptions": {
    "typeRoots": [
      "./node_modules/@types/",
      "./client/@types/"
    ],
  }
}

where store/index.ts contains this (and more). You should probably break this into it's own file actually, but I have it in store/index.ts along with my store content. Also this is importing the user service from my feathers server, which was generated by feathers-plus cli. It could simply be an interface that you define though.
import { User } from "../../server/services/v1/users/users.interface";
export interface Services {
  users: User;
}

Thanks for the clarification. Will try it as soon as I try another project with TypeScript and feathers-vuex!


Feature: a cmdline tool to explore a cloverDB

Hello, and thanks for this excellent lib!
The title says it all: is there a cmdline tool to explore a cloverDB? Query collections and documents, insert, delete, create indexes...
If not, is it planned?
Thanks :)

Hi, @matwachich, currently it is not in my plans. But if you would like building one, I would certainly collaborate to the project :=)


Diffbot Graph Transformer / Neo4j Graph document ingestion

@baskaryan Could you advice where it would be best to put docs/notebook, so we can get this merged in?


Publish to docker hub under bucharest-gold

The Makefile specifies the namespace for publishing to Docker Hub. Create a bucharest-gold Docker Hub account and use a bucharest-gold namespace for publishing these images.

Publish images to Docker Hub for each of the Node.js releases. Be sure to tag the GitHub repository with versions for these releases (not the Node.js version, but versions for the published images)

Done. https://hub.docker.com/r/bucharestgold


Display Key Mappings in Settings

Summary of the Pull Request

Single Key and Shortcut mappings are displayed in the KeyboardManager settings key.
Keyboard Manager can be enabled and disabled from the Settings page.

References

PR Checklist

[x] Applies to #889
[x] CLA signed. If not, go over here and sign the CLA

Detailed Description of the Pull Request / Additional comments

Validation Steps Performed

Also we should create an issue to track the input language change does not reflect in SettingsV2 until the control is reloaded. This would probably be a v1 thing or maybe even future, but it's good to keep track of it.


fix: correctly check if vsinstalldir is in $path on msvc

Before this commit having a falsly setup VSINSTALLDIR would not trigger the error.
This had two reasons:

first, the CMake string FIND module had the arguments mixed up
second, the check itself never expanded the output variable from the string FIND

After this commit the error should be emitted if $VCINSTALLDIR is not in $PATH

Sadly, after this it is still possible that the check succeeds but the asan runtime lib is still not found. @aminya i am not sure if this check is enough to ensure valid asan support for msvc.


Support for More JDK Distributions

Is your feature request related to a problem? Please describe.
Mostly not, but it could be for some people. Some people may want to use a custom JDK distribution with custom features, or want a JDK that can perform better (Oracle GraalVM (NOT GRAALVM Enterprise Edition or Community Edition) is known to be able to perform better than Temurin, though they're both good options)
Describe the solution you'd like
Add support to choose from a list of JDKs or use a custom download for a Java URL that's tar.gz and let the panel handle the rest.
Describe alternatives you've considered
Manually copying a self downloaded JDK over. It works and I made symbolic links, but it's not ideal in case an update of the JDK is needed.
Additional context
N/A

This is where I will point to using Docker to run the servers.
There is a lot of concerns about things like binary naming, how to handle mixing, and so on. Docker is designed to handle this a lot smoother and isn't limited by what we do.

This is where I will point to using Docker to run the servers.
There is a lot of concerns about things like binary naming, how to handle mixing, and so on. Docker is designed to handle this a lot smoother and isn't limited by what we do.

I see, then maybe add support to choose a custom Docker JDK image for the Docker templates?

I consider it an edge case, and one that only advanced would use. You can override the image as an admin, so I don't see why we need to make it a drop down or anything.


Shift all documentation focus to Markup 2.0

Populate refactor branch readme like main

Reopening as the docs still need a ton of work (e.g. some of the sections are just placeholders for now). Will complete as the last task for the stable V2 release.


Build errors when using latest Ember and ember-cli-chart

I am seeing the following build error when I use this add-on.
Build failed.
The Broccoli Plugin: [BroccoliMergeTrees: TreeMerger (vendor & appJS)] failed with:
Error: ENOENT: no such file or directory, open 'C:\repos\ember-quickstart\tmp\source_map_concat-input_base_path-ECsfiHVC.tmp\C:\repos\ember-quickstart\node_modules\chart.js\dist\Chart.js'
    at Error (native)
    at Object.fs.openSync (fs.js:641:18)
    at Object.fs.readFileSync (fs.js:509:33)
    at SourceMap.addFile (C:\repos\ember-quickstart\node_modules\fast-sourcemap-concat\lib\source-map.js:75:31)
    at C:\repos\ember-quickstart\node_modules\broccoli-concat\concat.js:200:16
    at Array.forEach (native)
    at Concat.<anonymous> (C:\repos\ember-quickstart\node_modules\broccoli-concat\concat.js:198:24)
    at C:\repos\ember-quickstart\node_modules\fast-sourcemap-concat\lib\source-map.js:393:12
    at initializePromise (C:\repos\ember-quickstart\node_modules\rsvp\dist\rsvp.js:567:5)
    at new Promise (C:\repos\ember-quickstart\node_modules\rsvp\dist\rsvp.js:1039:33)

The broccoli plugin was instantiated at:
    at BroccoliMergeTrees.Plugin (C:\repos\ember-quickstart\node_modules\broccoli-plugin\index.js:7:31)
    at new BroccoliMergeTrees (C:\repos\ember-quickstart\node_modules\ember-cli\node_modules\broccoli-merge-trees\index.js:16:10)
    at Function.BroccoliMergeTrees [as _upstreamMergeTrees] (C:\repos\ember-quickstart\node_modules\ember-cli\node_modules\broccoli-merge-trees\index.js:10:53)
    at mergeTrees (C:\repos\ember-quickstart\node_modules\ember-cli\lib\broccoli\merge-trees.js:85:33)
    at EmberApp._mergeTrees (C:\repos\ember-quickstart\node_modules\ember-cli\lib\broccoli\ember-app.js:1817:12)
    at EmberApp.javascript (C:\repos\ember-quickstart\node_modules\ember-cli\lib\broccoli\ember-app.js:1299:17)
    at EmberApp.toArray (C:\repos\ember-quickstart\node_modules\ember-cli\lib\broccoli\ember-app.js:1674:12)
    at EmberApp.toTree (C:\repos\ember-quickstart\node_modules\ember-cli\lib\broccoli\ember-app.js:1696:38)
    at module.exports (C:\repos\ember-quickstart\ember-cli-build.js:22:14)
    at Builder.setupBroccoliBuilder (C:\repos\ember-quickstart\node_modules\ember-cli\lib\models\builder.js:56:19)

To verify my configuration I rolled back to the simple ember-quickstart app. Still repros. Any ideas what is going on here?
Thanks in advance.

Does ember-cli-chart 3.2.0 work for you? Could be related to my issue..
https://github.com/aomran/ember-cli-chart/issues/77

I installed<EMAIL_ADDRESS>and generated a fresh app. I installed this addon and it worked. This is all using node v6.11.0.
What node version are you using and does npm install work for you?

I am using:
ember-cli: 2.13.3
node: 6.11.0
os: win32 x64

Contents of my package.json:
{
  "name": "ember-quickstart",
  "version": "0.0.0",
  "description": "Small description for ember-quickstart goes here",
  "license": "MIT",
  "author": "",
  "directories": {
    "doc": "doc",
    "test": "tests"
  },
  "repository": "",
  "scripts": {
    "build": "ember build",
    "start": "ember server",
    "test": "ember test"
  },
  "devDependencies": {
    "broccoli-asset-rev": "^2.4.5",
    "ember-ajax": "^3.0.0",
    "ember-cli": "2.13.3",
    "ember-cli-app-version": "^3.0.0",
    "ember-cli-babel": "^6.3.0",
    "ember-cli-chart": "^3.3.0",
    "ember-cli-dependency-checker": "^1.3.0",
    "ember-cli-eslint": "^3.0.0",
    "ember-cli-htmlbars": "^1.1.1",
    "ember-cli-htmlbars-inline-precompile": "^0.4.0",
    "ember-cli-inject-live-reload": "^1.4.1",
    "ember-cli-qunit": "^4.0.0",
    "ember-cli-shims": "^1.1.0",
    "ember-cli-sri": "^2.1.0",
    "ember-cli-uglify": "^1.2.0",
    "ember-data": "^2.13.2",
    "ember-export-application-global": "^2.0.0",
    "ember-load-initializers": "^1.0.0",
    "ember-resolver": "^4.0.0",
    "ember-source": "~2.13.3",
    "ember-welcome-page": "^3.0.0",
    "loader.js": "^4.2.3"
  },
  "engines": {
    "node": "^4.5 || 6.* || >= 7.*"
  },
  "private": true
}

I tried creating a new ember project (ember new testApp), then installed ember-cli-chart (ember install ember-cli-chart), and then build (ember build). Same error. I ran npm install (npm install ember-cli-chart) and then re-ran the ember install and build. Same error.
What else can I offer to help diagnose. I have zipped up my test project and attached it.
testApp.zip
Let me know what you think.
Thanks in advance, John

OK. A bit more information. If I run only npm install ember-cli-chart, then ember build still works. If I run ember install ember-cli-chart I get the the error above.
Thanks again, John

This error seems to only occur on windows.

likely duplicates #77 so closing this -- let's keep the conversation there.


az login APIVersion 2019-06-01 is not available on Archlinux

This is autogenerated. Please review and update as needed.
Describe the bug
Command Name
az login
Errors:
APIVersion 2019-06-01 is not available
Traceback (most recent call last):
python3.8/site-packages/knack/cli.py, ln 215, in invoke
    cmd_result = self.invocation.execute(args)
cli/core/commands/__init__.py, ln 625, in execute
    raise ex
cli/core/commands/__init__.py, ln 689, in _run_jobs_serially
    results.append(self._run_job(expanded_arg, cmd_copy))
cli/core/commands/__init__.py, ln 682, in _run_job
    six.reraise(*sys.exc_info())
...
azure/cli/core/_profile.py, ln 844, in find_through_interactive_flow
    result = self._find_using_common_tenant(token_entry[_ACCESS_TOKEN], resource)
azure/cli/core/_profile.py, ln 877, in _find_using_common_tenant
    tenants = client.tenants.list()
mgmt/resource/subscriptions/_subscription_client.py, ln 127, in tenants
    raise NotImplementedError("APIVersion {} is not available".format(api_version))
NotImplementedError: APIVersion 2019-06-01 is not available

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az login

Expected Behavior
Environment Summary
Linux-5.5.13-arch2-1-x86_64-with-glibc2.2.5
Python 3.8.2
Installer: PIP

azure-cli 2.3.1

Additional Context

hi @arrownj could you pls have a look

Hi @boogy , it seems that your azure-mgmt-resource version is not right. Could you please help tell what platform you are using? If you are on Windows, maybe you can check the SDK version by open folder C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\Lib\site-packages and check its child folder which starts with azure_mgmt_resource (it should be something like azure_mgmt_resource-8.0.1.dist-info).

Similar to #12779 . Please use the official azure_mgmt_resource sdk and let us know if there are other problems.


Give a warning about the obsoleted minute plugin

This should be merged once the internal repo is completely ready.

Ack :).


⚠ Mobitopup has degraded performance

In d56d618, Mobitopup (https://napcard.voz.tech) experienced degraded performance:

HTTP code: 200
Response time: 4178 ms

Resolved: Mobitopup performance has improved in 2064f9a.


doc-dash-holistic-view

Draft document; moved from private repo.

Closed because merged into the public repo Azure/DASH.


Feature: Simplify and automate more of the build process

Simplify the build process for the ESB Toolkit DLL's
Automate the version number update in UacElevate manifest
Automate the version number update in Tools CommonAssemblyInfo.cs
This work item was migrated from CodePlex
CodePlex work item ID: '11157'
Assigned to: 'tfabraham'
Vote count: '1'

[UnknownUser@2/5/2017]
Resolved with changeset 79722.


Scan the Barcode within specific div instead of full screen

How do we scan the QR code within particular div instead of Full Screen? Can we control the Scanning View port size?

+1

Closing because it's a duplicate of https://github.com/phonegap/phonegap-plugin-barcodescanner/issues/223
On iOS and android it's impossible to put a native view inside a div, not sure about windows.
Making the scanner view not full screen might be possible, but will require a lot of extra work, PRs are welcomed


dmenu: add conf option

Description of changes
Allow users to set their own config.h file, similarly to dwm.
See here for a usage example.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

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

[x] Fits CONTRIBUTING.md.

cc @pSub @globin

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/3415


Add support for jyperk / systemp to array config files

These are only used by miriad at the moment, but we could store these easily enough and pass them on to the writer

Deciding not to do this one


limit number of rows

Why I get the version that is 1.4.0?

Why I get the version that is 1.4.0?

I am sorry @IPOSDai I don't understand what version?

Why I get the version that is 1.4.0?

I am sorry @IPOSDai I don't understand what version?

NO maximumRowsCount property,  pod 'TagListView', '1.4.0'

NO maximumRowsCount property: pod 'TagListView', '1.4.0'

Okay @IPOSDai  this pull request didn't get merge yet (hopefully it does 🤞)
But for time being if you want to use this, you just use my fork instead
simply replace pod 'TagListView', '1.4.0' with pod 'TagListView', :git => "https://github.com/iAmrSalman/TagListView".
But remember to switch back once this pull request is merged.

Okay, Thanks .


Create bearzi.it and bearzi.org

Official website https://www.bearzi.it
IT Course https://www.bearzi.it/iti/presentazione-dei-corsi/
@bearzi.it is the domain used by teachers and @bearzi.org is the students' domain

@fabioburco Please rename lib/domains/it/bearzi to lib/domains/it/bearzi.txt and
lib/domains/org/bearzi to lib/domains/org/bearzi.txt.
Thank you.

Sorry, I added the extensions!

@fabioburco I am sorry for a delay with processing your request.
Pull request merged. Thank you!


Is AWS Provider required?

I'm getting this error from a fresh checkout of origin/master. After a successful Ansible build, i then run "vagrant up" results in the following error.
There are errors in the configuration of this machine. Please fix
the following errors and try again:
AWS Provider:

An access key ID must be specified via "access_key_id"
A secret access key is required via "secret_access_key"
vagrant_aws.config.ami_required

Did some searching, i needed to update Virtualbox
vagrant up --provider virtualbox

Glad you found the fix!


Compatibility with rails 8.0

Hello Scalingo Team,
Any chance you could bump up the gemspec to make the gem compatible with Ruby on Rails 8.0?
Currently getting this error message:
Could not find compatible versions05:27
Because scalingo >= 3.1.0 depends on activesupport >= 5, < 8
  and scalingo < 3.1.0 depends on activesupport >= 5, < 7,
  activesupport >= 5, < 8 is required.
So, because rails >= 8.0.1 depends on activesupport = 8.0.1
  and Gemfile depends on rails ~> 8.0.1,
  version solving has failed.

Thanks for your report
We'll have a look as soon as possible
That being said, we are a bit swamped at the moment, but if you'd like to put up a PR we can merge