Suggestion

Firstly, thanks for all this!  I was completely fine with the livepatch tip, but this has gotten totally out of hand.   Also, I don't think that "sudo pro config set apt_news=false" works.
Now that I have to do all this junk, I find myself inclined to want said live patch tip gone as well.  This is easily accomplished by editing /usr/lib/python3/dist-packages/UpdateManager/Dialogs.py and cobbling this function to return False.

    def _is_livepatch_supported(self):
        return False # Cut it out, #@&# it!
        di = distro_info.UbuntuDistroInfo()
        codename = get_dist()
        return di.is_lts(codename)

Credit:  MikeR

I think our line numbers are differing a bit (I'm also on 24.04).  24 is a blank line, 278-315 spans the middle of several functions for me, and the file ends at 475.  Maybe my file is out of date


How do I install other apps such as Chrome and Firefox on this?

Change the source to a debian distro and apt install firefox-esr

Change the source to a debian distro and apt install firefox-esr

how can i do that

You must have a proot container to use it, and xhost working


The signature of certain functions do not match the signature of the implementation

Bug Report
Functions such as isArrayType() and isTupleType have a different signature in src/compiler/types.ts and in the implementation in src/checker/types.ts.
In src/compiler/types.ts:
isArrayType(type: Type): boolean;
isTupleType(type: Type): boolean;

In src/compiler/checker.ts:
isTupleType(type: Type): type is TupleTypeReference;
isArrayType(type: Type): type is TypeReference;

This means that the post-condition of these functions cannot be made use of in external code.
🔎 Search Terms

isArrayType, isTupleType
Signature, TypeChecker

🕗 Version & Regression Information
This was only an internal issue until these functions were exposed in https://github.com/microsoft/TypeScript/pull/52467
💻 Code
if (typeChecker.isArrayType(type)) {
    // complains that type is not TypeReference
    typeChecker.getTypeArguments(type);
}

🙁 Actual behavior
TS2345 [ERROR]: Argument of type 'Type' is not assignable to parameter of type 'TypeReference'.
  Type 'Type' is missing the following properties from type 'TypeReference': target, objectFlags
                const typeArgument = checker.getTypeArguments(type);

🙂 Expected behavior
The code example given compiles without issues.
PS: I have a PR ready to be submitted to fix it for these particular functions

The internal signature is wrong, dangerous, and convenient, because they make negative implications that aren't correct (a thing that is not an ArrayType is not necessarily not a TypeReference). The external signature is correct, safe, and less-convenient.
We think this is a good trade-off for us, but not for people who aren't as familiar with TS as people who are working on TS itself.

Could adding an ArrayType which extends TypeReference fix the problem?

@NilsIrl That won’t fix anything.  The issue is that, if you say the return type is type is TypeReference and the function returns false, TS then assumes that type is not a TypeReference and narrows accordingly.  Which is wrong and a potential footgun because it might still be a TypeReference even if it’s not an ArrayType.
This is the same reason functions like Number.isFinite() don’t return x is number.  See https://github.com/microsoft/TypeScript/issues/15048.

The idea would then be to then change the signature to this:
interface ArrayType extends TypeReference {}

isArrayType(type: Type): type is ArrayType;

Which means that if the function then returns false, it doesn't mean type is not a TypeReference


Transitioning AIP 2.0 RFCs to the "ACCEPTED" status

A large number of AIP RFCs have had not had their status updated to ACCEPTED.  The goal of this issue is to track those transitions and propose a process that allows us to proceed with AIP 2.0 finalization without getting bogged down with the bureaucratic processes.
The process I propose is the following:

In the next Aries WG meeting, we walk through all of the "not yet Accepted" and take a "no discussion" vote on each RFC listed below.
For each unanimous yes vote, the repo maintainers are given the authority to add and merge a PR to update the status of the RFC.
For each vote that has one or more no votes, a discussion will be held after going through the rest of the list, and if possible another vote is held. The discussion should be brief so as to determine if a longer discussion or an update to the RFC is needed before another
If there is a majority yes vote following the discussion, the repo maintainers are given the authority to add and merge a PR to update the status of the RFC.
For the remaining RFCs, the group will decide how to address them -- keep the RFC in AIP 2.0, request a volunteer to work the "difficult" issues, etc.

The goal will be to get through the full list.  Participants are asked to review at least the RFCs that they think may be insufficient as they currently stand.
Here is the list of RFCs to be reviewed:

[x] Concept | 0519-goal-codes | :new:
[x] Feature | 0015-acks | AIP V1.0, Updated
[x] Feature | 0023-did-exchange | :new:
[x] Features | 0044-didcomm-file-and-mime-types | :new:
[x] Feature | 0360-use-did-key | :new:
[x] Feature | 0434-outofband | :new:
[x] Feature | 0557-discover-features-v2 | :new:
[ ] Feature | 0183-revocation-notification | :new:
[x] Feature | 0453-issue-credential-v2 | Update to V2 Protocol
[x] Feature | 0454-present-proof-v2 | Update to V2 Protocol
[x] Feature | 0627-static-peer-dids  | :new:

MEDIATE: Mediator Coordination

[x] Already accepted

INDYCRED: Indy Based Credentials

[x] Feature | 0592-indy-attachments | :new: Evolved from AIP V1.0
[x] Concept | 0441-present-proof-best-practices | :new:

LDCRED: JSON-LD Based Credentials

[x] Feature | PR: 0593-json-ld-cred-attach | :new:
[ ] Feature | 0510-dif-pres-exch-attach | :new:

BBSCRED: BBS+ Based Credentials

[ ] Feature | 0xxx-bbs+-signature-credential-exchange-attachments | :new:

DIFPX: DIF Presentation Exchange Support

[ ] Feature | 0510-dif-pres-exch-attach | :new:

DIDCOMMV2PREP: DIDComm v2 Prep

[x] Feature | 0587-encryption-envelope-v2 | :new:See envelope note below

First round -- votes without discussion:

[ x] Concept | 0519-goal-codes | :new:
[x ] Feature | 0015-acks | AIP V1.0, Updated
[ x] Feature | 0023-did-exchange | :new:
[ x] Features | 0044-didcomm-file-and-mime-types | :new:
[x ] Feature | 0360-use-did-key | :new:
[ ] Feature | 0434-outofband | :new:
[ x] Feature | 0557-discover-features-v2 | :new:
[ ] Feature | 0183-revocation-notification | :new:
[ x] Feature | 0453-issue-credential-v2 | Update to V2 Protocol
[x ] Feature | 0454-present-proof-v2 | Update to V2 Protocol
[ ] Feature | 0627-static-peer-dids  | :new:

MEDIATE: Mediator Coordination

[x] Already accepted

INDYCRED: Indy Based Credentials

[x ] Feature | 0592-indy-attachments | :new: Evolved from AIP V1.0
[ x] Concept | 0441-present-proof-best-practices | :new:

LDCRED: JSON-LD Based Credentials

[x ] Feature | PR: 0593-json-ld-cred-attach | :new:
[ ] Feature | 0510-dif-pres-exch-attach | :new:

BBSCRED: BBS+ Based Credentials

[ ] Feature | 0xxx-bbs+-signature-credential-exchange-attachments | :new:

DIFPX: DIF Presentation Exchange Support

[ ] Feature | 0510-dif-pres-exch-attach | :new:

DIDCOMMV2PREP: DIDComm v2 Prep

[x ] Feature | 0587-encryption-envelope-v2 | :new:

0434 -- @b1conrad will add a PR to change the language around
0183 -- @smithbk to add a PR to reference V2 Issue/Present (RFC 0453/0454); change "credential_id" to "thread_id" to indicate that the related credential, reference that if multiples of credential are issued they are the same data/different format; add note that this is not a security issue if done/not done; add please-ack.
0317 -- @TimoGlastra -- to take a pass at cleaning up this RFC and we'd like to include it in AIP 2.0
0627 -- @swcurran -- Need a community update transition --- issue and then RFC
0510 -- @TimoGlastra @llorllale -- to use Issue #598 to do a PR to RFC 0510.
BBS+ RFC -- @TimoGlastra to write that one.
After round two -- votes without discussion:

[x] Concept | 0519-goal-codes | :new:
[x] Feature | 0015-acks | AIP V1.0, Updated
[x] Feature | 0023-did-exchange | :new:
[x] Features | 0044-didcomm-file-and-mime-types | :new:
[x] Feature | 0360-use-did-key | :new:
[x] Feature | 0434-outofband | :new:
[x] Feature | 0557-discover-features-v2 | :new:
[x] Feature | 0183-revocation-notification | :new:
[x] Feature | 0453-issue-credential-v2 | Update to V2 Protocol
[x] Feature | 0454-present-proof-v2 | Update to V2 Protocol
[x] Feature | 0627-static-peer-dids  | :new:

MEDIATE: Mediator Coordination

[x] Already accepted

INDYCRED: Indy Based Credentials

[x] Feature | 0592-indy-attachments | :new: Evolved from AIP V1.0
[x] Concept | 0441-present-proof-best-practices | :new:

LDCRED: JSON-LD Based Credentials

[x] Feature | PR: 0593-json-ld-cred-attach | :new:
[x] Feature | 0510-dif-pres-exch-attach | :new:

BBSCRED: BBS+ Based Credentials

[ ] Feature | 0xxx-bbs+-signature-credential-exchange-attachments | :new:

DIFPX: DIF Presentation Exchange Support

[x] Feature | 0510-dif-pres-exch-attach | :new:

DIDCOMMV2PREP: DIDComm v2 Prep

[x] Feature | 0587-encryption-envelope-v2 | :new:

First round -- votes without discussion -- PRs:

[ ] Concept | 0519-goal-codes | :new:
[ ] Feature | 0015-acks | AIP V1.0, Updated
[ ] Feature | 0023-did-exchange | :new:
[ ] Features | 0044-didcomm-file-and-mime-types | :new:
[ ] Feature | 0360-use-did-key | :new:
[ ] Feature | 0557-discover-features-v2 | :new:
[ ] Feature | 0453-issue-credential-v2 | Update to V2 Protocol
[ ] Feature | 0454-present-proof-v2 | Update to V2 Protocol

INDYCRED: Indy Based Credentials

[ ] Feature | 0592-indy-attachments | :new: Evolved from AIP V1.0
[ ] Concept | 0441-present-proof-best-practices | :new:

LDCRED: JSON-LD Based Credentials

[ ] Feature | PR: 0593-json-ld-cred-attach | :new:

DIDCOMMV2PREP: DIDComm v2 Prep

[ ] Feature | 0587-encryption-envelope-v2 | :new:

Closed this, transitioned remaining work to: #647


Documentation and dependency fixes

This PR:

Clarifies that Python 3.7 or later should be used.
Fixes a typo in the doc.
Fixes the ChipWhisperer version to something known good and installs the archive rather than using git checkout in editable mode (may lead to issues with the main OpenTitan install where we can't upgrade the ChipWhisperer toolchain anymore due to the Python 3.6.5 requirement of OT).

Hey @andreaskurth, as I don't have a board at the moment, could you start from this PR and tell me if everything works?

@vrozic this might help you to get Husky working again.


Updates for frozen-string-literal compatibility.

(I've got patches for rspec-expectations, rspec-mocks and rspec-support which are related to this one, so I'm going to write out all the detail here, and then link to it from the others.)
I've put together these patches by running the test suites for each gem with the RUBYOPT=--enable-frozen-string-literal flag, so they're more thorough than my previous patches on this topic. However, as noted in those previous discussions, the test suite cannot yet be run reliably in that situation, so I've had some local changes to my Gemfile, and worked on patches for some dependencies. I've also had to have all rspec-x repos locally to debug some of the fixes in these patches.
Also: I've not got the cucumber test suites working in rspec-core, rspec-expectations, or rspec-mocks, so there could very well be further places in the Spec codebase that need changing. You're using a two-year-old version of Cucumber (1.3.x, when 2.x is released and 3.x is on the way), so I'm not sure how much effort should be put into updating that? Should we fork the 1.3.x release and make that frozen-string-literal-safe? Although, there are issues in Cucumber's dependencies as well…
Regarding how I've patched things: generally, I'm using dup instead of String.new - this is mostly because I've been working on similar patches for Rails, and the maintainers there prefer dup, hence that's my current habit. Also, String.new has an ASCII encoding, whereas String.new('some string') respects the argument's encoding (which defaults to UTF in recent Rubies), and that inconsistency is annoying.
I could (and might) keep going down the dependency rabbit hole and offer further patches, but I wanted to at least get these changes submitted so they're useful for the RSpec team sooner rather than later.
The dependency situation as it currently stands:
Patched (albeit with no new versions yet):

simplecov
simplecov-html

Pull Requests submitted:

coderay
parser (used by rubocop)

In-progress patches:

racc (used by parser)

No known patches:

cucumber
aruba (used by cucumber)
syntax (used by cucumber)
Possibly more, related to cucumber?

For anyone wanting to help: if you have commit bits on any of the above dependency repos, maybe get outstanding PRs merged, or help investigate failing test suites (racc). If anyone's on the Cucumber team: discussions need to be had around updating the version of Aruba it's dependant on, and maybe migrating from Syntax to Coderay (as that's what's recommended in the Syntax README).

Oh, one more thing: Travis should fail on this PR because I've made changes to get things working with the latest CodeRay release/commits, and their colours have changed after v1.0.9 (which is what you're locked to).

You're using a two-year-old version of Cucumber (1.3.x, when 2.x is released and 3.x is on the way), so I'm not sure how much effort should be put into updating that? Should we fork the 1.3.x release and make that frozen-string-literal-safe?

In general, there's no good reason for us to remain on an old version of cucumber.  We just haven't noticed the new releases or had anything forcing us to upgrade, so no one has put any effort into upgrading cucumber.
That said, RSpec still supports Ruby 1.8.7 and 1.9.2 (and, according to our understanding of SemVer, must continue to support it until RSpec 4), and it looks like cucumber 2.x won't install on those versions.  So I think our options are:

Stay on cucumber 1.x until RSpec 4.
Update our travis build so that cucumber 2.x is installed on Ruby 1.9.3+ while 1.x is installed on Ruby 1.8.7 and 1.9.2 -- assuming we're using a compatible subset of cucumber that works on both versions (or can easily get our use of cucumber down to a compatible subset).
Stop installing and running cucumber in the travis build for older rubies.  Personally, I never run cucumber locally, trusting our spec suite to be sufficient test coverage.  Cucumber provides a few extra sanity checks and helps us document how things work end-to-end.

I think any of those are viable options, and don't particularly feel strongly about it, as long as the maintenance burden is low (which might eliminate the 2nd option).
What do others think? /cc @rspec/rspec

So, I just spent some time getting edge cucumber and edge aruba working with the rspec-core test suite. There was one minor change related to frozen string literals, and I've pushed that commit.
I've also submitted related PRs:

https://github.com/cucumber/cucumber-ruby/pull/1136
https://github.com/dblock/syntax/pull/6
https://github.com/cucumber/aruba/pull/436

It's important to note, though: Cucumber uses an old version of Aruba, and so to get frozen-string-literal-friendly versions of both introduces a whole bunch of upgrading challenges (and if you want to support older Ruby versions while using multiple versions of Cucumber - the second option suggested - I foresee some serious headaches).
Hence, my vote - as much as it counts, given I'm not a maintainer here despite recent suggestions/warnings from some of you ;) - is for option 3 - though granted, that's still reliant on the Cucumber team updating their use of Aruba. An alternative option: run the cucumber tests only on older Ruby versions?

It's important to note, though: Cucumber uses an old version of Aruba,

I don't understand what you mean by this.  I can see that Cucumber uses Aruba ~> 0.6.1 as a development dependency, but it's not a runtime dependency, and their development versions shouldn't affect us.  Aruba itself, in its latest version, claims to work with cucumber >= 1.3.19.
In what way is cucumber's use of an old version of Aruba causing us problems?
On a side note: it would be nice to get this green so we can merge.  Can you undo the coderay-related changes or also include an upgrade to coderay in this PR so we can get the build green?

An alternative option: run the cucumber tests only on older Ruby versions?

I don't think we should seriously consider this.  We're going to drop older ruby versions eventually (RSpec 4 will definitely drop support for Ruby 1.8.7, and possibly Ruby 1.9.x) and I don't want us to be in the position where the only versions on which we run certain automated checks are older ruby versions.

Very valid point on when to run the cucumber tests - and I'd missed that Aruba is only a development dependency of Cucumber, so I can work on a separate PR that upgrades the RSpec Aruba usage if you'd like?
Also, just pushed a commit to use CodeRay 1.1.1, which should be green in CI with mutable string literals.

I can work on a separate PR that upgrades the RSpec Aruba usage if you'd like?

Yes, I'd like :).

Also, just pushed a commit to use CodeRay 1.1.1, which should be green in CI with mutable string literals.

Thanks.  The JRuby build failed due to some timeouts (it's an on-going intermittent problem, sadly) but I restarted those parts of the build so hopefully it'll go green this time.

according to our understanding of SemVer, must continue to support it until RSpec 4

I don't think this is correct, due to http://semver.org/#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api.

@mvz there's not right or wrong, just our interpretation :) We've consistently held that we were going to support 1.8.7 through to RSpec 4, since it would be a disruptive, breaking change to a large part of our user base. This is in our view aligned with the spirit of semver.

@xaviershay that makes sense. Thanks for explaining.


Feedback_M3

### Front-End:
- [ ] https://github.com/sopra-fs23-group-40/Client/issues/51
- [ ] https://github.com/sopra-fs23-group-40/Client/issues/52
- [ ] https://github.com/sopra-fs23-group-40/Client/issues/53
- [ ] https://github.com/sopra-fs23-group-40/Client/issues/54
- [ ] https://github.com/sopra-fs23-group-40/Client/issues/55
- [ ] https://github.com/sopra-fs23-group-40/Client/issues/56
- [ ] https://github.com/sopra-fs23-group-40/Client/issues/57
- [ ] https://github.com/sopra-fs23-group-40/Client/issues/59

### Acceptance Criteria:
- [x] Overview page should be refreshed to see newly created lobbies and changing player counts/lobby type
- [x] Player list in lobby is periodically updated.
- [x] Kick players from the lobby if it was deleted.
- [x] Lobbies can't be accessed with the correct URL (without actually joining)
- [x] Redirect every player to the correct game screen
- [x] Decrease maximum username length (?)

"Leaving by closing tab or pressing the back button, keeps lobby open and doesn't allow player to make a new one. => this should be fixed"
This was also a point in the Feedback we received, but we decided that we won't implement that, since it brings a lot of other issues and/or unwanted side effects.


Stage 0.3.0 release

r? @taiki-e @seanmonstar @Nemo157

Running a test now on async-std to check if anything is broken. Will update this comment to report back.

@yoshuawuyts Thanks for helping review! <3

https://github.com/async-rs/async-std/pull/460 passed on CI, which means that as far as async-std is concerned this patch should be good to go! @cramertj thanks so much for the work you've put in to get this release out!

There is a problem trying to update in tokio.
commit: https://github.com/tokio-rs/tokio/commit/fa71a584a601417331e3336fa22b9465e8d16c1d
error: implementation of `core::future::future::Future` is not general enough
   --> examples/connect.rs:31:5
    |
31  |       tokio::spawn(async move {
    |       ^^^^^^^^^^^^ implementation of `core::future::future::Future` is not general enough
    |
    = note: `futures_util::sink::send_all::SendAll<'0, tokio_util::codec::framed_write::FramedWrite<tokio::io::stdout::Stdout, codec::Bytes>, futures_util::stream::stream::map::Map<futures_util::stream::stream::filter_map::FilterMap<tokio_util::codec::framed_read::FramedRead<tokio::net::tcp::split::ReadHalf<'1>, codec::Bytes>, futures_util::future::ready::Ready<std::option::Option<std::vec::Vec<u8>>>, [closure@examples/connect.rs:99:25: 105:14]>, fn(std::vec::Vec<u8>) -> std::result::Result<std::vec::Vec<u8>, std::io::Error> {std::result::Result::<std::vec::Vec<u8>, std::io::Error>::Ok}>>` must implement `core::future::future::Future`, for any two lifetimes `'0` and `'1`...
    = note: ...but `core::future::future::Future` is actually implemented for the type `futures_util::sink::send_all::SendAll<'_, tokio_util::codec::framed_write::FramedWrite<tokio::io::stdout::Stdout, codec::Bytes>, futures_util::stream::stream::map::Map<futures_util::stream::stream::filter_map::FilterMap<tokio_util::codec::framed_read::FramedRead<tokio::net::tcp::split::ReadHalf<'_>, codec::Bytes>, futures_util::future::ready::Ready<std::option::Option<std::vec::Vec<u8>>>, [closure@examples/connect.rs:99:25: 105:14]>, fn(std::vec::Vec<u8>) -> std::result::Result<std::vec::Vec<u8>, std::io::Error> {std::result::Result::<std::vec::Vec<u8>, std::io::Error>::Ok}>>`

I will investigate later, but it may be https://github.com/rust-lang-nursery/futures-rs/pull/1946#discussion_r342560520.

@cramertj  I've confirmed that the above problem can be fixed once #1955 is merged.

+1 to removing the = requirements. It might pay to have another CI job/steps that verify the internal minimum versions are correct, but that seems like it might be complicated enough that it's not worth it (I believe that properly testing it would require a bunch of Cargo.toml rewriting to add and remove path dependencies as needed to test against the released versions).

I've landed #1955, rebased this change, and amended the versions to remove =. PTAL.

@taiki-e thank you for checking! <3
I say lets ship! Thank you for all your hard work @cramertj and others!

CI failure is unrelated, the job itself is wrong and needs fixing.

Out of curiosity, why is the executor feature on by default?
Seems like that would make sense as opt-in.

@theduke It is exposed as its own crate, futures-executor, which is reexported through the main facade crate. I have no strong opinion about whether or not it be enabled by default.

Yeah I saw that.
It only introduces one additional dependency ( num_cpus) but it seems to me like there is no big reason to tie it to the main facade at all and just provide it as the separate crate. It's certainly nice to have a simple stand alone executor available, but it would probably be a rather nieche thing to use, eg in small tests.

@theduke The primary value I see is convenience of having things like block_on available, which makes it possible to write small standalone tests and example code using only the futures crate.

It does seem useful for futures to be able to provide a block_on function out-of-the-box, even if a user probably shouldn't use it in most cases. 🤷♂

I can see that, and looking at how little code it is (< 1k lines) I'm not terribly concerned anymore.

As an arbitrary small datapoint, SNAFU compiles and tests pass against this branch.

@cramertj Thanks for coordinating this! And even more so for going through the backlog and closing all long-term outstanding issues!
@seanmonstar

It does seem useful for futures to be able to provide a block_on function out-of-the-box, even if a user probably shouldn't use it in most cases. 🤷♂

There was some discussion on including block_on as a minimal executor into std - since it's currently quite hard to use async without any other dependency (you can't even run things in play.rust-lang without boilerplate). I created https://github.com/rust-lang/rust/pull/65875 to implement this - but I don't whether and when we will see it getting there.


RFC: Should there be a human-readable-duration command?

With the resolution of issue #1029 we now have a $edit:command-duration variable. However, it is a simple float64 of the fractional number of seconds the command took to complete; e.g., 3.141592653589793. Which isn't friendly when displayed in a prompt. I have a utility function that converts that into a scaled human friendly string. There are two questions:

Is there enough consensus on how durations should be formatted for use in a prompt that adding a human-readable-duration command as a builtin is useful?

When issue #1030 is resolved the $edit:command-duration variable will probably be changed from a float64 to a Go time.Duration. That would have an implicit conversion to a string using its String() interface. People may feel that string representation is good enough for use in a prompt. In which case is an explicit command still necessary?

This is the function I currently use:
fn human-readable [duration]{
    if (> 0.001 $duration) {
        # Up to one millisecond display microseconds.
        printf '%.0f µs' (* $duration 1_000_000)
    } elif (> 1 $duration) {
        # Up to one second display milliseconds.
        printf '%.1f ms' (* $duration 1_000)
    } elif (> 60 $duration) {
        # Up to one minute display fractional seconds.
        printf '%.1f s' $duration
    } elif (> 3600 $duration) {
        # Up to one hour display fractional minutes.
        printf '%.1f m' (/ $duration 60)
    } else {
        # Otherwise display fractional hours.
        printf '%.1f h' (/ $duration 3600)
    }
}

This table shows how various durations would be represented by both solutions:

raw seconds
time.Duration.String()
human-readable

0.000243
243µs
243 µs

0.456789
456.789ms
456.8 ms

3.141592
3.141592s
3.1 s

789.123456
13m9.123456s
13.2 m

7890.123456
2h11m30.123456s
2.2 h

@krader1961 I think your function is a good start, but I'd argue that most people don't usually deal with fractional minutes nor hours. Instead of those, I think the fraction should be converted to seconds/minutes, respectively, e.g.:

raw seconds
human-readable

789.123456
13m9s

7890.123456
2h11m31s

Well, if I need to choose between 13m9.123456s and 13.2 m, I'd say the former is actually closer to the human-readable form.
@zzamboni's proposal can already be expressed in Go by using duration.Truncate to first truncate the duration to seconds:
package main

import (
	"fmt"
	"time"
)

func main() {
	t1 := time.Millisecond * 789123
	t2 := time.Millisecond * 7890123
	fmt.Println(t1.Truncate(time.Second))
	fmt.Println(t2.Truncate(time.Second))
}

~/tmp> go run t.go
13m9s
2h11m30s

So I don't think the command is necessary if we have a binding for the Duration.Truncate method.

Thanks for the feedback which illustrates why this is likely to be a highly subjective matter regarding the optimal presentation of this data. I deliberately use fractional minutes or hours for a couple of reasons. First, and most importantly, because when I'm looking at this info in the prompt I'm not really interested in the exact duration. I'm interested in the magnitude and something like 2.1 m or 1.8 h is adequate. I don't really care if it was 2m6.123s or 1h48m10.123s. First, for consistency with the fractional seconds and milliseconds format. Third, because having a single unit at the end of the string makes the string as short as possible and that unit conveys the most important fact.

So I don't think the command is necessary if we have a binding for the Duration.Truncate method.

I don't grok how that solves the problem since even if we have such a binding the user still has to explicitly use it before coercing the duration to a string. And that requires logic equivalent to the example function I provided since I don't want to truncate to the nearest second if the duration is sub second. So it seems like we would still want a convenience command rather than forcing every user to reinvent this wheel.
What we probably need is a couple of predefined formats that can be selected by an option; e.g., human-readable &minimal or human-readable &detailed for my preferred format or the time.Duration format respectively.

For anyone who stumbles upon this issue in the future I've published my cmd-duration:human-readable function. I still feel something like it should be included in the base Elvish program since it is a) extremely small (relative to the size of the elvish binary), and b) likely to be used by anyone wanting to display the previous command duration in their prompt in a human friendly form.

Closing since the presentation of command duration in the prompt is highly personal and it is unlikely there will ever be enough consensus to justify including an Elvish function with the shell to render that information. Even with options like &minimal and &detailed per my prior comment.


Use extension methods to avoid invalid override errors

In TypeScript, the any type is a valid override for every type. This occurs in a few places in the DOM. In the example below, BeforeUnloadEvent.returnValue cannot be declared within BeforeUnloadEvent, otherwise it will be an invalid override. If we expose it through an extension method instead, it circumvents the error.
@JS()
library X;

import "package:js/js.dart";

@JS()
abstract class Event {
  external bool get returnValue;
  external set returnValue(bool v);
}

@JS()
abstract class BeforeUnloadEvent implements Event {}

@JS()
abstract class _BeforeUnloadEvent {
  external dynamic get returnValue;
  external set returnValue(dynamic v);
}

extension BeforeUnloadEventExtensions on BeforeUnloadEvent {
  dynamic get returnValue {
    final Object t = this;
    final _BeforeUnloadEvent tt = t;
    return tt.returnValue();
  }
}

Actually this is probably unnecessary, changing dynamic to Object makes it valid.


Setup publish through github action

As a maintainer, I need to set up a GitHub action to automatically publish new releases
Acceptance criteria
1 - Publish a version through GitHub actions

duplicate #24


Meaning of parameters

Hello, thank you for publishing the code. When I was reproducing your code, I didn't quite understand the meaning of a few parameters. Can you help me solve it? Specific parameters include normal_ src, use_ ppf.

您能提供一下训练好的权重文件吗？


Enable health check only management port

Issue #2579 added the ability to bind health checks to a specific port so they're only visible to internal components. Good stuff.
However, it turns out you can't dedicate the port to management/health check purposes. That is, if there's a "main port" for handling other requests and a "management port" for handling health requests... you can still make all requests over that management port that you would over the main port. Setting a port on health checks means the health checks only listen on that port... but the rest of the app (e.g., the MVC middleware) is still listening on all ports.
It would be nice if you could specify the health check port and have that be an exclusive handler on that port - only health checks would respond on that port.
Granted, this is easy enough middleware to write oneself, which is what I'll end up doing to work around it, but it'd be helpful if this was supported out of the box.
My general use case here is Kubernetes and Istio using mTLS authentication. I want Kubernetes to be able to do readiness/liveness checks on a specific port that bypasses the mTLS because you can't make Kubernetes use the specified certs for those checks but I don't want to leave the "back door" open for all the other services in the cluster to bypass the mTLS auth by making calls on the port I leave open for the health checks.

Hi @tillig - we agree that this is a good idea to have a recipe for. We will need to do some more server and configuration work to make this easy.
I think you could do this today by placing the health checks middleware before the http redirect. If you register the health checks middleware with a port and an empty path it will respond to all requests for that port.
https://github.com/aspnet/AspNetCore/blob/master/src/Middleware/HealthChecks/src/Builder/HealthCheckApplicationBuilderExtensions.cs

Circling back on this, a concrete example of something that works:
app.UseHealthChecks("/healthz", 49331)
   .MapWhen(
     ctx => ctx.Connection.LocalPort == 49331,
     b => b.Run(ctx => { ctx.Response.StatusCode = 400; return Task.CompletedTask; }))

In this case, if the management port is set up and it's not a health request, everything else will be 400. However, on the main port for the app, the rest of the app will kick in correctly.
This would also allow you to add other checks, like a separate readiness check or something, on the same port as long as the middleware was registered before the MapWhen.


Latest version of rich doesn't work

Describe the bug
Since rich dependency in requirements.txt is not pinned, it tries to pull latest https://github.com/Textualize/rich/releases/tag/v13.9.0 version, which has a bug (see trace below):
Traceback (most recent call last):
  File "/Users/jcastillocano/git/bandit/.venv/bin/bandit", line 5, in <module>
    from bandit.cli.main import main
  File "/Users/jcastillocano/git/bandit/.venv/lib/python3.9/site-packages/bandit/__init__.py", line 7, in <module>
    from bandit.core import config  # noqa
  File "/Users/jcastillocano/git/bandit/.venv/lib/python3.9/site-packages/bandit/core/__init__.py", line 7, in <module>
    from bandit.core import manager  # noqa
  File "/Users/jcastillocano/git/bandit/.venv/lib/python3.9/site-packages/bandit/core/manager.py", line 16, in <module>
    from rich import progress
  File "/Users/jcastillocano/git/bandit/.venv/lib/python3.9/site-packages/rich/progress.py", line 45, in <module>
    from typing_extensions import Self  # pragma: no cover
ModuleNotFoundError: No module named 'typing_extensions'

Reproduction steps
1. `virtualenv .venv -p python3.9`
2. `. .venv/bin/activate`
3. `pip install bandit==1.9.0`
4. `.venv/bin/bandit --help`

Expected behavior
.venv/bin/bandit --help                                                                                (⎈|aws-otk-sandbox-dev-general-use1-002:default)
usage: bandit [-h] [-r] [-a {file,vuln}] [-n CONTEXT_LINES] [-c CONFIG_FILE] [-p PROFILE] [-t TESTS] [-s SKIPS] [-l | --severity-level {all,low,medium,high}] [-i | --confidence-level {all,low,medium,high}] [-f {csv,custom,html,json,screen,txt,xml,yaml}]
              [--msg-template MSG_TEMPLATE] [-o [OUTPUT_FILE]] [-v] [-d] [-q] [--ignore-nosec] [-x EXCLUDED_PATHS] [-b BASELINE] [--ini INI_PATH] [--exit-zero] [--version]
              [targets ...]

Bandit - a Python source code security analyzer
...

Bandit version
1.7.9 (Default)
Python version
3.9
Additional context
It get fixed when installing previous rich version with pip install rich==13.8.1

Related issue https://github.com/PyCQA/bandit/issues/1180

Created https://github.com/PyCQA/bandit/pull/1181 for fixing it.

This issue has been fixed in the latest version of rich. See https://github.com/Textualize/rich/releases/tag/v13.9.1


No syntax highlighting in log buffer when opening file using telescope.

When I open a file using either nvim path/to/file or using my file tree (tested with netrw and oil.nvim), the log buffer shows up with correct syntax highlighting. After this I can open other files however I wish and the log buffer shows up as required with syntax highlighting.

The issue arises when I open neovim using either nvim or nvim path/to/directory and then use telescope to open a file. In this case the log buffer shows up as shown below, ie without syntax highlighting.

Using :LspInfo I was able to find out that the lsp client I use for clojure (clojure_lsp) doesn't attach to the log buffer in this case.
Sorry for wasting your time if this issue isn't related to conjure. My reasoning for posting this here instead of nvim-lsp or something is that I'm facing facing this issue only in the conjure-log buffer. I tried opening *.cljc files and the lsp was attaching to the buffer as expected along with proper syntax highlighting so I think the issue must be with conjure. Not really all that proficient with the technicalities of neovim so I'm not sure how to proceed with debugging this so any pointers would also be appreciated.

Ah that's annoying, sorry about that. Can't say I've seen the same issue and I think it comes down to lazy package loading configuration. I don't use it for the most part because it causes so many issues and doesn't save me much time at all.
If you use :e inside the log buffer does the syntax highlighting then work fine?

:e doesn't seem to do anything other than clear the log buffer. New output is still lacking syntax highlighting.
I don't know if this information is helpful but I also tried lazy = false for conjure to see if that'd help but I didn't see any difference.
Is there anything I can try to figure out where the fault is? Could this issue be due to some differences in how telescope opens buffers? Which autocommand is being used to apply syntax highlighting to the log buffer? I could test a trivial config without conjure and see if there's some difference in how that autocommand is triggered when using telescope. Don't know if I'd be able to recreate it tbh.

Still facing this issue. Thought I'd see what events conjure had autocommands for and keep a log of when those events were being triggered using an autocommand of my own for logging. So far the only thing I've been able to observe is that whenever the syntax highlighting works, the BufEnter event has been triggered on the conjure-log file at some point and whenever it isn't triggered the syntax highlighting doesn't show up.
I have also noticed that this doesn't just happen with telescope. While using the mini.files plugin when I open the file using go_in, the BufEnter event is triggered for conjure-log and syntax highlighting works but when opening the file using go_in_plus, the event isn't triggered and syntax highlighting doesn't work. I think I'll try to find out what the difference is in how both these methods open the file and that might help me figure out why this issue is happening.
If I could get some idea about how the conjure-log file is opened and when BufEnter is triggered on it that'd be helpful.

Sorry for the delay, I was on holiday. Interesting, it does sort of feel like it's another plugin interfering here. As far as I can remember and see in the source, Conjure doesn't care about BufEnter (other than one plugin) and we set up FileType autocmds for the filetypes we support and care about at the time (which can be adjusted through configuration).
Conjure doesn't set the language or syntax of the buffer, we let Neovim do that by relying on the existing configuration based on the file extension. Which is why each Conjure log buffer is called conjure-log-$PID.$LANGUAGE_SPECIFIC_EXTENSION, we let your personal editor config load that buffer as it would any other .clj / .fnl / .lisp etc.
So if something's stopping that buffer from opening normally I don't think I can get around it from my side.
https://github.com/Olical/conjure/blob/master/fnl/conjure/log.fnl
That file, conjure.log, is the place where we actually create the log window and buffer where required. So if there's some funny business it might be in there but I still don't see anything that would behave like this at a glance.

Hope you had a great holiday!
Glad to report that I've finally figured out what was wrong. Thanks to your suggestion about interfering plugins, I tried disabling plugins one-by-one till the bug was fixed. Turns out it was nvim-lint that was causing the problem for me. I had configured it to lint with an autocommand that was running on BufEnter. Not sure exactly why but debouncing the try_lint call seems to fix this issue.
In case anyone else also comes across this specific issue, here is my configuration for nvim-lint using LazyVim as a reference.
local function debounce(ms, fn)
  local timer = vim.loop.new_timer()
  return function(...)
    local argv = { ... }
    timer:start(ms, 0, function()
      timer:stop()
      vim.schedule_wrap(fn)(unpack(argv))
    end)
  end
end

return {
  'mfussenegger/nvim-lint',
  event = {
    'BufReadPre',
    'BufNewFile',
  },
  dependencies = {
    'williamboman/mason.nvim',
  },
  config = function()
    -- required so nvim env includes linters installed by mason
    local mason = require 'mason'
    mason.setup()

    local lint = require 'lint'
    local linters = require 'config.linters'
    lint.linters_by_ft = linters

    local lint_augroup = vim.api.nvim_create_augroup('lint', {
      clear = true,
    })

    vim.api.nvim_create_autocmd({
      'BufWritePost',
      'BufReadPost',
      'InsertLeave',
    }, {
      group = lint_augroup,
      callback = debounce(10, function()
        lint.try_lint()
      end),
    })
  end,
}

Also sorry for wasting your time with an issue in my configuration and thanks for helping out anyway. I'll close this issue now.

 And not a problem, it was worth raising it so I
could take a look and give context.
On Tue, 12 Mar 2024, 07:05 Adam Jijo, @.***> wrote:

Hope you had a great holiday!
Glad to report that I've finally figured out what was wrong. Thanks to
your suggestion about interfering plugins, I tried disabling plugins
one-by-one till the bug was fixed. Turns out it was nvim-lint that was
causing the problem for me. I had configured it to lint with an autocommand
that was running on BufEnter. Not sure exactly why but debouncing the
try_lint call seems to fix this issue.
In case anyone else also comes across this specific issue, here is my
configuration for nvim-lint using LazyVim
https://github.com/LazyVim/LazyVim/blob/cca2e091490fc87eafd7ee27a965e4cbcacdc012/lua/lazyvim/plugins/linting.lua#L3
as a reference.
local function debounce(ms, fn)
local timer = vim.loop.new_timer()
return function(...)
local argv = { ... }
timer:start(ms, 0, function()
timer:stop()
vim.schedule_wrap(fn)(unpack(argv))
end)
endend
return {
'mfussenegger/nvim-lint',
event = {
'BufReadPre',
'BufNewFile',
},
dependencies = {
'williamboman/mason.nvim',
},
config = function()
-- required so nvim env includes linters installed by mason
local mason = require 'mason'
mason.setup()
local lint = require 'lint'
local linters = require 'config.linters'
lint.linters_by_ft = linters

local lint_augroup = vim.api.nvim_create_augroup('lint', {
  clear = true,
})

vim.api.nvim_create_autocmd({
  'BufWritePost',
  'BufReadPost',
  'InsertLeave',
}, {
  group = lint_augroup,
  callback = debounce(10, function()
    lint.try_lint()
  end),
})

end,
}
Also sorry for wasting your time with an issue in my configuration and
thanks for helping out anyway. I'll close this issue now.
—
Reply to this email directly, view it on GitHub
https://github.com/Olical/conjure/issues/562#issuecomment-1990915081,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACM6XJUKIIT26MZIHKLOT3YX2SNHAVCNFSM6AAAAABEBGJ546VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJQHEYTKMBYGE
.
You are receiving this because you commented.Message ID:
@.***>

This happened to me, and still persisted after disabling all my plugins.  Updating to master fixed it.


Support using config-drive instead of guestfish on PowerPC architectures

Following up on #678 which added support for ignition config to be passed to
s390x. The same is needed for PowerPC arches too as fw_cfg is not supported on
PowerPC.
Please make sure you read the contributor documentation before opening a Pull Request.

thx!

thanks @MalloZup ! is it possible for a merge? we are blocked on testing an openshift IPI install on PPC due to this.

done


On Candle Vote, add 15 seconds to timer

Don't let the extra time affect overlay

This is unrelated to the task, but need to attribute someone.
@allcontributors please add @andresamaris for code


Proposal feat(controller): add fine-grain scheduling policy

The idea behind this is the creation of a default policy to schedule apps inside the cluster using only the patterns shared by different implementations in fleet (the only option for now), mesos (and kubernetes?).
It must be possible to define a default configuration for all the apps but if any app can have a custom policy that will override the default.
The idea of this proposal is to see if this makes sense to other users :)  and what other options to schedule can/should be supported.
Policies:

one instance per node
metadata

proposed etcd content:
/deis/controller/schedulerModule                  -> [fleet | mesos]
/deis/controller/schedulingPolicy/default         -> [onePerNode | metadata]
/deis/controller/schedulingPolicy/apps/<app name> -> [onePerNode | metadata]

to define the metadata in any app we can use a env var like DEIS_SCHEDULER_METADATA="rack=rack-1"
the definition in deis must be agnostic to the scheduler and only the controller can be aware of the semantic of every scheduler option
Only one instance per node:
mesos:
{
 "instances": XX,
 "constraints": [
   ["hostname", "UNIQUE"],
   ["<app name_type.vXXX>", "GROUP_BY"]
 ]
}

fleet:
{
  "section": "X-Fleet",
  "name": "Conflicts",
  "value": "<app name_type.vXXX>"
}

Schedule using metadata:
mesos:
{
  "instances": XX,
  "constraints": [
    ["rack", "CLUSTER", "rack-1"]
  ]
}

fleet:
{
  "section": "X-Fleet",
  "name": "MachineMetadata",
  "value": "rack=rack-1"
}

https://github.com/coreos/fleet/blob/master/Documentation/unit-files-and-scheduling.md
https://github.com/mesosphere/marathon/blob/master/docs/docs/constraints.md#unique-operator
https://github.com/mesosphere/marathon/blob/master/docs/docs/constraints.md#group_by-operator
https://github.com/mesosphere/marathon/blob/master/docs/docs/constraints.md#cluster-operator

+1

@aledbf We see the motivation behind this, but I think this is difficult for a few reasons:

Deis arguably shouldn't deal with this level of scheduling, and instead should just deal with a scheduler abstraction much like the one we have now
Determining the common set of capabilities/features across different schedules is difficult and nearly impossible when the schedulers are changing as rapidly as they are currently
The motivation behind your policy concerns seem to stem from shortcomings with fleet, and will be addressed once we add support for more advanced schedulers like Kubernetes, Mesos, Swarm, etc.

@aledbf I'd like to take a closer look at this once #3134 lands in an optional "Swarm Preview".

Until then, I continue to run this script:
https://gist.github.com/ianblenke/36f1b82efd7eecef0732#file-add-xfleet-conflicts-sh
Purely out of operational necessity.

@ianblenke for the same reason I did this:
https://github.com/soficom/deis/blob/custom_1.3.1/controller/scheduler/fleet.py#L160

Not knowing django settings whatsoever, how someone set X_FLEET_CONFLICTS?
Would love to see a PR for that, or something very similar to that.

how someone set X_FLEET_CONFLICTS?

@ianblenke sorry. From here https://github.com/soficom/deis/blob/custom_1.3.1/controller/templates/confd_settings.py#L56

Now that we have previews for swarm, marathon, and k8s, I'd love to see this issue revisited.

Closing as we aren't adding any more features to v1 as we focus on Deis v2. Re-iterating @carmstrong's point, Deis shouldn't deal with this level of scheduling, and instead should just deal with a scheduler abstraction much like the one we have now.


How to start (readme) is incomplete

Brief bug description
I tried to run the site for the first time according to the description in the readme,

Copied the environment variables
Started the site with npm run dev

And it ended with an error that the preview API key is missing, so I had to provide it and run it again
It would be nice to make it more clear which environment variables are mandatory
BTW: Not sure how the preview is enabled, and if running with just start would use live or not. Also not clear from the readme. If not, it may not make sense to even provide project ID by default

Thank you for the feedback. We will clarify the points in the readme.


I'm attempting to add this library to my project and try to render literally any effect I can but all of them render a black screen. If I just render the RenderPass then it displays just fine, but as soon as I pass any sort of control over to any EffectPass, the screen renders black and the console outputs a whole bunch of OpenGL warnings/errors;
localhost/:1 [.WebGL-0000023AB34E7FF0]RENDER WARNING: texture bound to texture unit 0 is not renderable. It maybe non-power-of-2 and have incompatible texture filtering.
localhost/:1 [.WebGL-0000023AB34E7FF0]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glClear: framebuffer incomplete
localhost/:1 [.WebGL-0000023AB34E7FF0]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawArrays: framebuffer incomplete

I can confirm that my THREE.js version is r103 and postprocessing is at v6.1.1.
My code is as follows:
const composer = new pp.EffectComposer(tRenderer);

const renderPass = new pp.RenderPass(common.THREEstage, tCamera);
const outlineEffect = new pp.OutlineEffect(common.THREEstage, tCamera, {
	edgeStrength: 10,
	pulseSpeed: 0,
	visibleEdgeColor: 0xFFFFFF,
	hiddenEdgeColor: 0x0,
	blur: false,
	xRay: true
});

const outlinePass = new pp.EffectPass(tCamera, outlineEffect);
composer.addPass(renderPass);
composer.addPass(outlinePass);

renderPass.renderToScreen = false;
outlinePass.renderToScreen = true;

and later down the file I render like so:
composer.render(clock.getDelta());

I've attempted to change the order of the code a billion times to match with examples and stuff but all effects still render a black screen.

Hi,
your code looks fine to me. Are you loading any models? If so, does the error also occur without them?
Please check if the following example works for you:
https://jsfiddle.net/u5d7keby/

Hi, thanks for getting back so quick!
The fiddle works fine!
I am loading models yeah. I also tried loading an empty scene using const test = new THREE.Scene(); and adding nothing, but the errors persist. Adding just a simple box doesn't work, either.

Alright, the models should be fine then and there doesn't seem to be a hardware problem.
Try to modify the fiddle little by little to match your setup until the fiddle breaks.

Closing due to inactivity.

 I've tried different orders of operations with pass.enabled and pass.renderToScreen but can't seem to resolve the issue.

I think these diffs might account for the breakage.
https://github.com/mrdoob/three.js/commit/85f911fb5c3f2649aa6113a39bc0f5c3c57adef0

@RMDern I only see one RenderPass in the code you've posted. If you want to blur your scene every other frame, you can do it like this:
blurPass.enabled = !blurPass.enabled;
renderPass.renderToScreen = !blurPass.enabled;

Here's an example: https://jsfiddle.net/jkc5hxz6/
@EricEisaman I don't know what breakage you're talking about. To my knowledge, there's no bug in the postprocessing library that would cause black screens. If you're facing such a problem, please create a minimal example that demonstrates the breakage, preferably in a new issue.

@vanruesc Correct, there is only one RenderPass, the other is the BlurPass. From my understanding of the docs, they both are subclasses of Pass and should function mostly the same. RenderPass being a vanilla render, BlurPass having additional parameters to apply a blur. Putting them both in the same EffectComposer and only having one enabled at a time should give the desired effect, no? They each work that way in isolation, the switching causes the black screen.

I see now where the confusion is coming from. Let me try to clarify:
The Pass class is just an abstract base class that implements no particular render logic. The BlurPass is a specialized utility pass that blurs the input buffer;  it operates on whatever input data comes its way. In the example that I posted earlier, it blurs the scene colors that are rendered by the preceding RenderPass.
The RenderPass is the only pass that renders typical scenes. If you set its renderToScreen flag to true, then that marks the end of your effect chain, at least in terms of visual output on screen. In other words, the pass won't render anything to the internal buffer and subsequent passes will receive no input colors (the buffers will be empty or completely black).
It may seem weird that it's possible to cut your effect chain short like that, but there are use cases where you may have passes at the end of the chain that don't require input colors.
If you want to render two different scenes, you'll need to create two RenderPass instances.
I hope this clears things up a bit. If you have more questions, feel free to ask.

@vanruesc Thank you for the clarification! I acutally just resolved my issue based on the code you provided above:
blurPass.enabled = !blurPass.enabled;
renderPass.renderToScreen = !blurPass.enabled;

Changing my toggleRenderPass() function to include only that code produced the effect I was looking for. I was unaware that the render chain would be cut short like that.


Remove webrtc

WebRTC is causing more issues than it is worth. Given that the images being sent over the network are relatively small, using a socket seems to work reasonably well and is much more robust.
This will also fix the longstanding issue of the socket connecting but the webRTC not connecting.
Fixes #765
Shoutout to @brentyi for the idea.

tried that my web viewer still can't show the rendering.
os: fedora
local.

Tried that my web viewer still can't show the rendering... os: fedora connection:local.

Are you using https://viewer.nerf.studio/versions/branch/tancik-remove_webrtc/ and/or launching the viewer client manually?

Works great on my end too, this is great

The renderer completely stopped working today (I tried for 1 hour) with an ancient version of nerfstudio: https://viewer.nerf.studio/versions/23-01-25-0/?websocket_url=ws://localhost:7007. Was there changes to the viewer.nerf.studio backend hosted on the dev team's server?

@KokeCacao Try using the latest pip package. We were previously relying on a third party turn server (openrelay), there servers seem to have gone down.

@KokeCacao Try using the latest pip package. We were previously relying on a third party turn server (openrelay), there servers seem to have gone down.

Thank you for your help! I am using an old version because I made significant changes to the source code while implementing my own model. I fear that pulling from the latest version may result in many merge conflicts. I have tried --viewer.skip-openrelay=True but it doesn't seem to work. Is there a offline method using web interface (before or after I merge)?

@KokeCacao You will need to host your own viewer and comment out the following lines, https://github.com/nerfstudio-project/nerfstudio/blob/e2dadc20ab5be3ba41ed1fe104c37272f3631018/nerfstudio/viewer/app/src/modules/WebRtcWindow/WebRtcWindow.jsx#L22-L39

You can run a local webserver
(In another window/process, cd nerfstudio/viewer/app && yarn install && yarn start)
and then go to the local viewer instead of viewer.nerf.studio, at
http://localhost:4000/?websocket_url=ws://localhost:7007


samples/contiki: Simplify servo demo

Reusing these anonymous converters (using a explanatory name)
reduces the amount of nodes and connections and make it easier to read.
@zehortigoza please take a look on it. I can't test it here,
hopefully it works. But even if don't, I believe it's a good
start to simplify this sample.

Nice, less 100 on the generated file.

Thanks @bdilly I had improved the behavior of the demo and used your ideas on the new version #575


Implement support for returning started transaction without using transaction() methods callback function

Original inspiration behind this change was discussion on implementing DDD pattern in Javascript that we had at our company. Currently there is no convenient way for implementation-level (repositories) entities to generate a transaction instance that could then be passed from domain-level (use cases) entities across all the business logic execution steps without knowing what exact db operations are going to be executed.
fixes #3095

I'm not sure if it is confusing that meaning of a Promise that .transaction() returns is different based on provided params. It might be, and it may be a better solution to have separate method for this case, but I don't know what a good name that would be less confusing in that case would be.

@kibertoad this looks useful. It will surely come in handy on our project at @LeapLabs. Thanks!

@capaj You are welcome :)

Also might be a good idea to add to documentation something about availability of trx.initPromise for hooking functionality to transaction commit / rollback.

@elhigu Great point! There was, indeed, a gap in how errors were handled during transaction acquisition.

Also might be a good idea to add to documentation something about availability of trx.initPromise for hooking functionality to transaction commit / rollback.
Not really. initPromise is only used, as name implies, to track process of transaction itself getting prepared for usage. After this promise is resolved, it returns the transaction itself, and that's it. I don't think we should consider it a part of public api, as users are only supposed to consume it indirectly via knex.transaction()

Also might be a good idea to add to documentation something about availability of trx.initPromise for hooking functionality to transaction commit / rollback.
Not really. initPromise is only used, as name implies, to track process of transaction itself getting prepared for usage. After this promise is resolved, it returns the transaction itself, and that's it. I don't think we should consider it a part of public api, as users are only supposed to consume it indirectly via knex.transaction()

Right. I though that promise was the promise that get resolved / rejected when trx.commit() / trx.rollback(err) was called.

@elhigu Hmmm, I can't find your other comment about your expectation for this not to start the actual transaction until someone actually uses it. I think that is doable, although would require slightly more intrusive changes. Do you think we should go for it within the scope of this PR?

@elhigu Hmmm, I can't find your other comment about your expectation for this not to start the actual transaction until someone actually uses it. I think that is doable, although would require slightly more intrusive changes. Do you think we should go for it within the scope of this PR?

I don't think that is in the scope of this PR. I'll just rename the issue to be less confusing :)

