Reification

Meta-issue to track reification implementation

https://discourse.cayley.io/t/wip-bolt-2-reification-boogaloo/550/2

Happy Holidays all! While sitting at home with my folks I broke ground on a complete rewrite of the Bolt backend that could support our reification plan.

I've been reading through the github issues and the discourse topics, but I'm having a hard time piecing together how exactly Cayley plans to tackle reification. The most informative posts I could find is https://discourse.cayley.io/t/paper-chase-reification-aka-putting-data-about-links-on-links/328, but it doesn't really list a decision.

Any info would be greatly appreciated :)

@hidde-jan The current plan is to assign an unique ID for every node and quad, plus keep a hash index for these values as well. For quads we already have such index (SPOL index), and for values we will just separate an ID from hash (nodes were content-addressable before). Current implementation is done for KV in general and Bolt in particular (we call it bolt2). Although it's not yet exposed in any way.

@dennwc Thanks for the answer!

The current plan is to assign an unique ID for every node and quad

How exactly do you assign these IDs? Or is it implementation specific? If I have a specific quad, can I always determine its ID? I'm  investigating how people are currently implementing (and representing) reification for linked data. Since Cayley is working on their implementation I'm very curious about the choices you made.
Cheers

ID allocation is implementation-specific, but in general after reification we cannot determine quad ID without an index lookup.


Change toggle comment behaviour. Fixes #4198

Simple solution to the issue 4198.
Thanks @neikeq for the patience.

@luiz-pv9 It's not related to the commit, but you apparently use an email address in your git config that does not match the addresses defined in your GitHub account, so the commit does not appear linked to your account. It's not a problem, but if you'd like it to be linked to your GitHub account, you can add the email used in the commit in your GH settings.

Thanks for the feedback :)
Removed unnecessary variable and fixed my e-mail

Thanks @neikeq for the patience.

If you mean the confusion with the begin > end check, it was actually my mistake :P


Should Program automatically re-define existing definitions instead of allowing duplicates?

In pyQuil, when adding something like a DefGate or DefCalibration to a Program, it checks if the identifier has an existing definition first. If it exists, it replaces the existing definition with the new one. This is in contrast to quil-rs, which will always just add it to the program, which can lead to multiple definitions for the same identifier.
Should quil-rs mirror pyQuil's behavior here, or do we chalk it up to user error? To implement, we'd need to refactor CalibrationSet and FrameSet to behave like sets, with appropriate data types. We'd also need a new field to efficiently manage what gate definitions exist in the program.

The Quil spec doesn't state that multiple definitions of a DEFGATE or DEFCAL is invalid. quilc and QVM also both support duplicate DEFGATE definitions, so allowing it errs more on the side of representing Quil faithfully, but could be an inconvenience for downstream users.

Since the Quil spec considers this valid, we are not going to implement this as part of quil-rs.

I would add that the performance concern is much more significant than I had previously realized. In this direction we have discussed the addition of a method that would actually remove unused definitions in order to reduce serialization overhead.
One additional comment is that retrieving definitions for instructions is a common task that would be considerably easier and faster if they were stored as a dictionary. Some definitions (eg frames) already are while others are not.


Result builder annotations are ignored in extensions

Description
// define some @resultbuilder
struct Foo<T> {}

@resultBuilder
enum FooBuilder {
    static func buildBlock<T>(_ components: Foo<T>...) -> Foo<T> {
        .init()
    }
}

// some protocol where a property is annotated with the previously defined result-builder
protocol Bar {
    @FooBuilder
    var body: Foo<Int> { get }
}

// this works as expected:
struct MyBar1: Bar {
    var body: Foo<Int> {
        Foo<Int>()
        Foo<Int>()
    }
}

// this also works as expected:
struct MyBar2: Bar {}
extension MyBar2 {
    @FooBuilder // explicit @FooBuilder-annotation
    var body: Foo<Int> {
        Foo<Int>()
        Foo<Int>()
    }
}

// This gives an error:
struct MyBar: Bar {}
extension MyBar {
    var body: Foo<Int> {
        Foo<Int>()
        Foo<Int>() // Error: Missing return in getter expected to return 'Foo<Int>'
    }
}

If a protocol-requirement is annotated with a result builder, then the annotation seems to be ignored if the requirement is implemented in an extension on the conforming type.
Expected Behaviour
The annotation is also respected in extensions, or, if for some reason this is not possible, a meaningful error-message is shown.
Environment

swift-driver version: 1.75.2 Apple Swift version 5.8 (swiftlang-<IP_ADDRESS>.2 clang-14<IP_ADDRESS>.100)
Target: arm64-apple-macosx13.0
Xcode 14.3

Remarks
The same happens also if the body if a View is implemented in an extension. Error:

Function declares an opaque return type, but has no return statements in its body from which to infer an underlying type

Description
// define some @resultbuilder
struct Foo<T> {}

@resultBuilder
enum FooBuilder {
    static func buildBlock<T>(_ components: Foo<T>...) -> Foo<T> {
        .init()
    }
}

// some protocol where a property is annotated with the previously defined result-builder
protocol Bar {
    @FooBuilder
    var body: Foo<Int> { get }
}

// this works as expected:
struct MyBar1: Bar {
    var body: Foo<Int> {
        Foo<Int>()
        Foo<Int>()
    }
}

// this also works as expected:
struct MyBar2: Bar {}
extension MyBar2 {
    @FooBuilder // explicit @FooBuilder-annotation
    var body: Foo<Int> {
        Foo<Int>()
        Foo<Int>()
    }
}

// This gives an error:
struct MyBar: Bar {}
extension MyBar {
    var body: Foo<Int> {
        Foo<Int>()
        Foo<Int>() // Error: Missing return in getter expected to return 'Foo<Int>'
    }
}

If a protocol-requirement is annotated with a result builder, then the annotation seems to be ignored if the requirement is implemented in an extension on the conforming type.
Expected Behaviour
The annotation is also respected in extensions, or, if for some reason this is not possible, a meaningful error-message is shown.
Environment

swift-driver version: 1.75.2 Apple Swift version 5.8 (swiftlang-<IP_ADDRESS>.2 clang-14<IP_ADDRESS>.100)
Target: arm64-apple-macosx13.0
Xcode 14.3

Remarks
The same happens also if the body if a View is implemented in an extension. Error:

Function declares an opaque return type, but has no return statements in its body from which to infer an underlying type

// define some @resultbuilder
struct Foo {}
@resultBuilder
enum FooBuilder {
static func buildBlock(_ components: Foo...) -> Foo {
.init()
}
}
// some protocol where a property is annotated with the previously defined result-builder
protocol Bar {
@FooBuilder
var body: Foo { get }
}
// this works as expected:
struct MyBar1: Bar {
var body: Foo {
Foo()
Foo()
}
}
// this also works as expected:
struct MyBar2: Bar {}
extension MyBar2 {
@FooBuilder // explicit @FooBuilder-annotation
var body: Foo {
Foo()
Foo()
}
}
// This gives an error:
struct MyBar: Bar {}
extension MyBar {
var body: Foo {
Foo()
Foo() // Error: Missing return in getter expected to return 'Foo'
}
}

Note: Oops. I would have hidden those spam comments had I realized you could.


Health listener format issue

Required
When using the health listener like this:
health_bar:
  type: listener
  file: health_bar.png
  split: 25
  split-type: left
  setting:
    listener:
      class: health

it won't output the health value normaly with but with 34123 decimals. If possible to remove them and not have decimal numbers for the health value.

Tell me the detail about your problem.

Upload some screenshot or text log related your issue. such as:

health_bar:
  type: listener
  file: health_bar.png
  split: 25
  split-type: left
  setting:
    listener:
      class: health

Remember to notice your environment

OS windows
Server version: 1.21.3
Server platform paper

Disclaimer
I do NOT provide any solution about that.

Using informal launcher such as Feather client
Closed-source plugin/mod such as Optifine and ItemsAdder
Usage in hybrid bukkit such as ArcLight

It is listener; not a text.
If you mean text, please read wiki

It is listener; not a text. If you mean text, please read wiki

I don't see anything with the text and I do not wish to use placeholders to prevent issues.


GIN & GORM logging integration

Summary
Adds easy integration for Gin-Gonic & GORM with wharf-core's logging. See the _example_test.go files for how they're meant to be used, but here's the gist:
// Gin-Gonic
r := gin.New()

r.Use(ginutil.DefaultLoggerHandler)
gin.DefaultWriter = ginutil.DefaultLoggerWriter
gin.DefaultErrorWriter = ginutil.DefaultLoggerWriter

// GORM
db, err := gorm.Open(postgres.Open("host=localhost"), &gorm.Config{
	DryRun:               true,
	DisableAutomaticPing: true,
	Logger: gormutil.NewLogger(gormutil.LoggerConfig{
		Logger: logger.NewScoped("GORM"),
	}),
})

Motivation
GORM and Gin still has their built-in ways for logging, but allow you to add your own logger if you want to. These changes makes that integration easy, so with just a few lines then both GORM and Gin will use wharf-core/pkg/logger for logging instead of their own solutions, which will bring a more unified visual to our logs

Code style seems fine to me.
Th PR description is missing both what and why. What problem does this solve? What does the integration do?

Updated desc


[Feature] Support Automount RS

About the change
This adds support for automount feature of redshift which essentially treats the schema name as glue db name more details  : https://aws.amazon.com/blogs/big-data/simplify-external-object-access-in-amazon-redshift-using-automatic-mounting-of-the-aws-glue-data-catalog/

@singhpk234 Thank you for your feature submission. It is currently under review.

@singhpk234 We are currently in the process of adding support for this feature in a more general purpose way that will support both auto-mounted databases as well as other forms of data shares. Because of that, we will not be able to merge this PR. However, we greatly appreciate your submission and look forward to your feedback on the upcoming feature.

We are currently in the process of adding support for this feature in a more general purpose way that will support both auto-mounted databases as well as other forms of data shares

Do you have any timelines regarding when this support will be available ? @bsharifi

@singhpk234 A fix for this issue will be part of the next release of the connector. I don't have a firm date though unfortunately.

Hi @singhpk234, we are reopening and merging your feature since we were able to leverage some of your changes as part of our upcoming support. Thanks again for contributing to the connector!


[Perf Tests]: Introduce the "Max instances" test

Introducing instance limits tests
⚠ This PR depends on #5447
Summary
This commit introduces the "N-Instance Limits" test that tries to scale a
marathon app as much as possible until it starts failing or it takes way
too long to respond.
JIRA issues: MARATHON_EE-1648

@wavesoft what's the status?


Print source filename

It'd be great if this gem could also print the filename the error was found in, specifically for when we run it on the whole app. It kinda works to know where it is in the application.js, but with a large project, it's hard to tell what source file that maps to.
I started looking into this, and it looks like right now there's no concept of where each line of application.js came from. We could loop over the files from sprockets, using Rails.application.assets.each_file, but I think we'd run into linting issues where variables are defined in different files. I may dig into this some more and see if there's a good solution, but I'd also love to hear some feedback on how feasible this sounds.

@jonkessler This is resolved now.


Merge pull request #1 from silshack/gh-pages

Updating gh-pages with changes from silshack repo

Accidentally merged it the wrong way.


Stale Nomination Reward Curve

