Route loaded twice

Hello
I have actually an issue with my isomorphic react application. There is also code splitting with webpack.
I have been able to reproduce my issue with your project by modifying the render function of client.js
let render = () => {
  // We need to have a root route for HMR to work.
  const createRoutes = require('./routes/root').default;
  const routes = createRoutes(store);

  // Pull child routes using match. Adjust Router for vanilla webpack HMR,
  // in development using a new key every time there is an edit.

    // Render app with Redux and router context to container element.
    // We need to have a random in development because of `match`'s dependency on
    // `routes.` Normally, we would want just one file from which we require `routes` from.
    ReactDOM.render(
      <Provider store={store}>
          <Router routes={routes} history={browserHistory} key={Math.random()}/>
      </Provider>,
      container
    );
};

The problem can been seen by enable Network Throttle (Regular 3G).
Go to the page http://localhost:5000/post/hows-business-boomin and you can seen a blink of the page.
The page is displayed once thank to server rendering et then a second time and this is the problem.
It seems that the react-router client side a rendering the route again.
Have you been able to experience the same issue ? Can you explain me why plz ?
Why did wrapped the ReactDOM.render function into match({ routes, location }, () => {} by the way ?
Best regards

Ok, I just read this documentation - https://github.com/reactjs/react-router/blob/master/docs/guides/ServerRendering.md#async-routes
and it solves my issue.
When I first read this documentation, I didn't understand the asyn-routes section until I encountered this issue.

Are you still seeing the double-load?

No more double load 👍


add mainnet deployments

TODO:

[ ] Add mainnet and optimism to chain options
[ ] Move to using https://github.com/rainbow-me/rainbowkit

Codecov Report

Merging #24 (342577d) into main (14b9fd7) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main       #24   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            2         2
  Lines          133       133
  Branches        19        19
=========================================
  Hits           133       133

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 14b9fd7...342577d. Read the comment docs.


Bump vertx, jackson, netty and a couple of other deps

Issue
NA
Description
Versions for jackson and netty are the ones defined in vertx-dependencies
BREAKING CHANGE: Vert.x update might contain breaking changes.
Other dependencies will be updated in another PR

Gravitee.io Automatic Deployment
🚀 A prerelease version of this package has been published on Gravitee's private artifactory, you can:

use it directly by updating your project with version: 4.0.0-dep-major-update-SNAPSHOT
download it from Artifactory here

:tada: This PR is included in version 4.0.0-alpha.1 :tada:
The release is available on:

4.0.0-alpha.1
GitHub release

Your semantic-release bot :package::rocket:


Manual fix ruff

Fixed remaining errors in src/quemb/shared/external/cpmp2_utils.py and src/quemb/molbe/solver.py

removed unused variables
made it explicit that update_heff modifies self, i.e. it returns nothing now.
removed ecore from everywhere. It did not do anything anyway. If it should be reintroduced it is much easier, if automatic code analysis (unused arguments in particular) works.

part of #44

removed ecore from everywhere. It did not do anything anyway. If it should be reintroduced it is much easier, if automatic code analysis (unused arguments in particular) works.

It looks like functionality related to frozen core was stripped down here; we should perhaps discuss how to proceed with this.

removed ecore from everywhere. It did not do anything anyway. If it should be reintroduced it is much easier, if automatic code analysis (unused arguments in particular) works.

It looks like functionality related to frozen core was stripped down here; we should perhaps discuss how to proceed with this.

the functionality does not exist. There is an ecore argument to the outside, but that is never used. I would rather explicitly remove it and then cleanly add it, than have a non-working argument.


cityscapes_car

Hello,Can you offer the cityscapes_car database? thank you!

Hi
The cityscapes_car database is similar to the original cityscape dataset. Following previous settings in UDA object detection, we only use the objects under the 'car' category to train the model, while ignoring all the rest objects in other categories.
You can find the whole cityscape dataset in the:
https://drive.google.com/file/d/1mA0L5-1U_Vo-S8-cv12QBmhgG9FFf6nf/view


WSL2 - Unable to access localhost:5000

Please fill out the below information:

Your Windows build number:  (Type ver at a Windows Command Prompt)

Microsoft Windows [Version 10.0.18956.1000]

What you're doing and what's happening:  (Copy&paste the full set of specific command-line steps necessary to reproduce the behavior, and their output. Include screen shots if that helps demonstrate the problem.)

React front app
$ yarn start
Rails backend API
$ bundle exec rails s -b localhost -p 5000

What's wrong / what should be happening instead:

I want to connect my rails API but I can't.
If I type IP directly I can connect the API from react.
like
$ bundle exec rails s -b 172.xx.xx.xx -p 5000
cors.rb
origins /localhost:\d+/, /172.xx.xx.xx:\d+/
curl is OK
$ curl localhost:5000/users/1
{"status":"SUCCESS", ... }
but react
GET http://localhost:5000/users/1
net::ERR_CONNECTION_REFUSED
I am sorry I can't speak English well.

Try bundle exec rails s -b <IP_ADDRESS> -p 5000.

Connected.
Thank you.

Upgrading to a newer insiders build will remove the need to bind to <IP_ADDRESS>, so I'll close this issue out as resolved! :)


More examples for d3 function calls would be very nice to speed up programming.

Hi,
Would it be possible to have more examples to cover a broader class of visualizations to speed up programming?  Has @mbostock thought about writing a bible on d3.js?
Thanks!
Shyamal

There are thousands of examples covering most visualization types:
https://github.com/mbostock/d3/wiki/Gallery
https://bl.ocks.org/mbostock
(I’ve also talked about my examples.)
Please use Stack Overflow tag d3.js or the d3-js Google group to ask for help. These issues are for feature requests and bug reports only. Thank you!


Getting kNAUIOptionNoUI error when running jss recipe on High Sierra

Getting the following error on High Sierra GM using AutoPkgr + autopkg + jssimporter:

autopkg run THD_iTerm2.jss
Processing THD_iTerm2.jss...
'kNAUIOptionNoUI'
Failed.
The following recipes failed:
THD_iTerm2.jss
Error in THD_iTerm2.jss.recipe.local: Processor: JSSImporter: Error: 'kNAUIOptionNoUI'
Nothing downloaded, packaged or imported.

When running the recipe was a pkg recipe it works fine. Seems to be something with jssimporter.

This is actually an issue with the python-jss module, specifically it's use of the NetFS.framework API.  I've submitted an issue here:  https://github.com/sheagcraig/python-jss/issues/62

Thanks @pauldalewilliams. Closing this in leu of https://github.com/sheagcraig/python-jss/issues/62.


Authenticate mails sent by MaMpf

Mails have been sent unauthenticated internally via the Mathi mail server. This PR introduces user/password authentication.
The change I had to introduce in f40080e is unfortunate but necessary due to #542. Hopefully, we can fix this in the near future.
TODO

[x] Respective env variables have to be added to the server env files.

Converted back to draft as I'd like to have #542 fixed first.

Will merge without review as Denis is on vacation.


starter simple dockerize for mongocli

Hi-
------NOTE IN DRAFT STILL-----
This is a DRAFT PR for discussion purposes. This Dockerfile is not integrated with the source/builds for the mongocli project, rather it tries to download the latest monogcli binary and build a Docker image with it. There are probably lots better ways and I would also like to see if we can setup a github action to push updates automatically.
Having an official Docker image for mongocli will enable us to write simple DevOps scripts using containers and such.
For example here is a Kubernetes Job to list your projects. This can be extended to all CRUD resource scenarios.

Proposed changes

Jira ticket: CLOUDP-#

Closes #[issue number]
Checklist

[ ] I have signed the MongoDB CLA
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added any necessary documentation (if appropriate)
[ ] I have updated e2e/E2E-TESTS.md (if a new command or e2e test has been added)
[ ] I have run make fmt and formatted my code

Further comments

I don't oppose having a docker image, on how we should integrate with goreleaser, https://goreleaser.com/customization/docker/
This may also need changes on the machines we use to release mongocli on evergreen as I don't think those have docker installed


Translation issue with export?

French:

English basically says transaction may have timed out, check back later.

Don't think the export works when this happens also - the button just goes back to Export.
Don't recall how we wanted to handle this case - there may be a non-CF api which may help.

The sub-message is not translated and is simply the raw error returned by the call. I was hoping that printing out the error could help the user figure things out, or help the user pass it along to us, instead of just telling them "Failed to get transactions. Try again later.".
In this case, it's a generic Python error.  SDK bug?

Hmm, I thought the call was just timing out due to the 100 second clouldflare timeout. The english version didn't have that error, just the timeout.


Rename package variable to pkg, as "package" is reserved.

It is indeed a reserved keyword, although it still works. Merging as that's just a variable name, so minor change.


event_config_changed.json is not updated or newly created

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[X] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[X] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug
I have the following problem.
We have two FWs in HA setup here.
So that I do not forget that I have not pushed changes from master to the backup, I have created a monitoring with the help of /conf/event_config_changed.json.
Since 1-2 days I have the problem that the config does not change on the backup anymore.
Deleting the config does not create a new file.
Rebooting did not help either.
A config change on the master + trigger sync does not change anything either.
Maybe the problem was caused because I accidentally created a rule on the backup?
Maybe this is also desired here for reasons?
I don't know whether this is considered as a correct issue here.
To Reproduce
Unfortunately, I don't know.
It could be triggered by a rule change on the backup FW, would fit in terms of timing.
Software version used and hardware type if relevant, e.g.:
OPNsense 23.7.12-amd64
FreeBSD 13.2-RELEASE-p7
OpenSSL 1.1.1w
Intel(R) Atom(TM) CPU C3558 @ 2.20GHz (4 cores, 4 threads)

checked again on my end, it does look like something is off here

this https://github.com/opnsense/core/commit/042f71db129f848306449fbb538a892d03f6b777 should fix the issue, does need a syslog-ng restart afterwards.
service syslog-ng restart

Many thanks for the quick fix.
As you said, I ran the following on the backup FW:
opnsense-patch 042f71d
service syslog-ng restart
Then started a new sync from the master, the file was created and contains a new timestamp.

@ElXk6 thanks for confirming


Check if memory is allocated

Hi everyone,
I think we need to check if memory is really allocated before use it.
Regards

Hey,
Thanks! I have a couple issues here:

Since this is just the testapp I don't think this is strictly necessary. It won't be invoked while under high memory pressure :)
The code style seems a bit off.
Doesn't actually pass the test suite: whitespace.t is failing.