@elhigu It was a fairly trivial addition, though, so I ended up including it as a feature on top :)

@elhigu Phew, build finally passes again. Could you please rereview?

@capaj It was released as<EMAIL_ADDRESS>would be awesome if you could give it a try! Most likely final 0.17.0 stable will be published in a couple of days.


Update Filesystem.php

It's need to release directory lock. to avoid error: rmdir($directory); Text file busy. #41353

I am closing this pull request because it lacks sufficient explanation, tests, or both. It is difficult for us to merge pull requests without these things because the change may introduce breaking changes to the framework.
Feel free to re-submit your change with a thorough explanation of the feature and tests - integration tests are preferred over unit tests. Please include it's benefit to end users; the reasons it does not break any existing features; how it makes building web applications easier, etc.
Thanks!


Make mech use its battery in container

About the PR
Title.
Why / Balance
See #12971.
Technical details

Media

Requirements

[x] I have read and am following the Pull Request and Changelog Guidelines.
[x] I have added media to this PR or it does not require an ingame showcase.

Breaking changes

Changelog

@beck-thompson, it's not a bugfix, but a cleanup since MechComponent was doing its own battery thing instead of using an existing system.


New field "type" in json generated by LwM2mIdentitySerDes and LwM2mPeerSerDes.

Implementation of field "type" in json generated by LwM2mIdentitySerDes and LwM2mPeerSerDes.

