Which partition is supposed to store the Windows Boot Manager file?

The following two reddit posts covered my issues with dual-booting Windows with rEFInd up to this point;
1 - https://www.reddit.com/r/WindowsOnDeck/comments/1gjs3wo/long_story_short_either_i_boot_into_windows_and/
2 - https://www.reddit.com/r/WindowsOnDeck/comments/1gkjujd/where_is_the_windows_boot_file_supposed_to_be_aka/
Now, as I explain in the second post, after attempting a boot repair with EaseUS, it essentially created a new one, but I don't know which one that is, and since one of them is in the esp partition's rEFInd folder, I came to ask if that is the intended one that broke and that I have to somehow fix.

Just realized the answer was in another issue post


Support limiting number of Egress IPs that can be assigned to a Node

The current implementation of Egress uses 8 bits of pkt mark to indicate which SNAT IP the egress traffic should use, which means at most 255 Egress IPs can be assigned to a single Node. Besides, some Node network may restrict the number of secondary IPs that can be assigned to a Node, e.g. EKS.
This patch adds a configuration option maxEgressIPsPerNode and makes it default to 255. When a Node cannot accommodate more Egress IPs, the next Node will be tried, until an available Node is found or all Nodes are tried.
Signed-off-by: Quan Tian<EMAIL_ADDRESS>

/test-all