So I'll probably pass on this, but for future reference please run/check the test output on your own first :)

Hi @dormando,
Thanks for the feedback.
I removed some whitespaces.
Regards

squashed and merged for next, thanks!

released in 1.6.9!


Reduce image count

Overview
There are multiple images that can be merged in few images with configurable entry point:

common:

nsc
nsmd
...

vppagent-common:

vppagent-dataplane
vppagent-nsc
...

Making such images can reduce the count of CircleCI build jobs and reduce the CI complexity.
References

@Bolodya1997 Would it make sense to collapse the build of various NSE containers into a single CircleCI job?

Originally posted by @edwarnicke in https://github.com/networkservicemesh/networkservicemesh/pull/1013#issuecomment-487921878

I don't like this proposal and I think it is a misinterpretation of the said comment. The said containers have very little in common and should not be merged.
@edwarnicke @haiodo please weigh in here.

@nickolaev This was my idea, actually, to have common CI container we will use for CI, to not have examples, etc but have only testing and test container.
Examples should resist into examples repository and do not confuse any of users.
Thoughts?

It will simplify adding of any new applications required for CI testing more easy, just add compile into common ci docker image and pass as command for pod/container at start point in CI.

Well, are we saying we are going to distribute the whole NSM in 2 images - alpine and vppagent based? I get the point about simplifying the CI, but releasing a multi-entrypoint images is a serious design change and deserves a bit more discussion.
To me, except simplifying/speeding up the CI, I can't see any other advantages of such approach. But maybe I am missing something.


Setup CI to build wheels

Codecov Report
Base: 89.31% // Head: 89.31% // No change to project coverage :thumbsup:

Coverage data is based on head (a6729db) compared to base (85104f1).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main       #3   +/-   ##
=======================================
  Coverage   89.31%   89.31%
=======================================
  Files           3        3
  Lines         337      337
=======================================
  Hits          301      301
  Misses         36       36

Flag
Coverage Δ

unit
89.31% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Fix running state behavior with delete

When a dispatch is deleted, the running state change notification telling the actor that it is no longer running will only be sent if there are no other dispatches of the same type running.
Signed-off-by: Mathias L. Baumann<EMAIL_ADDRESS>

So the previous behaviour was that a stop event was sent even when there were other dispatches running for this type, so the dispatch would have stopped when it shouldn't, right?

correct


Highlighting text on chapter2 isnt visible, copying and pasting is difficult.

Look into how to change the highlight color, i didnt expect it to do that.

Changed code color and highlight color with css.  Learned that this was a thing today.


inline TOC background not dark-grey but grey in dark mode

Hi,
the collapsed inline TOC (eg. on small screen devices) is not dark-grey but grey in dark mode.
Thanks,
f-s

Hello
It would be nice to look at screenshots of the problem

I still don't understand what the problem is

the background colour is too bright compared to the rest of the themes background-colours in dark mode

Understood well, I'll try to choose a less bright one))


problem generating human-readable names for "comparable" types

I became curious about how to write a function that accepts multiple comparable values. First I decided to see what was inferred:
> f x y p q = (x < y, p < q)
<function>
 : comparable -> comparable -> comparable -> comparable -> (Bool, Bool)
> f 1 2 "hi" "bye"
(True,False) : (Bool, Bool)
> f : comparable -> comparable -> comparable -> comparable -> (Bool,Bool)

That inferred signature can't be right though, since the same type variable is used throughout. In fact, if I give this as the annotation, I get a type error (as expected) when calling it with two distinct types.
Here's another example that somehow typechecks:
f : comparable -> comparable -> comparable1 -> comparable2 -> (Bool, Bool)
f x y p q = (x < y, p < q)

ex = f 1 2 "hi" "blah"

I don't really know what's going on here but it seems like something is buggy.

Alright, this is resolved on the type-fixes branch which I'm working on merging into master now. Here's what I'm seeing in the REPL:
$ elm-repl
---- elm repl 0.16.0 -----------------------------------------------------------
 :help for help, :exit to exit, more at <https://github.com/elm-lang/elm-repl>
--------------------------------------------------------------------------------
> f x y p q = (x < y, p < q)
<function>
    : comparable
      -> comparable -> comparable' -> comparable' -> ( Bool, Bool )
> f 1 2 "hi" "bye"
(True,False) : ( Bool, Bool )
> f
<function>
    : comparable
      -> comparable -> comparable' -> comparable' -> ( Bool, Bool )
>

And the example program you gave is resulting in an error now as well.
Thanks for the report!


refactor(jstzd): move baker/client to octez

Context
leounoki-jstz-183/refactor
Description
All of the "new" octez related code is now placed in octez/src/async

move jstzd structs (client / endpoint / directory) to src/async/
move the logic for runnign octez baker to src/async/baker.rs
rename src/async_node -> src/async/node

Manually testing the PR
All the existing unit/integration tests pass
cargo test --package jstzd
cargo test --package octez

@johnyob Just a bit of context, this PR is  an intermediate step to allow any future work on jstzd and octez to continue in the correct™ code structure while not need to care about breaking the existing sandbox. A follow up  PR is required to replace synced octez with async octez.

A follow up PR is required to replace synced octez with async octez.

I figured :)


Run clippy and fix things

I haven't tried it, but I assume if we ran clippy on this repo, we could find a few things to fix. Might be a nice exercise for Rust beginners.
Up for grabs, if anyone wants to give it a shot.

Hi! I ran clippy on the repo and the first thing that stands out is
`[[bin]]
This will look in src/bin/mos6502.rs
name = "mos6502.rs"`
main.rs is the only file in src/bin
so I changed Cargo.toml to have `[[bin]]
This will look in src/bin/mos6502.rs
name = "main"`
Also I added autobins = false to [package] in response to the following warning:

warning: An explicit [[bin]] section is specified in Cargo.toml which currently
disables Cargo from automatically inferring other binary targets.
This inference behavior will change in the Rust 2018 edition and the following
files will be included as a binary target:

X:\Users\xyz\git_projects\mos6502\src\main.rs

This is likely to break cargo build or cargo test as these files may not be
ready to be compiled as a binary target today. You can future-proof yourself
and disable this warning by adding autobins = false to your [package]
section. You may also move the files to a location where Cargo would not
automatically infer them to be a target, such as in subfolders.

Apologies if this is nonsense- I'm very new to both rust and github, but saw this issue as an opportunity to get my feet wet without screwing up. Thanks.

Heyo @kzzt,
welcome to Rust! The community where everything goes. 🌈 Glad to have you on the team. 🦀
Nice that you're tackling this.

main.rs is the only file in src/bin

That's true. My fault. As far as I understand it, renaming that file to src/bin/mos6502.rs without any other changes should make the warning go away.

Also I added autobins = false to [package] in response to the following warning: [...]

That was the logical next step from what you did. Rust tells us that it dected main.rs in the bin folder and that without a [[bin]] section in our Cargo.toml, it would just assume that's a binary we'd like to compile. In the [[bin]] section we mistakenly specified a (nonexistent) binary however. And it was unsure, whether the main.rs would be something that is there by accident or on purpose, since it was never mentioned in the [[bin]] section.
I looked at main.rs and it doesn't make a lot of sense to me. Ported that over with the fork. It looks more like an integration test to me. So I added it to the README.md as a usage-example, which also gets executed with skeptic when running cargo test.

Apologies if this is nonsense- I'm very new to both rust and github, but saw this issue as an opportunity to get my feet wet without screwing up. Thanks.

That's great! Keep the pull requests coming. I'm sure there are many more odd things in this library. Just open more issues and we can all discuss them here. 👍

Super old ticket. All clippy issues should be fixed now. 😆 Closing. Thanks you both for helping me with that. 👍

Super old ticket. All clippy issues should be fixed now. 😆 Closing. Thanks you both for helping me with that. 👍


Add Pre-commit Support for Code Quality Assurance

Description:
To ensure consistent code quality and style across the repository, I propose adding pre-commit support. Pre-commit hooks can help automate several tasks before commits, such as code formatting, linting, and running basic tests.
Benefits:

Consistent Code Style: By using tools like black or yapf, we can ensure that the codebase has a consistent style, making it more readable and maintainable.
Catch Issues Early: Linters like flake8 or pylint can catch common Python mistakes before they're committed.
Automate Processes: Instead of manually running formatters or linters, developers can rely on these tools to run automatically, ensuring that only quality code gets committed.
Reduce Review Overhead: With automated checks in place, code reviewers can focus on the logic and structure of the code rather than style or basic issues.

Proposed Steps:

Add a .pre-commit-config.yaml file to the root of the repository.
Define the desired hooks, such as black, flake8, etc.
Update the README.md or contributing guidelines to instruct developers on how to set up pre-commit in their local development environment.
Optionally, integrate with CI/CD to ensure that commits and PRs adhere to the defined hooks.

Additional Resources:

Pre-commit official documentation

I believe that adding pre-commit support will significantly enhance our development workflow and ensure a higher code quality standard. Looking forward to feedback on this proposal!

We may need CI hooks first

I'd be interested in working on this. I can do both the linting config + CI via Github ACtions.


Add optional stateName parameter to filter states results

great project @ahmadawais 👍
I had a need to work with some individual state data and wanted to filter the results to save time.  The change as implemented is very simple.  I checked and it did not appear that the underlying API supported a state filter so I just did it on the client side.
I also added examples to the readme under the states section.
Hope this is helpful.
Questions or comments welcome.
thanks

thoughts?  feedback?
thanks


Diagnostics breadcrumb does not go away

Open diagnostics, click on home breadcrumb - the page is changed, but the breadcrumbs show diagnostics too

fixed in a51c8b2ee59dfea3896a923c37a9e65b7abbe359


chore: Add cpp binding Google style clang-format && format the code

Add cpp binding Google style clang-format && format the code

Hi, @silver-ymz, would you like to take a review?


Add GRU option to keep memory requirements under control for deeper networks

https://github.com/carlthome/tensorflow-convlstm-cell/commit/61fb348536cb1570c21272278efa15287c65048e


Update master

#21
#20
#19

Codecov Report
Attention: 20 lines in your changes are missing coverage. Please review.

Comparison is base (475c754) 86.71% compared to head (50e4be8) 86.10%.
Report is 3 commits behind head on master.

Files
Patch %
Lines

src/models/neural.jl
75.75%
8 Missing :warning:

src/models/neural2.jl
81.25%
6 Missing :warning:

src/models/bertalanffy_numerical.jl
70.00%
3 Missing :warning:

ext/PlotsExt.jl
0.00%
1 Missing :warning:

src/models/bertalanffy2.jl
95.65%
1 Missing :warning:

src/models/classical_bertalanffy.jl
94.44%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##           master      #23      +/-   ##
==========================================
- Coverage   86.71%   86.10%   -0.62%
==========================================
  Files          12       21       +9
  Lines         399      439      +40
==========================================
+ Hits          346      378      +32
- Misses         53       61       +8

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


.csv files presented as a table?

Hi Will, when running the rich command and passing it a csv file, I am not getting the table output format as shown in the Readme file.....is there a specific command or option I am missing ?  I am on Mac OS...
see output below when I point rich to one of this repo's csv files.....
rich https://raw.githubusercontent.com/Textualize/rich-cli/main/test_data/deniro.csv
"Year", "Score", "Title"
1968,  86, "Greetings"
1970,  17, "Bloody Mama"
1970,  73, "Hi, Mom!"
1971,  40, "Born to Win"
1973,  98, "Mean Streets"
1973,  88, "Bang the Drum Slowly"
1974,  97, "The Godfather, Part II"
1976,  41, "The Last Tycoon"
1976,  99, "Taxi Driver"
1977,  47, "1900"
1977,  67, "New York, New York"
1978,  93, "The Deer Hunter"
1980,  97, "Raging Bull"
1981,  75, "True Confessions"
1983,  90, "The King of Comedy"
1984,  89, "Once Upon a Time in America"
1984,  60, "Falling in Love"
1985,  98, "Brazil"
1986,  65, "The Mission"
1987, 100, "Dear America: Letters Home From Vietnam"
1987,  80, "The Untouchables"
1987,  78, "Angel Heart"
1988,  96, "Midnight Run"
1989,  64, "Jacknife"
1989,  47, "We're No Angels"
1990,  88, "Awakenings"
1990,  29, "Stanley & Iris"
1990,  96, "Goodfellas"
1991,  76, "Cape Fear"
1991,  69, "Mistress"
1991,  65, "Guilty by Suspicion"
1991,  71, "Backdraft"
1992,  87, "Thunderheart"
1992,  67, "Night and the City"
1993,  75, "This Boy's Life"
1993,  78, "Mad Dog and Glory"
1993,  96, "A Bronx Tale"
1994,  39, "Mary Shelley's Frankenstein"
1995,  80, "Casino"
1995,  86, "Heat"
1996,  74, "Sleepers"
1996,  38, "The Fan"
1996,  80, "Marvin's Room"
1997,  85, "Wag the Dog"
1997,  87, "Jackie Brown"
1997,  72, "Cop Land"
1998,  68, "Ronin"
1998,  38, "Great Expectations"
1999,  69, "Analyze This"
1999,  43, "Flawless"
2000,  43, "The Adventures of Rocky & Bullwinkle"
2000,  84, "Meet the Parents"
2000,  41, "Men of Honor"
2001,  73, "The Score"
2001,  33, "15 Minutes"
2002,  48, "City by the Sea"
2002,  27, "Analyze That"
2003,   4, "Godsend"
2004,  35, "Shark Tale"
2004,  38, "Meet the Fockers"
2005,   4, "The Bridge of San Luis Rey"
2005,  46, "Rent"
2005,  13, "Hide and Seek"
2006,  54, "The Good Shepherd"
2007,  21, "Arthur and the Invisibles"
2007,  76, "Captain Shakespeare"
2008,  19, "Righteous Kill"
2008,  51, "What Just Happened?"
2009,  46, "Everybody's Fine"
2010,  72, "Machete"
2010,  10, "Little Fockers"
2010,  50, "Stone"
2011,  25, "Killer Elite"
2011,   7, "New Year's Eve"
2011,  70, "Limitless"
2012,  92, "Silver Linings Playbook"
2012,  51, "Being Flynn"
2012,  29, "Red Lights"
2013,  46, "Last Vegas"
2013,   7, "The Big Wedding"
2013,  29, "Grudge Match"
2013,  11, "Killing Season"
2014,   9, "The Bag Man"
2015,  60, "Joy"
2015,  26, "Heist"
2015,  61, "The Intern"
2016,  11, "Dirty Grandpa"

Are you using the latest version?


Removed app.loadScene* callbacks from docs

I confirm I have signed the Contributor License Agreement.

Hold off on merging this, I just found out that the examples from https://developer.playcanvas.com/en/api/pc.SceneRegistryItem.html are also outdated so I will fix this first

Made loadScene private as it looked like it was made public accidentally during an API update to pc.Application.
Updated some tests and documentation.

Made loadScene public again. Removed unused callbacks.

Might wanna tweak the PR name now. 😄

Good call 😅

Hello @yaustar!
Happy to see the docs for pc.SceneRegistry being updated! If I may make a suggestion:
Please take a look at the callback parameter in each pc.SceneRegistry#loadScene* method. You will notice that they are all of type {Function}, which provides limited documentation and no actual callback argument type info. This is why the pc.callbacks.Load* definitions were added. They properly document each callback argument and more. Please consider replacing {Function} with the corresponding pc.callbacks.Load* type. You can compare with the same callback parameter in the now deprecated pc.Application#loadScene* methods.
Cheers,
Aidin

Good point @aidinabedi! I've gone ahead and made that change. Thanks! 😄


Updates apps/speed.c to use opt_int_arg() to prevent malformed proces…

…sing of hexadecimal input to some command line options. Updated help to notify the change.
CLA: trivial
In the "openssl speed" CLI, one is able to specify arguments to some options [like -seconds -bytes] in terms of hexadecimal values prefixed by 0x or 0X. These are accepted by the command-line parser as valid arguments as long as the value fits in the prescribed range. However, the actual conversion to an integer takes place via atoi(opt_arg()) which does not handle hexadecimal strings and returns 0 instead. This leads to issues since these options expect positive integers.
This PR replaces all such calls with opt_int_arg() which was already in use in this file. The help text has also been modified to ensure people are aware of the prefix rules surrounding the usage of opt_int_arg() [which calls strtol() internally]

Checklist

[x] documentation is added or updated

I think this is slightly outside of something acceptable with CLA: trivial.

I have sent my ICLA via e-mail.

I've not seen your ICLA come in yet.

@paulidale It was sent under the name Kevin. Please let me know if I need to contact anyone regarding this.

I wouldn't add the "[prefix '0' for base-8, prefix '0x'/'0X' for base-16]" to each of the options myself.

No sign of your CLA yet.  You should be able to email it to<EMAIL_ADDRESS>

@t-j-h would this work better then?
Usage: speed [options] [algorithm...]
All +int options consider prefix '0' as base-8 input, prefix '0x'/'0X' as base-16 input.
...

Reopened to remove CLA hold. I have submitted my ICLA.

Please drop the merge commit. We do not allow merge commits in the repository.

Sorry for the mess, I kind of mucked up my fork by accident and had to rectify it.
All the changes have been merged into a single commit now.
Sorry for the inconvenience.

I've updated the help text. Please check if it's sufficient @paulidale?

This pull request is ready to merge

Merged to master branch. Thank you for your contribution.


Investigate implementation of receiving and processing live audio input

i.e., audio input to the microphone/line-in records and saves as an audio file.

The Port Audio library provides functionality for recording and saving audio - I used the paex_record.c example file to successfully record audio from my PC's microphone. Likely can just copy this and modify it as needed for our purposes.


Flow doesn't have a few XPath-related properties in the standard libdefs

I just saw a StackOverflow question where someone wanted to use Flow to type some stuff related to XPath:
const xmlDoc: XMLDocument = new DOMParser().parseFromString(xmlString,"text/xml");

xmlDoc.evaluate(xPath, xmlDoc, null, XPathResult.ANY_TYPE, null);

It looks like they can just use Document in place of XMLDocument, but the current definition of Document doesn't seem to have an evaluate method. In addition, I don't see XPathResult defined anywhere. Are these things that we/you would be interested in adding to the libdefs?

Well, if something exists in specs but missed in libdefs, I think, it should be fixed.

Feel free to PR 👍


Font does not load after adding to resources

I am running 2021.8.8 of Home assistant and have included the font URL as a resource in HA but the font doesn't appear to be changing.
Do I need to do anything else to enable?

no comment


Update boltz.py

I got few errors in previous file , hence , I've updated the following:

Remove MSA code
boltz uses --use_msa_server
code recieves --input
L4 gpu with max timeout (can change)
export as zip
@charlesfrye

Hey @greenrace666, thanks for the PR!
Could you please explain all of the changes that you have made and your rationale for making them?
For example, you removed the code to parse MSAs from the input YAML. Boltz-1's YAML format includes support for linked MSA files, which this removes. Additionally, you're now always passing in the --use_msa_server flag, which previously was left as an option for users to pass if they wanted.

Sure

I removed the MSA code since automatic msa prediction would be very user friendly and quick for an average code user
-U now provide custom path to yaml using --input (again user friendly)
-Prob should change back to H100 , L4 takes longer
-zip can be easily extracted cross system
@charlesfrye


Unable to build from source

cork create --verbose --manifest-branch flatcar-stable2512.5.0 fails as it prompts for username and password for sdnotify

i've checked multiple times my creds are fine, unsure as to why this repo is requesting them.

Hi @ryanm101 , starting from v2605.7.1 git repositories have been renamed from flatcar-linux to kinvolk (see this commit: https://github.com/kinvolk/manifest/commit/cddda84e75098c933631ed47cb2978fa3b726ad5). That's why it prompts for credentials because this repo appears to be private for git but it actually does not exist anymore since it moves to https://github.com/kinvolk/sdnotify-proxy.
Would you mind trying with a more recent version (at least from --manifest-branch flatcar-stable-2605.8.0) ? For the record, the latest stable release is at the moment the 2765.2.6.
Let me know how it goes :)

@tormath1 Thanks i'll give that a whirl, is there any way to build the old ones as I'm trying to further troubleshoot: https://github.com/kinvolk/Flatcar/issues/286 and am trying to do it locally as having to redeploy my test cluster is a bit cumbersome

Hi @ryanm101 - thanks for trying to get to the bottom of #286 ! I believe a more viable path forward is to work with a recent release (please base your work on the latest Alpha), just add the kernel config options, build a custom OS image, and file a PR if that resolves your issue.

ok so i've tried to build flarcar from the latest sources and having a few issues:

On my macbook (work laptop) (it is possible i have some brew <> installed that is causing a conflict but any ideas?

./build cork
Building cork
# github.com/coreos/mantle/system/exec
system/exec/multicall.go:81:3: unknown field 'Pdeathsig' in struct literal of type syscall.SysProcAttr
system/exec/multicall.go:93:3: unknown field 'Pdeathsig' in struct literal of type syscall.SysProcAttr

Luckily i have a laptop running Fedora 34 so doing it on that.

Trying to build on the OS using the dev container per the custom kernel module instructions:
sudo systemd-nspawn     --bind=/usr/lib64/modules     --image=flatcar_developer_container.bin
Spawning container flatcardevelopercontainer.bin on /home/core/flatcar_developer_container.bin.
Press ^] three times within 1s to kill container.
Update Strategy: No Reboots
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

flatcardevelopercontainer ~ # emerge-gitclone
>>> Failed to read manifest commits for 2905.2.2
!!! Invalid PORTDIR_OVERLAY (not a dir): '/var/lib/portage/coreos-overlay'
!!! Section 'coreos' in repos.conf has location attribute set to nonexistent directory: '/var/lib/portage/coreos-overlay'
!!! Section 'portage-stable' in repos.conf has location attribute set to nonexistent directory: '/var/lib/portage/portage-stable'
!!! main-repo not set in DEFAULT and PORTDIR is empty.
>>> No git repositories configured.

flatcardevelopercontainer ~ # emerge -gKv coreos-sources
!!! Invalid PORTDIR_OVERLAY (not a dir): '/var/lib/portage/coreos-overlay'
!!! Section 'coreos' in repos.conf has location attribute set to nonexistent directory: '/var/lib/portage/coreos-overlay'
!!! Section 'portage-stable' in repos.conf has location attribute set to nonexistent directory: '/var/lib/portage/portage-stable'
!!! main-repo not set in DEFAULT and PORTDIR is empty.

!!! /etc/portage/make.profile is not a symlink and will probably prevent most merges.
!!! It should point into a profile within /var/lib/portage/portage-stable/profiles/
!!! (You can safely ignore this message when syncing. It's harmless.)

!!! Your current profile is invalid. If you have just changed your profile
!!! configuration, you should revert back to the previous configuration.
!!! Allowed actions are limited to --help, --info, --search, --sync, and
!!! --version.```

Some progress..
. /usr/share/flatcar/release
mkdir  /var/lib/portage/coreos-overlay
cp <rootCA> /etc/ssl/certs/
update-ca-certificates
emerge-gitclone
!!! Section 'portage-stable' in repos.conf has location attribute set to nonexistent directory: '/var/lib/portage/portage-stable'
!!! main-repo not set in DEFAULT and PORTDIR is empty.
Unavailable repository 'portage-stable' referenced by masters entry in '/var/lib/portage/coreos-overlay/metadata/layout.conf'
!!! Unable to parse profile: '/etc/portage/make.profile'
!!! ParseError: Parent 'portage-stable:default/linux/amd64/17.0/no-multilib/hardened' not found: '/var/lib/portage/coreos-overlay/profiles/coreos/amd64/parent'
Undefined license group 'EULA'
>>> Cloning repository 'coreos' from 'https://github.com/kinvolk/coreos-overlay.git'...
>>> Starting git clone in /var/lib/portage/coreos-overlay
Cloning into '/var/lib/portage/coreos-overlay'...
remote: Enumerating objects: 87605, done.
remote: Total 87605 (delta 0), reused 0 (delta 0), pack-reused 87605
Receiving objects: 100% (87605/87605), 21.94 MiB | 11.84 MiB/s, done.
Resolving deltas: 100% (53011/53011), done.
>>> Git clone in /var/lib/portage/coreos-overlay successful
Note: switching to 'refs/tags/stable-2905.2.2'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at e63358f38 Merge pull request #1191 from kinvolk/linux-5.10.59-flatcar-2905
>>> Release checkout refs/tags/stable-2905.2.2 in /var/lib/portage/coreos-overlay successful
!!! Section 'portage-stable' in repos.conf has location attribute set to nonexistent directory: '/var/lib/portage/portage-stable'
!!! main-repo not set in DEFAULT and PORTDIR is empty.
Unavailable repository 'portage-stable' referenced by masters entry in '/var/lib/portage/coreos-overlay/metadata/layout.conf'
!!! Unable to parse profile: '/etc/portage/make.profile'
!!! ParseError: Parent 'portage-stable:default/linux/amd64/17.0/no-multilib/hardened' not found: '/var/lib/portage/coreos-overlay/profiles/coreos/amd64/parent'
Undefined license group 'EULA'

Performing Global Updates
(Could take a couple of minutes if you have a lot of binary packages.)

!!! Section 'portage-stable' in repos.conf has location attribute set to nonexistent directory: '/var/lib/portage/portage-stable'
!!! main-repo not set in DEFAULT and PORTDIR is empty.
Unavailable repository 'portage-stable' referenced by masters entry in '/var/lib/portage/coreos-overlay/metadata/layout.conf'
!!! Unable to parse profile: '/etc/portage/make.profile'
!!! ParseError: Parent 'portage-stable:default/linux/amd64/17.0/no-multilib/hardened' not found: '/var/lib/portage/coreos-overlay/profiles/coreos/amd64/parent'
Undefined license group 'EULA'
!!! Your current profile is invalid. If you have just changed your profile
!!! configuration, you should revert back to the previous configuration.
!!! Allowed actions are limited to --help, --info, --search, --sync, and
!!! --version.
Traceback (most recent call last):
  File "/usr/lib/python-exec/python3.6/emerge-gitclone", line 68, in <module>
    subprocess.check_call(['emerge', '--check-news', '--quiet'])
  File "/usr/lib64/python3.6/subprocess.py", line 291, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['emerge', '--check-news', '--quiet']' returned non-zero exit status 1.```

Not sure if the loopback error is important.. then I get a proxy error.. not sure why as above commands worked via the proxy..
emerge -gKv coreos-sources

Calculating dependencies -Unable to configure loopback interface: Operation not permitted
 /Unable to configure loopback interface: Operation not permitted
 \Unable to configure loopback interface: Operation not permitted
 |Unable to configure loopback interface: Operation not permitted

......

>>> Installing (4 of 5) sys-devel/flex-2.6.4-r1::portage-stable
Unable to configure loopback interface: Operation not permitted
 * checking 5 files for package collisions
>>> Merging sys-devel/flex-2.6.4-r1 to /
 * Running stacked hooks for pre_pkg_preinst
 *    wrap_old_config_scripts ...                                                                                [ ok ]
--- /usr/
--- /usr/include/
>>> /usr/include/FlexLexer.h
--- /usr/lib64/
>>> /usr/lib64/libfl.a
--- /usr/bin/
>>> /usr/bin/flex
>>> /usr/bin/flex++ -> flex
--- /usr/lib/
>>> /usr/bin/lex -> flex
>>> sys-devel/flex-2.6.4-r1 merged.
>>> Regenerating /etc/ld.so.cache...
Unable to configure loopback interface: Operation not permitted

>>> Emerging binary (5 of 5) sys-kernel/coreos-sources-5.10.59::coreos
 * Fetching in the background:
 * /var/lib/portage/pkgs/sys-kernel/coreos-sources-5.10.59.tbz2.partial
 * To view fetch progress, run in another terminal:
 * tail -f /var/log/emerge-fetch.log
--2021-08-23 14:19:49--  https://storage.googleapis.com/flatcar-jenkins/boards/amd64-usr/2905.2.2/pkgs/sys-kernel/coreos-sources-5.10.59.tbz2
Resolving zproxy... <IP_ADDRESS>
Connecting to zproxy|X.X.X.X|:10074... connected.
Proxy request sent, awaiting response... 403 Forbidden
2021-08-23 14:19:54 ERROR 403: Forbidden.

>>> Failed to emerge sys-kernel/coreos-sources-5.10.59, Log file:

>>>  '/var/log/portage/sys-kernel:coreos-sources-5.10.59:20210823-141949.log'

Not sure if the loopback error is important.. then I get a proxy error.. not sure why as above commands worked via the proxy..
emerge -gKv coreos-sources

Calculating dependencies -Unable to configure loopback interface: Operation not permitted
 /Unable to configure loopback interface: Operation not permitted
 \Unable to configure loopback interface: Operation not permitted
 |Unable to configure loopback interface: Operation not permitted

......

>>> Installing (4 of 5) sys-devel/flex-2.6.4-r1::portage-stable
Unable to configure loopback interface: Operation not permitted
 * checking 5 files for package collisions
>>> Merging sys-devel/flex-2.6.4-r1 to /
 * Running stacked hooks for pre_pkg_preinst
 *    wrap_old_config_scripts ...                                                                                [ ok ]
--- /usr/
--- /usr/include/
>>> /usr/include/FlexLexer.h
--- /usr/lib64/
>>> /usr/lib64/libfl.a
--- /usr/bin/
>>> /usr/bin/flex
>>> /usr/bin/flex++ -> flex
--- /usr/lib/
>>> /usr/bin/lex -> flex
>>> sys-devel/flex-2.6.4-r1 merged.
>>> Regenerating /etc/ld.so.cache...
Unable to configure loopback interface: Operation not permitted

>>> Emerging binary (5 of 5) sys-kernel/coreos-sources-5.10.59::coreos
 * Fetching in the background:
 * /var/lib/portage/pkgs/sys-kernel/coreos-sources-5.10.59.tbz2.partial
 * To view fetch progress, run in another terminal:
 * tail -f /var/log/emerge-fetch.log
--2021-08-23 14:19:49--  https://storage.googleapis.com/flatcar-jenkins/boards/amd64-usr/2905.2.2/pkgs/sys-kernel/coreos-sources-5.10.59.tbz2
Resolving zproxy... X.X.X.X
Connecting to zproxy|X.X.X.X|:10074... connected.
Proxy request sent, awaiting response... 403 Forbidden
2021-08-23 14:19:54 ERROR 403: Forbidden.

>>> Failed to emerge sys-kernel/coreos-sources-5.10.59, Log file:

>>>  '/var/log/portage/sys-kernel:coreos-sources-5.10.59:20210823-141949.log'

Running curl -L --cacert ./zsc.pem https://storage.googleapis.com/flatcar-jenkins/boards/amd64-usr/2905.2.2/pkgs/sys-kernel/coreos-sources-5.10.59.tbz2 -o /var/lib/portage/pkgs/sys-kernel/coreos-sources-5.10.59.tbz2 works but running the emerge command still fails due to proxy


Possibiliy of running from Windows Host

Hello there,
Apologies on opening this as an issue - but I wanted to run the question by. I'm curious if you or anyone else has had any luck with getting this to run on a Windows host. I had to add --cap-ad NET_ADMIN from the command line in order to get it to run, and with some trial and error I got past the next hurdle regarding KVM acceleration. Ultimately, I was able to get the command to take with the following:
docker run -it --rm --name windows -p 8006:8006 --cap-add NET_ADMIN -e KVM=N --stop-timeout 120 dockurr/windows
Unfortunately I was met with the following errors, and leaving it run here for about an hour or so yielded no progress.
BdsDxe: failed to load Boot0002 "UEFI QEMU QEMU HARDDISK " from PciRoot(0x0)/Pci(0xA,0x0)/Scsi(0x0,0x0): Not Found
BdsDxe: loading Boot0001 "UEFI QEMU QEMU CD-ROM " from PciRoot(0x0)/Pci(0x5,0x0)/Scsi(0x0,0x0)
BdsDxe: starting Boot0001 "UEFI QEMU QEMU CD-ROM " from PciRoot(0x0)/Pci(0x5,0x0)/Scsi(0x0,0x0)

Has anyone had any success running from a Windows host (in my case, Windows 10 x64 with Virtualization / Hypervisor enabled at BIOS level) - and if so, what sort of variables/options were needed in order to run it?
Thank you - and my apologies for the question inserted as an Issue, I did try to search open issues to no avail - it wasn't after some digging that I realized that this seems to be designed with Linux in mind.

Thank you so much for the reply! So this time, I didn't see the error message on the VNC console but it was present in the command prompt where I kicked it off.
Unfortunately, it hung at a similar spot - I didn't capture a screenshot. Perhaps if my host was Win11 instead of Windows 10 I would have different results, but alas! Darn - appreciate the reply still. I'd continue trying options if there are any, otherwise I may accept my fate here unless something changes.
I was hoping to have a really quick Docker sandbox of a Windows machine I can use for testing applications/etc was my ultimate goal, as opposed to using a traditional virtual machine through VirtualBox/Hyper-V/VMware/etc


Do http-log plug-ins support idempotentity?

Does the http-log plug-in support idempotentity, and when my kong node goes down and restarts, can the logs be recorded in its entirety and sent to the http side again?Will it be consumed repeatedly?

Currently there is no persistent handling of logs in Kong. If Kong restarts, all logs that has not been flushed to the log server will be lost, and Kong will not try to send them again when it restarts.
There has been some discussion about this previously: https://github.com/Kong/kong/issues/4736

Closing due to inactivity and issue is being tracked elsewhere already.


Update vjp and jvp of power

x ** y have been already computed in ans, which can be replaced

👍 thanks!


impl Div and Rem for xxx

One obvious optimization that is possible with NonZeroXxx aside from simply elision of extra storage for Option<NonZeroXxx> is that it enables safe unchecked code that skips divide by zero checking.
It would be nice if, e.g., Rem<NonZeroUsize> were implemented for usize such that this would be a valid operation:
fn fast_and_safe(dividend: usize, divisor: NonZeroUsize) -> usize {
    dividend % divisor
}

This would be guaranteed panic free and there would be no need to generate the code that handles the case where divisor is zero.

https://github.com/rust-lang/rust/pull/79134

@sfackler thanks! I searched with a few variations of the type name and didn't find anything. (Maybe we should add a "keywords: ..." convention)


Add tests

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@cf48eea). Click here to learn what that means.
The diff coverage is 100%.