I Integrated this in identity_refactoring branch. (squashed in one commit 26a050a8c362e1ebb08106244cff3f2085c1758d)
@JaroslawLegierski there is a way to launch build to test Redis stores. Personally I use : mvn clean install javadoc:javadoc -Predis
The redis profile can only be launched locally with a redis server running on localhost by default (it could be changed using REDIS_URI environnement variable). This is not done by jenkins OR github action because we have no redis instance available.
When I did it,  RedisRegistrationTest failed :x:.
With this fix that sounds OK :heavy_check_mark:.  (This fix in integrated in squashed commit)
I guess we can close this issue now.


chat handler: openai doesn't exist

Test cli:
helix-gpt --handler openai --openaiKey 'sk-ogR5nc.......'
Hanging, no errors, no infos
Helix languages.toml:
[language-server.gpt]
command = "helix-gpt"
config = {}
args = ["--handler", "openai", "--openaiKey", "sk-ogR5nc......."

[[language]]
name = "bash"
auto-format = true
language-servers = [ "gpt" ]

[[language]]
name = "php"
language-servers = ["phpactor","gpt"]
auto-format = true

In Helix, % , Space + a, generate documentation
It's not working, no logs.
tail -f /root/.cache/helix/helix.log
Blank
tail -f /app/helix-gpt.log # Or wherever you set --logFile to
No found
locate helix-gpt.log
Not found

The code actions are only implemented for copilot at the moment, I'll add openai support soon. Could you check ~/.cache/helix for the log file instead?

tail -f ~/.cache/helix/helix.log
Language Server: protocol error: InvalidParams: Invalid params: missing field `uri`.
helix_term::application [ERROR] received malformed notification from Language Server: protocol error: InvalidParams: Invalid params: missing field `uri`.```

Willing to help debugging. Thank you.

tail -f ~/.cache/helix/helix.log
Language Server: protocol error: InvalidParams: Invalid params: missing field `uri`.
helix_term::application [ERROR] received malformed notification from Language Server: protocol error: InvalidParams: Invalid params: missing field `uri`.

Willing to help debugging. Thank you.

Haven't seen that error before. Best guess is that it's some helix weirdness with a language I haven't tested. I'll test it with your config when I'm home.

Also if you could run helix in verbose mode hx -v test.js that might give us a better idea

hx -v test.php
tail -f ~/.cache/helix/helix.log
2024-01-26T19:30:26.369 helix_lsp::transport [ERROR] Tried sending response into a closed channel (id=Num(6)), original request likely timed out
2024-01-26T19:30:26.369 helix_lsp::transport [INFO] gpt <- {"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"diagnostics":[]}}
2024-01-26T19:30:26.370 helix_term::application [ERROR] received malformed notification from Language Server: protocol error: InvalidParams: Invalid params: missing field `uri`.
2024-01-26T19:30:28.517 helix_lsp::transport [INFO] gpt -> {"jsonrpc":"2.0","method":"workspace/executeCommand","params":{"arguments":[{"query":"Refactor this code based on the comment.","range":{"end":{"character":0,"line":3},"start":{"character":6,"line":2}}}],"command":"refactorFromComment"},"id":8}
2024-01-26T19:30:28.519 helix_lsp::transport [INFO] gpt <- {"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"diagnostics":[{"message":"Executing refactorFromComment...","range":{"end":{"character":0,"line":3},"start":{"character":6,"line":2}},"severity":3,"source":"helix-gpt"}]}}
2024-01-26T19:30:28.519 helix_term::application [ERROR] received malformed notification from Language Server: protocol error: InvalidParams: Invalid params: missing field `uri`.
2024-01-26T19:30:28.520 helix_lsp::transport [INFO] gpt <- {"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"diagnostics":[{"message":"chat handler: openai does not exist","severity":1,"range":{"end":{"character":0,"line":3},"start":{"character":6,"line":2}},"source":"helix-gpt"}]}}
2024-01-26T19:30:28.520 helix_term::application [ERROR] received malformed notification from Language Server: protocol error: InvalidParams: Invalid params: missing field `uri`.
2024-01-26T19:30:31.714 helix_lsp::transport [INFO] gpt <- {"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"diagnostics":[]}}
2024-01-26T19:30:31.715 helix_term::application [ERROR] received malformed notification from Language Server: protocol error: InvalidParams: Invalid params: missing field `uri`.
2024-01-26T19:30:38.526 helix_lsp::transport [INFO] gpt <- {"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"diagnostics":[]}}
2024-01-26T19:30:38.526 helix_lsp::transport [INFO] gpt <- {"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"diagnostics":[]}}
2024-01-26T19:30:38.526 helix_term::application [ERROR] received malformed notification from Language Server: protocol error: InvalidParams: Invalid params: missing field `uri`.
2024-01-26T19:30:38.527 helix_term::application [ERROR] received malformed notification from Language Server: protocol error: InvalidParams: Invalid params: missing field `uri`.
2024-01-26T19:30:48.518 helix_term::commands::lsp [ERROR] execute LSP command: request 8 timed out

23.10, compiled from source.
Other LSP, such as phpactor, are working alright are fairly usable.
I tried to deactivate them all and run only helix-gpt, same errors as above^.
Same with other languages, such as bash.

23.10, compiled from source.
Other LSP, such as phpactor, are working alright are fairly usable.
I tried to deactivate them all and run only helix-gpt, same errors as above^.
Same with other languages, such as bash.

Ok leave it with me I'll check when I'm home. The error is pretty clear at least, the filepath isn't being passed.

23.10, compiled from source.
Other LSP, such as phpactor, are working alright are fairly usable.
I tried to deactivate them all and run only helix-gpt, same errors as above^.
Same with other languages, such as bash.

Could you try with release 0.11

2024-01-28T08:55:15.555 helix_vcs [INFO] file is untracked
2024-01-28T08:55:15.555 helix_vcs [INFO] failed to open diff base for /media/<--REMOVED-->/test.php
2024-01-28T08:55:15.556 helix_lsp::client [INFO] Using custom LSP config: {}
2024-01-28T08:55:15.556 helix_lsp::transport [INFO] gpt -> {"jsonrpc":"2.0","method":"initialize","params":{"capabilities":{"general":{"positionEncodings":["utf-8","utf-32","utf-16"]},"textDocument":{"codeAction":{"codeActioÆnLiteralSupport":{"codeActionKind":{"valueSet":["","quickfix","refactor","refactor.extract","refactor.inline","refactor.rewrite","source","source.organizeImports"]}},"dataSupport":true,"disabledSupport":true,"isPreferredSupport":true,"resolveSupport":{"properties":["edit","command"]}},"completion":{"completionItem":{"deprecatedSupport":true,"insertReplaceSupport":true,"resolveSupport":{"properties":["documentation","detail","additionalTextEdits"]},"snippetSupport":true,"tagSupport":{"valueSet":[1]}},"completionItemKind":{}},"hover":{"contentFormat":["markdown"]},"inlayHint":{"dynamicRegistration":false},"publishDiagnostics":{"versionSupport":true},"rename":{"dynamicRegistration":false,"honorsChangeAnnotations":false,"prepareSupport":true},"signatureHelp":{"signatureInformation":{"activeParameterSupport":true,"documentationFormat":["markdown"],"parameterInformation":{"labelOffsetSupport":true}}}},"window":{"workDoneProgress":true},"workspace":{"applyEdit":true,"configuration":true,"didChangeConfiguration":{"dynamicRegistration":false},"didChangeWatchedFiles":{"dynamicRegistration":true,"relativePatternSupport":false},"executeCommand":{"dynamicRegistration":false},"inlayHint":{"refreshSupport":false},"symbol":{"dynamicRegistration":false},"workspaceEdit":{"documentChanges":true,"failureHandling":"abort","normalizesLineEndings":false,"resourceOperations":["create","rename","delete"]},"workspaceFolders":true}},"clientInfo":{"name":"helix","version":"23.10 (f6021dd0)"},"initializationOptions":{},"processId":2627793,"rootPath":"/media/<--REMOVED-->","rootUri":"file:///media/<--REMOVED-->","workspaceFolders":[{"name":"SHELIX","uri":"file:///media/<--REMOVED-->"}]},"id":0}
2024-01-28T08:55:15.632 helix_lsp::transport [INFO] gpt <- {"jsonrpc":"2.0","method":"initialize","id":0,"result":{"capabilities":{"codeActionProvider":true,"executeCommandProvider":{"commands":["generateDocs","improveCode","refactorFromComment"]},"completionProvider":{"resolveProvider":false,"triggerCharacters":["{","(",")","=",">"," ",",",":",".","<","/"]},"textDocumentSync":{"change":1,"openClose":true}}}}
2024-01-28T08:55:15.632 helix_lsp::transport [INFO] gpt <- {"capabilities":{"codeActionProvider":true,"completionProvider":{"resolveProvider":false,"triggerCharacters":["{","(",")","=",">"," ",",",":",".","<","/"]},"executeCommandProvider":{"commands":["generateDocs","improveCode","refactorFromComment"]},"textDocumentSync":{"change":1,"openClose":true}}}
2024-01-28T08:55:15.632 helix_lsp::transport [INFO] gpt -> {"jsonrpc":"2.0","method":"initialized","params":{}}
2024-01-28T08:55:15.632 helix_lsp::transport [INFO] gpt -> {"jsonrpc":"2.0","method":"workspace/didChangeConfiguration","params":{"settings":{}}}
2024-01-28T08:55:15.633 helix_lsp::transport [INFO] gpt -> {"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"languageId":"php","text":"\n","uri":"file:///media/<--REMOVED-->/test.php","version":0}}}
2024-01-28T08:55:47.769 helix_lsp::transport [INFO] gpt -> {"jsonrpc":"2.0","method":"textDocument/didChange","params":{"contentChanges":[{"text":"<\n"}],"textDocument":{"uri":"file:///media/<--REMOVED-->/test.php","version":1}}}
2024-01-28T08:55:47.769 helix_lsp::transport [INFO] gpt -> {"jsonrpc":"2.0","method":"textDocument/completion","params":{"position":{"character":1,"line":0},"textDocument":{"uri":"file:///media/<--REMOVED-->/test.php"}},"id":1}
2024-01-28T08:55:47.975 helix_lsp::transport [INFO] gpt <- {"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"uri":"file:///media/<--REMOVED-->/test.php","diagnostics":[{"message":"Fetching completion...","severity":3,"range":{"start":{"line":0,"character":0},"end":{"line":1,"character":0}},"source":"helix-gpt"}]}}
2024-01-28T08:55:48.164 helix_lsp::transport [INFO] gpt -> {"jsonrpc":"2.0","method":"textDocument/didChange","params":{"contentChanges":[{"text":"<?\n"}],"textDocument":{"uri":"file:///media/<--REMOVED-->/test.php","version":2}}}
2024-01-28T08:55:48.638 helix_lsp::transport [INFO] gpt <- {"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"uri":"file:///media/<--REMOVED-->/test.php","diagnostics":[{"message":"Completion failed: request error with status code 429","severity":1,"range":{"start":{"line":0,"character":0},"end":{"line":1,"character":0}},"source":"helix-gpt"}]}}y

Updated to v0.11.
hx -v test.php
tail -f ~/.cache/helix/helix.log
UI: Completion failed. Request Error with status 429

Well, now that i have an error code,  that error 429 is an API quota rate limit: https://help.openai.com/en/articles/6891829-error-code-429-rate-limit-reached-for-requests
That's a bit of a misfortune :/ . i have other tools that are querying that api, and are still running. (Not the auto-completion service).
I see that each key type is sending a request, and in my opinion that is a bit aggressive, this will rapidly leads to troubles^
At this stage, can't confirm that helix-gpt runs fine, but it looks ok, thank you.

2024-01-28T08:55:15.555 helix_vcs [INFO] file is untracked
2024-01-28T08:55:15.555 helix_vcs [INFO] failed to open diff base for /media/<--REMOVED-->/test.php
2024-01-28T08:55:15.556 helix_lsp::client [INFO] Using custom LSP config: {}
2024-01-28T08:55:15.556 helix_lsp::transport [INFO] gpt -> {"jsonrpc":"2.0","method":"initialize","params":{"capabilities":{"general":{"positionEncodings":["utf-8","utf-32","utf-16"]},"textDocument":{"codeAction":{"codeActioÆnLiteralSupport":{"codeActionKind":{"valueSet":["","quickfix","refactor","refactor.extract","refactor.inline","refactor.rewrite","source","source.organizeImports"]}},"dataSupport":true,"disabledSupport":true,"isPreferredSupport":true,"resolveSupport":{"properties":["edit","command"]}},"completion":{"completionItem":{"deprecatedSupport":true,"insertReplaceSupport":true,"resolveSupport":{"properties":["documentation","detail","additionalTextEdits"]},"snippetSupport":true,"tagSupport":{"valueSet":[1]}},"completionItemKind":{}},"hover":{"contentFormat":["markdown"]},"inlayHint":{"dynamicRegistration":false},"publishDiagnostics":{"versionSupport":true},"rename":{"dynamicRegistration":false,"honorsChangeAnnotations":false,"prepareSupport":true},"signatureHelp":{"signatureInformation":{"activeParameterSupport":true,"documentationFormat":["markdown"],"parameterInformation":{"labelOffsetSupport":true}}}},"window":{"workDoneProgress":true},"workspace":{"applyEdit":true,"configuration":true,"didChangeConfiguration":{"dynamicRegistration":false},"didChangeWatchedFiles":{"dynamicRegistration":true,"relativePatternSupport":false},"executeCommand":{"dynamicRegistration":false},"inlayHint":{"refreshSupport":false},"symbol":{"dynamicRegistration":false},"workspaceEdit":{"documentChanges":true,"failureHandling":"abort","normalizesLineEndings":false,"resourceOperations":["create","rename","delete"]},"workspaceFolders":true}},"clientInfo":{"name":"helix","version":"23.10 (f6021dd0)"},"initializationOptions":{},"processId":2627793,"rootPath":"/media/<--REMOVED-->","rootUri":"file:///media/<--REMOVED-->","workspaceFolders":[{"name":"SHELIX","uri":"file:///media/<--REMOVED-->"}]},"id":0}
2024-01-28T08:55:15.632 helix_lsp::transport [INFO] gpt <- {"jsonrpc":"2.0","method":"initialize","id":0,"result":{"capabilities":{"codeActionProvider":true,"executeCommandProvider":{"commands":["generateDocs","improveCode","refactorFromComment"]},"completionProvider":{"resolveProvider":false,"triggerCharacters":["{","(",")","=",">"," ",",",":",".","<","/"]},"textDocumentSync":{"change":1,"openClose":true}}}}
2024-01-28T08:55:15.632 helix_lsp::transport [INFO] gpt <- {"capabilities":{"codeActionProvider":true,"completionProvider":{"resolveProvider":false,"triggerCharacters":["{","(",")","=",">"," ",",",":",".","<","/"]},"executeCommandProvider":{"commands":["generateDocs","improveCode","refactorFromComment"]},"textDocumentSync":{"change":1,"openClose":true}}}
2024-01-28T08:55:15.632 helix_lsp::transport [INFO] gpt -> {"jsonrpc":"2.0","method":"initialized","params":{}}
2024-01-28T08:55:15.632 helix_lsp::transport [INFO] gpt -> {"jsonrpc":"2.0","method":"workspace/didChangeConfiguration","params":{"settings":{}}}
2024-01-28T08:55:15.633 helix_lsp::transport [INFO] gpt -> {"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"languageId":"php","text":"\n","uri":"file:///media/<--REMOVED-->/test.php","version":0}}}
2024-01-28T08:55:47.769 helix_lsp::transport [INFO] gpt -> {"jsonrpc":"2.0","method":"textDocument/didChange","params":{"contentChanges":[{"text":"<\n"}],"textDocument":{"uri":"file:///media/<--REMOVED-->/test.php","version":1}}}
2024-01-28T08:55:47.769 helix_lsp::transport [INFO] gpt -> {"jsonrpc":"2.0","method":"textDocument/completion","params":{"position":{"character":1,"line":0},"textDocument":{"uri":"file:///media/<--REMOVED-->/test.php"}},"id":1}
2024-01-28T08:55:47.975 helix_lsp::transport [INFO] gpt <- {"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"uri":"file:///media/<--REMOVED-->/test.php","diagnostics":[{"message":"Fetching completion...","severity":3,"range":{"start":{"line":0,"character":0},"end":{"line":1,"character":0}},"source":"helix-gpt"}]}}
2024-01-28T08:55:48.164 helix_lsp::transport [INFO] gpt -> {"jsonrpc":"2.0","method":"textDocument/didChange","params":{"contentChanges":[{"text":"<?\n"}],"textDocument":{"uri":"file:///media/<--REMOVED-->/test.php","version":2}}}
2024-01-28T08:55:48.638 helix_lsp::transport [INFO] gpt <- {"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"uri":"file:///media/<--REMOVED-->/test.php","diagnostics":[{"message":"Completion failed: request error with status code 429","severity":1,"range":{"start":{"line":0,"character":0},"end":{"line":1,"character":0}},"source":"helix-gpt"}]}}y

Updated to v0.11.
hx -v test.php
tail -f ~/.cache/helix/helix.log
UI: Completion failed. Request Error with status 429
Well, now that i have an error code, that error 429 is an API quota rate limit: https://help.openai.com/en/articles/6891829-error-code-429-rate-limit-reached-for-requests
That's a bit of a misfortune :/ . i have other tools that are querying that api, and are still running. (Not the auto-completion service).
I see that each key type is sending a request, and in my opinion that is a bit aggressive, this will rapidly leads to troubles^
At this stage, can't confirm that helix-gpt runs fine, but it looks ok, thank you.

It should only be triggered by the characters below. But Helix has its own set of characters/rules to trigger too. I haven't had any 429s yet, so that's strange.
triggerCharacters: ["{", "(", ")", "=", ">", " ", ",", ":", ".", "<", "/"]

Looks like I am ban^ (I code a lot)
triggerCharacters: ["{", "(", ")", "=", ">", " ", ",", ":", ".", "<", "/"]
We tend to use them quite often^
Might come back later to report for your app, i guess next month.
Thanks again.

Looks like I am ban^ (I code a lot)
triggerCharacters: ["{", "(", ")", "=", ">", " ", ",", ":", ".", "<", "/"]
We tend to use them quite often^
Might come back later to report for your app, i guess next month.
Thanks again.

Yea do please. Still early days, but I think all of the features I want implemented are finished now. So my focus is on fixing any issues.
For the next release, I've updated the trigger characters to ["{", "(", " ", "."] As I see with PHP you would be triggering it a lot with the previous set. There's also a 200ms debounce, but that's not always effective.


Hotfix/histogram duplicates or absent

when user selected top_k_features to display all feature distributions, some of them were not shown as they have 0 importance for the decision tree, but the user needs to be able to look at the distribution of all features in a node
when using pipeline, some features hist were duplicated (multiple hist for the one hot encoded features)

Are the duplicates really duplicates? Is it not that for one hot encoded categorical features, you get a distribution for each category?

yes, exactly

@AgatheG are you ok with those changes?


Add visual changelog to Switch Asset UI as to what will receive changes or not

Issue
With #376 the Switch Asset UI now shows what the selected boxes "mean" for changes, but does not clearly showcase what it means for the end result on the selection. As such, it will be hard to figure out why some combinations may not be valid and result in no change - or what in the end the different containers will switch to.
Proposal
It'd be best to include a list widget that shows what the current selection will mean for the final result, how will it be influenced.
Here's a (very quickly!) drawn mock-up showcasing how that could work:

Reference: https://github.com/getavalon/core/pull/376#issuecomment-499035838
Related:

Switching Representations with different loaders - this issue is also about the Switch UI but describes a new feature. However, it could be good to keep that in mind when redesigning the visual view of the Switch UI.

With #551 still being open for performance improvements I thought it would be just as good a time as any to see if we can optimize and get this issue done too. Here's a quick visual prototype.

Note that I've also taken the "preparation" code from #551 and improved the speed for that by making it simpler query with a single aggregation pipeline, thus a single query sent to the database - as I felt the time to when the popup showed still took some time with the new code. About another 30% speed improvement.
The changes made in #551 also mention a BUG introduced there reported by @tokejepsen where previously it allowed to choose a combination of changes that would NOT switch all selected assets but just a subset of them - which was not allowed anymore in #551. That original behavior and intention of the tool was also described here - specifically the switching to another shot, where the other shot could miss a specific subset and then still allow the change for all other pieces. I'm looking to revert the logic that causes the BUG so that it will indeed allow skipping some conversion but with the "change preview" it should also be clear as to what exactly is about to happen.
Pointers/ideas on how to easily improve how one can see what is about to change let me know. I'm not entirely happy with the two comparison lists.
Note to self: it could be worth looking into how Bulk/Batch Rename utilities provide previews of what is about to change. Or e.g. "refactoring" previews for code. Images are welcome!
@tokejepsen @davidlatwe @mkolar let me know if you have good references or ideas!

Think this looks good!
Only comments are cosmetics from me:

Orange instead of purple to keep with the general Avalon theme.
The lists are big and only need a single line on each side.

Orange instead of purple to keep with the general Avalon theme.

I was thinking of even tinting each part of the string different, e.g. asset separate from subset, representation, etc.

The lists are big and only need a single line on each side.

This was actually to accomodate for when switching multiple loaded content, like this:

Anyway, hope to find some time soon to continue with this :)

Why is the representation red here?

Would love to try out, but I am on vacation till next Monday.
Still, is this prototype can be git checkout somewhere in you fork ?


Not working on K70

What are you experiencing an issue with?

[ ] Aurora
[ ] Aurora supported game, (Fill in the game)
[ ] Aurora Wrapper
[ ] Aurora Profile
[x] Aurora supported device, (Fill in problematic devices)
[ ] Aurora Scripts
[ ] Aurora Updater
[ ] Aurora Lighting issue
[ ] Other, (Fill in another issue here)

What kind of an issue is it?

[ ] Crash
[ ] Performance problems
[ ] Visual bug
[ ] Localization issue
[ ] Enhancement suggestion
[x] Device issue
[ ] Other, (Fill in another type of issue here)

Expected behavior:
My keyboard should be showing the lightning effects as the aurora program shows.
Actual behavior:
The aurora program shows the lightning effects, but my k70 doesnt
How often does this problem occur?
This problem occurs everytime

Do you have the SDK option in CUE enabled?

To follow on what @BadoTl said, do you have CUE installed and the SDK option enabled? If you do check what it says for Corsair under Settings -> Device Manager and post your log file please


[BUG] pointsMod not working on first run.

Describe the bug
Currently, when you run pointsMod the first time, the data for the user is created and they're given their initial points, but the successful message is never supplied.
To Reproduce
To reproduce this, award points to a user that has never received points from the bot. The bot won't respond, but if you check the database, the data is available. Subsequent calls to pointsMod will receive responses just fine.
Screenshots

This issue is being caused by the fact that points is being accessed on incomingPointData when the user's point data is null on the first run:

Adding handling for when incomingPointData is null fixes the issue.

I have the fix for this ready to push after PR #87 is approved and merged in.


This is extremely confusing

The examples on this page relate to a future version of the application not in current public preview and should be hidden or marked as not-current.
For example, the current version of Migration Manager only supports file shares, but this gives examples on how to migrate from an On-Prem SharePoint server to SharePoint Online

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

ID: 7331acc8-e10a-d41b-2f8d-0bc991987f3c
Version Independent ID: e42887fd-650c-259d-706a-635eacc08a76
Content: How to format a CSV or JSON file for bulk upload in Migration Manager - Migrate to SharePoint and OneDrive
Content Source: migration/mm-bulk-upload-format-csv-json.md
Service: sharepoint-online
GitHub Login: @JoanneHendrickson
Microsoft Alias: jhendr

@jantoney  Thank you for submitting feedback and contributing to the docs. We are currently investigating this.

Thank you for seeing this.  The document has been updated to reflect only  file shares only.


fix typo in index.html again

This pull request fixes a typo in index.html.  I noticed that it was originally fixed by @penance316 but on a subsequent merge by @DavidScales it was changed back to the original typo.
Just thought I'd try my hand at a PR for the first time with this simple change.  Thanks!

Thanks for fixing this Glenn!


Issue: imToken wallet not showing on UI

I have added 'imToken' as an option to connect the wallet but it doesn't appear in the modal. Is there anything special here?

I found out 'imToken' wallet only shows on mobile, how can i display it on desktop

@kingsley1996 As far as I know it is a mobile app so you can't use it on desktop. You would want to use WalletConnect 👍🏾


Is any possible can connect multiple devices at a time?

You can create and use multiple instances of FastbootDevice simultaneously, but a serial number check will be necessary for proper reconnection.

1d,,,,,,,,,A,,,,(//(,


remove usage of res://icon.png from typed_editors/dock_texture.tscn

Hey,
I found a small problem / warning while including the godot-4 branch into my project using Godot 4.2.1:

scene/resources/resource_format_text.cpp:448 - res://addons/resources_spreadsheet_view/typed_editors/dock_texture.tscn:4
ext_resource, invalid UID: uid://c08qavfwqr3k7 - using text path instead: res://icon.png

I suspect this warning will get shown for every project using the plugin.

I've replaced the placeholder texture for the dock_texture scene with well, a placeholder texture :)
Otherwise a really awesome plugin, thank you for all the work put into it 🎉

Huh. I didn't even know these existed.
Well, looks good to me!


gazebo reset

In order to robot learning, we always need the reset function.

reset joint position
reset model velocity
reset world
reset without simulation time or with simulation time
reset gazebo plugins with time or without time

But we should know that gazebo is still not friendly with this!
Reset joint position
Reset joint position can' work with ros controllers. See spawn_model -J initial joint positions not working #93
Reset World
Currently, reset_world() will reset time. see issues with reset buttons.
Other issues

/joint_states will return wrong and very large data after self collision or contact with other objects. And it can't be reset at present!

Reference

reset /joint_states and gazebo plugins state in gazebo #27
issues with reset buttons
spawn_model -J initial joint positions not working #93

Reset gazebo model joint position which spawned from ros URDF with gazebo_ros_control plugin
# stop ros controllers should before pause physics, or will be blocked
rosservice call /controller_manager/switch_controller [] ["arm_gazebo_controller"] 2

# pause physics
rosservice call /gazebo/pause_physics

# rosrun gazebo_ros spawn_model ....

# set model joint configuration with URDF parameter
rosservice call /gazebo/set_model_configuration '{model_name: "robot", urdf_param_name: "robot_description", joint_names:['shoulder_pan_joint', 'shoulder_lift_joint', 'elbow_joint','wrist_1_joint', 'wrist_2_joint', 'wrist_3_joint'], joint_positions:[1.2, 0.3, -1.5, -0.5, -1.5, 0.0]}'
sleep 5

# unpause physics
rosservice call /gazebo/unpause_physics
# after unpause the robot will be set to the previous pose(before paused)

# restart ros controllers should after unpaused physics, or will be blocked
rosservice call /controller_manager/switch_controller ["arm_gazebo_controller"]  [] 2

If we want start gazebo without ros controller
# We can start gazebo with ROS service support
roslaunch gazebo_ros empty_world.launch

# set model joint configuration directly without URDF
rosservice call /gazebo/set_model_configuration '{model_name: "ur10", joint_names:['shoulder_pan_joint', 'shoulder_lift', 'elbow','wrist_1', 'wrist_2', 'wrist_3'], joint_positions:[2, -1, -1.5, -1.5, -1.5, 0.0]}'

Important findings:
If we spawn the robot from gazebo .world file, not using the following spawn_model node
<node name="spawn_gazebo_model" pkg="gazebo_ros" type="spawn_model" args="-urdf -param robot_description -model robot" respawn="false" output="screen" />

then we can set the model configuration correctly with the following procedure

stop ros controllers
set model configuration using ros service

rosservice call /gazebo/set_model_configuration '{model_name: "ur10", joint_names:['shoulder_pan_joint', 'shoulder_lift_joint', 'elbow_joint','wrist_1_joint', 'wrist_2_joint', 'wrist_3_joint'], joint_positions:[1.0, 0.0, 1.9, 0.2, 0.0, 0.0]}'

start ros controllers
The controller wouln't set the joint value as the previous values.

like this:
<?xml version="1.0"?>
<sdf version="1.6">
  <world name="default">
    <physics type='ode'/>
    <include>
      <uri>model://ground_plane</uri>
    </include>
    <include>
      <uri>model://sun</uri>
    </include>
    <include>
      <uri>model://ur10_clone</uri>
      <name>ur10</name>
      <pose>0 -2 0 0 0 0</pose>
      <plugin name="ros_control" filename="libgazebo_ros_control.so">
      </plugin>
    </include>
  </world>
</sdf>

where we clone the ur10 model from gazebo models to ur10_clone which modified the joint names to align with the urdf file in ros description package.

Possible causes of reset failure

sim hardware interface

see default_robot_hw_sim
Only if we set the ros control plugin in the URDF before loading by gazebo, this node will start, and regardless of whether or not a corresponding controller exists for the robot.
This will reset the position, but for some physics engine, the interface may not supported by ros, so it failed.

controller will set the joint position by its states(from where?)

controller manager how to set the states of the hardware interface


use gem to install cocoapods, instead of brew

official docs of cocoapods use gem
gem is preinstalled on mac, brew isn't
people could be using ports, not brew

partially resolves #16458

/xx @xster

We'd like to avoid creating a divergence between the recommendations we make on the various other dependencies (which are not available in gem like libimobiledevice) and cocoapods.
We're also likely to move the installation process itself to a single installer that declares other dependencies so it'll likely be all on homebrew or all on macport (less likely). Mixing in gems will increase divergence.

I'll close this for now. Please feel free to reopen if your concerns aren't fully addressed.
(https://github.com/flutter/flutter/pull/16461 is still a great idea though)


feature Enhance for compatibility of old cloud create table logic

Proposed changes
Issue Number: close #xxx
For existing Cloud clusters, when creating tables, FE passes an empty vault name. Subsequently, it will look for the object info with the largest ID in the S3 object info and use it as the vault.

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

included by #33308


Cannot power off a VM in phase: failed

If a VM is powered on, but in phase: failed (which means not actually powered on?), and currently as we see it as Powered On in ManageIQ, if we try to Power it off from manageiq, it just stays there as Powered on in ManageIQ, and in vms on openshift.
@pkliczewski suggests this is on kubevirt side

@vatsalparekh can you please posed the corresponding VirtualMachine and OfflineVirtualMachine objects?

Also which version of KubeVirt are you using?

@rmohr
This VM's scheduling failed was mainly when openshift node was down, and make the cluster up again
[fedora@vparekh-automation-provider ~]$ oc get vms test -n default -o yaml
apiVersion: kubevirt.io/v1alpha1
kind: VirtualMachine
metadata:
  annotations:
    presets.virtualmachines.kubevirt.io/presets-applied: kubevirt.io/v1alpha1
  clusterName: ""
  creationTimestamp: 2018-05-21T11:45:38Z
  deletionGracePeriodSeconds: 0
  deletionTimestamp: 2018-05-22T06:23:34Z
  finalizers:
  - foregroundDeleteVirtualMachine
  generateName: test
  generation: 0
  labels:
    kubevirt.io/nodeName: localhost
  name: test
  namespace: default
  ownerReferences:
  - apiVersion: kubevirt.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: OfflineVirtualMachine
    name: test
    uid: 073661be-58e7-11e8-9971-fa163ed3a8d3
  resourceVersion: "82050"
  selfLink: /apis/kubevirt.io/v1alpha1/namespaces/default/virtualmachines/test
  uid: 7afe1ec5-5cec-11e8-9128-fa163ed3a8d3
spec:
  domain:
    cpu:
      cores: 4
    devices:
      disks:
      - disk: {}
        name: registrydisk
        volumeName: registryvolume
      - disk: {}
        name: cloudinitdisk
        volumeName: cloudinitvolume
    firmware:
      uuid: feec480d-31a1-59fa-9199-a330c83aa404
    machine:
      type: q35
    resources:
      requests:
        memory: 1Gi
  volumes:
  - name: registryvolume
    registryDisk:
      image: kubevirt/fedora-cloud-registry-disk-demo:latest
  - cloudInitNoCloud:
      userDataBase64: I2Nsb3VkLWNvbmZpZwpwYXNzd29yZDogYXRvbWljCnNzaF9wd2F1dGg6IFRydWUKY2hwYXNzd2Q6IHsgZXhwaXJlOiBGYWxzZSB9Cg==
    name: cloudinitvolume
status:
  interfaces:
  - ipAddress: <IP_ADDRESS>
  nodeName: localhost
  phase: Failed

[fedora@vparekh-automation-provider ~]$ oc get ovms test -n default -o yaml
apiVersion: kubevirt.io/v1alpha1
kind: OfflineVirtualMachine
metadata:
  clusterName: ""
  creationTimestamp: 2018-05-16T08:56:31Z
  generation: 0
  labels:
    kubevirt.io/os: rhel-7
  name: test
  namespace: default
  resourceVersion: "80579"
  selfLink: /apis/kubevirt.io/v1alpha1/namespaces/default/offlinevirtualmachines/test
  uid: 073661be-58e7-11e8-9971-fa163ed3a8d3
spec:
  running: true
  template:
    metadata:
      creationTimestamp: null
    spec:
      domain:
        cpu:
          cores: 4
        devices:
          disks:
          - disk: {}
            name: registrydisk
            volumeName: registryvolume
          - disk: {}
            name: cloudinitdisk
            volumeName: cloudinitvolume
        machine:
          type: q35
        resources:
          requests:
            memory: 1Gi
      volumes:
      - name: registryvolume
        registryDisk:
          image: kubevirt/fedora-cloud-registry-disk-demo:latest
      - cloudInitNoCloud:
          userDataBase64: I2Nsb3VkLWNvbmZpZwpwYXNzd29yZDogYXRvbWljCnNzaF9wd2F1dGg6IFRydWUKY2hwYXNzd2Q6IHsgZXhwaXJlOiBGYWxzZSB9Cg==
        name: cloudinitvolume
status:
  created: true

kubevirt version was v0.5.0

@vatsalparekh the OfflineVirtualMachine shows that the VirtualMachine exists (spec.created=true). It does not show it as ready (spec.ready=true would need to be set). That means If a node goes down, the pod where the vm runs in goes to "unknown" state. That means that the system does not know 100% if the vm is down or not. That blocks the deletion of  the VirtualMachine (as you can see OfflineVirtualMachine already marked the VirtualMachine for deletion: deletionTimestamp: 2018-05-22T06:23:34Z). So as soon as you remove the pod in unknown state, the deletion of the virtual machine is unblocked and OfflineVirtualMachine will create a new instance of VirtualMachine.
We need to work on propagating the Pod state in a more user-friendly way to the vm state so that it is easier to see why things are not proceeding (e.g. registry disk image not found, node down, ...) but at least the implemented parts behave like expected.

@rmohr could you please file two bugs:

propagating the pod state
documenting this behavior in the user-guide

Should there actually be another hint to tell the user what to do, or how to find more information sbaout these situations?

The implication is actually as follows:

VMI will not be removed
VM can thus not be started anymore

@rmohr is this still an issue?


Get rid of conda

Default bash in container always launches with conda activated. We want to remove this.

Accomplished with https://github.com/ContactEngineering/ce-container-stack/commit/89828f4a633e86fe41b9b1bc82c8ea68cf4b6a7c


Extend validator guide with concrete validations a beacon node should perform for builder blocks

A builder provides an ExecutionPayloadHeader when offering bids to a given proposer.
The proposer (and specifically the local beacon node the proposer is running) should check the header against their local execution state to ensure the header is not inaccurate or even malicious.
We should specify the set of validations that should be performed in the validator guide.

Absolutely, ensuring the integrity and accuracy of the ExecutionPayloadHeader is crucial for the security of the Ethereum network. Here are some concrete validations that a beacon node should perform when processing builder blocks:

Signature Verification: The beacon node should verify the signature of the ExecutionPayloadHeader to ensure it was signed by the correct builder.

Execution State Validation: The beacon node should compare the execution state referenced in the ExecutionPayloadHeader with its own local execution state. This includes checking the correctness of the execution environment, the account balances, and the contract code.

Gas Limit Check: The beacon node should verify that the gas limit specified in the ExecutionPayloadHeader is within the acceptable range defined by the network protocol. This prevents excessive gas consumption and potential denial-of-service attacks.

Timestamp Validation: The beacon node should check the timestamp in the ExecutionPayloadHeader to ensure it falls within an acceptable range. This prevents the inclusion of outdated or future-dated execution payloads.

Nonce Verification: The beacon node should validate the nonce of the ExecutionPayloadHeader to ensure it is correctly incremented. This prevents replay attacks and ensures the freshness of the execution payload.

Consensus Rules Compliance: The beacon node should enforce the consensus rules defined by the Ethereum protocol. This includes checking for any protocol-specific requirements or restrictions on the execution payload.

By performing these validations, a beacon node can ensure the integrity and correctness of the builder blocks it processes, contributing to the overall security and stability of the Ethereum network.