Would like to start a conversation, pre-RFC, about an idea that was brought up while at Sub0 Asia 2024.
The high level goal is to create some incentive / pressure for nominators to re-nominate in some regular frequency, with the hope that we can better identify the best validators for Polkadot at any given time.
The problem is that many nominators have stale nominations, that is they nominated some of the OG validators back when the network first launched, and perhaps have not updated their nominations for months / years.
The NPoS process will better identify high quality validators, and allow new validators into the set, when nominators are updating their nominations.
A proposed solution to this problem is to create a decreasing reward curve on nominator payouts based on the last time they submitted nominations.
For example:
Imagine a simple curve which is flat at 1.0 until 6 months. Then linearly decreases to 0 for the next 2 years.
A nominator will receive their full staking rewards for the first 6 months after their original nomination. However, after 6 months, if they do not submit a new nomination extrinsic, they will start to receive slightly lower rewards. For example, at 1.5 years since their original nomination, they will only receive 50% of their potential rewards.
The first important detail to note is that this mechanism does not force anyone to do anything. It is simply an economic pressure to incentivize a behavior. I also want to note that this mechanism cannot force nominators to pick different validators. In fact, we might expect some nominators to pick the same exact set of validators every 6 months.  We do NOT want to force the selection of random new validators when a nominator feels that a certain set of validators are best.
However, this pressure to at least submit a new nomination extrinsic I believe will be enough pressure for people to evaluate if their current selection can be improved. There are new dashboards and metrics every day which are telling us more information about the quality of validators, and validators have had more requirements to perform as of recently (with beefy, parachains, etc...). My guess is that some pressure like this would be a strong net benefit to the security and quality of the network.
Second to note is that this curve should be easily configurable. I suggest above some values just for the sake of illustration. Whether we tune the curve to start decreasing at 3 months or 6 months, whether we tune the curve to go all the way to 0 or stop at .5, and how long it takes to get there are all things which can be easily updated. The curve could also not be linear. Thankfully with OpenGov code, I believe all the logic needed for many curves are already part of the Polkadot-SDK. I think my suggested curve is not so bad as a starting point, but would not push back on less or more aggressive configurations.
Finally, I want to note that I believe this features adds little overhead to the staking system, and can be easily implemented in a fully scalable way. The only thing we need to introduce here is:

An additional field in the storage of nominators which tracks the block number the last time they submitted a nomination.

The additional value will be a field on an existing storage, not a new storage, thus the overhead to weights and benchmarks is nominal.
This value will be updated when they next call nominate, and requires no changes to the end user experience.

A static and configurable nomination reward curve that defines a global behavior for all nominators.
A single lightweight calculation, during payouts, which will adjust the final payout to a nominator based on their last nomination block and the nomination reward curve.

A potential migration would be needed to update the storage of all nominators to include the new "last block nominated" storage field. There are probably methods we could use to migrate to this lazily, since things won't affect end users for 6 months anyway.
From an economics perspective, it is possible that this curve decreases the rate of inflation of the network where stale nominators are not getting their maximal possible payouts if their nominations are stale.
Not included in this write up is brainstorming on how we can expose this new feature to end users and UIs, and how we can make the experience better for everyone. But open to those discussions below.
Overall, I think this is a simple but high quality improvement we can make to our network.

Don't you think that this will just bring up people to write bots for doing this?
IMO we need to improve reporting to nominators. I mean we have already seen on Kusama that some validators are getting less rewards. So, there is already economical pressure, but nominators don't seem to care. We should rework the reward points to ensure they are rewarding better actual work that matters for the chain.

Don't you think that this will just bring up people to write bots for doing this?

I don't think the average nominator (i.e. a random DOT holder) is the kind to write scripts.
But if they wanted to, then sure, let them. Perhaps they will write a script which finds the best nominators based on some API metrics.
I do NOT think the average nominator will run a long term VM, so that a simple script can run once every 6 months. I think most people will go to a UI like Polkadot Staking Dashboard, and ideally go through their selection process again.
If this was targeted at the validators, I would say that the likelihood of scripting would be high enough that it is not useful.

I absolutely love the fact that we think and talk about these things.
The stickyness of stake is insane and I bet many nominations are around from pre-redenomination.
My concern is that most of these sticky i-don't-care-nominations are from large holders which don't actively care for their nominations or the network.
Might happen easily that they just never realize why their rewards go down and therefore the whole thing might not have big effect.
I would rather think about turning around that mechanism and instead of lowering the nominators rewards over time make the nomination less effective for the validator.
For example:
A fresh delegation has 1.0 x delegated_DOT backing-power and after 6 months that backing-power goes down until a point where the delegation has 0 x delegated_DOT backing-power after 2 years.
This way the validator would lose backing and might be phragmen'ed out for an active validator that has responsive and caring nominators.

Rather than burning the rewards of less active nominators, did you consider handing it to the more active nominators? There should be even more incentive this way as not only is there a stick, but a carrot too.

We definitely want nominators to do the work of nominating, but we should avoid nominators carrying their stash keys with them.  We'd one good story for this with controller keys aka free staking proxies, but they're already depricated.  Afaik, our proxies are not so expensive, but folk still complain, which makes me worry, so..
We'd ideally have some cheap zero-storage certificate based replacement for our current storage based proxy systems before doing this.
In essence, your stash would create & sign a certificate that delegates some staking powers to a delegee key aka proxy key, but this delegee key need not exist anywhere in storagem and thius requires zero ED itself.  Instead, delegee keys post their full certificate on-chain with each tx, but the certificate would be shorter than the extra merkle proof required by controllers/proxies.
This certificate has the size of the delegation statement, including the 32 byte stash and 32 bytes delegee keys, plus a 64 byte signature.  In principle, the certificate could live entirely in polkadot.js, so then the delegee key could live in vault like a normal key.
As an alternative, we could employ implicit certificates, which schnorrkel supported from day one and closely resemble segwit.  Implicit certificates are 64 bytes shorter, so just the size of the delegation statement plus 32 bytes, so maybe 70 bytes with everything.  Implicit certificates would require vault itself understand the certificate format though, and delegee keys cannot be exported via words like other keys.
All certificate schemes need expiration dates and a revokation path, meaning a stash can revoke a certificate within its own record.
We started with on-chain controllers instead of certificates only because folks obsesse over blocksize, but nobody realized how overpriced the ETH trie is.  We'd ideally have moved directly form controllers to certificates, and never implemented proxies, but path dependence exists everywhere.
Anyways..
I kinda suspect re-nominating often indicates nominators who optimize their own rewards over the interests of polkadot.
You cannot "write a script which finds the best [validator operators]" from polkadot's perspective, because that means not byzantine now or in the future.  As an approximation to this, we should really ask nominators to assess the character, competence, and independence of validator operators.
We've little chance they'll access sysadmin competence unless validator operators start speaking publically about operational security topics.  Just fyi, Tor achieves this via their extensive outreach and relay operator meet ups, but those discuss many concerns like "how to talk to cops."
We could push nominators towards assessing validator operators character and independence though.  Again meetups help here, especially if one believes you should never nominate a validator operator unless you've met them in person.
Actual ideas..
We should do more outreach about what being a good nominator from polkadot's perspective means, including commants that this minimizes slashing risk.  In this, we could organize validator-nominator meetups at conferences, primarily our conferences, but really any where we've some presense.  This would make our ecosystem look (and be) more competent.
As I think @bkchr suggests, we could make your nominated validators appear more prominiantly in polkadot.js and other staking platforms, including direct links to validator operators blogs, twitters, etc.
We could try our own centralized off-chain channel through which validators send signed message to their nominators.  We've many messangers in the world today, so one could imagine many options, but probably a simpler "validator blog" interface serves our interests better.  Assuming validators appear promenently, recent blogs by validators you nominate could show up in your staking interface.
We've designed a [https://hackmd.io/@rgbPIkIdTwSICPuAq67Jbw/S1fHcvXSF](rewards scheme) that captures the critical activities, even availability.  We suposidly have too many validators run crappy machines, probably cloud VMs, so correct rewards should result in them missing some backing jobs.  We simply promote this reality once rewards work correctly, so then everyone slowly learns from our outreach.

@SimonKraus If I understand your suggestion, a curve on the nominated dot would basically cause the same effect of lowering the rewards the nominator gets, but also cause effects on who is in the nominated set.
I think this might actually align with what @gavofyork is also suggesting by creating both a reward for those who are updating their nominations, and punishing those that are not, since those with updated nominations will now get a bigger chunk of the rewards than their stale counterparts.
I am not sure if we can implement it just as easily as the payouts, but I will certainly look at it, and if lowering of delegation itself is a desired behavior, then we can do it.
@burdges

We definitely want nominators to do the work of nominating, but we should avoid nominators carrying their stash keys with them.

I think on the order of one transaction per 6 months is not that scary, and should be doable with proxies as you mentioned. Perhaps we could make it so that anyone staking gets a free staking proxy. In any case, not updating their nominations once per 6 months is probably certainly bad (on average) for the overall security of the network.

Actual ideas..

I think all of these are great, but work even better once you have nominators periodically interacting with the network. We can create all of these channels and outreach and whatever, but if they are not seeing them, it makes no impact. Having users interact with the chain on some reoccurring time period at least ensures that they can see these kinds of things.
But yeah, ultimately a mechanism like this would not need to exist on chain if most nominators truly understood their role in the security of Polkadot. But unfortunately they think of it mostly as passive income, and thus I think we need to bring these kinds of mechanics in.

We definitely want to break the idea that staking is passive income, and yes once every six months feels harmless, but we should not make checking nominations all the time some sacrement either.  In fact, interacting too much on-chain actually provides evidence of reward chasing that harms security.
Attach scenario:  Attackers controls DOTs for k validators, which they spin up, nominate themselves, set commission to zero, and engage with community to attract nominators who actively chase rewards.  After these validators recieve enough nominators, then attackers launches another k validators using their own take.  After n iterations they control k*n validators, so they sell their DOTs, and engage in an attack with nothing at stake.  This is one of the reasons we want a minimum commission.
In fact, they could simply get themselves slashed, report the slash themselves, and walk away with some of their their nominators money.  This is why the rewards for slashing reports must be kept low, like maybe 1%.
We might say six months, but if we promote this as "check your nominations more", then some precentage starts optimizing weekly, which worsens this vulnerability.  It's our outreach that matters more than our code change here.

work even better once you have nominators periodically interacting with the network

It's kinda the opposite of what you imply here.  They already interact regularly, by selling DOTs to price average to pay their taxes.
The actual regular work of nominating is in the nominators head, aka they should assess if they like their nominations.  This is best handled with "gameification", but the simplest form of this is making their nominations more prevelent in the staking interface, meaning they see them when they connect to do anything else.  Afaik incentives matter relatively little without this interface change.

This suggestion is pointing out a real issue: NPoS works the best with (possibly) fewer but more active nominators than the opposite, we all agree on that, and I believe it is pretty uncontroversial.
I do have worries about people deploying a "bot" of some sort as @bkchr mentioned, but at the same time, since there is no better alternative, I am in favor of implementing this, and letting the network play with the parameters to see if it is useful or not.

IMO we need to improve reporting to nominators. I mean we have already seen on Kusama that some validators are getting less rewards

I don't think we can get much better at this. Staking dashboard and other UIs are already pretty encouraging towards nominators to be active, but you can't do anything about someone who doesn't even open any dashboard. We don't have any way to reach the 22500 nominators of each network either, so it is hard to "inform" them that there are economic incentives for them to chose different validators.