@@           Coverage Diff            @@
##             master     #22   +/-   ##
========================================
  Coverage          ?   44.8%
========================================
  Files             ?      23
  Lines             ?     770
  Branches          ?       0
========================================
  Hits              ?     345
  Misses            ?     376
  Partials          ?      49

Impacted Files
Coverage Δ

structs/pricing.response.types.go
13.08% <100%> (ø)

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 cf48eea...6e07e6d. Read the comment docs.


Switcheroo variables passed to decorator

For full-fat type checking of arbitrary length containers, instead of providing wrapped built in types that must be imported, wrap them at runtime and swap them out in place. Maybe this is only possible in cpython and relies on implementation details?

Sweetness. I love this sort of abstract rumination. As the physical world melts down around us, let us bravely cogitate!

Meanwhile, this is Python. CPython itself prohibits directly monkey-patching builtin types:
>>> list.append = lambda self, obj: self.append(obj + ' uhoh')
TypeError: can't set attributes of built-in/extension type 'list'

As you suggest, this is circumventable by replacing builtin types with comparable subclasses via the stdlib builtins module:
>>> import builtins
>>> class UnicornList(list):
>>>     def append(self, obj): super().append(obj + ' ohnoudint')
>>> builtins.list = UnicornList
>>> crabrave_list = list(('dis', 'is', 'balls'))
>>> crabrave_list.append('uwutm8')
>>> print(crabrave_list)
['dis', 'is', 'balls', 'uwutm8 ohnoudint']

So what's the Gordian knot here?
Syntactic sugar. Lists typically aren't explicitly instantiated via their builtin type name; they're instantiated via [- and ]-delimited syntactic sugar. For unknown reasons that exceed my meagre intellect, the above approach does not apply to lists instantiated via the standard approach:
>>> crabrave_list = ['dis', 'is', 'balls']
>>> crabrave_list.append('uwutm8')
>>> print(crabrave_list)
['dis', 'is', 'balls', 'uwutm8']

Since a solution that only solves the least likely of two possible cases is no solution, our hands are tied by CPython internals implemented well before even more important stuff like Doom and GeoCities and poorly maintained GeoCities sites about Doom were first created.

Maybe this is only possible in cpython and relies on implementation details?

Yes. Yes, it does.
Technically, a risky third-party library named forbiddenfruit that no one is supposed to know about or ever use does exist. Pragmatically, this library commonly causes fatal runtime segfaults, requires use of a function called curse, appears to have only been tested up to Python 3.3, and (in any case) only applies to CPython.
But let's leave this issue open. I'd love to find the Shangri La of builtin monkey-patching techniques that would safely, portably, and efficiently enable us to transparently "improve" core container types across Python interpreters. Someone who is smarter than me: help us and all the Internet karma will be yours.

And let's not forget this:

Even if you got all of this right, the C level code that directly calls the PyList_* or PySequence_Fast* APIs bypasses lookup of __setitem__/mp_ass_subscript/sq_ass_item entirely, so your code wouldn't be invoked. – ShadowRanger

Thanks, ShadowRanger, for destroying our collective hopes and dreams.
tl;dr
can't. be. done. probably.

That said, I just ideated a few helpful heuristics for deeply type-checking a few common types of containers – all with amortized time complexity O(1).
Hashability Is Deep Immutability... Mostly
The core insight here is that there effectively exists a one-to-one mapping between hashability and deep immutability in Python, excluding the well-known caveat of user-defined mutable classes whose default __hash__() implementations return their instance IDs. This caveat is trivially detectable and thus ignorable for most purposes.
Why is this useful? Because we only need to type-check deeply immutable objects once. Makes sense, it does. Note the meaningful distinction between deep and shallow immutability, however; a tuple is guaranteed to be shallowly but not deeply immutable. This means that we walk softly and carry a big stick.
Although there exists no means of directly deciding whether an object is deeply immutable in Python, there does exist a means of directly deciding whether an object is hashable in Python: e.g.,
obj = ('TNT', ["it's", "dynamite"])
is_obj_hashable = False
try:
    hash(obj)
    is_obj_hashable = True
except:
    pass

Although tuples are of course shallowly immutable, tuples containing mutable objects are not hashable and thus not deeply immutable. The above example demonstrates this by defining a tuple containing an immutable object (i.e., a string) and a mutable object (i.e., a list) and then attempting to hash that tuple, which raises a TypeError that we conveniently ignore.
The above snippet successfully detects hashability and thus deep immutability for builtin types, but yields false positives for user-defined mutable types. There exist three cases here:

The common case, in which a user-defined class fails to override the __hash__() dunder method and thus inherits that method from object, whose default implementation of that method simply returns that object's ID.
The uncommon non-erroneous case, in which a user-defined class correctly overrides that method to either:

If instances of that class are mutable, return None. This is the standard idiom to indicate unhashability in Python.
If instances of that class are immutable, return something non-None.

The uncommon erroneous case, in which a user-defined mutable class incorrectly overrides that method to return something non-None. That's bad, but there's mostly nothing we can do about that. User errors are on the user. PEBKAC is our sole defence, bro!

The common case case must be explicitly guarded against. The uncommon non-erroneous case needn't be guarded against, because it behaves as expected. The uncommon non-erroneous case needn't be guarded against either, because it's a low-level error beyond our control or capacity to detect.
Thankfully, guarding against the common case is easy. Just exclude types whose __hash__() dunder method is exactly the object.__hash__() dunder method: e.g.,
class LetThereBeBeartype(object): pass
obj = LetThereBeBeartype
is_obj_hashable = False
try:
    hash(obj)
    is_obj_hashable = type(obj).__hash__ is not object.__hash__
except:
    pass

This extension now accurately detects hashability and thus deep immutability. There are performance concerns even here, however:

Hashing time complexity. Although the builtin hash() function is known to be reasonably fast, this only applies to builtin scalar types that internally cache their hashes (e.g., str, int). The tuple.__hash__() implementation is a notable counterexample; to reduce space complexity, this implementation intentionally does not internally cache its hash. Since this implementation's time complexity is O(len(tuple)), naively hashing arbitrary objects passed to and returned from @beartype-decorated callables is a BadIdea™.
Hashing space complexity. The prior concern can, of course, be ameliorated by an internal @beartype hash cache mapping from object ID to hash. Builtin scalar types already internally cache hashes and would thus be omitted from this cache. For efficiency, all other objects would need to be cached. The space complexity required to do so could rapidly become ugly. That concern can, of course, also be ameliorated by limiting the size of that cache in an intelligent manner – like, say, with the Least Recently Used (LRU) replacement strategy implemented by the builtin @functools.lru_cache decorator, which appears to have reasonable performance. If that fails, there's also this clever LRU dictionary implementation.

Phew! So, hashing time and space complexity is a demonstrable concern – but only trivially so, because we can hack around those concerns with sufficient foresight, which we have.
...So Good, So What?
By the above argument, we see that we can efficiently decide whether arbitrary objects are deeply immutable or not. That's good, because deeply immutable objects only need to be type-checked once.
Here's how we do that:

Add a new private beartype._decor.cache submodule declaring at least the following functions:

is_object_immutable_deep(), a @functools.lru_cache-decorated function accepting an arbitrary object and returning True if and only if that object is deeply immutable by the above algorithm. Since caching object ID <-> boolean pairings has trivial space complexity, this LRU cache should be stupidly large.
beartype_object_immutable_deep(), a @functools.lru_cache-decorated function accepting a deeply immutable object and associated type hint and unconditionally returning None after deeply type-checking that object. Thanks to LRU caching, this should have the intended effect of only deeply type-checking that object on the first call to that function with that object. Since caching object ID <-> None pairings has even more trivial space complexity, this LRU cache should be even stupidly larger than that of is_object_immutable_deep().

In the @beartype decorator implementation:

For each deeply immutable object type-hinted with PEP 484-compliant deep hinting (e.g., typing.Tuple[str]) either passed to or returned from a @beartype-decorated callable: Note that all keys of all mappings are guaranteed to be of immutable types, so we needn't test them.
If is_object_immutable_deep() returns True, unconditionally call beartype_object_immutable_deep().

Of course, we can probably optimize a bit of that heuristic way – in theory, anyway. Rather than the is_object_immutable_deep() function, what we really want is a function that decides whether an arbitrary PEP 484-compliant type hint describes a deeply immutable type or not. typing.Tuple[str] does, for example, but both typing.Tuple[List[str]] and typing.List[str] do not. While the is_object_immutable_deep() function is trivially implemented (as above), deciding the deep immutability of typing types is probably not trivial implemented. There's no well-defined ABC or Protocol governing immutability or mutability, so it's unclear exactly how we would generalize that. In any case, is_object_immutable_deep() probably suffices for now.
The above then gives us amortized time complexity O(1) for deeply type-checking all deeply immutable types. That sounds nice, doesn't it? Since deeply immutable types probably constitute a reasonable fraction of all container types, we're well on our way to type-checking first Berlin, then Manhattan, and then... the World! muhah–cough, wheeze

beartype 0.1.0 is now live (and maybe worky) on PyPi, much to the astonishment of my weary brainpan: :sleepy:
pip3 install beartype

@terrdavis: I definitely missed this commentary on my earlier speedread of your Gist:

It tests for the new error "TypeError: Subscripted generics cannot be used with class and instance checks" by always attempting to use the __origin__ attribute of Generic types for instance checks. I also did some refactoring.

That's super-exciting stuff, bro. When I get the chance, I'd love to integrate that into the upcoming beartype 0.1.1 release – I think, anyway. Volunteer time is scarce for me at the moment, but all of that sounds wondrous. Of course, pull requests are always welcome as well... :grinning:

Note to self: related commentary from several months ago at @terrdavis' awesome gist fork, mostly pertaining to randomly selected type-checking of deeply nested containers. It is fun.

And so it came to pass that in the third day of the ninth month of the Year of Our COVID this issue was summarily terminated, nobody having even the foggiest of a glimmer of an inkling of a cogent idea about how to sanely resolve it.
Actually... that's a bald-faced lie. @albanie, I believe it was, had a brilliantly simple solution that I've since toyed around with and come to see the value-added benefit of: just randomly type-check one item from each container on each call. Assuming a sufficient number of calls, this heuristic eventually type-checks all items from each container with hard statistical guarantees inspired by the coupon collector's problem. Basically, you need n logn calls repeatedly passed the same container to type-check all items from that container – on average, anyway. What won't those credentialed statisticians think up next?
So, this might not necessarily be the unsolvable issue we thought it once was. Or maybe it still is. Feel to free to reopen this if you're suddenly assaulted by some clever hackery in the middle of the night. Until then, this is...
closed for business :door:


End-user requests management

From<EMAIL_ADDRESS>on January 18, 2011 16:37:24
Must be provided the functionality to manage enduser requests
Original issue: http://code.google.com/p/syncope/issues/detail?id=77

From chicchiricco on April 11, 2011 03:45:40
Requests user-initiated (like as self-management requests, for example) will be managed (input, actions, review, status, ...)
Summary: End-user requests management
Labels: Milestone-Release-2011Q3

From chicchiricco on April 12, 2011 09:29:08
Labels: -Milestone-Release-2011Q3 Milestone-Release-201112

From chicchiricco on September 19, 2011 05:16:13
Blocking: 167

From chicchiricco on September 19, 2011 05:23:25
A new section on the administration console will be provided ("TODO"), showing, for administrators, which requests have to be / have been approved, with all related information.

From chicchiricco on October 20, 2011 05:42:19
This issue was closed by revision r1207 .
Status: Fixed


the secondary sidebar overlap with the primary sidebar

@jorisvandenbossche, I think it's coming from https://github.com/pydata/pydata-sphinx-theme/commit/2e88b0f66695a182ddb077cbf7d9eff55e4f9532 but in dev version on my macBook pro 13" the secondary sidebar overlap under the primary one as shown on this image (https://pydata-sphinx-theme--637.org.readthedocs.build/en/637/demo/kitchen-sink/paragraph-markup.html):

PS: you need to scroll down to the bottom to see the secondary as it's displayed after the prev-next line

nailed it:
it's coming from https://github.com/pydata/pydata-sphinx-theme/blob/281e10393217a5cd20c8426a5aa0dedf0f43da8b/src/pydata_sphinx_theme/theme/pydata_sphinx_theme/layout.html#L79
I think this variable is only defined in the docs_tocblock. It's out of scope when it's required line 95.


Unable to connect to new Container App

Please provide us with the following information:

This issue is a: (mark with an x)

[X] bug report -> please search issues before submitting
[ ] documentation issue or request
[ ] regression (a behavior that used to work and stopped in a new release)

Issue description
A clear and concise description of the observed issue.
Steps to reproduce

follow Quickstart  and create container app in canadacentral via CLI using PowerShell

Expected behavior [What you expected to happen.]
I expected to be able to view the new app in a browser
Actual behavior [What actually happened.]
The browser timed out (multiple times over 12+ hours)

Screenshots
There is a full video here: Deploy a Python app to Azure Container Apps
Additional context
Ex. Did this issue occur in the CLI or the Portal?
CLI
Here's some additional information.
The Container App above that is failing is located here:
Resource Group: charris-container-app01
Container app: https://my-container-app.blackcliff-4e19c3d1.canadacentral.azurecontainerapps.io/
I created a 2nd container app in the same RG, and it is also failing due to timeout.
This morning, I created a new container app in a new RG, but same region (canadacentral) and this one is working:
Resource Group: charris-container-app2
Container app: https://charris-containerapp2.happyriver-56be0df4.canadacentral.azurecontainerapps.io/

Here is the subscription ID: 1163fbbe-27e7-4b0f-8466-195fe5417043
The env name in both RGs is: my-environment

@charris-msft Once you were able to get a container app going, do you know if subsequent creations also worked?
I've tried doing the quickstart with both portal and cli, tried across many different resource groups, environments , etc. (mostly trying to stick to Central Canada, but I tried others as well).
but all of my container apps give me the same timeout.
most recent attempt here: https://asdlfl.mangobush-60d3a0c5.canadacentral.azurecontainerapps.io
I was hoping that waiting long enough to give it all some breathing room and then maybe creating yet another new one would end up working, but to no avail as of yet.

Hi, sorry for the inconvenience. The issue was caused by the reourses migration. It has already been resolved. Can you please have a try?


📝 chore(docs): Add Introduction section

Current dependencies on/for this PR:

new-dawn

PR #1069   👈

This stack of pull requests is managed by Graphite.


granted: 0.18.0 -> 0.19.2

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/common-fate/granted/releases.
meta.description for granted is: The easiest way to access your cloud.
meta.homepage for granted is: https://github.com/common-fate/granted
meta.changelog for granted is: https://github.com/common-fate/granted/releases/tag/0.19.2
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.19.2 with grep in /nix/store/d4s4jaw0h7k6zrf53cv2ckrfj7xvm9am-granted-0.19.2
found 0.19.2 in filename of file in /nix/store/d4s4jaw0h7k6zrf53cv2ckrfj7xvm9am-granted-0.19.2

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
granted

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/d4s4jaw0h7k6zrf53cv2ckrfj7xvm9am-granted-0.19.2 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A granted https://github.com/r-ryantm/nixpkgs/archive/a18d8396867bf7c001635df2a8b1a68211b26d7e.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/a18d8396867bf7c001635df2a8b1a68211b26d7e#granted

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/d4s4jaw0h7k6zrf53cv2ckrfj7xvm9am-granted-0.19.2
ls -la /nix/store/d4s4jaw0h7k6zrf53cv2ckrfj7xvm9am-granted-0.19.2/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

granted

Maintainer pings
cc @ivankovnatsky for testing.

Result of nixpkgs-review pr 265081 run on aarch64-darwin 1

1 package built:

granted


Create Dockerfile

github lab proba actions #2

I'll respond in your new pull request with next steps.


Documentation Improvements

Description:
There are some areas that we should cover in the documentation, such as.

Ingress creation for TCP endpoints
Port forwarding doc for quick testing purposes

Fixed in https://github.com/siddhi-io/www/commit/7395cb9ea3585616a738e05f43d338c3dd37d505#diff-9a173c923376a7fc038eb53c9458f71a ...


First-class Nix knowledge of reproducible builds

Debian is putting a lot of effort into getting full reproducibility, and I'm hoping we might be able to piggyback off of it. Has there been any effort to carry any of those patches over?
We also have the underused nix-build --check tool which would be nice to run during CI, at least on things that we declare to be reproducible.
One nice feature we could have is to add an attribute on a derivation called meta.reproducible. This would instruct Hydra (or some kind of build helper tool) to try running nix-build --check on it, because the package maintainer believes it should be reproducible. A builder would raise an error if it turned out not to be byte-for-byte identical, and we could have some sort of "verify trust" on supposedly reproducible builds that with probability p tries rebuilding substitutes from upstream and makes lots of noise if things don't match up.

It's way more complicated than that. If you want to be sure the build is binary deterministic, you need at least two different environments that differ in a lot of things and then you can compare the results.

Running in a chroot build seems mostly sufficient these days, right? It's basically a full container already, with isolated network, filesystem, PIDs, and so on.

Yeah, that's correct, our isolated environments help a lot. It would be still interesting to see difference between two builds of release-15.09 binaries.