Do you know if we already publish an error condition in the Egress Status if we fail to select an Node for the Egress (e.g., because the ExternalIPPool doesn't select any Node, or with this change, because we hit the limit).

We don't publish error condition in the status yet. Currently if the Egress Node field is empty, it would mean no Node is eligible for the Egress IP. But an error condition would be a good UE improvement, let me see if we should do it in another PR.

Do you know if we already publish an error condition in the Egress Status if we fail to select an Node for the Egress (e.g., because the ExternalIPPool doesn't select any Node, or with this change, because we hit the limit).

We don't publish error condition in the status yet. Currently if the Egress Node field is empty, it would mean no Node is eligible for the Egress IP. But an error condition would be a good UE improvement, let me see if we should do it in another PR.

The challenge is who should be responsible for reporting the error. If no Node is selected by the pool, how to reach an agreement among the agents that which one should do it. Any good idea?

/test-all


Object.values() does not seem to be supported within the editor

(Obligatory: I'm new here, if I'm in the wrong place, be nice :) )
This is the Kata: https://www.codewars.com/kata/5966847f4025872c7d00015b/train/javascript
This is what I've written, and this is the error:

I copied the syntax pretty much exactly from this article: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_objects/Object/values
Object.keys() works great. CanIUse.com seems to indicate widespread support for Object.values(): https://caniuse.com/#search=object.values
This alternative implementation of the same code works fine, but isn't as clean as Object.values():
let valIWant = '';

Object.keys(numLib).forEach((key) => {
    if (numLib[key] === avg){
      valIWant = key
    }

Near as I can tell, it is not specific to this Kata.

This isn't an issue, this is you not getting your version history and their added features right.
Node v6 doesn't support Object.values , The support for that was added beginning in Node v7.

The alternate code you mentioned is not as clean as Object.values : dunno about that.

 Here is a better way to do it :
  objKeysMap = Object.keys(obj).map(k => obj[k])

Use Node 8 if you need Object.values. If the kata doesn't have it, let the author and contributors know by commenting on the kata discourse page.


Can't read language spec

Ghidra Version is 9.2.2

It worked last time I tried it (though that was a while ago).  Is there a file at /opt/ghidra/Ghidra/Processors/65816/data/languages/65816.slaspec and does it have sensible file permissions?   I guess?

mine has a 65816.sla file and it is 1,4967KB.

Any idea how it gets created?
https://github.com/achan1989/ghidra-65816/tree/master/data/languages doesn't contain such file.

If I remember correctly, the .sla file is auto-generated by Ghidra after it loads and processes the .slaspec file.
@hellow554 your data files are all owned by root, so unless you're running Ghidra as root (which is probably a bad idea!) Ghidra won't have permission to read the files.

Ghidra is installed to /opt by my package manager pacman. So I copied your files into /opt/... as well and gave them the same file permissions as all the other processor types as well. That should be the right way to do. Is there a specific reason the .sla file is generated on the fly? Why do other processor specs to not do that? :/

I don't remember, it's been a long time since I've used this module.

The issue seems to be a handful of unused labels in 658xx.sinc getting treated as errors.  Commenting out the labels with a '#' at the beginning of the following lines seems to solve it
658xx.sinc:1579:
658xx.sinc:1622:
658xx.sinc:2018: <to_emulation>
658xx.sinc:2044: <to_emulation>


fix for a memory leak

removed the constant creation of new <canvas>  that would spike memory usage and also added a missing semicolon

@googlebot I signed it!

Will this be merged in? Still open but approved!

Thanks for reminding us! Slipped through the cracks, it's merged now.

@HalfdanJ - I noticed there's another PR that's open from @AliKarpuzoglu. Seems like a legitimate ask re image normalisation, could that be checked too?


Replace Vuex state before mounting the component

The Vuex state should be restored before mounting the component otherwise Vue will try to render a component with different state to what was server rendered.

@marconi1992  any reason why this is not merged?

merged @nadelicious @iamphill

:tada: This PR is included in version 3.0.5 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Remove OpenTelementry imports from remotes/docker package

Signed-off-by: Maksym Pavlenko<EMAIL_ADDRESS>

@mxpv  Do you think about using otel-http to trace outgoing http requests, instead of creating manual spans?
I have a PR #7692  that wraps the existing http handler and produces traces for all incoming requests.

@swagatbora90 No, the goal was to just isolate dependencies here.


envoy: revert recent upstream updates

Description: c6e1af6 (#958) broke Android builds on MacOS and 811235d (#981) adopted new Envoy interfaces making it no longer possible to an older SHA. Together this makes Android development extremely difficult. This rolls back those changes on main until the breakage can be resolved.
Risk Level: TBD
Testing: Local and CI

Can you elaborate on the issues you're encountering (CI is green on master)?
I'm concerned about reverting back to a version of Envoy from several weeks ago - each time we upgrade, we typically have several issues that need to be resolved, and getting further out of date makes it harder to upgrade as time goes on. Can we fix the issues instead?

Resolved this offline, looks like a local NDK issue we were all experiencing. Thanks for the help @buildbreaker and @keith!


bump zk version to 3.4.7 (latest stable)

This already happened in 302077e3fedcf2dc830b68711fd713c476178aba, and shipped as v3.0.0 (b/c upgrading ZK is potentially breaking for folks).


How do I use it with VS2012 and Mono?

Is there a F# 3.1, assembly version <IP_ADDRESS> somewhere that is usable? I installed v<IP_ADDRESS> for VS2013 and got the DLL installed, referencing that still gives problems.
And or, how do I make it work in any way possible?

Closing this very old issue


Support document authorization by specific users

Currently document type definitions are limited to providing a list of channels to which a user must belong (either directly or indirectly through membership in a role that includes the channel(s)) in order to create/replace/delete documents of that type. However, Sync Gateway also exposes the requireUser function to sync functions, which specifies that only one of the provided users may perform the operation. Add configuration support for defining the list of users that a document requires.
See Authorizing Document Updates for more info. Related to #22.

Addressed by #58


Support loading weights from pytorch model

Currently, NNTrainer partially support weight transfer for a simple model that layers are stacked linearly. This is because when NNTrainer read weights, it depend on the order of weights, not the name of weights. So.. we need other solution to support weights transfer for models with more complex connections.
If the weights are transferred based on the name of the weights, the weights can be transferred regardless of the model connection structure. Therefore,  we need to update NNTrainer to load weights based on names, not the order of weights.
The name of weights depends on various factors such as the variable name used by the developer, so we need preliminary data to map the weights name, which can be delivered from the user (json file..?).
To implement this method, first of all, NNTrainer define a weights table as follows (not exactly the same structure, but I know that similar forms have already been defined in NNTrainer. )

weights_name
data type
start position(address)
size(length)

model.linear1
float32
0
1024

model.output
float32
1024
10

After that, read the name-based weights in the form of a map data structure and allocate the weights with the start position of each mapped weights name.
This method may not be the best in terms of memory efficiency.
However, I would like to present a draft for discussion and implement it in a more advanced direction.

:octocat: cibot: Thank you for posting issue #2616. The person in charge will reply soon.


Fix some types

Element -> HTMLElement

Coverage remained the same at 83.568% when pulling 302d8c46db42fe55acc278620c6bed645f7a3d4a on fix/types into 83801fba0ba4baa8432de9234c21902453dfa81e on master.


Emails on our domain

When we will publish contact Emails on the website, will be nice to have Emails in our domains.
Initial suggestion is (in alphabetical order):
<EMAIL_ADDRESS>      => for regular support
<EMAIL_ADDRESS>  => for @ArmenVardanyan
<EMAIL_ADDRESS>     => for @dgrig1
<EMAIL_ADDRESS>      => for @davitkalantaryan
<EMAIL_ADDRESS>   => for Zohrab
Implementation will start after a discussion of possible implementation on 29 Mar 2022

@dgrig1's comment (https://github.com/focustm/p01-general/issues/29):
My suggestion is to use the<EMAIL_ADDRESS>email address for the website contact email. This is some type of standard for today. We will also need to have personal emails, but those will be used in specific cases.


added fix for efficient_su2

Summary
Details and comments

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Ethan Gordon seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Ethan Gordon seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

Thanks! There's also pauli_two_design which has the same issue 🙂

oh shoot did not catch that sorry! Will put in fix tonight!

Thanks for the updates! The CI seems to be complaining the black should be run, otherwise this LGTM 👍🏻

Thanks for the updates! The CI seems to be complaining the black should be run, otherwise this LGTM 👍🏻

should be good to go!

Pull Request Test Coverage Report for Build<PHONE_NUMBER>2
Details

13 of 13 (100.0%)  changed or added relevant lines in 4 files are covered.
11 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.008%) to 88.942%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/lex.rs
5
91.98%

crates/qasm2/src/parse.rs
6
97.62%

Totals

Change from base Build<PHONE_NUMBER>9:
-0.008%

Covered Lines:
79386

Relevant Lines:
89256

💛  - Coveralls


issue with units : addition and substraction

We can not add or subtract numbers with different units.
So 2 sec + 5 m should throw an error instead of returning 7 Kilometers

I am planning to add grace error and strict error modes , In grace error  mode only syntax error will be thrown . In strict error mode this kinda error will be considered
PRs are welcome for this issue


Enable statitcheck at build time.

Add staticcheck to the Makefile.
Fix staticcheck errors.
Ignore deprecated function in kubernetes API.

Closes: https://github.com/prometheus/prometheus/issues/3124

If you're concerned about the deprecation warnings, but don't want to use promhttp until 2.0, you can choose to specifically ignore those with a flag to staticcheck. It's not ideal but works.

@mdlayher Yes, I fixed up the -ignore option.

@SuperQ planning to merge?

Ahh, sure, just forgot to click the button.


fixed the bug in toast in save 1923

Fixes Issue
Closes #1923

Changes proposed

Screenshots

Checklist

[ ] You've linked this PR to the correct issue.
[ ] You have checked that the code is working correctly.
[ ] You ⭐ the repository!

Note to reviewers

@Spyware007


Provide checked operators on NativeAddress

See: https://learn.microsoft.com/es-es/dotnet/csharp/language-reference/proposals/csharp-11.0/checked-user-defined-operators
This is going to run into:

https://github.com/DotNetAnalyzers/StyleCopAnalyzers/issues/3478

Closing since we will be removing memory manipulation stuff from this library (see #85).


Fullscreen stacking mode

Thinking about looking into adding fullscreen stacking mode kinda like i3 for linux,
however I doubt it will be possible to show a list of all open windows in the way that i3 does.
From the users perspective, the feature would act as a tiling mode separate to binary space partitioning,
and so a space would then be able to have 3 states - bsp tiling, stacking, floating.
After you set the space to stacking mode, the (last) focused window will take up the entire screen,
and the user might navigate to the prev/next window using some command; hopefully the same
window -f prev|next that already exists.
Again, I have not yet been able to think of a way to display all windows available in the stacking space, to the user in a useful manner that complements this windowing-arrangement.
Is this something that people are interested in? If not, it will be dropped.

This would be cool to have, maybe in the bottom gap of the screen a terminal could be running or something that mimics i3 - this would be a bit of work, but it could just be a terminal running a small program. Then just updates the ui of the program to whichever window is on top

(bottom terminal is separate)

Stacking mode should now be in and seems to work.
There is as of right now no way to actually see what windows are in this space,
I guess using OSXs mission control would work, however it does not show the order
that that the windows will be navigated in.
To switch between windows, the kwmc command window -f prev|next can be used.

Stacking mode should now be in and seems to work.
There is as of right now no way to actually see what windows are in this space,
I guess using OSXs mission control would work, however it does not show the order
that that the windows will be navigated in.
To switch between windows, the kwmc command window -f prev|next can be used.

Thanks for this great feature! Instead of accessing bsp, monocle and float modes through three separate keybindings is it possible to bring all modes under one keybinding through toggling?


Add a -f command for xiwi to handle forking processes

xiwi -f should make xiwi show a dialog when all windows are gone asking to quit instead of actually quitting, and the dialog should auto-disappear when an additional window is created.
This means forking applications will never have the X11 server ripped out from under them, but well-behaved applications will close xiwi promptly.

Just pushed xiwif which does a naive implementation (you have to ctrl-c xiwi to quit if you specify -f).  This isn't really ideal, and won't work well if you launch it in the background.
Another possibility is having xiwi automatically quit if you close the xiwi window when there are no windows open inside.
A third option is having xiwi create a window that asks if you want to quit, whenever there are no other windows.
I think the second option is best (quit when the window is closed if there are no windows open)...thoughts?

OK, just pushed an implementation of the second option.  This behaves really well, as far as I can tell.

Question: Do we specify this new option as: sudo enter-chroot xiwi -f [gui-app] ?
I ask because I thought that enter-chroot might eat the '-f' opton - maybe not.
( I suppose I should try it first before I start asking unnecessary questions :)

enter-chroot stops parsing parameters once it hits a non-option parameter.  So sudo enter-chroot xiwi -f ... will work fine.

K, thankx again.
On Tue, Mar 31, 2015 at 2:07 PM, David Schneider<EMAIL_ADDRESS>wrote:

enter-chroot stops parsing parameters once it hits a non-option parameter.
So sudo enter-chroot xiwi -f ... will work fine.
—
Reply to this email directly or view it on GitHub
https://github.com/dnschneid/crouton/issues/1538#issuecomment-88192409.

--
DennyL@GMail


Replace uniqid with random_bytes

I've been working with a system made up of multiple PHP applications talking to a centralized API using WSSE authentication.  Under load a very small percentage of these internal API calls will fail with a "reused nonce" error, and the cause appears to be uniqid:
https://github.com/8p/guzzle-wsse-middleware/blob/3998dae6fed29f2d3384024764046b63a764ddda/src/EightPoints/Guzzle/WsseAuthMiddleware.php#L213-L216
uniqid(true) is basically just microtime() split and hex-encoded, with a prefix of 1 ((string)true).  So we suspect that this is caused by two API calls from different parts of the system executing at exactly the same time.
This PR swaps out sha512(uniqid) for random_bytes(128).

Thanks a lot, @adamlundrigan!
I will create a new version/tag soon.

Created new version: v4.3.0 (https://github.com/8p/guzzle-wsse-middleware/releases/tag/v4.3.0)


C4PlantUMLExporter mistakes container and component description for technologies when only description is present

Description
The official Structurizr DSL reference syntax for containers and components is:
container <name> [description] [technology] [tags]
component <name> [description] [technology] [tags]

Though to be more precise, that is slightly ambiguous, and most Structurizr tooling interpret it as:
container <name> [description [technology [tags]]]
component <name> [description [technology [tags]]]

Which is to say, tags is the most-optional, followed-by technology, then description.  This can be seen in ContainerParser::parse() and ComponentParser::parse().
However, when C4PlantUMLExporter::writeElement() generates C4-PlantUML Container(...) and Component(...) procedure calls, if technology is not set, then description ends up in the technology argument's positional, and this description gets rendered as a technology.
Steps to reproduce

Consider this example DSL:

workspace {
  model {
    enterprise "Demo" {
      demoSystem = softwaresystem "demoSystem" {
        demoContainer = container "demoContainer" "desc" "tech" "tags" {
          component "component1" "component1 description" "component1 technology" "component1 tag1,tsg2"
          component "component2" "component2 description" "component2 technology"
          component "component3" "component3 description"
          component "component4"
        }
      }
    }
  }
  views {
    component demoContainer {
      include *
    }
   }
}

Render that via Structurizr, and C4-PlantUML, eg via https://structurizr.com/dsl

Observe that only component3, and only in the C4-PlantUML rendering, the component3 description text appears where the technology text should. See screenshots in the next section.

Screenshot
Here's a sample show how it is correct for the Structurizr output, for all four components:

And here, you can see how for the C4-PlantUML output, component3's description appears in the technology position:

Code sample
See "Steps to reproduce" above.

Configuration
No response
Severity
Major
Priority
Low
Resolution
I'm willing to fix this myself and raise a PR
More information
Looking at the generated C4-PlantUML (for the above sample DSL), it includes:
Container_Boundary("demoSystem.demoContainer_boundary", "demoContainer", $tags="") {
  Component(demoSystem.demoContainer.component1, "component1", "component1 technology", "component1 description", $tags="")
  Component(demoSystem.demoContainer.component2, "component2", "component2 technology", "component2 description", $tags="")
  Component(demoSystem.demoContainer.component3, "component3", "component3 description", $tags="")
  Component(demoSystem.demoContainer.component4, "component4", "", $tags="")
}

You can see that for component3, then description has shifted into the technology position.
For convenience, here are links to the relevant current C4-PlantUML procedure definitions:

Container
ContainerDb
ContainerQueue
Component
ComponentDb
ComponentQueue

And here's the code in C4PlantUMLExporter.java that writes (sometimes incorrectly) those procedure calls (ie this is where I'd say the fixes should go):

C4PlantUMLExporter::writeElement() - Container[Db|Queue]
C4PlantUMLExporter::writeElement() - Component[Db|Queue]

Note, the components fix will likely conflict with my existing open PR #60, so I would strongly recommend merging that PR (assuming you're happy with it) before fixing this. Or branch off my PR.
I'd be happy to have a go at fixing this bug too. Just not sure when I'll have time to get to it.
Cheers!

Thanks ... given that the code in the exporter explicitly does something different for null/empty technologies, I'm guessing something has recently changed with PlantUML and/or C4-PlantUML to make this invalid ... especially since nobody has raised this before. I will merge your PR, then resolve this issue.


False-positives caused by newer versions of path dependencies of the scanned crate

Steps to reproduce the bug with the above code
When specifying a package by path dependency, cargo is only willing to use that package's own declared path dependencies and ignores newer SemVer-compatible dependency versions. It refuses to update to newer versions even if explicitly asked with cargo update or even cargo update --precise.
This causes false positives. For example:

tokio v1.40 made some types newly become UnwindSafe.
Auto-traits propagate automatically, making many of tokio-stream's types newly become UnwindSafe across a variety of tokio-stream versions when used with tokio v1.40.
SemVer checking an older version of tokio-stream now results in false positives:

The baseline is a registry version of tokio-stream, for which cargo resolves the tokio dependency to 1.40. That means the baseline's types are UnwindSafe.
The "current" (scan target) version of tokio-stream is a path dependency, for which cargo chooses the path dependency tokio version. That tokio is older than 1.40, so its types aren't UnwindSafe. As a result, the tokio-stream types aren't UnwindSafe either.
Since the older tokio-stream had``UnwindSafe` types, and the newer one did not, this is reported as a breaking change!
In #901 I was under the impression that cargo update inside the placeholder project we generate when creating rustdoc JSON for tokio-stream (where we have a path dependency to it) would result in newer tokio. This is not the case, due to the issue described at the top.

Repro:
git clone git@github.com:tokio-rs/tokio.git
cd tokio
git checkout d7b7c6131774ab631be6529fef3680abfeeb4781
cd ..

mkdir repro
cd repro
cat <<EOF >Cargo.toml
[package]
name = "rustdoc"
version = "0.0.0"
edition = "2021"
publish = false

[workspace]
members = []

[dependencies.tokio-stream]
path = "../tokio/tokio-stream"
features = ["default", "fs", "io-util", "net", "signal", "sync", "time", "tokio-util"]

[lib]
path = "lib.rs"
required-features = []
EOF

mkdir src
touch src/lib.rs

# To generate the lockfile and confirm the manifest is valid.
cargo check

# Note tokio v1.25.0 is selected. This is the version that
# the path dependency on tokio-stream pulls in.
cargo tree --invert --package tokio
# Outputs:
# tokio v1.25.0 (.../tokio/tokio)
# ├── tokio-stream v0.1.12 (.../tokio/tokio-stream)
# │   └── rustdoc v0.0.0 (.../tokio/target/semver-checks/local-tokio_stream-0_1_12)
# └── tokio-util v0.7.7 (.../tokio/tokio-util)
#     └── tokio-stream v0.1.12 (.../tokio/tokio-stream) (*)

# Observe a bunch of crates get updated.
# But tokio is not one of them, even though 1.40 is available!
cargo update

# Even explicitly attempting to update tokio fails!
cargo update --precise 1.40.0 tokio
# Outputs:
#     Updating crates.io index
#     Updating tokio v1.25.0 (/.../tokio/tokio) -> v1.25.0
# note: pass `--verbose` to see 21 unchanged dependencies behind latest

Actual Behaviour
Two items:
(1) There should be a way to run cargo update inside a project with a path dependency to force it to use latest SemVer-compatible versions of dependencies.
(2) cargo update --precise 1.40.0 tokio should either upgrade tokio to 1.40.0 as requested, or should exit with an error. It should not completely ignore the 1.40.0 argument and exit cleanly.
Expected Behaviour
(1) cargo update silently does not update versions of path dependencies of a path dependency. Instead, it pins the path dependencies and their path dependencies exactly. There does not appear to be a way to override this.
The first cargo update run after the setup above may update some non-path-related dependencies. Subsequent cargo update runs will look like this, and will not upgrade tokio to 1.40.0 nor mention it in any way.
$ cargo update
    Updating crates.io index
     Locking 0 packages to latest compatible versions
note: pass `--verbose` to see 21 unchanged dependencies behind latest

$ cargo update --verbose
    Updating crates.io index
     Locking 0 packages to latest compatible versions
   Unchanged mio v0.8.11 (latest: v1.0.2)
   Unchanged socket2 v0.4.10 (latest: v0.5.7)
   Unchanged wasi v0.11.0+wasi-snapshot-preview1 (latest: v0.13.2+wasi-0.2.1)
   Unchanged windows-sys v0.45.0 (latest: v0.59.0)
   Unchanged windows-sys v0.48.0 (latest: v0.59.0)
   Unchanged windows-targets v0.42.2 (latest: v0.52.6)
   Unchanged windows-targets v0.48.5 (latest: v0.52.6)
   Unchanged windows_aarch64_gnullvm v0.42.2 (latest: v0.52.6)
   Unchanged windows_aarch64_gnullvm v0.48.5 (latest: v0.52.6)
   Unchanged windows_aarch64_msvc v0.42.2 (latest: v0.52.6)
   Unchanged windows_aarch64_msvc v0.48.5 (latest: v0.52.6)
   Unchanged windows_i686_gnu v0.42.2 (latest: v0.52.6)
   Unchanged windows_i686_gnu v0.48.5 (latest: v0.52.6)
   Unchanged windows_i686_msvc v0.42.2 (latest: v0.52.6)
   Unchanged windows_i686_msvc v0.48.5 (latest: v0.52.6)
   Unchanged windows_x86_64_gnu v0.42.2 (latest: v0.52.6)
   Unchanged windows_x86_64_gnu v0.48.5 (latest: v0.52.6)
   Unchanged windows_x86_64_gnullvm v0.42.2 (latest: v0.52.6)
   Unchanged windows_x86_64_gnullvm v0.48.5 (latest: v0.52.6)
   Unchanged windows_x86_64_msvc v0.42.2 (latest: v0.52.6)
   Unchanged windows_x86_64_msvc v0.48.5 (latest: v0.52.6)

(2) cargo update --precise 1.40.0 tokio completely ignores the --precise 1.40.0 requirement, and exits cleanly as a no-op.
$ cargo update --precise 1.40.0 tokio
    Updating crates.io index
    Updating tokio v1.25.0 (/.../local_code/tokio/tokio) -> v1.25.0
note: pass `--verbose` to see 21 unchanged dependencies behind latest

Generated System Information
Software version
cargo-semver-checks 0.34.0
Operating system
Linux <IP_ADDRESS>-microsoft-standard-WSL2
Command-line
/.../.cargo/bin/cargo-semver-checks semver-checks --bugreport

cargo version
> cargo -V
cargo 1.80.1 (376290515 2024-07-16)

Compile time information

Profile: release
Target triple: x86_64-unknown-linux-gnu
Family: unix
OS: linux
Architecture: x86_64
Pointer width: 64
Endian: little
CPU features: fxsr,sse,sse2
Host: x86_64-unknown-linux-gnu

Build Configuration
No response
Additional Context
No response

The invocation of cargo-semver-checks that triggers the false-positives is this:
$ cargo semver-checks --manifest-path ../tokio/tokio-stream/Cargo.toml --release-type minor --exclude benches --exclude examples --exclude stress-test --exclude tests-build --exclude tests-integration
    Finished `release` profile [optimized] target(s) in 0.18s
     Running `target/release/cargo-semver-checks semver-checks --manifest-path ../tokio/tokio-stream/Cargo.toml --release-type minor --exclude benches --exclude examples --exclude stress-test --exclude tests-build --exclude tests-integration`
     Parsing tokio-stream v0.1.12 (current)
      Parsed [   0.869s] (current)
     Parsing tokio-stream v0.1.12 (baseline, cached)
      Parsed [   0.039s] (baseline)
    Checking tokio-stream v0.1.12 -> v0.1.12 (assume minor change)
     Checked [   0.014s] 80 checks: 79 pass, 1 fail, 0 warn, 7 skip

--- failure auto_trait_impl_removed: auto trait no longer implemented ---

Description:
A public type has stopped implementing one or more auto traits. This can break downstream code that depends on the traits being implemented.
        ref: https://doc.rust-lang.org/reference/special-types-and-traits.html#auto-traits
       impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.34.0/src/lints/auto_trait_impl_removed.ron

Failed in:
  type ReceiverStream is no longer UnwindSafe, in /.../tokio/tokio-stream/src/wrappers/mpsc_bounded.rs:11
  type ReceiverStream is no longer RefUnwindSafe, in /.../tokio/tokio-stream/src/wrappers/mpsc_bounded.rs:11
  type UnboundedReceiverStream is no longer UnwindSafe, in /.../tokio/tokio-stream/src/wrappers/mpsc_unbounded.rs:11
  type UnboundedReceiverStream is no longer RefUnwindSafe, in /.../tokio/tokio-stream/src/wrappers/mpsc_unbounded.rs:11

     Summary semver requires new major version: 1 major and 0 minor checks failed
    Finished [   0.966s] tokio-stream

cc @Darksonn on the off chance you notice this while working on tokio.
Scanning on new tokio versions should be fine, since the path dependency on tokio will point past 1.40.0. But re-scanning older commits can trigger this.
If you have opinions the cargo behavior, or ideas on how to get it to update transitive path dependencies to latest compatible versions, I'd love to hear them!

Interesting. Our CI job doesn't get any lock file as input, so I don't think we will hit this.
It sounds like the proper solution would be for tokio-util to use the local Tokio in both builds being compared?

I agree, I don't think you'll hit it either. Just wanted to preemptively warn you just in case, so you don't end up debugging a phantom breaking change.
Yes, we'll have to figure out a way to use the same version of tokio (and all other dependencies) on both sides of the comparison. Otherwise it's apples to oranges. I'm hoping we can somehow get cargo to use the version number from the transitive dependency, instead of the path component of the transitive path dependency. But I haven't figured out a way to do that yet.

Thanks for the heads up. I guess it could potentially affect our branches used for making backports to LTS releases.


Add support for request option generation and middleware configuration in ruby

After merging #330 ruby generation will generate inaccurate clients as it was built without the middleware options in mind.
TODO

[ ] add a request option interface in the abstractions
[ ] add a options collection, addrequestoptions and get requestptions on request info
[ ] update generation to add the options to the request in the request generator methods
[ ] update generation to pass the options from the request executor to the generator
[ ] add a middleware infrastructure and a way to get the defaults in the http library (depends on #419)
AB#10516

related #635

closing as duplicate of #1650


Index the blockchain events

We need to run a database (sql database?) and index all necessary events:

currency network events
exchange events
token events
(later) eth transfers for a list of users addresses. (list can be all known users at first draft).
maybe use sql alchemy similar to the exchange?

The database needs to be able to

run a full update from a contract events query.
run an incremental update if an event occurs.
(later) react to chain reorgs by removing deleted events.

Done, besides of the things marked as later, will open new issues for that when we need it.


Colab doesn't start - Encodec.cpp seems to lack CMakeLists.txt

Here's the error I get when I run the first cell of the colab:
/content/bark.cpp
/content/bark.cpp/build
-- The C compiler identification is GNU 11.4.0
-- The CXX compiler identification is GNU 11.4.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at CMakeLists.txt:21 (add_subdirectory):
  The source directory

    /content/bark.cpp/encodec.cpp

  does not contain a CMakeLists.txt file.

-- Configuring incomplete, errors occurred!
gmake: Makefile: No such file or directory
gmake: *** No rule to make target 'Makefile'.  Stop.

Yep same exact error!

looks like the git submodule was not initialized, either clone recursively or run git submodules update --init

Yeah that solved it, thanks!

Thanks for answering @Green-Sky . Closing this issue as this is solved. Feel free to re-open if you have another issue.


Add Minimum level to Cast Activity

Some features grant additional spells at varying levels, but the cast activity is all or nothing when it comes to granting spells. A Minimum Level option would allow some spells to be granted when the feature is gained, and others at the appropriate level.

Related I guess? #4518


Setting the time of the day/neutral time zone

Hey again :)
It would be nice to specify when on the day new selections are created. Eg., in the system I'm working on all users are expected to (at least currently) be located in the timezone "Europe/Copenhagen", which naturally means that this is what moment is set to. That is, GMT+2. However our server side considers GMT as the neutral time zone, which means that all dates that is sent to the server ends up being the day before the one actually selected.
Thing is the fields are stored in the database using a date, so let us say that I create a date the 22. June 2016, then it will send 2016-06-22T00:00:00+02:00 to the server, which then transforms it to 2016-06-21T22:00:00+00:00 and stores it in the database as a date that is 2016-06-22T00:00:00+02:00. Next time the data is loaded the response I get is 2016-06-21T00:00:00+00:00, which fortunately stays consistent from that time on (as long as I don't mess with other time zones :p )
Currently I post-parse all the fields ensuring a consistent time, but it would be nice to have the option to specify the desired time of the day, or perhaps even better a neutral time zone, to overcome this issue.

I think you'll have to keep post parsing dates, I don't want to add too much dependencies to the date-picker, it's pretty simple to do it with MomentTimeZone
Moment is giving you an Iso8601 date, so you have everything you need to work with it server-side. If there is a timezone in it (+02:00), your client, server and DB should deal with it easily.


Store data in a different way, compatible with transcluded parent directives

@amcdnl this works for getting the columns through transclusion, and can be tested in demos/transclude.html.  Still working on getting access to the parent scope data, that seems not to work just yet.

@amcdnl ready to rock now, fixed the issue mentioned in the comment above. :ship:

I'd prefer to convert the elms to a object before storing. Also, it would be faster to store in a service than attaching to the data of the elm.

Converting to an object is fine, I think.  But storing them in a service?  They need to be stored in your template: function block and it's not possible to access or inject services at that phase - it's before hte $digest cycle starts.  Maybe I'm missing something, but I'll need you to give more detail about the approach you're envisioning.

Also noting that this fixes #43.

Storing templates as strings now, rather than storing the whole DOM node.  No clue how you would use a service to do this, so waiting to hear your rationale behind that.

@amcdnl This I pushed a new commit that replicates the brokenness I'm experiencing in my project.  I have 2 scopes, the main one declared at the ui-router route definition which has logic relevant to that route (e.g. <outer-wrap> in my transclude.html). And then a <main-wrap> directive which holds general ui logic for main navigation, etc. (e.g. <inner-wrap> in my transclude.html demo). The artificial "$scope" creation by iterating over the $scope.$parent's enumerable properties and binding them to the directive's this.options.$outer in DataTableController and then exposing them to the <column> templates via in CellDirective.js via:
cellScope = $rootScope.$new(true);
            angular.forEach(ctrl.options.$outer, function(v,k) {
              if(k[0] !== '$'){
                cellScope[k] = v;
              }
            });

Is painful and I'm not sure if it can work with nested $scopes.  Artificial extending of $scope is just asking for trouble in my opinion and needs to be done away with entirely.

I'm not 100% sure on this, but basically, the way I understand it works is that controllerAsParent.method() traverses recursively up $scope.$parent's looking for the method.  If I try to whitelist that property with something like if(k[0] !== '$' || k === '$parent' ){it's a stack overflow. Thoughts on how it could be wired up to work properly?

Please review my latest commits and see if this fixes your problem ( besides the transclude item )

I think we have this working now! :)

Yup! :+1: :100:


allow tizen apps with space in the name

Description
When using an appName with spaces for Tizen (TV), the install command no longer worked because the file could not be found.
This PR made a simple rename of the .wgt file.
I have tested my changes on:
ReNative project directly:

[ ] ios simulator
[ ] ios device
[ ] android simulator
[ ] android device
[ ] web browser
[ ] web -e next browser
[ ] tvos simulator
[ ] tvos device
[ ] androidtv simulator
[ ] androidtv device
[ ] androidwear simulator
[ ] androidwear device
[ ] tizen simulator
[x] tizen emulator
[ ] tizen device
[ ] tizenmobile simulator
[ ] tizenwatch device
[ ] webos simulator
[ ] webos device
[ ] macos
[ ] windows
[ ] chromecast device

@pavjacko
From travis CI:
  Running:  test.spec.js                                                                    (1 of 1)
/proc/self/exe: /lib/x86_64-linux-gnu/libdbus-1.so.3: no version information available (required by /proc/self/exe)
  Change Background
    1) "before each" hook for "cy.go() - go back or forward in the browser's history"
  0 passing (1s)
  1 failing
  1) Change Background
       "before each" hook for "cy.go() - go back or forward in the browser's history":
     CypressError: `cy.visit()` failed trying to load:

I am not sure if that relates to my changes... The other PR has the same problem

@EyMaddis doesn't look related. I'm checking the root cause as it passes locally. once determined will look at merging it


encoding/json: invalid use of ,string struct tag, trying to unmarshal "" into int

What version of Go are you using (go version)?

$ go version
latest (playground)

Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
playground

What did you do?
Unmarshal  json (https://play.golang.org/p/Ka8kdddUHKu):
s := struct{
	Val int `json:",string,omitempty"`
}{}

println(json.Unmarshal([]byte(`{"val":""}`), &s))

What did you expect to see?
Since val is "", the error as such  is expected, however I  would expect the omitempty to make a  difference and hence return nil error. According to https://golang.org/pkg/encoding/json/:

The "omitempty" option specifies that the field should be omitted from the encoding if the field has an empty value, defined as false, 0, a nil pointer, a nil interface value, and any empty array, slice, map, or string.

What did you see instead?
Error: invalid use of ,string struct tag, trying to unmarshal "" into int
Reasoning
To give flexibility in handling external json input it is preferable to  handle the omitempty tag before handling further validations like string. In this case the order seems to be different.
If effect, ,string,omitempty should allow "" to be unmarshaled into numeric zero values.
UPDATE I realize this might indeed be more a proposal as omitempty  seems to be documented and take effect only for marshaling but not unmarshaling.

@andig if you’d like this to be a proposal, could you update the first comment and subject accordingly? See https://golang.org/s/proposal for more info. Thanks!

Closing this one. I feel the scope I'm asking about is much too narrow for a proper proposal. A proposal if any should consider a wider range of encoding (and potentially decoding) issues.


Quicksight url pattern matching modified

Fixes https://github.com/spulec/moto/issues/5183

[a-zA-Z0-9._-]+ for namespaces according to aws docs
[^/]+ - for username and groups. Unfortunately. I was not able to add handling for /. Url resolver acts weird. Omitting / makes the solution more stable.

Codecov Report

Merging #5186 (10de78f) into master (34a98d2) will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #5186      +/-   ##
==========================================
- Coverage   95.90%   95.89%   -0.02%
==========================================
  Files         682      682
  Lines       67730    67731       +1
==========================================
- Hits        64958    64950       -8
- Misses       2772     2781       +9

Flag
Coverage Δ

servertests
36.84% <ø> (-0.01%)
:arrow_down:

unittests
95.84% <ø> (-0.01%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

moto/quicksight/urls.py
100.00% <ø> (ø)

moto/resourcegroupstaggingapi/models.py
83.18% <0.00%> (-0.59%)
:arrow_down:

moto/route53/responses.py
96.69% <0.00%> (-0.42%)
:arrow_down:

moto/sns/models.py
96.83% <0.00%> (-0.40%)
:arrow_down:

moto/efs/models.py
91.20% <0.00%> (-0.30%)
:arrow_down:

moto/sqs/models.py
96.76% <0.00%> (-0.18%)
:arrow_down:

moto/config/models.py
99.22% <0.00%> (-0.13%)
:arrow_down:

moto/ssm/models.py
94.53% <0.00%> (-0.11%)
:arrow_down:

moto/s3/models.py
95.57% <0.00%> (+<0.01%)
:arrow_up:

Continue to review full report at Codecov.

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


use const for variables that are never modified

Hello!
I am learning Zig via these Ziglings so apologies is this is a bad call.
I noticed a few places where var is used for variables that are only assigned to once, so thought it would be better to use const in those cases.
I'm slowly running through the exercises so will update this PR as I find them until there's response 🙂

I've finished the ziglings. They were great fun, thanks for the entertaining introduction to the language! This is all the vars I found that could be consts, but I'm sure there are others.

@adamu Yeah, good idea. Thanks for this!


age +/- [0.5, 5)

...moving from +/- [0.5, 1.5) to an upper bound of 5y

...this change is not actually needed


in java

https://github.com/Shamao/Beauty/blob/master/gank/src/main/java/com/louise/gank/view/DiagonalDrawable.java
   DiagonalDrawable.Builder builder = new DiagonalDrawable.Builder()
                .setStartColor(Color.parseColor("#E52878"))
                .setEndColor(Color.parseColor("#EE2A7B"))
                .setReverseLayout(true);
   DiagonalDrawable drawable = builder.build();

Sorry?

sorry. forgive my poor English. I achieve the effect in java code. is it useful for your project？


Number Not Found using Purchase method

$availableNumbers = Nexmo::numbers()->searchAvailable('US'); returns available numbers, but when I pass one of the returned numbers to purchase(), like this, Nexmo::numbers()->purchase(12148567978);, I receive Nexmo \ Client \ Exception \ Request (404) number not found. Am I missing something or doing something wrong?

Consequently, Nexmo::numbers()->cancel(11234567890) works just fine. I just cancelled my own number ...

@randyrankin I've just reproduced this issue. It looks as though there's an issue with purchasing numbers when providing a string.
I'll get this fixed, but in the mean time you can purchase a number by passing a Number object rather than a string. Here's an example that works for me:
$numbers = $client->numbers()->searchAvailable('US');
$client->numbers()->purchase($numbers[0]);

@mheap Thank you. Passing an array works fine and I will watch the repo for updates. In the meantime, is purchasing a Toll-Free number possible? I do not see type as an optional parameter in searchAvailable().

Hey @randyrankin,
I'm not familiar with Toll-Free numbers and couldn't see anything in the documentation about them - https://developer.nexmo.com/api/developer/numbers#buy-a-number
Do you have a link to more information that I could read?

Well, yes and no. I can purchase toll-free numbers in my Nexmo dashboard, but there is no reference to them in the AP docs. Am I correct in assuming then that this is not possible? I was sure hoping to offer toll free numbers to my customers.

@randyrankin Sorry for the delay, it took a bit of searching to find the correct endpoints.
I've just tagged version 1.3.1 which allows you to set the number type
$available = $client->numbers()->searchAvailable('US', ['type' => 'landline-toll-free']);

plz help
when i purchasing a number in nexmo then i got an error "authentication failed"
My code:
numbers()->searchAvailable('US');
        try
        {
         $prch = $client->numbers()->purchase($nums[0], 'US');
        } catch (\Exception $e) {
          return $e;
        }

    }


Maintenance – Community

Hey @mariusandra
I'm not sure who's having push permission to this repo, but I see that there are a couple pull requests hanging and there is a community effort to bring the component forward. It's hard to keep the community together if everyone is working in its own repo but don't push upstream again because people see no activity in the repo anymore.
Therefore my request; I completely know it's a hassle to keep maintaining a project if day-jobs and stuff are eating your time. But could you please give someone else (or a few) push access so we could also keep the momentum without bothering you? It's always good if the "original" is the pot to bring all the commits back together. I know technically every fork could also do that but people usually find only the "original". What do you think?
Personally I use the component in a payed job and I work every few days on that project. I would be willing to invest a bit work in helping (with others) to maintain this repo during 2017. @meengit works with me and we worked on the multiple selection together (https://github.com/namespace-ee/react-calendar-timeline/pull/71) we also have 1-2 other changes we could commit later that year. We are building a copy past function in our software to duplicate multiple items.

@signalwerk  -  you're absolutely right, our company (and I'm sure others) have ended up forking the project due to lack of activity.  Several critical issues (eg #76, #64) have fixes in PRs but they have not been merged, not to mention all the great features that other have added.
I would also be available to help maintain this project, it is a critical piece of our application and we want to see it continue to improve!

Hello! Sorry about this delay. Yes this is a critical part of our application also. We will be reviewing the pull requests and answering questions latest:  1st of July. Hopefully even next week.
And of course we can discuss somebody coming on board also to have push/commit permissions to this library so we can build it faster. I will discuss this today and get back to you beginning of next week.

@schwermer @signalwerk I have talked with Marius and have decided that we will add Stefan as a contributor to this project so he will also have the push and commit access to maintain and release new versions. As he took initiative in this and I think would be a step in the right direction and building a community.
Ourselves we also use this component as a very important part of our projects. We will be putting in new effort towards react-calendar-timeline in the upcoming weeks but I understand that this is too long of a delay.
So Stefan let me know if you have any questions. Otherwise great to have somebody on board with us and maybe we can discuss future goals of react-calender-timeline together at some point and set a roadmap where we would like it to go in the future.

  Sorry guys. I'm next week back in the office and plan time to review a couple PRs. I think for the first release after some month I would plan a new branch for version 0.12.0 before that goes to master
@schwermer I would love to see you in the loop and help to bring this repo back to a state where you could also take the original fork again.
we didn't have an update during the last 5 months so give me/us a bit time for the work. thx

Hi guys, joining the discussion as we have picked the timeline in our app and would like to contribute some improvements - this is more of a heads up at this point because they are not quite ready for a pull request but I was glad to see some activity on the project!  Thank you!

How is the state? There is still some critical PRs open and I'd love to see them merged :)

@bkniffler I'm right now a bit in a hurry with other stuff but I'm work on it. I took one of the worst bugs first (#76 fixed by @schwermer) and made now my first new release. Version 0.11.2 lives right now in https://github.com/signalwerk/react-calendar-timeline/tree/hotfix/group-ordering
since it's my first release I would like to get first an OK of @madisvain or @schwermer before I merge it to master. I try to do it right rather than to do it quick. I also started to introduce a test-framework (jest & enzyme) to have the bug covered by a test. I'll not write for each PR a test but if we start to try to write tests when we write stuff we will probably end in a better code quality.

@madisvain to do my first release I also need permission for npm (https://docs.npmjs.com/cli/owner) could you please add me? signalwerk is also my name on npm

@signalwerk Added!

@signalwerk congrats for the first release! I'll close this issue for now. We'll also be helping you out more regarding this and getting the development on track. Please don't hesitate to ask for our help in some of these issues and we'll be putting effort into this library also in the upcoming months to bring it further.

@madisvain thanks a lot!
maybe you noticed that I made a little mistake. version 0.11.2 was never published on npm so it's 0.11.3 now. too avoid that in the future and to do the release task automatically I would like to setup a travis-ci deploy task. so my final request regarding user rights:
could you please add a deploy key for me to the repo? with a deploy key travis-ci is able to push the tags, npm and other stuff... it's not my personal ssh-key it's a fresh key and is never used before. the idea is that only travis-ci will use it and it then only has access to that repo. you can find the instruction how to add it to the repo her: https://developer.github.com/guides/managing-deploy-keys/#deploy-keys
should take you 2 min to do it.
here is the public key for travis:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC84CcWY7qDC74g/cZDuo513axKlFX0IPchVjcXTA9vlZpGLF9/cseTQxtBFqeMH8Axxr2pec/upegylRQ/ZzQvL1wBmpe3Z0ez7A38OKUXouN87BCRy7COp6WxDEoocQpQbcWC+/VGE2ci4gEttaqSkR3m63fcrwBtPIKv0bxc3MaqZ5jZdOhoEwUMWzZ8pdVmlEy7bZu7+l48yOhNHrKkedp1wTZA0dhuoATacaC0ctWOCM5eZ6e5/Ty0NRBgb4Xg+HhX81EjXRY4S901o5XgUXhR7m2nXSCXY4k3a/w6fI/ckxG9IjNwwwEDLmkZIcAnqTHJ6zqt+UhOnuTAP0cFtNwJaH+0L0GYEGSRNwitMrdqYZA+FAKn6zdvxMo3vcNHc9NQ06/XF6cNITDj/vzSNYxtNYTiS5yhef8Po3vI3KyidEc8mBYOn3dYQYC8qm6obkM3VpXNgAFcebyBUuUQLyw0zfqZu3PlvTyviobGRssJpMyvQ4+cotD3E1KaADeI5vd9i8Ks4x6LzxlbtfkyTO0KHN3w7G6nZTRE4OgY9CjQQLDi3nje1GzzqA1lS65aRhM89FMwSjQmoaTKAoiKl/HjcfW7vRVoSDnhM8SjOjxLMepizSeHPDNR32xgsQ8LGd7vPlWUjv6u/L2E6Eae2VF3WixER7+GGWNVxPfHWw==<EMAIL_ADDRESS>
With that I could also automate the gh-page so that the demo page of the component could be hosted on github and you don't need to host it on your personal server anymore.

@signalwerk Public repos should not need a deploy key in Travis, there is no such section even in the public travis settings area.
I just enabled this repo on travis, check it out here: https://travis-ci.org/namespace-ee/react-calendar-timeline

Do you guys need help in setting some of this up?  Would love to see more updates on this repo, we are running a custom version of the timeline in our app - it has proven super useful and I'd love to give something back :)
This is something we did with custom renderers:

Hei guys! So we have still not been able to get started from our side. I think we need to expand the community a bit for this library to move forward.
@signalwerk what are your plans currently and also @schwermer @nicocrm what do you propose how shall we continue? We are open to expanding the community but I think if its going to be more people we should somehow start discussing the features that make it into the project and also the main goals of this library.

Thanks Madis, I picked the library in part because it is relatively lightweight compared to some of the options out there and I think it would be great to keep it that way, but add some extension points so that users can further configure it to fit their needs (and also of course, include the PR that bring bug fixes and improve the documentation).  Thank you for your work on this!

Hey everyone!
I discussed with @madisvain and we agreed to work on this project again for the foreseeable future, contributing a few hours each week.
I started today with some PRs and cleaning up the package structure, package.json, build scripts, etc.
Some of the bigger changes so far:

Merged two simple PRs (#96 and #101)
Fixed travis - now tests work
Removed the UMD builds (/build/dist folder). Please let me know if anyone was still using them. I don't think they should be in git anyway.
Removed the "modules" folder from git (now just "src" is here) and added a "prepublish" script that automatically builds the library before pushing. Now the publishing process is just "npm version minor/patch; npm publish" (and git push)
Replaced the old demo with a new webkit-based one (/demo/demo.js). I still need @madisvain to change the github page from the gh-pages branch to the /docs folder, into which the demo is now build
Released v0.12.0 with the two merged PRs and the new project structure to make sure everything works as intended. It seems to have worked.

I will be around in the next days responding to issues, cleaning up PRs and maintaining as well as I can, at least a few hours each week. So expect more updates to come! That's it for today.

@madisvain @mariusandra Thank you guys for your constant efforts to bring the project forward. I couldn't spend too much time the last couple weeks here but I try to get back to it.
@mariusandra your suggestions sounds really good! The Travis CI integration I suggested a couple days ago was intended to publish automatically to the 'gh-pages' branch from within Travis-CI. But for that Travis needs access. I did it with an encrypted deploy key. Here you see how I set it up for an other project of mine: https://github.com/signalwerk/colorlab/blob/master/deploy_doc.sh

@signalwerk That's cool! I'll try to get that working at some point. It's indeed better to do this than to pollute the repository with big .js bundles. Thanks! :)

@mariusandra it's pretty simple if you have a key set in github. I can do it (then I need the public ssh in the github) or if you like to do it yourself just hit me if you need help.

I released 0.13.0 with most of the PRs. I also added the deploy script, so as soon as @madisvain approves the ssh key, it'll be set to auto deploy.
Thank you everyone for your contributions! @goooseman @nicocrm @meikoudras @meengit @jmerriweather @signalwerk @bkniffler
(I really hope I didn't miss anyone... :))
The updated demo is here: http://namespace.ee/react-calendar-timeline/
In the next days I'll investigate the remaining PRs and issues... and then spend some effort on making the timeline faster/smoother as well.

Hey, I'm closing this issue. It seems we have a decent workflow regarding the maintenance of this component now. 😄
Cheers and thanks everyone! 👍


[Gamification] Add user level & points calculation logic

Calculates user's accumulated "points" and their level.
Fix #74

Coverage increased (+0.7%) to 89.234% when pulling ee2e8d32aa00e679a880d9f3202a451df97d0d43 on 74-level into 2af6dc451adc6c900874c1a2f069a2b9f55e1b15 on master.


BUG: Fix division by zero in trust-region optimization methods

Check convergence condition before starting iteration. Solves problem
with division by zero if we have a Jacobian with zero magnitude.
Add corresponding tests.
Fixes #8686.
Work done together @panvaf @lizweer @mezdahun

thanks, lgtm


HELP WANTED: ES6 Conversion Effort

Hello pixi devs!
Thanks to this PR #2936 (shoutout to @leonardo-silva!) we have begun an effort to convert the code-base of Pixi.js to ES6. The purpose of this upgrade is to future-proof as well as make Pixi.js more maintainable.  While the source will be ES6, we will continue to build to ES5-compatible JavaScript using Babel. But hopefully in the future we'll be able to provide an ES6+ build.
Usually these types of changes are very challenging and difficult to pull off because of how distruptive they are to existing PRs and development, so ideally we'd like to get to stability as quickly as possible. So, we need your help!
There are a couple things that would be really useful if you're looking to help:

We have setup a dev-es6 branch and welcome PRs to that branch for those proficient with ES6. Particularly, looking for additional PRs to add more use of const, fat arrows functions, and static getters.
We need help performance testing the Babel build to make sure we have not compromised any of the amazing Pixi-speed we have all come to love.
We could use help smoke-testing the latest build on this branch (see below for build links). Please add this to your v4 projects and post if you find any issues.
We could use help smoke-testing the documentation to make sure jsdoc still plays well with ES6 (see link below)

ES6 Builds
http://s3-eu-west-1.amazonaws.com/pixi.js/dev-es6/pixi.js
http://s3-eu-west-1.amazonaws.com/pixi.js/dev-es6/pixi.min.js
Documentation
http://s3-eu-west-1.amazonaws.com/pixi.js/dev-es6/docs/index.html

Which route do you want to go down with let and const? Default to const, and only use let for properties that should have their reference changed
Or
Default to let, and only use const as more of a hint to the developer that they, I'm serious, don't change this.

The former option. Default to using const. I converted all internal vars to let and fixed obvious scoping issues and disallowed the use of var with jshint. Needs another pass with const.

Things I would recommend:
[ ] Use babel-preset-es2015-loose, I had poor perf with just babel-preset-es2015 alone.
[ ] Switch to eslint, it has better ES6 support and is just better than jshint in general. Here is a good starting point for pixi's style.
[ ] Use the latest master of jsdoc, it has a lot of ES6 fixes in there.
[ ] Switch to webpack. More and more of our users are using this, and I think it fits our use-case better.

Thanks @englercj. Good list.

@englercj The babel-preset-es2015-loose has a deprecation warning, did you try babel-preset-es2015 with the option {"loose": true} like it suggests?
I also prefer webpack to browserify, a couple of useful links:
https://github.com/webpack/webpack/tree/master/examples/multi-part-library
http://krasimirtsonev.com/blog/article/javascript-library-starter-using-webpack-es6

My preferences is to wait on webpack and not pile that on. Potentially for another smaller PR. That change represents a build process change but not necessarily improvement to ES6. Also, would need to make sure sourcemaps, headers etc. work. I understand how it's better but let's wait for that for now.

The babel-preset-es2015-loose has a deprecation warning, did you try babel-preset-es2015 with the option {"loose": true} like it suggests?

Ha, that was just added 2 weeks ago. I haven't tried that because it didn't exist at the time I started using it.

Hi everyone,
Just a quick shout to echo Chad's thought about the loose mode, and add my two cents here.
As we discussed with @GoodBoyDigital before we have to be really careful about performance, so I think the loose mode is a good starting point.
Also, I'm not sure how up-to-date this table is : https://kpdecker.github.io/six-speed/  do you guys know?
If it still is then we have to be careful not to go ES2015 madness and convert things that don't need to be, i.e: if for-of still brings down the performance as it says on the table, we shouldn't use it when iterating scene graph children.

Babel should now optimize for-of for arrays (see: Optimization), those tests seem to be quite old.
Anyway, @alvinsight you're right, everything doesn't need to be ES2015.

Good list @englercj !
Also agreed with @alvinsight. We are already seeing much cleaner code with es6 syntax so winning all round :)
Every other decision  should be based on perf - 'Does it look better but run slower - don't do it'
Array looping is a good example - there's no need to replace stuff that is a fast and readable already just because we can.
Also yes to webpack! @bigtimebuddy is correct, that should be part two of this shift to es6.

Agreed!
It's so much nicer to finally be able to write extends Container !

Updated

Replaced jshint with eslint (and fixed linting errors, eslint for the win!)
Using loose: true with babel-preset-es2015

Evening all!
Hit a little shnag with our mixins..
Object.assign(
    core.DisplayObject.prototype,
    require('./interactiveTarget')
);

The above not currently working on in the ES6 branch so things like interaction are busted.
Is there a nice way to do this with es6 classes?
Answers on a postcard please!

Scratch that - I don't know what I'm talking about.. That part works fine :P

Ok I was right the first time - the above code is not working currently.. (Can I blame this on the fact its Friday night?)

I guess this is where composition shines!

Hmm, what isn't working? This worked for me:
class MyThing {}
Object.assign(MyThing.prototype, { newFn: function () { console.log('mix'); } });
var mything = new MyThing();
mything.newFn(); // logs: "mix"

Interesting! Currently interaction is not working and interactive properties seem to be missing. Maybe another reason? Will keep digging...

Ah ha! Found it
Object.assign(
    core.DisplayObject.prototype,
    require('./interactiveTarget') <--- this is a require!
);

import interactiveTarget from './interactiveTarget';

Object.assign(
    core.DisplayObject.prototype,
    interactiveTarget
);

??

yup!

PR 1 here: https://github.com/pixijs/pixi.js/pull/2960
It fixes a few bits like the mixins and text.
Tomorrow I will look at filters...
Looking really good though chaps!

Good work! Yah, using require() like that would return an object with a single default key containing everything else you expected.

Filters looking good now! Ran this on a current project I'm working on that's pretty complex - and everything seems to work 100%!
Might test it out on a few other games but should be good to merge pretty soon!
@bigtimebuddy have you tried this build with pixi-animate?

Throwing this out there.. traceur seems faster than babel?
Worth investigating?
https://kpdecker.github.io/six-speed/

Those tests are old, and not run with babel loose.

I'll suggest to you guys to consider using TypeScript as part of this major rewrite/adaptation. Just some points about TypeScript:

Using type system in JavaScript will become the new standard, it's just a matter of time.
It IS JavaScript. No difference in syntax besides the type system.
Improves code quality. You'll possibly find a considerable amount of code that needs to be slightly restructured to match the types in the right places.
Increase pull-request quality check - if there's some type issue, the patch simply cannot be merged.

I know this is not an easy chore, but I believe it can bring major benefits for the code base and the community.
Cheers!

@endel I'm moving pixi-spine to typescript, there will be demos of TS plugins for pixi.

@endel just curious, but has TS resolved the issue it had when I last looked at it: that it's an all or nothing situation when it comes to the output, i.e. everything is transpiled back to ES5, or nothing is, based on the target?
I remember it didn't use polyfills at all. So if you want a single code-base to run on a wide range of browsers, from cutting edge down to legacy, you still have to target ES5, and all of the nice new features, that modern browsers now support natively, get ignored because it downgrades to ES5 anyway? Or is it still the case where you need to use an ES6 polyfill on-top of TS output to cover all bases?

that it's an all or nothing situation when it comes to the output, i.e. everything is transpiled back to ES5, or nothing is, based on the target?

Not sure what you mean by this. If you target ES5, it transpiles the syntax to ES5. But so does babel, tracuer, et al. Is there something specific you are referring to?

I remember it didn't use polyfills at all.

It does not, but again neither does babel, tracuer or other transpilers; so I'm not sure what you are driving at? We would have to use core-js polyfills either way (babel or TS).

@photonstorm With TypeScript, to the best of my knowledge, you cannot pick and choose features to transpile to ES5 like you can with Babel.
I use TypeScript and think it's awesome. Would love to see Pixi adopt eventually. Google is now encouraging developers to use TypeScript with Angular, which is a good sign of wide-spread adoption. For a codebase as complex was Pixi, would be well served by strict-typings.
Some issues that would need to be addressed with TypeScript would include jsdocs (anyone have experience with this?) and upstream-dependencies who might be using the src when require('pixi.js') (is anyone requiring like this?).
As a first step, moving to ES6 is still a good option, since we'll need to convert to classes anyways. We could consider TypeScript another "pass" on modernizing the codebase one we're certain all concerns can be addressed.

With TypeScript, to the best of my knowledge, you cannot pick and choose features to transpile to ES5 like you can with Babel.

I had no idea you could do that. I'm not sure I see the benefit of it for us since we have to target ES5 anyway. But that is neat!

Some issues that would need to be addressed with TypeScript would include jsdocs

https://github.com/TypeStrong/typedoc

upstream-dependencies who might be using the src when require('pixi.js') (is anyone requiring like this?).

We can point "main" to anything we want, and with typescript you point it to the built files (not the bundle). For example, TS files go into src/ and you transpile each file to js/ or something, then point main there.

As a first step, moving to ES6 is still a good option, since we'll need to convert to classes anyways. We could consider TypeScript another "pass" on modernizing the codebase once we're certain all concerns can be addressed.

👍

With TypeScript, to the best of my knowledge, you cannot pick and choose features to transpile to ES5 like you can with Babel.

They added this feature on TypeScript 2.0: https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript#including-built-in-type-declarations-with---lib
It's usual to use ES5 as a target but include ES6 as libraries, to have the type definitions for things like Symbol, Map, etc.
Indeed, as @englercj said, you need to include shims after your code is compiled no matter which compiler you're using. Babel doesn't include a Symbol polyfill for IE9 automatically, for example.

I had no idea you could do that with babel. I'm not sure I see the benefit of it for us since we have to target ES5 anyway. But that is neat!

For Pixi, not that useful, but yes, you can cherry pick Babel presets to select only certain features to transpile. This can be useful if you want to build to ES6 but only want to support bleeding-edge V8 features in Node 6, Electron 1, etc.

It's an interesting paradox really. Use ES6 to build with, because it's clean, and lovely, and very well supported / internally optimised by modern browsers. Yet have all that hard work destroyed by transpiling like it's 1995 :) (and with language syntax changes you can't shim around this).
I appreciate the problem is universal, nothing to do with TS or Pixi. Just a bit of a weird situation to be in.

@photonstorm It is an unfortunate irony 😞 hopefully we can have ES6 and ES5 builds so that for packaged apps (like electron) they can use the ES6 build.

Just jumping in to the discussion here :) I've seen people transpile TS to ES6 then use Babel to transpile it to ES5, i guess if you'd want something like certain features transpiled that would be quite nice?
Also, there is (yet another...) module bundler around, however i think this one seems to produce some pretty slick code, with the possibility of multiple outputs.
http://rollupjs.org/ it bundles from ES6/ES2015 module syntax, which i guess is pretty nice if you want to future proof the code.
i'm +1 for PIXI being written in Typescript. From my experience, type really does help a lot with the structure for projects like this. If only it can be kept performant :)

RollUp is fantastic, I love using it. Its tree shaking is seriously smart. Used with bubel (instead of babel) it makes for a really, really fast workflow.
Interesting to see so much TS love here. Certainly wasn't the case a year ago :) There are ways to type check ES2015 which may be worth considering.

@photonstorm didnt find bubel, but there's "buble"

Yeah yeah, typo. http://buble.surge.sh/
BubleTape is a nice test harness for it https://github.com/snuggs/buble-tape

Is #2936 the reason why Members dropped off the docs?  This has one exposed member, where this has 25+.
Does @memberof need to be added to them now, or is there some magic that can be applied?

@staff0rd I think we are still cleaning things up, once it stabilizes a bit we will look into cleaning up the docs. Most likely it is just because the jsdoc version we are using has ES6 bugs. We should be able to get to cleaning this up soon.

ES6 has been merged to dev, thanks everyone who helped out. It is much appreciated!
Closing this for now.


[Core] The episode/experiment "done" flag is not set

When an agent reaches an opponent base, the episode should conclude and "done" parameter should be set to true

https://github.com/lab-v2/pyreason-gym/blob/fb540328dce5f9bba0a9288126ad1ff3d31f36ab/tests/base_done_check/test.py#L22

@devrz45 This can be done by modifying the is_done() function here
Use the self.base_positions variable as well as the observations for the agent's position to find the done signal


A11y_SQLAzureDataStudio_SQLServerBigDataCluster_ConfigurationProfile_Screenreader: Repeatative announcement of radiobutton while navigating to each cell of the table while using NVDA

“Check out Accessibility Insights! - Identify accessibility bugs before check-in and make bug fixing faster and easier.”
GitHubTags:#A11yMAS;#A11yTCS;#SQL Azure Data Studio;#DesktopWeb;#Win32;#MAS1.3.1;#Benchmark;#A11y_SQLAzureDataStudioBenchmark;#A11ySev2;#NVDA;
Environment Details:
Version: 1.16.0-insider
Commit: 506c6a5
Date: 2020-02-17T05:43:18.399Z
VS Code: 1.42.0
Electron: 7.1.11
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Windows_NT x64 10.0.18363
Additional Details:
MAS References: MAS1.3.1
NVDA Version: 2019.2
Repro Steps:

Launch Azure Data Studio.
Select the Connections icon (if not already selected) from left bar.
Click on the ellipses '...' and select "New Deployment".
Select "SQL Server Big Data Cluster" card under deployment options.
Select the version & checkbox.
Navigate till Selet button & hit enter.
Launch NVDA screenereader
Navigate to table present under radiobutton using down arrow key

Actual:
While NVDA is on and navigated to tables of radiobutton using down arrow key, screenreader repeatatively announce radiobutton with checked/ uncheched status while navigating to each cell of the table
Expected:
While NVDA is on and navigated to tables of radiobutton using down arrow key, screenreader repeatatively should not announce radiobutton + it's checked/ uncheched status while navigating to each cell of the table
User Impact:
Screenreader users will face difficulty as repeatative radiobutton announcement is done by screenreader.
Attachment link reference:
9342_A11y_SQLAzureDataStudio_SQLServerBigDataCluster_ConfigurationProfile_Screenreader.zip

@alanrenmsft Could you please the reopened the bug as it should be verified the Trusted Tested.
Please provide the latest environment details where we can verify this and take action accordingly.
GithubTags:#Regressed:06-02-23;

As "SQL Server Big Data Cluster" has been removed.
GithubTags:#Closed;

GitHubTags:#SQLADS-Win32-Feb2020;


view spec: controller.extra_params cannot be used to set extra params for URL generation

What Ruby, Rails and RSpec versions are you using?
Ruby version: ruby 3.0.4p208 (2022-04-12 revision 3fa771dded) [x86_64-darwin21]
Rails version: Rails <IP_ADDRESS>
RSpec version: RSpec 3.12

rspec-core 3.12.2
rspec-expectations 3.12.3
rspec-mocks 3.12.5
rspec-rails 6.0.2
rspec-support 3.12.0

Observed behaviour
This is about a view spec. According to https://github.com/rspec/rspec-rails/blob/main/lib/rspec/rails/view_spec_methods.rb it should be possible to set extra params required for URL generation, but that isn't working (anymore?).
I'm doing something like:
before do
  controller.extra_params = { :seller_id => seller.id }
end

And in the template I'm using a URL method which requires a :seller_id in the path. This works fine serving the page, but in the view spec this causes a No route matches error with missing required keys: [:seller_id].
Expected behaviour
The extra_params should be used when URLs are generated.
Investigation / Suggested Fix
Rails is using a _recall hash in the options hash passed around for url generation to lookup previous path parameters. This is initialized in https://github.com/rails/rails/blob/58528bf270325789562413eec20b3cbf1a866e7f/actionpack/lib/action_controller/metal/url_for.rb#L33, using the request.path_parameters.
When I used the following code, the URL generation works fine:
before do
  request.path_parameters.merge!(seller_id: seller.id)
end

The extra_params on the other hand only seem to affect the request.path (maybe used in older Rails  versions?). It should also adjust the request.path_parameters which should resolve the issue.

This is weird because we test this in features/view_specs/view_spec.feature, which method are you using that causes the error?

@JonRowe apologies for bumping an old thread but we've just ran into this today. We have a generic view used for multiple objects where we have the line
<%= link_to request.params.merge(sort_by: @name, sort_direction: link_sort_direction) do %>
we also ran into a url generation error where if we used
   request.path_parameters.merge!(x_id: x.id)

The param was set correctly, but
  controller.extra_params = { x_id: x.id }

Resulted in it being missing from request.params


Optix Error

I followed setup steps and I could able to get into the chrono container without problem. Inside container, I can run "nvidia-smi" without problem. However, I get the following error when I try to run the python demo. I tried cpp demo as well and it seems to give the same error.

What version of numpy is installed in the container? You can check this by importing numpy in python, and running numpy.version.version. Only other issue I could maybe see is the driver version - I am using 545.36, but unsure why that would be a problem...

This numpy version:

after I rebuild, it break at 12/18

@jy2247 can you please post what command you are running to build the chrono service?

I think is this one: atk dev -dbua -s dev --optionals gpus vnc

Can you try pulling the containers rather than building: first, stop the running sim container with the atk -d option. Then run docker system prune to remove any old images, and try running atk dev -ua -s chrono --optionals gpus vnc. If that doesn't work, the only issues I can think of is with the NVIDIA driver version, or that you are on Windows I believe (correct?), in which case I would have to do a bit more testing...

@StefanCaldararu  @AaronYoung5
Not urgent but seems I could reproduce the error on my machine:

Is this Windows 11 or within wsl?

Is this Windows 11 or within wsl?

Within WSL. Should I try on windows 11 directly?

And you've pulled the latest, deleted old chrono images?

Yea I did that.

Have you tried the existing chrono docker image, like the one that thomas made? Does that work?

And what about outside a container? Does it work on these computers without docker?

Has this been solved? @harryzhang1018

Has this been solved? @harryzhang1018

Sorry about the late reply. I tried Thomas' chrono ros docker image and it works well.

With the same computer as you're seeing this issue with?

@AaronYoung5 The link to the docker image is: https://hub.docker.com/r/uwsbel/ros/tags. You might want to ask Thomas to give you access on docker script to create this image.

With the same computer as you're seeing this issue with?

Yes, the same one, my laptop.


Retrieving Current AccessToken Expiration Extends It

Core Library
MSAL.js v2 (@azure/msal-browser)
Core Library Version
2.17.0
Wrapper Library
MSAL React (@azure/msal-react)
Wrapper Library Version
1.0.2
Description
I used to retrieve how long user's access token available from 1st approach
I got a feedback from @tnorling that, it's not guaranteed that this would give up to date expiration date for user's access token. So I was recommended to use second approach
Using 2nd approach, I am able to say 1st approach does bring old expiration time. The problem is in the 2nd approach updating expiration time even though, I am not intending to do that. All I need to do is to know when this user's access token will expire.
My goal explanation, if matters is here. Access token needs to be active only 1 hour from the last time user used it. If user sign-in at 1pm, they take some action at 1:20pm, their access token at that time should expire at 2:20pm. The reason I ask for expiration time of the Access Token is that, if user does not take an action for 1 hour, I need to log them out. If I do not check their access token user stays logged in forever. If someone logs in and leave their PC on for hours someone else can click and load up things through API.
Error Message
No response
Msal Logs
No response
MSAL Configuration
export const b2cPolicies = {
  names: {
    signUpSignIn: "***",
    forgotPassword: "***",
  },
  authorities: {
    signUpSignIn: {
      authority:
        "***",
    },
    forgotPassword: {
      authority:
        "***",
    },
  },
  authorityDomain: "loginservicedev.b2clogin.com",
};
/**
 * Configuration object to be passed to MSAL instance on creation.
 * For a full list of MSAL.js configuration parameters, visit:
 * https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/configuration.md
 */
export const msalConfig = {
  auth: {
    clientId: "****", // This is the ONLY mandatory field that you need to supply.
    authority: b2cPolicies.authorities.signUpSignIn.authority, // Choose SUSI as your default authority.
    knownAuthorities: [b2cPolicies.authorityDomain], // Mark your B2C tenant's domain as trusted.
    redirectUri: "/", // You must register this URI on Azure Portal/App Registration. Defaults to window.location.origin
    postLogoutRedirectUri: "/", // Indicates the page to navigate after logout.
    navigateToLoginRequestUrl: false, // If "true", will navigate back to the original request location before processing the auth code response.
  },
  cache: {
    cacheLocation: "localStorage", // Configures cache location. "sessionStorage" is more secure, but "localStorage" gives you SSO between tabs.
    storeAuthStateInCookie: false, // Set this to "true" if you are having issues on IE11 or Edge
  },
  system: {
    tokenRenewalOffsetSeconds: 1740,
  },
};

Relevant Code Snippets
1st approach

export const b2cGetSessionTimeLeft = () => {
  return Math.round(
    (accounts[0]?.idTokenClaims.exp - Math.round(Date.now() / 1000)) / 60
  );
};

2nd approach
function fetchToken(forceRefresh = false) {
  params.forceRefresh = forceRefresh;
  return instance
    .acquireTokenSilent(params)
    .then((response) => response)
    .catch(() =>
      instance
        .acquireTokenRedirect(params)
        .then((response) => response)
        .catch(() => false)
    );
}
export const b2cTimeLeft = async () => {
  let expDateTime = await fetchToken().then((res) => res.expiresOn);
  return Math.round(
    (Math.round(expDateTime / 1000) - Math.round(Date.now() / 1000)) / 60
  );
};

### Reproduction Steps

Request token using acquireTokenSilent and it will extend accesstoken expireson.

### Expected Behavior

Do not extend expireson on each acquireTokenSilent call unless forcerefresh is true.

 Please update this feature once we close on it.

My 2 cents on this is that sign-out should be handled by the application, without using the concept of access token expiration. Access tokens are not even meant for the client application, they are meant for a downstream web api. Also, the token lifetime is not a guaranteed constant (1h) as far as I know.
Exposing this level of control implies that app with make unnecessary requests to AAD, because the app wants fresh tokens.
A better way to handle this scenario could be using CA policies - see https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-session-lifetime


Failure to load other users messages

This again. Nothing in the system logs is out of order.

This may have been a Twitch IRC issue, re-open if this happens again.


Feature Request: All apps must be AOT compilable.

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report
[x] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Other... Please describe:

Current behavior
Currently, the daff.io and the demo are not AOT buildable.
Expected behavior
I should be able to run:

ng build daffio --prod
ng build demo --prod

without errors.
Minimal reproduction of the problem with instructions
What is the motivation / use case for changing the behavior?
Performance at run-time.

this is partially solved by #316


Feature: migrate to<EMAIL_ADDRESS>

Notes:

Support npm@5 (add package-lock.json)
We change logic ignore* (see https://github.com/stylelint/stylelint/pull/2709)
Use stylelint build-in isStandardSyntax* (less code - best support)
Remove replace package (is not used anywhere)

Thanks for taking over this!
I'll release new versions tomorrow. First a patch with the current fixes in master and then a major version with these changes. :+1:


[Arch Linux] electron4 / libevent-2.1.so.7 - Can't open atom or check atom version

Prerequisites

[ X] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: https://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
Followed all applicable steps in the debugging guide: https://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description

When attempting to run atom via atom atom --safe atom --clear-window-state etc. I get /usr/bin/electron4: error while loading shared libraries: libevent-2.1.so.7: cannot open shared object file: No such file or directory and atom doesn't open.
Running atom --version does not display any error, version information, etc.
Steps to Reproduce

Run atom

Expected behavior:
Atom opens
Actual behavior:
Error: /usr/bin/electron4: error while loading shared libraries: libevent-2.1.so.7: cannot open shared object file: No such file or directory
`
Reproduces how often:
100% of the time
Versions
pacman (via pacman -Qi package_name) states that my atom version is 1.39.1-1, my electron4 version is 4.2.8-2, and my libevent version is 2.1.10-1
Additional Information

The pacman package is not official, and is using a different major version of Electron to what is currently intended.

Thanks for reaching out!
We've determined that you are currently using an unofficial build or distribution of Atom. Often these customized versions of Atom are modified versions of the Stable branch of Atom with mismatched versions of built-in components. These updated components are taken from the Beta channel or master branch and then injected into the Stable version and a new Atom package is generated. Because of the way Atom is constructed, using these mismatched components can cause mysterious and hard-to-diagnose problems. You can find out more about why we chose to not support unofficial distributions here.
You can find instructions for installing an official version of Atom in the Flight Manual. If you are still seeing this problem on an official build please file a new issue, thanks!


Security enhancements

We need to set up some security enhancements to the API and Web-UI, At the moment traffic is sent from the client unencrypted and we need to add more validation on each API call to make sure data passed to the API will not result in arbitrary code executions.
Auto-generate a self-signed TLS/SSL certificate during the install process and add more strict API validation functions to api.cgi

added self singed certificates function to setup script and updated Nginx config to point to the newly generated certificates. untested will close this issue once ci passes

added validation function to api will close once ci passes


US26: Upon landing on the Menu, the user can first see the Leaderboard..

Closed with commit: d5d91232ea0166433ed32c7a35821b5324763a72


Fix/madqn

What?
Did major refactoring to the MADQN code.
Implemented working system for value decomposition based algorithms such as VDN and QMIX.
Created a SMAC wrapper so that we can compare with pymarl since the PZ SMAC wrapper is functionally different.
Created environment wrappers that concat prev actions and agent ids to the observations.
Why?
Improved reliability and performance in the MADQN system.
VDN and QMIX were not working before.
SMAC wrapper, prev action wrapper and agent id wrapper let us compare better with pymarl.
How?
MADQN refactor.
New Value Decomposition system inherits from MADQN with additional, interchangeable mixer component.
Extra
[Any extra information.]

Looks amazingg @jcformanek , we are just going to benchmark madqn first and then test some of the wrappers :+1:

Thanks guys. Sorry that this was a "Big Bang PR". I will make sure PRs are smaller in future :+1:


STOI Error

I am getting an error with all commands of the system, including the ROS node. Every command I run gets a message of ifm3d error: stoi. The ROS node dies with a similar error. I have built from source for the tools, and I have installed precompiled versions. I am running on a Ubuntu 20.04 system.

Tried the 20.04 and 16.04 containers and same problem.

Hey @rpangrazio, can you please describe the error in more details? As @tuxx0rz pointed out, can you also please share the device you are using O3D/O3X or O3R and the version of ifm3d you are using. In case you are running ROS please create an issue on the ROS driver.

Its an O3R.
So I rebuilt the 2004 container using main-next branch. No change. If I run any command of the ifm3d application that requires communication to the device it fails, e.g "ifm3d dump" or "ifm3d dump -ip <IP_ADDRESS>".
I can ping the sensor.
Please note that I am not using the ROS driver right now. I only mentioned it because I tried it. I am no longer trying to bring up the ROS system till I have this working.

Can you please post the complete error message? Or is the error message simply
error: stoi

ifm3d error: stoi

That's strange, can you please check if ifm3d without any command does output the version?
ifm3d
ifm3d: version=0.90.0

If this also throws an error, what is the output of:
$ find /usr -name "*ifm3d*"

Can you also please provide an link to the Dockerfile you have used to build the Container?

ifm@48ce3b6989b0:~$ ifm3d -v
ifm3d: version=0.20.1
ifm@48ce3b6989b0:~$ ifm3d dump
ifm3d error: stoi
ifm@48ce3b6989b0:~$ which ifm3d
/usr/bin/ifm3d
ifm@48ce3b6989b0:~$

ifm@48ce3b6989b0:~$ ifm3d -v
ifm3d: version=0.20.1

This version is not the one needed to interact with the O3R. After building from source from the branch o3r/main-next you should end up with something like 0.90+. I suspect something went wrong when you installed both from apt and from source.
We have a docker container ready to use that you can directly pull, which should contain the most recent version of ifm3d and get you on your way:
https://github.com/ifm/ifm3d/pkgs/container/ifm3d

I am using the docker container.

When I run that docker container, I get ifm3d version 0.92:
me@ME:~$  docker pull ghcr.io/ifm/ifm3d:latest-ubuntu
me@ME:~$ docker run -it ghcr.io/ifm/ifm3d:latest-ubuntu
ifm@e1363a064335:/$ ifm3d -v
ifm3d: version=0.92.0+39.47f850f

Did you pull that container recently?

I built the container today, but I am refollowing all the directions without regard to what I did before. Essentially starting from scratch, because I have a sinking suspicion I messed something up.

Pulled it from the repo instead of building locally worked. Thank you very much for the help.

No worries at all :) Can you tell us which dockerfile you used to build before? There might be an error in the instructions there that I could correct.

All of the docker files in the repo under the docker folder. Tried them all. Used the python script to build them.

Just for reference, the Dockerfiles for the o3r version are located in the docker/ifm-robotics folder, the others are all building the master version. So the one used for building the current version container would be this: https://github.com/ifm/ifm3d/blob/o3r/main-next/docker/ifm-robotics/docker/Dockerfile


windows: failing to load codecs library in v1.1

due to failing to load the prt codecs library, assets cannot be loaded from RPKs:
[warning] [Method: 'Default$WindowFrame'] i(): Asset 'window_frame.obj' (project ''): error, using 'builtin:unknownasset'.
the underlying problem is a clash between Alembic.dll in CE SDK and Alembic.dll in Houdini. both have the same name but are not compatible (probably different versions).
fix by renaming Alembic.dll in CE SDK to AlemPRT.dll and edit the import section of com.esri.prt.codecs.dll.

did not find a programmatical way to do this - tried lief and peedit python tools. both tools cause an infinite loading loop when prt core tries to load the modified codecs.
it works by manually modifying the codecs library using the "CFF Explorer" tool (http://www.ntcore.com/exsuite.php). care must be taken to have the same number of characters in the renamed dll (else the dll section layout is corrupted).
attached the patched CE SDK release to the Palladio v1.1 release:

keeping this ticket open to find a more elegant fix...

fixed in PRT 2, alembic now statically linked.


Commissioning of enocean BLE sensor/switch via blynk APP/dashboard.

What if it is a single "standalone house" without display or payed data connection...?

Got request from Haaks to make offer for stand alone house with basic functionality (current control and lighting)... should we offer lighting if we have no means of commissioning switches


Add Whois command

Add Whois command
I want to get domain information.
The Ideal Solution
Make command like jsk pip
Summary
And run whois with subprocess.

My main concern with this is having to build in dependence to a whole bunch of web servers to implement it properly. Compared to e.g. just pulling DNS records, where I can rely on your system config, to get WHOIS info I need to figure out which of a list of a lot of possible servers actually has the info I need, and this list can change over time and ever expands with more TLDs.
Having to maintain that within jishaku seems obviously quite tedious and silly, so it would call for pulling in a dependency that can separately ensure it is up to date, but that requires picking one that is actively maintained/has async support/doesn't pull in too many dependencies of its own/etc. It's not a no (I thought about adding DNS lookup before, and that would probably go in with this if it does end up happening someday), but it leans into the dubious region of "is jishaku a tool people should use for this" chart.

I see