Finally, I want to note that I believe this features adds little overhead to the staking system, and can be easily implemented in a fully scalable way.

Correct.
Moreover, I would add a few more points that could be bundled with this initiative to make it more successful:

Ideally we want fewer nominators, and more pools. Therefore, we should make pools equally convenient to participate in even for big holders. The only major disadvantage of pools at the moment compared to direct nomination is https://github.com/paritytech/polkadot-sdk/issues/445. In other words, switching pools is costly (you lose 28 days of staking rewards), but switching nominations is free.
Moreover, pools have the benefit of claiming rewards when the nominator wants, which may be beneficial for accounting and tax reasons
Both the UI and the protocol should allow a smooth transition whereby a nominator is prompted about their inactivity, and are suggested to either:

be more active
join a pool with 1 click.

Moreover, active nominators should be prompted to "upgrade" themselves (similarly with 1 click) to a pool, and possibly claim an extra pool commission for their good choice and allowing others to subscribe to them.

Side note, the fact that we have pools and nominators now is a technical debt on the implementation side. Conceptually, all nominators should be "delegate-able" i.e. all 22500 nominator slots should be used by pools, and end users who wish to be less active should just join a pool. @ank4n is already working on the refactoring needed for this, but it will be a more long term effort. Code wise, you can imagine something like:

Shawn and I recently discussed this during our meeting in Singapore, and I am very much in favor of such a mechanism. Polkadot is paying their nominators 15%+ APY to actively curate the set of validators and optimize their nominations, but empirical data shows that a large share simply “sets and forgets.” I recall examining the actual data and found that, of those active in the last six months, 77% did not update their selection. I am sure their staleness extends even farther into the past. I highly doubt that any of them actually checked on their selection. In short, Polkadot gives nominators a huge reward for a job that many of them do not properly perform.
Here are some additional thoughts:

We should find a feasible implementation that not only reduces the rewards for stale nominators but also extends this effect to the backing of their respective validators. While this “stale backing” will always be fully slashable, it should not contribute to the NPoS election calculation of those validators. This has the benefit of exerting pressure on validators to keep engaging with nominators, trying to “regain” them. For the network, it has the benefit of potentially removing some of the old validators that were added at the beginning. This could lead to a well-deserved rotation in the validator set. Or maybe not, but at least there will be some pressure for nominations to be reconfirmed.
Once word about this gets out, people who are only remotely interested in interacting with Polkadot but still want to hold their DOT in their own custody will have the best interest in joining staking pools. I’d say this would be a good development.
I think we should use a mechanism that redistributes the rewards deducted from stale nominations to those that are not stale. Given that we might soon see lower inflation on Polkadot, which would necessarily lower staking rewards for all nominators, we should allocate more rewards to those nominators who actively perform their tasks. I am sure there is some smart technical way to achieve this without too much complexity.

The point about bots is valid, of course. But I don't think a whole lot of people would do that and even if only a few people are nudged to spend more time looking at the validator set and making their selection, it’s already worth it.

Polkadot is paying their nominators 15%+ APY to actively curate the set of validators and optimize their nominations, but empirical data shows that a large share simply “sets and forgets.”

Again, actively changing suggests worse nominator behavior:  A nominator who nominates only their friends provides the highest quality nomination information, but might never change their nominations.  A nominatior who changes frequently likely chases yield, which makes them easily manipulatable, which makes the nomination information they provide almost worthless.
It's possible a "set & forget" nominator did their job.  It's basically impossible a nominator who actually changes does their whole job.
Again, some simple reaffirm after 6 months would not be too problematic, but we definitely send the wrong message by doing this.  If we do an RFC for this, then we should explain that this is a harmful feature, but we want more engagement, and really helpful engagement features are much much harder.
An example of a helpful engagement feature:  All validator operators have a MOTD which their nominators read.  We decreates rewards if you do not read some MOTDs from your nominations for 6 months.  It's harder to assess reading messages though.  Also, doing a MOTD requires much more work than this feature.

Polkadot is paying their nominators 15%+ APY to actively curate the set of validators and optimize their nominations, but empirical data shows that a large share simply “sets and forgets.”

Again, actively changing suggests worse nominator behavior: A nominator who nominates only their friends provides the highest quality nomination information, but might never change their nominations. A nominatior who changes frequently likely chases yield, which makes them easily manipulatable, which makes the nomination information they provide almost worthless.
It's possible a "set & forget" nominator did their job. It's basically impossible a nominator who actually changes does their whole job.
Again, some simple reaffirm after 6 months would not be too problematic, but we definitely send the wrong message by doing this. If we do an RFC for this, then we should explain that this is a harmful feature, but we want more engagement, and really helpful engagement features are much much harder.
An example of a helpful engagement feature: All validator operators have a MOTD which their nominators read. We decreates rewards if you do not read some MOTDs from your nominations for 6 months. It's harder to assess reading messages though. Also, doing a MOTD requires much more work than this feature.

 Then, reaffirming is much less costly than finding a new set of validators, so I don't see how this drives people not to nominate their friends anymore.

@burdges I hear your line of reasoning, but I strongly disagree with it given the timelines proposed in this idea.
It feels to me impossible that over the course of 6 - 12 months, that nothing relevant has changed which would influence the majority of nominators from making better selections for the network.

Each nominator is given 16 people they can nominate. Even if they have super strong selections for the top 10, you can imagine once you get to the bottom 6 people, it is likely that higher quality validators could appear which would be a better choice for these nominators.
There is nothing that requires the nominator actually change any of their selection. If they have selected 16 friends, all of which are the highest quality, then a simple single extrinsic call to have the nominator confirm this selection is super relevant to let the network / community know that they are still actively making a decision. We could even introduce a super minimal extrinsic which is just renew_nominations and has no inputs, low fees, and selects the same set. However, simply the action of making that call is I think the right catalyst for those who are not 100% certain to simply rethink their selection.
Tooling for selecting validators is getting better and better each month in the Polkadot ecosystem. I think where we are at today with the Staking Portal is leagues better than where we were when we first launched the network. Similarly, I think we still feel there is a lot of room for improvement, so we should expect a few years from now, it will again be an order magnitude better for nominators to select the highest quality validators for Polkadot. This kind of periodic update also brings our community to these new staking resources, exposes them to new information, and allows them to make better informed decisions.
Your argument includes the idea that nominators nominate their 'friends' whom they know in person and are the highest quality choice for them, but from a data standpoint, we absolutely know this is not the case. Most nominators have no tangible relationship with their validator, and have pretty much picked the set based on lowest commission, or some auto-ranking from a UI. I have already had the experience where a validator that I nominated increased their commission after I selected them, and until I went to renew my nominations, that change was pretty much unknown to me.

Again, some simple reaffirm after 6 months would not be too problematic, but we definitely send the wrong message by doing this. If we do an RFC for this, then we should explain that this is a harmful feature, but we want more engagement, and really helpful engagement features are much much harder.

I would like you to clarify what "message" we are sending, and what about it is "harmful".

An example of a helpful engagement feature: All validator operators have a MOTD which their nominators read. We decreates rewards if you do not read some MOTDs from your nominations for 6 months. It's harder to assess reading messages though. Also, doing a MOTD requires much more work than this feature.

As you know, with the tools in available by blockchains, we cannot really force any behavior, just encourage it at a high level through economics. If validators have to continue to stay relevant, then behaviors like creating daily messages / updates / metrics / etc will happen. There will not be voiceless non-participatory validators who got into the set just because they had connections to Web3 Foundation at genesis. People will be constantly re-evaluate which validators are doing the best for their nominators and are having the best interests of Polkadot in mind.

We pay nominators to judge the character, competence, and independence of validator operators.  We do not pay nominators to judge their payouts because 33% attackers can easily manipulate nominators who judge by payouts.
If the validator operator has little public presence, and no personal relationship with the nominator, then payouts are their only communication, so alone this feature sends the message that nominators should listen to their payouts, which is incorrect.
It's not that nothing changed, but that no communication channel exists.  This feature does not alter any communication channels.  It's magical thinking if you believe this feature results in more communication.  It doesn't touch the available communication channels, does not incentivize listening to existing ones, etc.
We already de facto require nominators interact regularly with polkadot.js because they must sell dots regularly.  If you're worried that's false, then alright maybe we need them to interact more with the interface, so then that becomes the justification for this feature.  Afaik, that's simply a question of tax law around the world though.
If nominators do not even login, then yes positive synergies could exist between this feature plus MOTD or whatever.  Alone, this feature is still harmful though.
I do not object to two steps forward preceeded by one necessary step backwards, but alone this feature is only the step backwards.

We pay nominators to judge the character, competence, and independence of validator operators. We do not pay nominators to judge their payouts because 33% attackers can easily manipulate nominators who judge by payouts.

How does the mechanism of reaffirm your nomination change that? You implicitly assume that their first selection was well-informed and this mechanism drives them away from that and chase yield? I doubt that.

We already de facto require nominators interact regularly with polkadot.js because they must sell dots regularly. If you're worried that's false, then alright maybe we need them to interact more with the interface, so then that becomes the justification for this feature. Afaik, that's simply a question of tax law around the world though.

Being a nominator does not entail any costs, so I don't see how they "must sell" dots regularly. But even if, their interaction with Polkadot does not lead them to engage with their selection again.

I do not object to two steps forward preceeded by one necessary step backwards, but alone this feature is only the step backwards.

I agree that the topic is not solved with this mechanism and that we should find more ways to make it easier for nominators to properly inform themselves if they chose to (or nudged to by this mechanism). One obvious idea would be to leverage the 1kv more in that regard and help to make a connection between well-performing (not only in yield but generally) validators and nominators looking for new validators.


Asking about license

Hello, I'm heesuk.
I would like to use your source code in my commercial app.
Is there any license like a MIT, Apache-2.0 etc??
plz, let me know.
best regards.

I will add one now


No save or download file option on Android

Description
I am testing on Android 10 and I don't see the option to Save or Download the shared photo to my photo library. It is available in iOS though.
Is it related to permission?
FYI, I have granted Camera and Photos permissions using the Capacitor Camera plugin and have the READ_EXTERNAL_STORAGE & WRITE_EXTERNAL_STORAGE lines in AndroidManifest.xml.
Capacitor version:
Run npx cap doctor:
@capacitor/cli: 4.7.0
  @capacitor/core: 4.7.1
  @capacitor/android: 4.7.1
  @capacitor/ios: 4.7.1

Library version:

4.0.0

Your Plugin Configuration
{
    filename: `photo-${this.activePhoto.id}.jpg`,
    base64Data: this.activePhotoBase64,
    contentType: "image/jpg",
}

As a iOS user I'm a little bit suprised that Android does not support that. I tested with Android 13 and can confirm that. I need to test further
Resources understand this behavior:

https://stackoverflow.com/questions/37130096/share-image-intent-with-custom-save-to-gallery-option
https://developer.android.com/training/secure-file-sharing/share-file

Any update regarding this?


Was working with Unraid for several months but now getting "Incorrect api key" in Log