We should package stuff from https://reproducible-builds.org/tools/

The tools from https://reproducible-builds.org/tools/ are now packaged. See ba5402a32822193577219cef2682359c2e3587e1, 5f34fb2c16e2e471e584a7d4488ed098fff7180f and 5e0dca6d062fdce53be93d2f99ddffb8e52f5ae7.

is somebody working on this? how would one go to use nix-build --check with diffoscope? to compare the outputs?

@copumpkin With https://github.com/NixOS/nix/commit/8fdd156a650f9b2ce9ae8cd74edcf16225478292 and the tools packaged, would you consider this closed for now?

close?


filters in generic API are not working anymore

filters in the generic API routes are not applied, all objects are returned
In Tibschool instance is working as intended, using this commit (https://github.com/acdh-oeaw/apis-core-rdf/commit/dff296b)

@stefanprobst thats the issue tracking the broken filters


x:Bind not working with StateTrigger

Describe the bug
The application crash when using x:Bind to set the StateTrigger.IsActive property.
Steps to reproduce the bug
Add the following XAML code in the MainWindow XAML of a blank WinAppSDK C# app:
<StackPanel>
    <ToggleButton
        x:Name="toggleStates"
        Content="Toggle states"
        IsChecked="False" />

    <TextBlock x:Name="toggleStatus" Text="Off" />

    <VisualStateManager.VisualStateGroups>
        <VisualStateGroup>
            <VisualState>
                <VisualState.StateTriggers>
                    <StateTrigger IsActive="{x:Bind toggleStates.IsChecked.Value, Mode=OneWay}" />
                </VisualState.StateTriggers>
                <VisualState.Setters>
                    <Setter Target="toggleStatus.Text" Value="On" />
                </VisualState.Setters>
            </VisualState>
        </VisualStateGroup>
    </VisualStateManager.VisualStateGroups>
</StackPanel>

Run the application.
It crashes at startup because the StateTrigger instance is null in
private static class XamlBindingSetters
{
   public static void Set_Microsoft_UI_Xaml_StateTrigger_IsActive(global::Microsoft.UI.Xaml.StateTrigger obj, global::System.Boolean value)
    {
        obj.IsActive = value;  // <-- obj is null
    }
};

Expected behavior
The generated code should work as in UWP apps where this was working without any issue.
Screenshots
No response
NuGet package version
WinUI 3 - Windows App SDK 1.5.1: 1.5.240311000
Windows version
Windows 11 (22H2): Build 22621
Additional context
No response

This will not work in Window you need a Page

@vgromfeld did you try elsewhere?
Otherwise I guess it's related to https://github.com/microsoft/microsoft-ui-xaml/issues/5515


update starsector to 0.96a-RC7

Description of changes
https://fractalsoftworks.com/2023/05/05/starsector-0-96a-release/
Things done

Built on platform(s)

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

[x] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

recreated #230211 without everyone being subscribed.

You should split it into two commits, the first one maintainers: add lizelive, and the second one starsector: 0.95.1a-RC6 -> 0.96a-RC7.

fyi a hotfix RC8 has been released

fyi a hotfix RC8 has been released

cool ill make another pr. please approve #230913 per @wegank request

Well I can't approve things, but I'm pretty sure you could've just force-pushed two consecutive commits in this pull request - and also update to RC8 at the same time

@wegank if i rebase it will notify everyone

@wegank it was very rude to close #230913 after asking for that shit. I made another pr #230954 if someone wants to approve that i will reraise this pr.

@wegank if i rebase it will notify everyone

Not at all.

@wegank it was very rude to close #230913 after asking for me to split into two and blocking this pr. I made another pr #230954 if someone wants to approve that i will reraise this pr with latest version

I'm sorry for my possible rudeness.
To be clear, I never asked you to create another PR. What I asked for was to split a commit into two, each with an appropriate commit message, so that your PR would meet the standard of the repo (including CONTRIBUTING.md which you've falsely ticked). I don't think it's too difficult to do that.

@wegank thank you for apology, and i had to recreate the pr anyhow because i can't reopen it.
I have to apologize as well. I initially misread the CONTRIBUTING.md and your advice was really solid and correct. i followed it in #230958
but CONTRIBUTING.md does not include a policy for having a pr that just adds someone to contributes. there is a line about it here https://nixos.org/manual/nixpkgs/unstable/#var-meta-maintainers.
thank you for your advice.


Input validation consistency

Hi Milan,
Thanks a bunch for this awesome project—it's exactly what I've been searching for!
I'm pretty new to clean architecture and DDD, and I've got a couple of questions about keeping things consistent with input rules, like checking for not null or empty and setting maximum lengths. I'd love to hear your thoughts.
The not null/empty rules are in the Domain layer, but they're also duplicated in the Application layer. So, when I need to change the rules, I have to make updates in two places. There's a risk that a developer might forget to update one of them. Any best practices for solving this?
The max length rules are in the Application layer. Should I also have the same rules in the Domain layer? If not, why do we have not empty rules in both layers? If yes, it brings me back to my first question.
Looking forward to your insights.
Best regards.

Y


Validation: Removed Absolute Links

Category

[x] Content fix
[ ] New article

Related issues
This PR is part of the Validation cleanup efforts.
Removed absolute links.

Docs Build status updates of commit 4892e6a:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs/spfx/publish-to-marketplace-after-publishing.md
:warning:Warning
View
Details

docs/spfx/publish-to-marketplace-after-publishing.md

Line 2, Column 1: [Warning: ms-prod-and-service - See documentation] Only one of the following attributes can exist: 'ms.prod', 'ms.service'. Use ms.prod for on-premise products, or ms.service for cloud services.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 69ef6dc:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs/spfx/publish-to-marketplace-after-publishing.md
:warning:Warning
View
Details

docs/spfx/use-aadhttpclient.md
:warning:Warning
View
Details

docs/spfx/use-theme-colors-in-your-customizations.md
:warning:Warning
View
Details

docs/spfx/publish-to-marketplace-after-publishing.md

Line 2, Column 1: [Warning: ms-prod-and-service - See documentation] Only one of the following attributes can exist: 'ms.prod', 'ms.service'. Use ms.prod for on-premise products, or ms.service for cloud services.

docs/spfx/use-aadhttpclient.md

Line 2, Column 1: [Warning: ms-prod-and-service - See documentation] Only one of the following attributes can exist: 'ms.prod', 'ms.service'. Use ms.prod for on-premise products, or ms.service for cloud services.

docs/spfx/use-theme-colors-in-your-customizations.md

Line 2, Column 1: [Warning: ms-prod-and-service - See documentation] Only one of the following attributes can exist: 'ms.prod', 'ms.service'. Use ms.prod for on-premise products, or ms.service for cloud services.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 32666df:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs/spfx/publish-to-marketplace-after-publishing.md
:warning:Warning
View
Details

docs/spfx/use-aadhttpclient.md
:warning:Warning
View
Details

docs/spfx/use-theme-colors-in-your-customizations.md
:warning:Warning
View
Details

docs/spfx/publish-to-marketplace-after-publishing.md

Line 2, Column 1: [Warning: ms-prod-and-service - See documentation] Only one of the following attributes can exist: 'ms.prod', 'ms.service'. Use ms.prod for on-premise products, or ms.service for cloud services.

docs/spfx/use-aadhttpclient.md

Line 2, Column 1: [Warning: ms-prod-and-service - See documentation] Only one of the following attributes can exist: 'ms.prod', 'ms.service'. Use ms.prod for on-premise products, or ms.service for cloud services.

docs/spfx/use-theme-colors-in-your-customizations.md

Line 2, Column 1: [Warning: ms-prod-and-service - See documentation] Only one of the following attributes can exist: 'ms.prod', 'ms.service'. Use ms.prod for on-premise products, or ms.service for cloud services.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

The Content & Learning team is fixing build validation errors on docs.microsoft.com for the rest of H2. This will eliminate potential accessibility, security, and usability issues. This PR includes only build validation fixes and does not change other content. Please review within five business days and merge or comment in the PR with any changes you’d like to see. Thank you!


Inmate#run: rescue all Exception instead of just StandardError

This allows you to capture all exceptions an inmate's method might raise.
/cc @spraints

➕ 💯
Can you add a test (or modify the existing one)?

@spraints Ages later, I finally did what you asked. Thoughts?


Hamburger icon needs to replace with close icon after menu opens

Is your feature request related to a problem? Please describe.
Hamburger icon needs to replace with close icon after menu opens
Describe the solution you'd like
A clear and concise description of what you want to happen.
Additional context
Add any other context or screenshots about the feature request here.

Hello @Priyaaa1 please assign this issue to me under gssoc 24

Hello @Priyaaa1 i raised pr #608 . please check


[Android] Notification callback is not the same in foreground/background.

Describe the bug
I'm sending push notifications to an Android with the following structure:
{
	"notification": {
		"title": "My Title",
		"body": "My Message",
		"sound": "default"
	},

	"to": "<Device Token>",
	"priority":"high",
	"content_available": true
}

When the app is open, the callback is this:
{
    "tap":false,
    "body":"My Message",
    "title":"My Title"
}

But when the app is closed or background, the callback received when you tap the notification is the following:
{
    "google.sent_time":1536590283524,
    "google.ttl":2419200,
    "tap":true,
    "from":"<CODE>",
    "google.message_id":"0:1536590283530183%dafe50fedafe50fe",
    "google.priority":"high",
    "collapse_key":"<App identifier>"
}

Note that body and title field are completely missing from callback, and I need those fields to display a message inside the application.
To Reproduce
Steps to reproduce the behavior:
Send a push notification to an Android device and log its callback.
Expected behavior
I would expect to receive at least body and title field in both cases.
Desktop (please complete the following information):

OS: MacOS High Sierra 10.13.4

Smartphone (please complete the following information):

Device: Samsung A7 and Huawei P7
OS: Android 6.0.1

Additional context
I'm currently using Ionic 3. Tested with version 2.0.0 of this plugin.

Are you trying to differentiate your notifications based on the title/body?  If so, you might consider the best practice of passing a url or other unique data in the data section of the notification and key off of that.  I know for a fact that works with the plugin as I use that myself.
By doing this, you can also avoid any issues you may have during translations when the title/body represent that same text but are actually different.
You can see the documentation here on how to add the extra property to your notification you create, https://firebase.google.com/docs/cloud-messaging/concept-options#notification-messages-with-optional-data-payload

Hi @briantq
Thanks for your advice. I was expecting the same behavior because in the past I used phongap-push-notifications, and that gave me always the same callbacks.
Thanks again, additional fields worked fine in android and ios, and in both modes (foreground and background).

@Cirivas I am glad it worked.  I have only been working with Cordova for less than a month, much of my effort on push notifications so I have been trying to find all the best practices I can.  If I can save others time and head ache, I am more than happy to help!


How to pass coordinante (x,y) on screen device to getControllerForwardAsync()

I am trying build feature measure distance by using Viro-React. I mesuared distance between two node when I click into ARScene. I used getControllerForwardAsync() to do it. But now, I have a issue. I want convert coordinantes at one point in screen of device (x,y) to coordinantes of ARScene (x,y,z) and function getControllerForwardAsync() will receive this coordinantes to input.
The purpose is when I click in one point with fixed position then getControllerForwardAsync() will get position in this for input.
How to do it ? Thank All.

Hey @betieu , to find a position in the world with device coordinates, you could try performing an AR hit test, given the device's screen coordinates.
performARHitTestWithPoint as shown here

Thank for the reply ! I will try it.


Bump up clair to v2.0.4

This commit bump up clair to v2.0.4.  The current build process is
download the binary from google storage, the update of the binary in
google storage is not reflected in this commit.
Verified on a patched environment.

Pull Request Test Coverage Report for Build 7623

0 of 0   changed or added relevant lines in 0 files are covered.
2 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.006%) to 65.205%

Files with Coverage Reduction
New Missed Lines
%

src/common/scheduler/scheduler.go
2
81.87%

Totals

Change from base Build 7622:
-0.006%

Covered Lines:
11643

Relevant Lines:
17856

💛  - Coveralls


1.1.1 beta1 release commits

Should I create the branch before or after I merge these?

Before.  I think 1.1.1-pre3 should be on that branch, not on master.

Can we keep master frozen for awhile and then rebase all the fixes onto it?

Can we keep master frozen for awhile and then rebase all the fixes onto it?

If we were going to do that then it would be better not to create the branch at all!! It's a bit late in the day for that!!

Yeah, I don't think that's a good idea...

I am curious why you don't think it's a good idea, @levitte.  I also don't see why keeping master frozen requires doing anything other than what we're aleady doing.

I'm holding the release until this is resolved (I am literally sat here about to push the branch creation).

@mattcaswell is entirely correct, if we freeze master "for a while", there's really no point in creating a 1.1.1 branch at all.  Our published plan, though, is to create this branch.
There is work going on that is for post-1.1.1 that has been on pause for a while (because we've obviously worked only on 1.1.1 stuff), you want to prolongue that further?

Of course I can see where you're going, you want to make sure that everything we do is about 1.1.1, no "distractions" such as post-1.1.1 stuff.  I'm just not at all sure this is the right path to take.

If there is any doubt about whether we should create the branch then we can decouple it from the release. We can create the branch at any time - it doesn't need to be at the same time as a release. We could continue with the release (without creating the branch), and then take the discussion to the project list. If the consensus view is that the branch should still be created then we can do it immediately.

Also, I react at the vagueness of "for a while".

We can create the branch at any time - it doesn't need to be at the same time as a release.

That's a good point, the "starting point" of the branch is really not that important so long as the content of 1.1.1 branch doesn't differ from the master branch...  which actually makes your initial question kinda moot ;-)
(this holds at most until include/openssl/opensslv.h becomes different in the 1.1.1 and master branches)

... this actually begs the question when it's time to change the master version to 1.1.2-dev...  but that doesn't have to be answered now

My point is that we will have two months of fixes going that must be picked and tested going to two branches, and I don't see the reason for that. I would prefer we kept working off master, and kept feature submits out of it, but just keeping master locked for now seems simpler.
And yes, I want to keep us completely focused as a project on getting this release out.  As a team, we should be working on nothing else.  Keep it in your own branch, or share it if necessary.
I am disappointed that we extended the deadline and still had to squeak some third-party PR's in at the last minute. We don't seem to have discipline that we need.
I used informal words, and saying you disagree because it's vague is kinda silly.  But if you prefer, I want to keep master frozen until we are much closer to releasing 1.1.1  Maybe up until the day that we actually release 1.1.1; let the OMC decide.
Branch and proceed with the release.  Let's have a discusssion about keeping master frozen, if we need to have that discussion. And until we have it, don't unfreeze the branch. We can always keep master effectively frozen by putting -1 on all feature PR's.  And during that time, everyone will have double the amount of work.

I think that at this point, I can be satisfied with postponing branch creation and otherwise carry on with the release.

I think that at this point, I can be satisfied with postponing branch creation and otherwise carry on with the release.

Ok. @richsalz is that a good enough compromise for now, and we can continue the discussion on openssl-project?

And during that time, everyone will have double the amount of work.

I dunno about you, but I think coding and reviewing is the larger part of the job.  Cherry-picking is small stuff in comparison...

... and we can continue the discussion on openssl-project?

Good idea.

Yes I am fine with that, thanks.
As for the relative amount of work, it's also the perception and discipline that bothers me.  The team should not be working on anything other than 1.1.1 from now until it's done.

Ok, I will continue on that basis.


Manifest keys from snapkit not refldcting in project level privacy report

I am using snapkit library in our project through cocoapods.
We are using latest version which has manifest file added.
When i am generating final project level report from archive, Privacy Keys from snapkit is not included in the report.
other sdks keys are properly coming in the report.
Expected behavior
As per apple guideline all third party sdk keys should get reflected in project level privacy report combinly.
Version of Snapkit - Latest
Environmental information
Xcode 15.2.

@rinkusadhwani can you let me know another SDK that is reported fine? I don't use Cocoapods anymore and thought the integration implemented is correct as I haven't gotten other reports about it.

Hi,
Thanks for your reply.
Other SDKs like BioCatch, LPSDK ( Live Person) works perfectly fine as
expected.
There keys gets reflected in report.
Thanks,
Rinku Maharishi
On Wed, 20 Mar, 2024, 3:46 am Robert Payne, @.***>
wrote:

@rinkusadhwani https://github.com/rinkusadhwani can you let me know
another SDK that is reported fine? I don't use Cocoapods anymore and
thought the integration implemented is correct as I haven't gotten other
reports about it.
—
Reply to this email directly, view it on GitHub
https://github.com/SnapKit/SnapKit/issues/803#issuecomment-2008247649,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAXL632A3V5CPROQDGR6UXLYZC2KHAVCNFSM6AAAAABE5WFMW2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBYGI2DONRUHE
.
You are receiving this because you were mentioned.Message ID:
@.***>

Snapkit library Privacy Manifest doesn't have 'Privacy Nutrition Label Types', so you won't see it in the report.
If I'm wrong, please share your opinion.

Snapkit library Privacy Manifest doesn't have 'Privacy Nutrition Label Types', so you won't see it in the report.
If I'm wrong, please share your opinion.

This indeed might be it. Snapkit collects no data.


please use stable release of google protobuf

There are some .proto files (e.g. storage/storagepb/kv.proto and others) that use syntax = "proto3" supported by yet to be released protoc. Latest stable release of protobuf compiler 2.6.1 supports only syntax = "proto2".
Whenever possible please consider to use only stable dependencies for stable releases of Etcd.

@onlyjob We are using proto3 for gPRC. And it is for our alpha version of v3 api. So I am not worry about it until we decide to release stable version of etcd3.

I guess the concern here is for packaging the dependencies without this?
@xiangli I wonder if we should make it easier for packagers to build etcd
without any of the v3 stuff linked in.
Xiang Li<EMAIL_ADDRESS>schrieb am Sa., 6. Feb. 2016 16:56:

Closed #4446 https://github.com/coreos/etcd/issues/4446.
—
Reply to this email directly or view it on GitHub
https://github.com/coreos/etcd/issues/4446#event-541766760.

I guess the concern here is for packaging the dependencies without this?

Yes, for downstream packaging here in Debian it is quite a problem as since recent update of vendored github.com/gogo/protobuf Etcd FTBFS when built with stable release of protobuf compiler:
src/github.com/coreos/etcd/storage/storagepb/kv.pb.go:84: undefined: proto.RegisterType
src/github.com/coreos/etcd/storage/storagepb/kv.pb.go:85: undefined: proto.RegisterType

Thanks for understanding, @jonboulle.

protobuf 3 is release: https://github.com/google/protobuf/releases/tag/v3.0.0
proto3 syntax is in the stable release. so closing.


Content changes : Wallet Seed Words

[ ] Title Replace “Recovery Key” by “Wallet Seed Words”

[ ] At Bottom  "Write down and store securely. Never share, they're your
wallet's key."

[ ]

[ ] Title And QR - "Wallet Seed Words”

[ ] subtitle after 12 - Wallet Seed Words

[ ] Note - losing your - Wallet Seed Words

Done task 1 and 2,

Done 3, 4, 5 -


Update sbt-scoverage to 1.9.0

Updates org.scoverage:sbt-scoverage from 1.8.2 to 1.9.0.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scoverage", artifactId = "sbt-scoverage" } ]

labels: sbt-plugin-update, semver-minor

Codecov Report

Merging #134 (fab0aad) into master (50e95d3) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #134   +/-   ##
=======================================
  Coverage   54.41%   54.41%
=======================================
  Files           1        1
  Lines          68       68
=======================================
  Hits           37       37
  Misses         31       31

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 50e95d3...fab0aad. Read the comment docs.


Provide a Flag to Hide Icons

Icons can be a problem when interactive with pipes, to be more compatible with ls. For example:
$ lsd | grep 'foo.txt' | xargs rm  # not work
$ ls | grep 'foo.txt' | xargs rm  # works

PS. Is it a bug for lsd to print an extra line?
i.e. lsd | wc -l (always) == ls | wc -l + 1

Hi @mitnk ,
Thanks for the report. It's known that in its current state lsd doesn't work as expected with the pipes. A flag need to be added in order to make the icons optional when using pipes.
This will be fixed soon

The feature request #70 could probably help you too.

Thanks, look forward to it!


FEAT: PAR ID refs in FormatFamily arrays

changed BusinessRule.formatFamilies and FormatFamily.formatFamilies in api/par-api.yaml;
added missing formatFamilies property FormatFamily in schema/types.json; and
changed BusinessRule.formatFamilies in schema/business-rule.json.

This came with far too much WikiDP development cruft, sorry. #53 is the place to be.