What trouble are you having?
I had setup Deepstack-AI and node-deepstackai Trigger on Unraid with BlueIris running on another computer and all was working perfectly for several months.
On Feb 7th, things stopped working. A check of the Log  for: node-deepstackai-trigger is in log section below:
Note the "Incorrect api key" message is shown at the end of the log file.
2021-03-13T20:49:39-03:30 [Main] Starting up version 5.8.1
2021-03-13T20:49:39-03:30 [Main] Timezone offset is 210
2021-03-13T20:49:39-03:30 [Main] Current time is Sat Mar 13 2021 20:49:39 GMT-0330 (Newfoundland Standard Time)
2021-03-13T20:49:39-03:30 [Settings] Unable to read the settings file: ENOENT: no such file or directory, open '/run/secrets/settings'.
2021-03-13T20:49:39-03:30 [Settings] Unable to load file /run/secrets/settings.
2021-03-13T20:49:39-03:30 [Settings] Unable to read the secrets file: ENOENT: no such file or directory, open '/config/secrets.json'.
2021-03-13T20:49:39-03:30 [Settings] Loaded settings from /config/settings.json
2021-03-13T20:49:39-03:30 [MQTT] MQTT is disabled via settings.
2021-03-13T20:49:39-03:30 [Local storage] Creating local storage folders in /node-deepstackai-trigger.
2021-03-13T20:49:39-03:30 [Local storage] Enabling background purge every 60 minutes for files older than 30 minutes.
2021-03-13T20:49:39-03:30 [Local storage] Running purge
2021-03-13T20:49:39-03:30 [Main] Annotated image generation enabled.
2021-03-13T20:49:39-03:30 [Main] Web server enabled.
2021-03-13T20:49:39-03:30 [Triggers] Unable to read the settings file: ENOENT: no such file or directory, open '/run/secrets/triggers'.
2021-03-13T20:49:39-03:30 [Triggers] Unable to load file /run/secrets/triggers.
2021-03-13T20:49:39-03:30 [Triggers] Unable to read the secrets file: ENOENT: no such file or directory, open '/config/secrets.json'.
2021-03-13T20:49:39-03:30 [Triggers] Loaded configuration from /config/triggers.json
2021-03-13T20:49:39-03:30 [Triggers] Loaded configuration for Person detector
2021-03-13T20:49:39-03:30 [Triggers] Loaded configuration for Person detector
2021-03-13T20:49:39-03:30 [Triggers] Loaded configuration for Person detector
2021-03-13T20:49:39-03:30 [Trigger manager] There are 5 images waiting in /aiinput/PixelProFrontSD*.jpg for Person detector.
2021-03-13T20:49:39-03:30 [Trigger manager] There are 0 images waiting in /aiinput/AnnkeSideDrSD*.jpg for Person detector.
2021-03-13T20:49:39-03:30 [Trigger manager] There are 0 images waiting in /aiinput/AnnkeBackDkSD*.jpg for Person detector.
2021-03-13T20:49:39-03:30 [Pushbullet] Pushbullet is disabled via settings.
2021-03-13T20:49:39-03:30 [Pushover] Pushover enabled.
2021-03-13T20:49:39-03:30 [Telegram] Telegram is disabled via settings.
2021-03-13T20:49:39-03:30 [Trigger Person detector] Listening for new images in /aiinput/PixelProFrontSD*.jpg
2021-03-13T20:49:39-03:30 [Trigger Person detector] Listening for new images in /aiinput/AnnkeSideDrSD*.jpg
2021-03-13T20:49:39-03:30 [Trigger Person detector] Listening for new images in /aiinput/AnnkeBackDkSD*.jpg
2021-03-13T20:49:39-03:30 [Main] Watching for changes to /config/settings.json
2021-03-13T20:49:39-03:30 [Main] Watching for changes to /config/triggers.json
2021-03-13T20:49:39-03:30 [Main] ****************************************
2021-03-13T20:49:39-03:30 [Main] Up and running!
2021-03-13T20:49:39-03:30 [Web server] Listening at http://localhost:4242
2021-03-13T20:49:39-03:30 [Local storage] Purge complete
2021-03-13T20:49:39-03:30 [Trigger Person detector] /aiinput/PixelProFrontSD.20210309_104037653.jpg: Skipping as it was created before the service started.
2021-03-13T20:49:39-03:30 [Trigger Person detector] /aiinput/PixelProFrontSD.20210309_104042653.jpg: Skipping as it was created before the service started.
2021-03-13T20:49:39-03:30 [Trigger Person detector] /aiinput/PixelProFrontSD.20210309_104047653.jpg: Skipping as it was created before the service started.
2021-03-13T20:49:39-03:30 [Trigger Person detector] /aiinput/PixelProFrontSD.20210313_203006532.jpg: Skipping as it was created before the service started.
2021-03-13T20:49:39-03:30 [Trigger Person detector] /aiinput/PixelProFrontSD.20210313_203011532.jpg: Skipping as it was created before the service started.
2021-03-13T21:00:08-03:30 [Trigger Person detector] /aiinput/AnnkeSideDrSD.20210313_210006986.jpg: Analyzing
2021-03-13T21:00:08-03:30 [Trigger Person detector] Error: Failed to call DeepStack at http://<IP_ADDRESS>:5000/: {"success":false,"error":"Incorrect api key","duration":0}
2021-03-13T21:00:08-03:30 [Trigger Person detector] /aiinput/AnnkeSideDrSD.20210313_210006986.jpg: Analysis failed
A clear and concise description of what you're stuck on.
As a new image comes in the following is added to the log file for every image analyzed:
2021-03-13T21:00:08-03:30 [Trigger Person detector] Error: Failed to call DeepStack at http://<IP_ADDRESS>:5000/: {"success":false,"error":"Incorrect api key","duration":0}
2021-03-13T21:00:08-03:30 [Trigger Person detector] /aiinput/AnnkeSideDrSD.20210313_210006986.jpg: Analysis failed
Have you tried with the sample files?
-Yes and everything was working perfectly for several months
Have you tried the steps in the troubleshooting guide?
https://github.com/danecreekphotography/node-deepstackai-trigger/wiki/Troubleshooting

[Yes - this issue is not found

Log entries
2021-03-13T20:49:39-03:30 [Main] Starting up version 5.8.1
2021-03-13T20:49:39-03:30 [Main] Timezone offset is 210
2021-03-13T20:49:39-03:30 [Main] Current time is Sat Mar 13 2021 20:49:39 GMT-0330 (Newfoundland Standard Time)
2021-03-13T20:49:39-03:30 [Settings] Unable to read the settings file: ENOENT: no such file or directory, open '/run/secrets/settings'.
2021-03-13T20:49:39-03:30 [Settings] Unable to load file /run/secrets/settings.
2021-03-13T20:49:39-03:30 [Settings] Unable to read the secrets file: ENOENT: no such file or directory, open '/config/secrets.json'.
2021-03-13T20:49:39-03:30 [Settings] Loaded settings from /config/settings.json
2021-03-13T20:49:39-03:30 [MQTT] MQTT is disabled via settings.
2021-03-13T20:49:39-03:30 [Local storage] Creating local storage folders in /node-deepstackai-trigger.
2021-03-13T20:49:39-03:30 [Local storage] Enabling background purge every 60 minutes for files older than 30 minutes.
2021-03-13T20:49:39-03:30 [Local storage] Running purge
2021-03-13T20:49:39-03:30 [Main] Annotated image generation enabled.
2021-03-13T20:49:39-03:30 [Main] Web server enabled.
2021-03-13T20:49:39-03:30 [Triggers] Unable to read the settings file: ENOENT: no such file or directory, open '/run/secrets/triggers'.
2021-03-13T20:49:39-03:30 [Triggers] Unable to load file /run/secrets/triggers.
2021-03-13T20:49:39-03:30 [Triggers] Unable to read the secrets file: ENOENT: no such file or directory, open '/config/secrets.json'.
2021-03-13T20:49:39-03:30 [Triggers] Loaded configuration from /config/triggers.json
2021-03-13T20:49:39-03:30 [Triggers] Loaded configuration for Person detector
2021-03-13T20:49:39-03:30 [Triggers] Loaded configuration for Person detector
2021-03-13T20:49:39-03:30 [Triggers] Loaded configuration for Person detector
2021-03-13T20:49:39-03:30 [Trigger manager] There are 5 images waiting in /aiinput/PixelProFrontSD*.jpg for Person detector.
2021-03-13T20:49:39-03:30 [Trigger manager] There are 0 images waiting in /aiinput/AnnkeSideDrSD*.jpg for Person detector.
2021-03-13T20:49:39-03:30 [Trigger manager] There are 0 images waiting in /aiinput/AnnkeBackDkSD*.jpg for Person detector.
2021-03-13T20:49:39-03:30 [Pushbullet] Pushbullet is disabled via settings.
2021-03-13T20:49:39-03:30 [Pushover] Pushover enabled.
2021-03-13T20:49:39-03:30 [Telegram] Telegram is disabled via settings.
2021-03-13T20:49:39-03:30 [Trigger Person detector] Listening for new images in /aiinput/PixelProFrontSD*.jpg
2021-03-13T20:49:39-03:30 [Trigger Person detector] Listening for new images in /aiinput/AnnkeSideDrSD*.jpg
2021-03-13T20:49:39-03:30 [Trigger Person detector] Listening for new images in /aiinput/AnnkeBackDkSD*.jpg
2021-03-13T20:49:39-03:30 [Main] Watching for changes to /config/settings.json
2021-03-13T20:49:39-03:30 [Main] Watching for changes to /config/triggers.json
2021-03-13T20:49:39-03:30 [Main] ****************************************
2021-03-13T20:49:39-03:30 [Main] Up and running!
2021-03-13T20:49:39-03:30 [Web server] Listening at http://localhost:4242
2021-03-13T20:49:39-03:30 [Local storage] Purge complete
2021-03-13T20:49:39-03:30 [Trigger Person detector] /aiinput/PixelProFrontSD.20210309_104037653.jpg: Skipping as it was created before the service started.
2021-03-13T20:49:39-03:30 [Trigger Person detector] /aiinput/PixelProFrontSD.20210309_104042653.jpg: Skipping as it was created before the service started.
2021-03-13T20:49:39-03:30 [Trigger Person detector] /aiinput/PixelProFrontSD.20210309_104047653.jpg: Skipping as it was created before the service started.
2021-03-13T20:49:39-03:30 [Trigger Person detector] /aiinput/PixelProFrontSD.20210313_203006532.jpg: Skipping as it was created before the service started.
2021-03-13T20:49:39-03:30 [Trigger Person detector] /aiinput/PixelProFrontSD.20210313_203011532.jpg: Skipping as it was created before the service started.
2021-03-13T21:00:08-03:30 [Trigger Person detector] /aiinput/AnnkeSideDrSD.20210313_210006986.jpg: Analyzing
2021-03-13T21:00:08-03:30 [Trigger Person detector] Error: Failed to call DeepStack at http://<IP_ADDRESS>:5000/: {"success":false,"error":"Incorrect api key","duration":0}
2021-03-13T21:00:08-03:30 [Trigger Person detector] /aiinput/AnnkeSideDrSD.20210313_210006986.jpg: Analysis failed
Please copy and paste all the log messages from the Docker output
Installation details

Unraid 6.9.1
Docker setup  UnRAID

Additional context
Note that DeepStackAI does have an API key defined in the Unraid XML and checking the documentation at the deepquest site on API key the exact message is identified there. So when "...Trigger" calls Deepstack AI does it include the API key defined in DeepStackAI?
Any help would be greatly appreciated.
Add any other context about the problem here.

There's no API key sent to Deepstack AI because none is needed. Sounds like you have an older Deepstack image that used to require API keys to unlock and that key expired.
I'm not sure which Deepstack tagged image you're using but try pulling the latest or switching to a different tagged image from https://hub.docker.com/r/deepquestai/deepstack/tags?page=1&ordering=last_updated. Try cpu-2020.12 or gpu-2020.12. They long ago stopped requiring API keys.

Thank you very much for your quick response. Did as you suggested and now all is working with no API key.
Cheers,
Neil
Sent from my iPhone

On Mar 13, 2021, at 11:51 PM, danecreekphotography @.***> wrote:

There's no API key sent to Deepstack AI because none is needed. Sounds like you have an older Deepstack image that used to require API keys to unlock and that key expired.
I'm not sure which Deepstack tagged image you're using but try pulling the latest or switching to a different tagged image from https://hub.docker.com/r/deepquestai/deepstack/tags?page=1&ordering=last_updated. Try cpu-2020.12 or gpu-2020.12. They long ago stopped requiring API keys.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


[NFC] Move VMVX pipeline method from LLVMCPU to VMVX.

It is step towards decoupling VMVX and LLVMCPU dependencies.

Move CPU bufferization pipeline methods to Common/CPU/
Create VMVXLowerExecutableTargetPass and move the VMVX pipelines out of LLVMCPU.

It adds a dep of VMVX on LLVMCPU because we need
createLLVMCPULowerToUKernelsPass in VMVX pipeline. The dep can be removed if we move the pass to the Common/CPU/ folder.

nice!! we'll definitely need to move the ukernel stuff to common as we want to allow building the compiler with vmvx but not llvmcpu (this is a great start to finally decoupling the two!)

Yes, my next step is moving it to Common/CPU. I will refactor more things to common/cpu, so we can completely remove the deps between LLVMCPU and VMVX. It will also help remove VMVX deps from Codegen/Common. Given that we are stabilizing data-tiling/encoding path, I want to make sure we have as less tech debt as possible.

FYI @bjacob I'm refactoring VMVX implementations. I hope that won't impact your work. My goal is to completely untangle VMVX and LLVMCPU deps.

@pzread FYI


nixos/buildbot: fix type for pythonPackages

Motivation for this change
#110682 broke the module by specifying the wrong type for the pythonPackages option.
I also added myself as a maintainer for the module.
cc @nand0p @Mic92 @Scriptkiddi @SuperSandro2000
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@ofborg test buildbot

@ofborg test buildbot

sorry about that, thanks for the fix


wrap animated icons in IconDisplay component

Fixes #122. Wrap animated Icons in the IconDisplay component to make it more organized.

Looks good!


[Slider] Accessibility dark theme for disabled elements

Describe the bug
There is not enough contrast in dark mode for disabled items.

disabled items should be flag as disabled with the correct aria attribute and then I think are not taken into account for contrast.

Closed because as correctly said by @ExFlo, disabled item are not subject of contrast rules.


Allow registerEffect to run on the server

No-ops velocityHelpers.registerEffect if our Velocity server-side shim
is in place. Allows it to return a value but doesn't try to register it
with the non-existant Velocity.
See #44

:shell: :sheep: :ship:


Cleanup unused locals

These were leftovers from the v1 blueprint, see https://github.com/embroider-build/addon-blueprint/pull/23#discussion_r910915745.

There is some unrelated noise in the diff, due to running prettier. Seems some previous PR was not running prettier. And we have no linting set up, created https://github.com/embroider-build/addon-blueprint/issues/39.


[SM68] Initial proposal for Wave Matrix

This proposal adds new WaveMatrix data types that support lane cooperative matrix multiplication.
A preview implementation of this proposal is available as part of the DXC 1.8.2306 preview release.

https://github.com/microsoft/DirectXShaderCompiler/pull/6807
I assume that this proposal has been denied ?

microsoft/DirectXShaderCompiler#6807
I assume that this proposal has been denied ?

Denied is probably the wrong phrasing... In need of significant reworking.
This is definitely a feature we want, but the design proposed here has some pretty big limitations that we haven't had time to address. That resulted in us pausing development on it and not shipping it with the Shader Model 6.8 release.
We hope to refine this feature (in public) and include an updated version of it in the future.


feat(@embark/specialconfigs): introduce dynamic address support

This commit introduces a new Smart Contract configuration addressHandler
that lets users define a function to "lazily" compute the address of the
Smart Contract in question.
This is useful when a third-party takes care of deploying a dependency
Smart Contract, but the address of that Smart Contract only being available
at run-time.
Example:
contracts: {
  SimpleStorage: {
    fromIndex: 0,
    args: [100],
  },
  OtherContract: {
    deps: ['SimpleStorage'],
    addressHandler: async (deps) => {
      // use `deps.contracts.SimpleStorage` to determine address
    },
    abiDefinition: ABI
  },
}

In the example above, OtherContract will be deployed after SimpleStorage
because it uses the deps property to define Smart Contracts that it depends
on. All dependencies are exposed on the addressHandler function parameter
similar to deployment hooks.
Note: This only works when an ABI is provided for the Smart Contract that
is already deployed (in this case OtherContract).
Closes #1690

@iurimatias this has been closed without a comment. Are we discarding this feature now?


sdr support

Consider sdr support. Mostly want to DQ in some SDR implemented protocol and index that to node position. This feels more likely to be a collection of plugins rather than one single plugin that does it all.
Interesting Protocols
ads-b

rtl_adsb
dump1090
gr-adsb

ais

gnuais
aisrx

aprs

https://github.com/dl1ksv/gr-ax25
https://luaradio.io/examples/rtlsdr-ax25.html
https://linux-ax25.in-berlin.de/wiki/Main_Page
https://github.com/ve7fet/linuxax25
https://www.ax25.net/AX25.2.2-Jul 98-2.pdf

ERT

rtlamr

TPMS

rtl_433

Tutorial

gr-tpms - Deprecated

https://github.com/jboone/tpms

pocsag

multimon-ng
pocsag-mrt
gr-mixalot - Supports tx

radiosondes
APT - weather satelites

https://noaa-apt.mbernardi.com.ar/

Interesting Tools

https://github.com/pothosware/SoapySDR/wiki
https://github.com/triq-org/tx_tools
https://github.com/jopohl/urh
https://github.com/miek/inspectrum

Format data using sigmf?
https://github.com/sigmf/SigMF


Lock Git version

Stop automatically guessing the latest Git installer version download URL. It's convenient, but it results in build breaks over time for the VM generation.
Hardcode the download URL for the currently-latest Git installer version instead.

Sorted in 678d79f7801684d3e5d50fd150ab23ccc1dc4146 . There is now a ToolsAndVersions.psd1 that contains exact download URIs for external packages. No more guessing of URLs...
We would ideally have an automated process for updating those URLs (something that we'd run once per month), but I'm not sure how feasible that is.


Move to go 1.18.

Had to run gofmt on a few files too.

with the race condition behind us, this one is now ready for final review and merge.
I had to add a few more time.Sleep calls to avoid another race condition. I'm not happy about it but it seems to help.... at least for now.
@embano1 @lionelvillard


Updata dependencies

Update glam dependencies from 0.9.5 to 0.10.0
bevyengine/bevy#770

Hello!
This is a breaking change to our API, and hence we should update the major version of the crate. That way, Bevy (our largest dependant) is able to update to the newer version when needed, and does not break compatibility.

Actually, I didn't see that bevy issue, I'll merge right now.


Feature/apps templates

Application templates.

Resolves #441
DCO 1.1 Signed-off-by: Scott Nath<EMAIL_ADDRESS>

@Snugug changes added


remove test/index.html?

Seems to already be covered by test/browserTestRunner.tmlp.html?
don't know if you are using test/index.html or not

Nope. Strip it


Inconsistent Result while using a fix random seed

I have been using Spacy - Classy Classification to classify text messages. Python version 3.10
Below is the the training model and I get the Unknown category with the highest score for this specific message:
#Import training data
with open ('SID - Commercial.txt', "r", encoding="utf8") as a:
    Commercial = a.read().splitlines()

with open ('SID - Crypto.txt', "r", encoding="utf8") as b:
    Crypto = b.read().splitlines()

with open ('SID - Extortion.txt', "r", encoding="utf8") as c:
    Extortion = c.read().splitlines()

with open ('SID - Financial.txt', "r", encoding="utf8") as d:
    Financial = d.read().splitlines()

with open ('SID - Gambling.txt', "r", encoding="utf8") as e:
    Gambling = e.read().splitlines()

with open ('SID - Gift.txt', "r", encoding="utf8") as f:
    Gift = f.read().splitlines()

with open ('SID - Investment.txt', "r", encoding="utf8") as g:
    Investment = g.read().splitlines()

with open ('SID - Invoice.txt', "r", encoding="utf8") as h:
    Invoice = h.read().splitlines()

with open ('SID - Phishing.txt', "r", encoding="utf8") as i:
    Phishing = i.read().splitlines()

with open ('SID - Romance.txt', "r", encoding="utf8") as j:
    Romance = j.read().splitlines()

with open ('SID - Unknown.txt', "r", encoding="utf8") as k:
    Unknown = k.read().splitlines()

data = {}
data["Commercial"] = Commercial
data["Crypto"] = Crypto
data["Extortion"] = Extortion
data["Financial"] = Financial
data["Gambling"] = Gambling
data["Gift"] = Gift
data["Investment"] = Investment
data["Invoice"] = Invoice
data["Phishing"] = Phishing
data["Romance"] = Romance
data["Unknown"] = Unknown

# NLP model
spacy.util.fix_random_seed(0)
nlp = spacy.load("en_core_web_md")
nlp.add_pipe("text_categorizer",
    config={
        "data": data,
        "model": "sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2",
        "cat_type": "multi-label",
        "device": "gpu"
    }
)

print(nlp("FW: ðšð™´: ðšˆðš˜ðšž ðš‘ðšŠðšŸðšŽ ðš˜ðš—ðšŽ (ðŸ·) ðš˜ðš›ðšðšŽðš› ðš™ðšŽðš—ðšðš’ðš—ðš ðšðšŽðš•ðš’ðšŸðšŽðš›ðš¢. #622460835")._.cats)

Result (which is correct as the Unknown as the highest score):
{'Commercial': 0.13948287736862833, 'Crypto': 0.015437351941468657, 'Extortion': 0.0860014895963152, 'Financial': 0.01987490991768424, 'Gambling': 0.029074990906618126, 'Gift': 0.06850244399154756, 'Investment': 0.012729882351053419, 'Invoice': 0.0718818617408037, 'Phishing': 0.046637490542787444, 'Romance': 0.05515818363916855, 'Unknown': 0.45521851800392493}
Importing test dataset:
# Import the dataset and assign scores
Messages = pd.read_csv('November SID2.csv', encoding='utf8')

Messages['Body'] = Messages['Body'].astype(str)
Messages['NLP_Result'] = Messages['Body'].apply(lambda x: nlp(x)._.cats)

#Find the category based on highest score and join back to the original dataset

Scores = pd.json_normalize(Messages.NLP_Result)
Scores['Category'] = Scores.idxmax(axis=1)
Scores['Category'] = Scores['Category'].replace('_', ' ', regex=True)

Messages_Final = pd.concat([Messages, Scores], axis=1)
Messages_Final.to_csv('out.csv', index=False)

The result in csv file for that same statement:

Body
NLP_Result
Commercial
Crypto
Extortion
Financial
Gambling
Gift
Investment
Invoice
Phishing
Romance
Unknown
Category

FW: ðšð™´: ðšˆðš˜ðšž   ðš‘ðšŠðšŸðšŽ ðš˜ðš—ðšŽ (ðŸ·) ðš˜ðš›ðšðšŽðš›   ðš™ðšŽðš—ðšðš’ðš—ðš ðšðšŽðš•ðš’ðšŸðšŽðš›ðš¢. #622460835
{'Commercial': 0.03343028275903707, 'Crypto': 0.012076486026176284,   'Extortion': 0.08983918751534335, 'Financial': 0.07360790896376578,   'Gambling': 0.014564933067751274, 'Gift': 0.08460245841797985, 'Investment':   0.017324353297565327, 'Invoice': 0.1522007262418396, 'Phishing':   0.4507937431127887, 'Romance': 0.010566873139864728, 'Unknown':   0.060993047457888194}
0.03343
0.012076
0.089839
0.073608
0.014565
0.084602
0.017324
0.152201
0.450794
0.010567
0.060993
Phishing

Why are they inconsistent even when my training model has 'spacy.util.fix_random_seed(0)'?
Thank you

This is the case because the classifiers are not spacyspecific. They use torch or scikit-learn.

This is the case because the classifiers are not spacyspecific. They use torch or scikit-learn.

Thank you, did you mean underlying spacy library is using torch and scikit-learn? Because I haven't imported either of those for this project. Is there a way I can make it consistent by any chance?

Yes indeed, it uses them internally and asigns the predictions to a
spacy.Doc under doc._.cats.
On Wed, Dec 7, 2022 at 8:05 AM swageeth @.***> wrote:

This is the case because the classifiers are not spacyspecific. They use
torch or scikit-learn.
Thank you, did you mean underlying spacy library is using torch and
scikit-learn? Because I haven't imported either of those for this project.
Is there a way I can make it consistent by any chance?
—
Reply to this email directly, view it on GitHub
https://github.com/Pandora-Intelligence/classy-classification/issues/20#issuecomment-1340489357,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGAZHZCSUGP7TXZBFQV5TIDWMAZKPANCNFSM6AAAAAASWNTUFE
.
You are receiving this because you commented.Message ID:
@.***
com>

@swageeth does it make sense to you to align the seed with the spacy seed?

@swageeth does it make sense to you to align the seed with the spacy seed?

how can I make it align with the spacy seed in my code?

As of now, that isn`t possible, but I can include it in a next release.

As of now, that isn`t possible, but I can include it in a next release.

yes, please

@swageeth I will take a look the week after Christmas.

@swageeth this was handled in the new 0.5.4 release. Happy Holidays 🎄

Thanks @davidberenstein1957. Happy holidays to you too! :)


Revert "CI: use 'git diff $commits' as a whole patchset to do checkpatch"

Summary
This reverts commit 350131d00e1f0dddcd9252ec6a535830b08f0d1c.
If one PR is on a former master code base, using 'git diff $commits' would result in
abnormal checkpatch report sometimes. So revert it anyway.
Impact
Testing

@liuguo09 There was a similar one in apps/, should that be revert it as well?

@liuguo09 There was a similar one in apps/, should that be reverted as well?

Yes, I just revert it also. Thanks.


Track completed statuses (#111)

For some devices there may be an additional status update broadcast after the on_complete callback. This causes the status to be added back to the dictionary where it will never be removed.
Track which statuses have been completed and check this set when updating to ensure that a completed status is never added back to the snapshot after on_complete is called.

The code coverage check does highlight that there aren't currently any tests for this.

What is a status_name that we are tracking, the uuid of the status?

rename to something like status_uuid?

Sounds good to me.


Do not enforce arbitrary max header list size in HpackEncoder

Motivation:
When connecting to an HTTP/2 server that did not set any value for the
SETTINGS_MAX_HEADER_LIST_SIZE in the settings frame, the netty client was
imposing an arbitrary maximum header list size of 8kB. There should be no need
for the client to enforce such a limit if the server has not specified any
limit. This caused an issue for a grpc-java client that needed to send a large
header to a server via an Envoy proxy server. The error condition is
demonstrated here: https://github.com/JLofgren/demo-grpc-java-bug-4284
Fixes grpc-java issue - https://github.com/grpc/grpc-java/issues/4284
and netty issue #7825
Modifications:
In HpackEncoder use MAX_HEADER_LIST_SIZE as default maxHeader list size.
Result:
HpackEncoder will only enforce a max header list size if the server has
specified a limit in its settings frame.
Motivation:
Explain here the context, and why you're making that change.
What is the problem you're trying to solve.
Modification:
Describe the modifications you've done.
Result:
Fixes #.
If there is no issue then describe the changes introduced by this PR.

Can you also add a unit test ?

Am 06.04.2018 um 20:59 schrieb JLofgren<EMAIL_ADDRESS>Motivation:
When connecting to an HTTP/2 server that did not set any value for the
SETTINGS_MAX_HEADER_LIST_SIZE in the settings frame, the netty client was
imposing an arbitrary maximum header list size of 8kB. There should be no need
for the client to enforce such a limit if the server has not specified any
limit. This caused an issue for a grpc-java client that needed to send a large
header to a server via an Envoy proxy server. The error condition is
demonstrated here: https://github.com/JLofgren/demo-grpc-java-bug-4284
Fixes grpc-java issue #4284 - grpc/grpc-java#4284
and netty issue #7925 - #7825
Modifications:
In HpackEncoder use MAX_HEADER_LIST_SIZE as default maxHeader list size.
Result:
HpackEncoder will only enforce a max header list size if the server has
specified a limit in its settings frame.
Motivation:
Explain here the context, and why you're making that change.
What is the problem you're trying to solve.
Modification:
Describe the modifications you've done.
Result:
Fixes #.
If there is no issue then describe the changes introduced by this PR.
You can view, comment on, or merge this pull request online at:
https://github.com/netty/netty/pull/7853
Commit Summary
Do not enforce arbitrary max header list size in HpackEncoder
File Changes
M codec-http2/src/main/java/io/netty/handler/codec/http2/HpackEncoder.java (2)
Patch Links:
https://github.com/netty/netty/pull/7853.patch
https://github.com/netty/netty/pull/7853.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Added.

@carl-mastrangelo @Scottmitch @ejona86 PTAL


RuntimeError: Tensors must have same number of dimensions: got 3 and 4

The following command:
python repositories/GPTQ-for-LLaMa/llama.py /path/to/my/text-generation-webui/models/llama-7b c4 --wbits 4 --save llama-7b-4bit.pt
Fails with:
__Traceback (most recent call last):
File "/path/to/my/text-generation-webui/repositories/GPTQ-for-LLaMa/llama.py", line 410, in
quantizers = llama_sequential(model, dataloader, DEV)
File "/usr/local/lib64/python3.10/site-packages/torch/autograd/grad_mode.py", line 27, in decorate_context
return func(*args, **kwargs)
File "/path/to/my/text-generation-webui/repositories/GPTQ-for-LLaMa/llama.py", line 88, in llama_sequential
outs[j] = layer(inps[j].unsqueeze(0), attention_mask=attention_mask)[0]
File "/usr/local/lib64/python3.10/site-packages/torch/nn/modules/module.py", line 1194, in call_impl
return forward_call(*input, **kwargs)
File "/my/homedir/.local/lib/python3.10/site-packages/transformers/models/llama/modeling_llama.py", line 318, in forward
hidden_states, self_attn_weights, present_key_value = self.self_attn(
File "/usr/local/lib64/python3.10/site-packages/torch/nn/modules/module.py", line 1194, in call_impl
return forward_call(*input, **kwargs)
File "/my/homedir/.local/lib/python3.10/site-packages/transformers/models/llama/modeling_llama.py", line 228, in forward
query_states, key_states = apply_rotary_pos_emb(query_states, key_states, cos, sin, offset=offset)
File "/my/homedir/.local/lib/python3.10/site-packages/transformers/models/llama/modeling_llama.py", line 142, in apply_rotary_pos_emb
q_embed = (q * cos) + (rotate_half(q) * sin)
File "/my/homedir/.local/lib/python3.10/site-packages/transformers/models/llama/modeling_llama.py", line 136, in rotate_half
return torch.cat((-x2, x1), dim=-1)
RuntimeError: Tensors must have same number of dimensions: got 3 and 4
Any thoughts on what might be wrong?  That source model works just fine on its own.
I've tried downloading models converted by others and using them in text-generation-webui. The server starts fine, but whenever I click generate, I again get the same "Tensors must have same number of dimensions" error.
In case it matters, I do have two GPUs.  But setting CUDA_VISIBLE_DEVICES=0 doesn't help, neither with llama.py nor text-generation-webui's server.py. Nor does --gpu_memory 5 5 or similar help in text-generation-webui.

ED: this might be the solution:
pip uninstall transformers
pip install git+https://github.com/zphang/transformers.git@68d640f7c368bcaaaecfc678f11908ebbd3d6176

You seem to have solved this problem. I will close the issue.

This problem still exists, I solved with the same way as @enn-nafnlaus after trying different thins for 1 hour .
@qwopqwop200 What is the commit hash that you use mainly in https://github.com/zphang/transformers/tree/llama_push ?
Cause he changed lots of things and lots of stuff is broken rn. If you can pin the exact commit in the requirements.txt, that would be way better.

As per your suggestion, we will use a fixed commit version until the Transformer is stable.


[HHH-10187] fix OuterJoinCriteriaTest hanging on Sybase

https://hibernate.atlassian.net/browse/HHH-10187

This issue was fixed by HHH-10045, this PR is no longer needed.


Other certificate addition

Sorry for trying to ask all together, it is my mistak.Apologize for that.
Focused only in add "othercerts":
The value returned by bytes(attrDict(PK11.CKA_VALUE)) is in bytes format, which is not admitted by cer2asn function as is not a X509.Certificate and then "cert.public_bytes(serialization.Encoding.PEM" is tried.
Thanks

I have always prepared other certificates by hand.
After loading the certificate from HSM, convert it to x509:
from asn1crypto import x509
cert = x509.Certificate.load (cert_bytes)
or by:
cert = endesive.signer.cert2asn (cert_bytes, False)

Thanks very much. With this I have been able to add the certificate.
Thanks for all


How to organize Documentation content in a right order

We can think about what contents should each Objectives or sub-communities can contribute to Documentation SWG, e.g. Core objective or Japanese-speaking community.

(to be) merged to #119.


footer update

there should be some gap in footer , which can make it look more beautiful ,
please assign me this issue under gssoc

Assigned! @dhairyagothi
Make sure to attach before & after screenshots in your PR. Also, star the repo before working on it. While creating your PR, ensure you pull all existing changes beforehand to avoid conflicts.
Happy open-source contributing!

Assigned! @dhairyagothi Make sure to attach before & after screenshots in your PR. Also, star the repo before working on it. While creating your PR, ensure you pull all existing changes beforehand to avoid conflicts. Happy open-source contributing!

thankyou for assigning me soon i will make PR with changes


Textual changes of some models on the "Manage backup" screen.

-Headline: Please complete Level 1
Sub heading: It seems you have not backed up your wallet on the cloud. Please complete Level 1 to proceed

-Verified this change on dev app v1.5.0(260)


Fixed an issue with the form builder and drag-and-drop outside of panel.

Fixes https://github.com/formio/ngFormBuilder/issues/168


Quarantine 2 sig-compute flaky tests

Signed-off-by: Federico Gimenez<EMAIL_ADDRESS>
What this PR does / why we need it: quarantine flaky tests to improve suite stability.

[Serial][rfe_id:393][crit:high][vendor:cnv-qe@redhat.com][level:system][sig-compute] VM Live Migration Starting a VirtualMachineInstance  with a Fedora shared NFS PVC (using nfs ipv4 address), cloud init and service account should be migrated successfully, using guest agent on VM [test_id:5004] with postcopy

Reported by flakefinder https://storage.googleapis.com/kubevirt-prow/reports/flakefinder/kubevirt/kubevirt/flakefinder-2021-05-16-168h.html#row0
Recent failures:

https://prow.ci.kubevirt.io/view/gs/kubevirt-prow/logs/periodic-kubevirt-e2e-k8s-1.19-sig-compute/1394135611610238976
https://prow.ci.kubevirt.io/view/gs/kubevirt-prow/logs/periodic-kubevirt-e2e-k8s-1.20-cgroupsv2/1394080246579335168
https://prow.ci.kubevirt.io/view/gs/kubevirt-prow/logs/periodic-kubevirt-e2e-k8s-1.20-sig-compute/1394057588013797376
https://prow.apps.ovirt.org/view/gs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/5637/pull-kubevirt-e2e-k8s-1.19-sig-compute/1394131651264516096
https://prow.apps.ovirt.org/view/gs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/5580/pull-kubevirt-e2e-k8s-1.20-sig-compute/1394056541820162048

[sig-compute]HookSidecars [rfe_id:2667][crit:medium][vendor:cnv-qe@redhat.com][level:component] VMI definition [Serial]with sidecar feature gate disabled [test_id:2666]should not start with hook sidecar annotation

Reported by flakefinder https://storage.googleapis.com/kubevirt-prow/reports/flakefinder/kubevirt/kubevirt/flakefinder-2021-05-16-168h.html#row5
Recent errros:

https://prow.apps.ovirt.org/view/gs/kubevirt-prow/logs/periodic-kubevirt-e2e-k8s-1.20-sig-compute/1393574551383707648
https://prow.apps.ovirt.org/view/gs/kubevirt-prow/logs/periodic-kubevirt-e2e-k8s-1.19-sig-compute/1392927628029071360
https://prow.apps.ovirt.org/view/gs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/5652/pull-kubevirt-e2e-k8s-1.19-sig-compute/1394168093344796672
https://prow.apps.ovirt.org/view/gs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/5637/pull-kubevirt-e2e-k8s-1.20-sig-compute/1393829404286652416

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

NONE

/test pull-kubevirt-e2e-k8s-1.20-sig-storage

/lgtm

Hey @fgimenez ,
Regarding test_id:5004 - please see the quick discussion on the test in this PR, you might find it useful.
Regarding test_id:2666 - please bear in mind that sidecar tests are about to be removed from tier1 as sidecar feature gate it not supported anymore.

/approve

Hey @fgimenez ,
Regarding test_id:5004 - please see the quick discussion on the test in this PR, you might find it useful.
Regarding test_id:2666 - please bear in mind that sidecar tests are about to be removed from tier1 as sidecar feature gate it not supported anymore.
/lgtm

@fgimenez Also in this PR notice that [test_id:4747] fails on the same issue. Could 4747 and 5004 be related?

/test pull-kubevirt-build-arm64
/test pull-kubevirt-client-python
quay timeouts

Regarding test_id:2666 - please bear in mind that sidecar tests are about to be removed from tier1 as sidecar feature gate it not supported anymore.

@iholder-redhat kubevirt hyperconverged operator does not expose the sidecar feature as it has security downsides. Red Hat customers, for example, do not want it. However, on the KubeVirt level, I was not aware of plans to deprecate this feature and its tests. I suspect do not want to drop tests while keeping the production code. Please make sure that you discuss feature deprecation in a wide forum.

Regarding test_id:2666 - please bear in mind that sidecar tests are about to be removed from tier1 as sidecar feature gate it not supported anymore.

@iholder-redhat kubevirt hyperconverged operator does not expose the sidecar feature as it has security downsides. Red Hat customers, for example, do not want it. However, on the KubeVirt level, I was not aware of plans to deprecate this feature and its tests. I suspect do not want to drop tests while keeping the production code. Please make sure that you discuss feature deprecation in a wide forum.

Hey Dan,
Thanks for the clarification :)
I was talking to @stu-gott about this and he said that we can simply delete all of the code for the tests that relay on sidecar feature gate in upstream. That's what we both understood from the Slack thread in which wide range of people were talking about this. In today's quarantine meeting @phoracek and I talked about this and he thought there might be a misunderstanding here, therefore he sent a clarification message in the Slack thread to hear other people's opinion about this.

@fgimenez Also in this PR notice that [test_id:4747] fails on the same issue. Could 4747 and 5004 be related?

@iholder-redhat hmm maybe not sure, in the recent failures linked above test_id:5004 was failing alone:
https://prow.ci.kubevirt.io/view/gs/kubevirt-prow/logs/periodic-kubevirt-e2e-k8s-1.19-sig-compute/1394135611610238976
https://prow.ci.kubevirt.io/view/gs/kubevirt-prow/logs/periodic-kubevirt-e2e-k8s-1.20-cgroupsv2/1394080246579335168
https://prow.ci.kubevirt.io/view/gs/kubevirt-prow/logs/periodic-kubevirt-e2e-k8s-1.20-sig-compute/1394057588013797376
https://prow.apps.ovirt.org/view/gs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/5637/pull-kubevirt-e2e-k8s-1.19-sig-compute/1394131651264516096
https://prow.apps.ovirt.org/view/gs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/5580/pull-kubevirt-e2e-k8s-1.20-sig-compute/1394056541820162048

/test pull-kubevirt-unit-test

/test pull-kubevirt-unit-test

/retest


Robonomics-chain plugin request

Para-chain name
Robonomics
Description
Overview of your para-chain.

Website: https://robonomics.network
Dapp: https://dapp.robonomics.network/
Explorer: https://polkadot.js.org/apps - select Robonomics in Kusama parachains
Plugin repo: https://github.com/Multi-Agent-io/polkawallet_plugin_robonomics

Plugin functions
Overview of your Plugin.

Sending Launch command into network
Sending Datalog command with parameters
Reading Datalog current ring index and element by index from network

Hello!
We'd like to add Robonomics Network in Polkawallet. Robonomics has won a parachain slot in Kusama last January and provides utility functions for IoT devices. It enables easy connection IoT to Web3 world!
First release of the plugin includes the very basic functions such as launch and datalog. The first allows one to launch on and off a specific device (via its robonomics address), the second one allows to store or retrieve data to/from blockchain (for example telemetry of a device)

I just tested your plugin and found it doesn't has an icon for XRT, maybe you should add the XRT icon in plugin.tokenIcons.

@RomeroYang, Just updated assets and packages. Now it should be clean

@RomeroYang Did you have a chance to test the plugin again?

Set genesisHash of the network like this https://github.com/polkawallet-io/polkawallet_plugin_kusama/blob/37ea059b990e6771926da7e0148da417d376a4fd/lib/polkawallet_plugin_kusama.dart#L53
Polkawallet will check it to ensure the plugin sending Extrinsics to the right network.

@RomeroYang, done. Added genesis. You can check it further

Go to Settings -> Metadata page in https://polkadot.js.org/apps, you will see the genesisHash, it should be 0x631ccc82a078481584041656af292834e1ae6daab61d2875b4dd0c14bb9b17bc for robonomics.

@RomeroYang changed to this

@RomeroYang
Bump

@RomeroYang did you have time to check the plugin?

Integrated in release 3.1.8


_WD_JsonCookie() added

Here is my new proposal

I'm wondering how mulptiple coockies should be added ?
Simply like in this following example:
	_WD_Cookies($sSession, 'add', _WD_JsonCookie("name1", "value1"))
	_WD_Cookies($sSession, 'add', _WD_JsonCookie("name2", "value2"))
	_WD_Cookies($sSession, 'add', _WD_JsonCookie("name3", "value3"))

or for all this 3 different cookies should or even must be created single JSON string like this:
 {
   "cookie": [
     {"name": "cookie1", "value": "hello"},
     {"name": "cookie2", "value": "goodbye"}
   ]
 }

?

I'm wondering how mulptiple cookies should be added ?

I haven't seen anywhere that suggests that it could be done in a single command, but this is something you would need to test.

also this all feature should be added

Don't forget Cookie path and Cookie domain

I haven't seen anywhere that suggests that it could be done in a single command, but this is something you would need to test.

https://github.com/jlipps/simple-wd-spec/
The Add Cookie command adds a single cookie to the cookie store associated with the active document's address.
Is it sufficient to confirm how it works?

As for now in DemoCookies() i used:
Local $sCookie = _WD_JsonCookie($sName, $sValue, Default, 'www.google.com', True, False,<PHONE_NUMBER>, "None")

When it comes to $iExpiryTime =<PHONE_NUMBER> I would like to do something like current time + 1 minute.
I search for some UNIX EPOCH time on the forum.
I found some discusions/examples here:
https://www.autoitscript.com/forum/topic/97645-date-to-unix-timestamp-conversion/
https://www.autoitscript.com/forum/topic/83667-epoch-time/
Which I should use in: DemoCookies() ?

Is it sufficient to confirm how it works?

Yes, that matches my understanding from the official specs


Update and rename petstore.yaml to test1.1.yaml

Could you provide an description of why this OAS document is a better replacement for the petstore example?

This PR appears to overwrite the Petstore example with a different example.  Please feel free to reopen if you want to submit a different example along side the Petstore example.


[BUG] System.Exception: Signature does not match!

Acknowledgement of preliminary instructions

[X] I have read the preliminary instructions, and I am certain that my problem has not already been addressed.

What problem did you encounter?
I checked the Wiki first, but it still did not work. I have tried to run as administrator, but it still does not work. the same error occurred when I was trying to install bloxstrap for the first time but i can fix it with just run as administrator, but now when upgrading Roblox, it happened again.
Here the logs: 2024-01-26T08:23:54Z [App::OnStartup] Starting Bloxstrap v2.5.4
2024-01-26T08:23:54Z [App::OnStartup] Compiled Saturday, 4 November 2023 at 4:46:02 AM from commit 880c076fcd875fc10b5f6bef770033074d79a7a8 (tag/v2.5.4)
2024-01-26T08:23:54Z [App::OnStartup] Loaded from %UserProfile%\AppData\Local\Bloxstrap\Bloxstrap.exe
2024-01-26T08:23:54Z [Logger::Initialize] Initializing at %UserProfile%\AppData\Local\Bloxstrap\Logs\Bloxstrap_20240126T082354Z.log
2024-01-26T08:23:54Z [Logger::Initialize] Finished initializing!
2024-01-26T08:23:54Z [Logger::Initialize] Cleaning up old log file 'Bloxstrap_20240119T080954Z.log'
2024-01-26T08:23:54Z [JsonManager::Load] Loading from %UserProfile%\AppData\Local\Bloxstrap\Settings.json...
2024-01-26T08:23:54Z [JsonManager::Load] Loaded successfully!
2024-01-26T08:23:54Z [JsonManager::Load] Loading from %UserProfile%\AppData\Local\Bloxstrap\State.json...
2024-01-26T08:23:54Z [JsonManager::Load] Loaded successfully!
2024-01-26T08:23:54Z [JsonManager<Dictionary2>::Load] Loading from %UserProfile%\AppData\Local\Bloxstrap\Modifications\ClientSettings\ClientAppSettings.json... 2024-01-26T08:23:54Z [JsonManager<Dictionary2>::Load] Loaded successfully!
2024-01-26T08:23:54Z [NotifyIconWrapper::NotifyIconWrapper] Initializing notification area icon
2024-01-26T08:23:54Z [JsonManager::Save] Save request ignored
2024-01-26T08:23:54Z [App::OnStartup] Initializing bootstrapper
2024-01-26T08:23:54Z [App::OnStartup] Initializing bootstrapper dialog
2024-01-26T08:23:54Z [App::OnStartup] Creating singleton mutex
2024-01-26T08:23:54Z [Bootstrapper::Run] Running bootstrapper
2024-01-26T08:23:54Z [Bootstrapper::Run] Performing connectivity check...
2024-01-26T08:23:54Z [Bootstrapper::SetStatus] Connecting to Roblox...
2024-01-26T08:23:54Z [RobloxDeployment::GetInfo] Getting deploy info for channel LIVE (extraInformation=False)
2024-01-26T08:23:54Z [HttpClientLoggingHandler::ProcessRequest] GET https://clientsettingscdn.roblox.com/v2/client-version/WindowsPlayer/channel/LIVE
2024-01-26T08:23:57Z [HttpClientLoggingHandler::ProcessResponse] 200 OK https://clientsettingscdn.roblox.com/v2/client-version/WindowsPlayer/channel/LIVE
2024-01-26T08:23:57Z [Bootstrapper::Run] Connectivity check finished
2024-01-26T08:23:57Z [Bootstrapper::CheckForUpdates] Checking for updates...
2024-01-26T08:23:57Z [HttpClientLoggingHandler::ProcessRequest] GET https://api.github.com/repos/pizzaboxer/bloxstrap/releases/latest
2024-01-26T08:23:59Z [HttpClientLoggingHandler::ProcessResponse] 200 OK https://api.github.com/repos/pizzaboxer/bloxstrap/releases/latest
2024-01-26T08:23:59Z [Bootstrapper::CheckForUpdates] No updates found
2024-01-26T08:23:59Z [RobloxDeployment::GetInfo] Getting deploy info for channel LIVE (extraInformation=False)
2024-01-26T08:23:59Z [RobloxDeployment::GetInfo] Deploy information is cached
2024-01-26T08:23:59Z [DeployManager::DefaultBaseUrl.Set] Testing connection to 'https://setup.rbxcdn.com'...
2024-01-26T08:23:59Z [HttpClientLoggingHandler::ProcessRequest] GET https://setup.rbxcdn.com/version
2024-01-26T08:24:00Z [HttpClientLoggingHandler::ProcessResponse] 200 OK https://setup.rbxcdn.com/version
2024-01-26T08:24:00Z [DeployManager::DefaultBaseUrl.Set] Connection successful!
2024-01-26T08:24:00Z [HttpClientLoggingHandler::ProcessRequest] GET https://setup.rbxcdn.com/version-2355c01e37774010-rbxPkgManifest.txt
2024-01-26T08:24:00Z [HttpClientLoggingHandler::ProcessResponse] 200 OK https://setup.rbxcdn.com/version-2355c01e37774010-rbxPkgManifest.txt
2024-01-26T08:24:00Z [HttpClientLoggingHandler::ProcessRequest] GET https://setup.rbxcdn.com/version-2355c01e37774010-rbxManifest.txt
2024-01-26T08:24:01Z [HttpClientLoggingHandler::ProcessResponse] 200 OK https://setup.rbxcdn.com/version-2355c01e37774010-rbxManifest.txt
2024-01-26T08:24:01Z [Bootstrapper::SetStatus] Upgrading Roblox...
2024-01-26T08:24:01Z [Bootstrapper::DownloadPackage.RobloxApp.zip] Downloading...
2024-01-26T08:24:01Z [HttpClientLoggingHandler::ProcessRequest] GET https://setup.rbxcdn.com/version-2355c01e37774010-RobloxApp.zip
2024-01-26T08:24:01Z [HttpClientLoggingHandler::ProcessResponse] 200 OK https://setup.rbxcdn.com/version-2355c01e37774010-RobloxApp.zip
2024-01-26T08:24:02Z [Bootstrapper::DownloadPackage.RobloxApp.zip] An exception occurred after downloading 5470787 bytes. (1/5)
2024-01-26T08:24:02Z [Bootstrapper::DownloadPackage.RobloxApp.zip] System.IO.IOException: The decryption operation failed, see inner exception.
---> System.ComponentModel.Win32Exception (0x80090330): The specified data could not be decrypted.
--- End of inner exception stack trace ---
at System.Net.Security.SslStream.ReadAsyncInternal[TIOAdapter](TIOAdapter adapter, Memory1 buffer)    at System.Net.Http.HttpConnection.ReadAsync(Memory1 destination)
at System.Net.Http.HttpConnection.ContentLengthReadStream.ReadAsync(Memory`1 buffer, CancellationToken cancellationToken)
at Bloxstrap.Bootstrapper.DownloadPackage(Package package)
at Bloxstrap.Bootstrapper.DownloadPackage(Package package)
at Bloxstrap.Bootstrapper.DownloadPackage(Package package)
2024-01-26T08:24:02Z [Bootstrapper::DownloadPackage.RobloxApp.zip] Retrying download over HTTP...
2024-01-26T08:24:02Z [HttpClientLoggingHandler::ProcessRequest] GET http://setup.rbxcdn.com/version-2355c01e37774010-RobloxApp.zip
2024-01-26T08:24:03Z [HttpClientLoggingHandler::ProcessResponse] 200 OK http://setup.rbxcdn.com/version-2355c01e37774010-RobloxApp.zip
2024-01-26T08:24:25Z [Bootstrapper::DownloadPackage.RobloxApp.zip] An exception occurred after downloading 80971667 bytes. (2/5)
2024-01-26T08:24:25Z [Bootstrapper::DownloadPackage.RobloxApp.zip] System.Exception: Signature does not match!
at Bloxstrap.Bootstrapper.DownloadPackage(Package package)
at Bloxstrap.Bootstrapper.DownloadPackage(Package package)
at Bloxstrap.Bootstrapper.DownloadPackage(Package package)
2024-01-26T08:24:25Z [HttpClientLoggingHandler::ProcessRequest] GET http://setup.rbxcdn.com/version-2355c01e37774010-RobloxApp.zip
2024-01-26T08:24:25Z [HttpClientLoggingHandler::ProcessResponse] 200 OK http://setup.rbxcdn.com/version-2355c01e37774010-RobloxApp.zip
2024-01-26T08:24:53Z [Bootstrapper::DownloadPackage.RobloxApp.zip] An exception occurred after downloading 80971667 bytes. (3/5)
2024-01-26T08:24:53Z [Bootstrapper::DownloadPackage.RobloxApp.zip] System.Exception: Signature does not match!
at Bloxstrap.Bootstrapper.DownloadPackage(Package package)
at Bloxstrap.Bootstrapper.DownloadPackage(Package package)
at Bloxstrap.Bootstrapper.DownloadPackage(Package package)
2024-01-26T08:24:53Z [HttpClientLoggingHandler::ProcessRequest] GET http://setup.rbxcdn.com/version-2355c01e37774010-RobloxApp.zip
2024-01-26T08:24:54Z [HttpClientLoggingHandler::ProcessResponse] 200 OK http://setup.rbxcdn.com/version-2355c01e37774010-RobloxApp.zip
2024-01-26T08:25:18Z [Bootstrapper::DownloadPackage.RobloxApp.zip] An exception occurred after downloading 80971667 bytes. (4/5)
2024-01-26T08:25:18Z [Bootstrapper::DownloadPackage.RobloxApp.zip] System.Exception: Signature does not match!
at Bloxstrap.Bootstrapper.DownloadPackage(Package package)
at Bloxstrap.Bootstrapper.DownloadPackage(Package package)
at Bloxstrap.Bootstrapper.DownloadPackage(Package package)
2024-01-26T08:25:18Z [HttpClientLoggingHandler::ProcessRequest] GET http://setup.rbxcdn.com/version-2355c01e37774010-RobloxApp.zip
2024-01-26T08:25:18Z [HttpClientLoggingHandler::ProcessResponse] 200 OK http://setup.rbxcdn.com/version-2355c01e37774010-RobloxApp.zip
2024-01-26T08:25:39Z [Bootstrapper::DownloadPackage.RobloxApp.zip] An exception occurred after downloading 80971667 bytes. (5/5)
2024-01-26T08:25:39Z [Bootstrapper::DownloadPackage.RobloxApp.zip] System.Exception: Signature does not match!
at Bloxstrap.Bootstrapper.DownloadPackage(Package package)
at Bloxstrap.Bootstrapper.DownloadPackage(Package package)
at Bloxstrap.Bootstrapper.DownloadPackage(Package package)
2024-01-26T08:25:39Z [App::OnStartup] Bootstrapper task has finished
2024-01-26T08:25:39Z [NotifyIconWrapper::Dispose] Disposing NotifyIcon
2024-01-26T08:25:39Z [App::OnStartup] An exception occurred when running the bootstrapper
2024-01-26T08:25:39Z [App::OnStartup] System.AggregateException: One or more errors occurred. (Signature does not match!)
---> System.Exception: Signature does not match!
at Bloxstrap.Bootstrapper.DownloadPackage(Package package)
at Bloxstrap.Bootstrapper.DownloadPackage(Package package)
at Bloxstrap.Bootstrapper.DownloadPackage(Package package)
at Bloxstrap.Bootstrapper.InstallLatestVersion()
at Bloxstrap.Bootstrapper.Run()
at Bloxstrap.Bootstrapper.Run()
at Bloxstrap.App.<>c__DisplayClass56_0.<b__1>d.MoveNext()
--- End of inner exception stack trace ---

Besides the information given in the Wiki, there isn't really much else I can do to help you as of now, sorry.


Fix crash on indexing callgraph for impls [phab:D980]

Created by djrenren at 2016-07-22 18:23:38:
When indexing callgraphs we inspect the parent item to determine it's something we want to attach a childof edge to. Unfortunately, expect_item was causing a crash when inspecting parents which were method impls because they aren't of type Item. The new method safely inspects the parent by only acting on the call if it is of one of the two appropriate types.

shahms commented inline (context lost during migration) at 2016-07-22 18:26:20:
nit: wrap this comment?

shahms wrote at 2016-07-22 19:41:43:
(Other than the minor formatting nit).

shahms accepted this revision at 2016-07-22 19:41:43

djrenren closed via commit 0b0b4a4db3e6043f09f0d846d9421a9b410df7eb at 2016-07-22 20:57:22

djrenren commented inline (context lost during migration) at 2016-07-22 20:58:15:
We're using the defacto rust style guide which utilizes 99 character line length. This is the result of running the file through rustfmt


Commited

Change, 01-spell-check.md

Thank You @rajvijen for the PR!
Since we want to keep the mistakes for other participants to work on, we wouldn't be merging this PR. Hope the practice was good nevertheless :)


[DROOLS-986] fix reteoo intialization via system property

ok to test

@mariofusco the test you committed has no assertions. Maybe you can add some assertions there to at least "document" expected behaviour?
The fix looks fine.

Merged by https://github.com/droolsjbpm/drools/commit/731f00a66b0fbe6591160af588e0bed44d186c83