Should this become ASGI framework agnostic? Nearly there

Hi there,
This was flagged on https://github.com/florimondmanca/awesome-asgi/pull/84 as a tool providing "amazing output in the developement phase". It surely looks so!
awesome-asgi is focused on tools and libraries that are as close to the ASGI spec as possible, i.e. "framework agnostic".
StarceptionMiddleware is already a pure ASGI middleware so it's already fairly agnostic.
From a quick analysis, it seems the only bit preventing this middleware from being usable with any ASGI framework is this line:
https://github.com/alex-oleshkevich/starception/blob/master/starception/middleware.py#L42
This would notably work with Starlette, which sets scope["app"] and exposes a .debug attribute. But this is not guaranteed to work for other frameworks if they don't comply with this interface (which will almost certainly be the case).
Maybe this middleware could keep the "automatic debug detection" functionality for Starlette-based framework, and rely on a debug=... parameter for other cases? Something like this...
class StarceptionMiddleware:
    def __init__(self, app, *, debug=None):
        self.app = app
        self._debug = debug

    async def __call__(self, scope, receive, send):
        ...

        try:
            debug = request.app.debug
        except AttributeError:
            if self._debug is None:
                raise RuntimeError(
                    "Could not infer whether the app is running in debug mode, as "
                    "'request.app.debug' is unavailable. "
                    "Hint: you can pass a debug flag explicitly using "
                    "'StarceptionMiddleware(app, debug=...)'."
                )
            debug = self._debug

Then, I believe the Integration with other frameworks documentation could hint at using StarceptionMiddleware(app, debug=...) instead of hinting users at using the exception_handler.
I believe that would work better because a) most (all?) of the ASGI frameworks have some middleware mounting API, but b) most frameworks that have an error handler API won't accept a Starlette Request instance.
Then I think the library would be fully framework-agnostic! On top of allowing support for the widest userbase possible, in my experience this also reduces the maintenance burden. Starlette can be hidden as an implementation detail, and not exposed in the library public API at all.
What do you think? I'll be happy to provide a PR.

Interested : I was using this package a lot on a particular project that used FastAPI then switched to Litestar and cant use it anymore which is too bad because it saves alot of time,  still using it on legacy projects though.
I remember having tried to adapt it and failed but can't remember where the issue was.

Oo I should revisit then !

The reason it works is a combination of luck and the fact that Litestar embraces ASGI (should it be featured on awesome-asgi?).
oh and a big yes !

Thanks for your interest! I don't want to use StarceptionMiddleware and will remove it someday. Because to work properly this middleware must be at the very top of the stack.
The advised way to work is exception handlers. I think the library can drop starlette dependency and become pure ASGI if it would define a request protocol and return ASGI callable as responses.
However, different frameworks have their own quirks and I am not sure if there is a generic solution. So per-framework exception handlers are good here.


torchvision C++ compiling

quesion:

When I trying to compile torchvision from source in c++ language,  the terminal thow erros:
In file included from /home/pc/anaconda3/include/python3.8/pytime.h:6:0,
from /home/pc/anaconda3/include/python3.8/Python.h:85,
from /media/pc/data/software/vision-0.9.0/torchvision/csrc/vision.cpp:4:
/media/pc/data/software/libtorch/include/ATen/core/ivalue_inl.h:647:30: error: stray ‘\343’ in program
const std::vector& slots() const {
^
/media/pc/data/software/libtorch/include/ATen/core/ivalue_inl.h:647:30: error: stray ‘\200’ in program
const std::vector& slots() const {
^
/media/pc/data/software/libtorch/include/ATen/core/ivalue_inl.h:647:30: error: stray ‘\200’ in program
const std::vector& slots() const {
^
/media/pc/data/software/libtorch/include/ATen/core/ivalue_inl.h:647:30: error: stray ‘\343’ in program
const std::vector& slots() const {
^
/media/pc/data/software/libtorch/include/ATen/core/ivalue_inl.h:647:30: error: stray ‘\200’ in program
const std::vector& slots() const {
^
/media/pc/data/software/libtorch/include/ATen/core/ivalue_inl.h:647:30: error: stray ‘\200’ in program
const std::vector& slots() const {
^
In file included from /media/pc/data/software/libtorch/include/c10/core/DispatchKey.h:6:0,
from /media/pc/data/software/libtorch/include/torch/library.h:61,
from /media/pc/data/software/vision-0.9.0/torchvision/csrc/vision.cpp:6:
/media/pc/data/software/libtorch/include/ATen/core/ivalue_inl.h:835:12: error: stray ‘\343’ in program
obj->slots().size() == 1,
^
/media/pc/data/software/libtorch/include/ATen/core/ivalue_inl.h:835:12: error: stray ‘\200’ in program
obj->slots().size() == 1,
^
/media/pc/data/software/libtorch/include/ATen/core/ivalue_inl.h:835:12: error: stray ‘\200’ in program
obj->slots().size() == 1,
^
/media/pc/data/software/libtorch/include/ATen/core/ivalue_inl.h:835:12: error: stray ‘\343’ in program
obj->slots().size() == 1,
^
/media/pc/data/software/libtorch/include/ATen/core/ivalue_inl.h:835:12: error: stray ‘\200’ in program
obj->slots().size() == 1,
^
/media/pc/data/software/libtorch/include/ATen/core/ivalue_inl.h:835:12: error: stray ‘\200’ in program
obj->slots().size() == 1,
^
/media/pc/data/software/libtorch/include/ATen/core/ivalue_inl.h:853:12: error: stray ‘\343’ in program
obj->slots().size() == 1,
^
/media/pc/data/software/libtorch/include/ATen/core/ivalue_inl.h:853:12: error: stray ‘\200’ in program
obj->slots().size() == 1,
^
/media/pc/data/software/libtorch/include/ATen/core/ivalue_inl.h:853:12: error: stray ‘\200’ in program
obj->slots().size() == 1,
^
/media/pc/data/software/libtorch/include/ATen/core/ivalue_inl.h:853:12: error: stray ‘\343’ in program
obj->slots().size() == 1,
^
/media/pc/data/software/libtorch/include/ATen/core/ivalue_inl.h:853:12: error: stray ‘\200’ in program
obj->slots().size() == 1,
^
/media/pc/data/software/libtorch/include/ATen/core/ivalue_inl.h:853:12: error: stray ‘\200’ in program
obj->slots().size() == 1,
^

enviroment:
libtorch: 1.8.1
vision: 0.9.1
cmake: 3.19.6
gcc: 7.5.0
python: 3.8.5
system: Ubuntu 18.04

compile code
cmake -DCMAKE_PREFIX_PATH=/media/pc/data/software/libtorch -DCMAKE_INSTALL_PREFIX=/media/pc/data/software/torchvision/install -DCMAKE_BUILD_TYPE=Release -DWITH_CUDA=ON ..

Thanks~！

@swordnosword It looks like this might be an issue caused by the encoding of characters (see [1] and [2]).

@datumbox I just doownloaded the source code and chaged nothing.

@datumbox I have compiled successfully in docker image with python 3.6.9, it seems like we can solve this problem by lower the python version.
Thanks any way!


Release Google.Cloud.DataFusion.V1 version 2.2.0

Changes in this release:
No API surface changes; just dependency updates.

Created release for Google.Cloud.DataFusion.V1-2.2.0


its gone

what do you mean
april fools was yesterday

what do you mean april fools was yesterday

so?

What do you mean, it’s gone?

What do you mean, it’s gone?

He means it's not on the channel store. It has been taken down for unknown reasons.


Can I add some vocabs of Vietnamese to VOCABS file ?

🚀 The feature
I have added vietnamese vocabs for VNese devs like me to use doctr better, following this issue: https://github.com/mindee/doctr/pull/464#pullrequestreview-752843039
This is my pull request, please review it.
Motivation, pitch
I am very appreciate and congrats on your great work. This package will help me alot in my work :) However, I am working on Vietnamese OCR, so Vietnamese vocabs is required and I can't see any guide to locally added vietnamese vocabs without changing the main repository (which I am quite afraid of damaging something I dont know). It would be very nice if you could guide me or review my contribution on vietnamese vocabs here: https://github.com/mindee/doctr/pull/878
Alternatives
No response
Additional context
And please, if you agree with my contribution, can you also give me soem tips on how to apply the new vocab in your work ? Are there any tools or guide line on how to create and train a custom dataset ?
Thank you very much ~!

Hey, I am in a similar situation, but in my case, I need a model for Czech. I found the advice they gave to someone who wanted to train the text recognition model in Spanish useful https://github.com/mindee/doctr/discussions/565.

@charlesmindee
Can be closed ? :)

just simple, transfer learning maybe can be solution. edit little in end layer and then learning the model with your custom data.


create save and open grid functionality via json

Let me know what you think of this, did some tests and seems to work fine. Just created some Dto models such that the calculation models stay exactly the same.

@roy-t would it be possible to make a new nuget release as well? Saves me from having my custom version of your library.

@jcageman hey definitely! But I haven't been able to test the code yet. My planning is to do that wednesday and to release a new minor nuget package that day :).


handle sass import file in webpack loader (reopen #11448)

see this
@evilebottnawi please read again.
I have try in this way. But loader can only handle "style.scss", can't get "./theme.scss".

Please use stackoverflow for questions, it is bug tracker

Maybe you need https://github.com/sass/node-sass#importer--v200---experimental


Update graph implementation and add dropdown county selection

Request Description / Summary
Updates mwc-select implementation to allow county selection, defaulting to the first item in the list.

Updates chartjs implementation to show tooltips, use M/d date display, show legend, and display the selected county and state data. (also includes built-in legend functionality to show/hide data)

Tag the local or remote issues that are related
closes #22
closes #23
closes #62

@ncraley can you by chance check out the docs folder from master and push to resolve those conflicted files? those shouldn't have been committed by colby

@krumware Cleared out docs on this branch and checked out the version from master. Still showing in changed files, though? Not sure why, looks like it's showing renames/moves, but the "new" files have the same names as the ones on master.

@krumware Fixed dropdown styling issue, looks good on https://viz-enhancements.covid-sc.dev.krum.io/

@krumware Added Top 3 default for the dropdown/graph:

I'll go ahead and update the docs folder


When node: true is set globally, can't override to false

I have a mixture of Node files and client-side javascript modules (loaded with require.js) in my application.
The Gruntfile defines a jshint task:
jshint: {
  files: [
    '**/*.js',
    '!node_modules/**/*'
  ],
  options: {
    node: true
  }
},

I get errors from the client-side use of Require.JS global require variable:
lib/require.config.js
 13 |var require = {
         ^ Redefinition of 'require'.

This is allowed in RequireJS, and I use it to share configuration (module loading paths) between tests and production code, although they have different initial require() statements.

Also, you can define the config object as the global variable require before require.js is loaded, and have the values applied automatically. This example specifies some dependencies to load as soon as require.js defines require():

I think the solution would be to turn node mode off for the client-side JavaScript files, leaving it on for the server-side files. But I get the above error even if I have the following line in the same file:
/* jshint node: false */

It appears that I can't turn Node mode off. Any idea why?
Note: I can disable the warning with this code instead:
/*jshint -W079 */

But of course I don't want to allow polluting the global namespace accidentally.

This is a dupicate of #1535

yes, I agree


🐛 [tandoor_recipes] No mariadb_addon as DB_TYPE

Which addon?

Addon name : tandoor_recipes
Addon version : 1.4.4

Describe the bug
In the readme it appears that "mariadb_addon " can be selected as DB_TYPE, but in the config it cannot be selected.

To Reproduce

Full addon log

Full addon config

System

Supervisor version:
Host system version:

Hi, thanks, tandoor recipes doesn't support mariadb and I had to remove it. I'll adapt the readme, thanks for noticing


Fix Input get_action_raw_strength binding

This was a mistake introduced in #42976, likely a copy/paste error.

Thanks!


Clean up IEnvelopePersistence API

Make it much more clear which methods require an active session. Maybe split incoming vs outgoing persistence? Use IReadOnlyList everywhere. Maybe bring in CancellationToken? Deal with any TODO in the code too.

Move anything that's specific to the the durability agent into durability agent specific code. Related to #126 now.


Build on MacOS failed on master branch

building in macOS from the master branch fails with the error below:

warning: Run script build phase 'Copy www directory' will be run during every build because it does not specify any outputs. To address this warning, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase. (in target 'Outline' from project 'Outline')
warning: Run script build phase 'Remove unused framework architectures' will be run during every build because it does not specify any outputs. To address this warning, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase. (in target 'Outline' from project 'Outline')
** BUILD FAILED **
The following build commands failed:
SwiftEmitModule normal x86_64 Emitting\ module\ for\ VpnExtension (in target 'VpnExtension' from project 'Outline')
(1 failure)
node:internal/process/esm_loader:94
internalBinding('errors').triggerUncaughtException(
^
Error: xcodebuild: Command failed with exit code 65
at ChildProcess.whenDone (/Users/administrator/Documents/outline-client/node_modules/cordova-common/src/superspawn.js:136:25)
at ChildProcess.emit (node:events:390:28)
at maybeClose (node:internal/child_process:1064:16)
at Process.ChildProcess._handle.onexit (node:internal/child_process:301:5) {
code: 65
}
Thrown at:
at whenDone (/Users/administrator/Documents/outline-client/node_modules/cordova-common/src/superspawn.js:136:25)
at emit (node:events:390:28)
at maybeClose (node:internal/child_process:1064:16)
at ChildProcess._handle.onexit (node:internal/child_process:301:5)
▶ action(cordova/build): ❌ Failed.

Environment

OS: [macOS 13.1
NPM version (npm --version) 8.1.0
Node.js version 16.13.0

That's odd, the CI was working, I believe.
In any case, it seems to be working now, and it will be more reliable after https://github.com/Jigsaw-Code/outline-client/pull/1527


Runtime flags for doing specific stuffs.

It would be great if we can setup temporary runtime flags that gets reset on every reload so it helps with testing / messing around, without having a lasting effect. For example, we might have:
!!~privreq"0" ~owneradd Vogel612

this issue seems to be greatly underspecified. It would be easier to implement this if you could tell us what flags should exist, what they should do, and so on.
The idea in and of itself seems to be a good one, though

Actually, I'm just going to immediately freeze this issue until JCE is done. I originally had this idea, then decided to incorporate this into the library for convenience - ignoring all events by a specific user by never queuing them in the first place, having User metadata and stuff like that. That would be relatively simple to implement via the library. So no point worrying about it right now. Kbai4now


Stream upstream tls

#Hi ,I would suggest you to change name of 't' folder to some meaningful name as it doesn't seem to be attracting or meaningful and doesn't convey any message or meaning to give a word 't' to any folder/repository.

Summary

Checklist

[ ] The Pull Request has tests
[ ] There's an entry in the CHANGELOG
[ ] There is a user-facing docs PR against https://github.com/Kong/docs.konghq.com - PUT DOCS PR HERE

Full changelog

[Implement ...]

Issue reference

Fix #[issue number]

t means is test, i think this is Okay for this project. Nginx Project also use t folder to test case.

But this doesn't give a clear picture to the new-comers of this repository that what actually this 't' means,so according to me u should rename it to 'test'.


Idea: Give concrete actions and put people in communities. Voting. Calculate greenhouse gasses not carbon,

Thanks so much for your hard work. This app seems great.
You'll be able to see which action will lead to the greatest personal carbon reduction. Can you create communities (whatsapp/facebook to put people in so they can work together to enact these?) look at "one year no beer" for an example of this.
Can you rate the plans of the govt and see how your vote could affect your personal carbon output.
In my understanding some greenhouse gasses are far more damaging that carbon. Can there be a "carbon equivalent emissions" rathar than just co2?

Hey there - great feedback, once your respond I'll close the issue and open them internally.
I believe your ideas on community engagement and civic impact would be great! If you have ideas on where to find the data about the performance about your govt on climate issues, that'd be amazing (and also how much the public sector emits!).
Everything we track is carbon footprint (CO2eq). Is there somewhere where this is not clear?

Feel free to close this comment.


The download of pytorch_model-00001-of-00003.safetensors got stuck

The download speed was 50 megabytes per second at the beginning.
As the download approaches completion, the download speed gradually decreases until it drops to several kilobytes. The final result is that I can never complete the download.

Same happened to me, just download the model manually and then use local path as model in config where it reads name_or_path :
# huggingface model name or path
name_or_path: "f:/5_Training_tools/ai-toolkit/FLUX.1-dev"

Same happened to me, just download the model manually and then use local path as model in config where it reads name_or_path :
# huggingface model name or path
name_or_path: "C:/.../ai-toolkit/FLUX.1-dev"


How to test?

Awesome project, thanks for taking this on :tada:
I assumed I could create an app.rustle file with the following contents:
<script>
  let test = "test";
</script>

<h1>{test}</h1>

Then run rustle_cli app.rustle to create a compiled app.js file, but that throws:
thread 'main' panicked at 'Parse error: expecting ={', /home/jimafisk/.cargo/registry/src/github.com-1ecc6299db9ec823/rustle_lib-0.0.1-alpha/src/compiler/parse/parser.rs:120:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I've moved the library crate from rustle_lib to rustle namespace on crates.io and rustle_cli 0.0.1-alpha depends on that namespace. I'm still learning and it's possible I've messed some things up on crates.io.
Can you try updating the rustle_cli binary with cargo install rustle_cli --version "0.0.2-alpha"

Thanks for the cargo command, I'm unfamiliar with Rust. That ran a build that completed with:
Compiling rustle v0.0.1-alpha
Compiling rustle_cli v0.0.2-alpha
Finished release [optimized] target(s) in 12m 17s
Replacing /home/jimafisk/.cargo/bin/rustle_cli
Replaced package `rustle_cli v0.0.1-alpha` with `rustle_cli v0.0.2-alpha` (executable `rustle_cli`)

Running which rustle_cli returns /home/jimafisk/.cargo/bin/rustle_cli
However rustle_cli --version still says Rustle 0.0.1-alpha

Oh whoops, I forgot to update the version in the CLI crate. Running --version with the 0.0.2-alpha version is going to return 0.0.1-alpha.
I just saw the error and tried it out, and it appears that <h1> tags don't work and return that error. Try using a <div> instead, that should work.

Using a <div> worked! Very exciting! Can't wait for more, awesome job so far :)

Thank you for bringing this issue to my attention, I haven't realised that only div tags work. I'll look into it!

@pintariching the issue seems to be caused when trying to parse attributes.

Maybe the number in the tag is throwing the parser off? If you'd like you can look into it.

I skimmed through the part of the parser that handles attributes and seems it doesn't have conditions for parsing normal html attributes .

Looked through here to see how the svelte compiler parses attributes tag.ts

Currently busy I could look into it later though.

No worries, I'll take a look at it tomorrow.

This should work now


yo jekyllrb not working

I install generator-jekyllrb, run yo jekyllrb and I got this error. I think it got a bug in it.
/usr/local/lib/node_modules/yo/node_modules/inquirer/node_modules/rx/dist/rx.js:4586
        throw e;
              ^
TypeError: undefined is not a function
    at Generator.run (/usr/local/lib/node_modules/generator-jekyllrb/node_modules/yeoman-generator/lib/base.js:444:21)
    at Environment.run (/usr/local/lib/node_modules/yo/node_modules/yeoman-environment/lib/environment.js:330:20)
    at module.exports (/usr/local/lib/node_modules/yo/lib/routes/run.js:20:11)
    at Router.navigate (/usr/local/lib/node_modules/yo/lib/router.js:36:30)
    at PromptUI.completed (/usr/local/lib/node_modules/yo/lib/routes/home.js:76:20)
    at PromptUI.onCompletion (/usr/local/lib/node_modules/yo/node_modules/inquirer/lib/ui/prompt.js:69:10)
    at AnonymousObserver.Rx.AnonymousObserver.AnonymousObserver.completed (/usr/local/lib/node_modules/yo/node_modules/inquirer/node_modules/rx/dist/rx.js:1929:12)
    at AnonymousObserver.Rx.internals.AbstractObserver.AbstractObserver.onCompleted (/usr/local/lib/node_modules/yo/node_modules/inquirer/node_modules/rx/dist/rx.js:1866:14)
    at AutoDetachObserverPrototype.completed (/usr/local/lib/node_modules/yo/node_modules/inquirer/node_modules/rx/dist/rx.js:4604:23)
    at AutoDetachObserver.Rx.internals.AbstractObserver.AbstractObserver.onCompleted (/usr/local/lib/node_modules/yo/node_modules/inquirer/node_modules/rx/dist/rx.js:1866:14)

I can see the same behavior :(

I'm having the same issues.
I'm setting up a new machine and trying to get this generator to work but am getting similar errors thrown by "rx.js".
I've tried this with various combinations of Ruby versions and Node versions by using rvm and nvm. I've tried Ruby versions 2.1.4 and 2.2.0. I've tried npm versions 0.10.36 and 0.12.0.
In all cases I'm getting the following error. Unfortunately in reading these errors I'm confused about where the problem might be.
/Users/john/.nvm/v0.10.36/lib/node_modules/yo/node_modules/inquirer/node_modules/rx/dist/rx.js:580
    throw e;
          ^
TypeError: Cannot read property 'name' of undefined
    at Prompt.render (/Users/john/.nvm/v0.10.36/lib/node_modules/yo/node_modules/inquirer/lib/prompts/list.js:99:69)
    at Prompt.onSubmit (/Users/john/.nvm/v0.10.36/lib/node_modules/yo/node_modules/inquirer/lib/prompts/list.js:127:16)
    at AnonymousObserver.Rx.AnonymousObserver.AnonymousObserver.next (/Users/john/.nvm/v0.10.36/lib/node_modules/yo/node_modules/inquirer/node_modules/rx/dist/rx.js:1940:12)
    at AnonymousObserver.Rx.internals.AbstractObserver.AbstractObserver.onNext (/Users/john/.nvm/v0.10.36/lib/node_modules/yo/node_modules/inquirer/node_modules/rx/dist/rx.js:1872:35)
    at AnonymousObserver.tryCatcher (/Users/john/.nvm/v0.10.36/lib/node_modules/yo/node_modules/inquirer/node_modules/rx/dist/rx.js:568:29)
    at AutoDetachObserverPrototype.next (/Users/john/.nvm/v0.10.36/lib/node_modules/yo/node_modules/inquirer/node_modules/rx/dist/rx.js:4871:51)
    at AutoDetachObserver.Rx.internals.AbstractObserver.AbstractObserver.onNext (/Use~/Sites/jekyll

Here's a look at the environment that created this error message above.
$ gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 2.4.6
  - RUBY VERSION: 2.1.4 (2014-10-27 patchlevel 265) [x86_64-darwin14.0]
  - INSTALLATION DIRECTORY: /Users/john/.rvm/gems/ruby-2.1.4
  - RUBY EXECUTABLE: /Users/john/.rvm/rubies/ruby-2.1.4/bin/ruby
  - EXECUTABLE DIRECTORY: /Users/john/.rvm/gems/ruby-2.1.4/bin
  - SPEC CACHE DIRECTORY: /Users/john/.gem/specs
  - SYSTEM CONFIGURATION DIRECTORY: /Users/john/.rvm/rubies/ruby-2.1.4/etc
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-darwin-14
  - GEM PATHS:
     - /Users/john/.rvm/gems/ruby-2.1.4
     - /Users/john/.rvm/gems/ruby-2.1.4@global
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :backtrace => false
     - :bulk_threshold => 1000
  - REMOTE SOURCES:
     - https://rubygems.org/
  - SHELL PATH:
     - /Users/john/.nvm/v0.10.36/bin
     - /Users/john/.rvm/gems/ruby-2.1.4/bin
     - /Users/john/.rvm/gems/ruby-2.1.4@global/bin
     - /Users/john/.rvm/rubies/ruby-2.1.4/bin
     - /Users/john/.rvm/bin
     - /Users/john/bin
     - /usr/local/bin
     - /usr/bin
     - /bin
     - /usr/sbin
     - /sbin

Any suggestions?

Ok, upon more investigation, I've noticed I get the above error "Cannot read property 'name' of undefined" only when I don't pick one of the 2 template options. If I leave it to pick the default for me, this error occurs. This makes me think the error I had and the ones mentioned earlier here are not the same error.

I've got the same error, but I didn't installed a Jekyll in my environment.
I just ran gem install jekyll before yo jekyllrb and works.

I've tried uninstalling my global jekyll with sudo rm which jekyll` which did uninstall it.
I then installed again while in the directory I was trying to build into using gem install jekyll before yo jekyllrb like you've suggested. No dice on my end. Still producing the same errors for me. :-/

This issue appears to be solved with baf6f238db1b5b260731799b57035da7e27c78e4, however this fix hasn't been published to npm, yet. Hence installing with npm install -g generator-jekyllrb will result in above mentioned error while using the GitHub version directly will work just fine.


pin scikit-learn version to less than / equal to 0.18.2

scripts in PCB paper use GMM, deprecated in version 0.18.2
https://scikit-learn.org/0.19/whats_new.html
@dgmets reports that

there are differences in the Likelihoods emitted from GaussianMixture as compared to the previous GMM module.  In particular, the Likelihoods are strongly impacted by the covariance type used.  This didn't used to be the case.  Anyway, I am going to try to run this down...   The current Dkl measures are proportional to the previous ones, but not the same.

in the meantime we can pin to a version before deprecation.
Using 0.18.2 gives a DeperecationWarning that can be annoying when it gets dumped to stdout 150k times, might be worth using a slightly earlier version

@sthaar this is the issue I was referring to, looks like I have not fixed this

@sthaar @yangzheng-121
I pushed a branch here where I found dependency versions that seemed to match what was used for the original scripts
https://github.com/NickleDave/songdkl/tree/add-pcb-scripts-generate-oracle
If you clone this repo and check out that branch you can create an environment with the environment.yml file.
(Notice it is different from the environment.yml file that's in the root of the current directory!)
git clone https://github.com/NickleDave/songdkl
cd songdkl
git checkout -t origin/add-pcb-scripts-generate-oracle
conda env create -f environment.yml

Hi Dave, Just a bit of feedback, not urgent.
I tried the above code, but either I'm doing something wrong, or the environment.yml file in the brach actually IS the same as the master?? I don't see any differences. If I do env list, I get no songdkl and I do get scikit-learn 0.21.3, same as master.
However, if I do pip install songdkl, it overwrites with scikit learn 0.24.2 (also other versions for numpy, mahotas, matplotlib, and scipy)
I manually uninstalled scikit, then pip installed scikit-learn 0.21.3, mahotas-1.4.9 and numpy-1.17.2 (as listen in .yml)
Now it runs without errors or warnings.
BUT, is scikit-learn 0.21.3 OK? From the above link I understood it should be 0.19.2. If I manually install that it also works fine, without warnings or errors. The version doesn't seem to affect the number of syllables and the dkl value. I tested only on one folder.
Since this seems to work, I'll just continue using this environment. My current environment ('env list') is attached as txt file
envsita.txt
btw, I do get errors on manual install of scikit-learn, yet it does install:
Collecting scikit-learn===0.19.2   Downloading https://files.pythonhosted.org/packages/eb/f1/8ab06a3ae2f047098a953e43e1714f47ae0db28d2960afcacaa04d671b51/scikit_learn-0.19.2-cp37-cp37m-manylinux1_x86_64.whl (4.9MB)      |████████████████████████████████| 4.9MB 7.7MB/s  ERROR: songdkl 0.1.0 has requirement mahotas<2.0.0,>=1.4.11, but you'll have mahotas 1.4.9 which is incompatible. ERROR: songdkl 0.1.0 has requirement numpy<2.0.0,>=1.19.4, but you'll have numpy 1.17.2 which is incompatible. ERROR: songdkl 0.1.0 has requirement scikit-learn<0.25.0,>=0.24.0, but you'll have scikit-learn 0.19.2 which is incompatible. Installing collected packages: scikit-learn Successfully installed scikit-learn-0.19.2

Hi @sthaar
Sorry, I wasn't very clear in my instructions.
I think what might be happening is that when you do pip install in the environment, pip gets the version of songdkl of PyPI, and it installs the dependencies specified for that version, "clobbering" the dependencies you install with the environment.yml file
Can you try instead doing an "editable" installation of the local code (not from PyPI) using pip? Like so:
git clone https://github.com/NickleDave/songdkl
cd songdkl
git checkout -t origin/add-pcb-scripts-generate-oracle
conda env create -f environment.yml
# activate the environment, that I confusingly gave the same name as the package
conda activate songdkl
pip install -e .

The last two lines are the ones I left out in the snippet above.
If you do it this way you should not get pip overwriting with e.g. scikit-learn 0.24.x

BUT, is scikit-learn 0.21.3 OK? From the above link I understood it should be 0.19.2.

It needs to be less than version 0.18.2 (not 0.19.2) because that is where GMM changed
see release notes here:
https://scikit-learn.org/stable/whats_new/v0.18.html#id5

The old mixture.GMM is deprecated in favor of the new mixture.GaussianMixture. The new class computes the Gaussian mixture faster than before and some of computational problems have been solved. #6666 by Wei Xue and Thierry Guillemot.

If I manually install that it also works fine, without warnings or errors. The version doesn't seem to affect the number of syllables and the dkl value. I tested only on one folder.

If you installed from PyPI in both cases and the scikit-learn version is > 0.18.2 then I would expect you to get the same # of syllables and the same dkl value. If you use scikit-learn < 0.18.2 that has the class mixture.GMM instead of the newer  mixture.GaussianMixture you should get a different dkl value I think. But I'm not sure yet whether it ultimately affects results
Try for example running the original script (included in this branch) and comparing that output with what you get from the songdkl package. You can see the use of GMM in the original script here:
https://github.com/NickleDave/songdkl/blob/c8938c31cbf090b4cdecb616b07d2a38663c1895/src/pcb-scripts/pcbi.1006437.s006.py#L202

Ok thanks! pip install -e . was the missing info for me.
But I get an error that the setup.py is missing:
pip install -e . ERROR: File "setup.py" not found. Directory cannot be installed in editable mode: /home/sitath/songdkl (A "pyproject.toml" file was found, but editable mode currently requires a setup.py based build.)
Also, I understand that the version should be lower thatn 0.18.2, which is why I got confused in the first place, but the enveronment.yml file downloaded from this branch add-pcb-scripts-generate-oracle (using code above) lists - scikit-learn=0.21.3=py37hd81dba3_0. Or will that change after pip install -e .??

Hi @sthaar I'm really sorry for confusing you; after spending some time this morning on this I have a better sense of where I left things.
The short version:

You are right, the env files that were in that branch did not have earlier scikit-learn versions
I have fixed this, and re-written history for the branch
The easiest thing for you to do will be to re-clone the entire repo from github
then do the following, to give you an environment where you can run the original scripts from the paper that are in src/pcb-scripts, and compare the output with what you get from running the current songdkl in another environment

git clone https://github.com/NickleDave/songdkl
cd songdkl
git checkout -t origin/add-pcb-scripts-generate-oracle
conda env create -f environment.yml
conda activate songdkl-python3.5
cd src/pcb-scripts
python Song_D_KL_calc.py folder_with_songs_from_bird_1 folder_with_songs_from_bird_2 number_of_syllable_calsses_bird_1 number_of_syllable_classes_bird_2

re: doing an editable install of the 'src/songdkl` code into the same conda env:
I fought a bunch with various env things but I was not able to find a way yet to directly install the current version of songdkl into the same environment. I might be able to do so later, e.g. by changing the requires-python and dependencies in the pyproject.toml file to match what's in the conda env, building with flit, and then pip installing the .tar.gz into the env.
Doing an editable install has even more complications I will skip describing for now.

Thanks heeps!!
This works :).
Just to confirm in case someone wants to reproduce: the songdkl-python3.5 environment indeed has the older scikit-learn. It gives much more reasonable dkl values (0.02, 16 syllables) than the master branch (63.8, 19 syls), when comparing the exact same folder of song. (For zebra finch, 16 syllables is still on the high side though, but there are many other things I should try)
tiny change in code if someone wants to reproduce:
first
cd src/pcb-scripts
then
conda env create -f environment.yml
conda activate songdkl-python3.5
running the original scripts:
for calculating number of syllables:
python pcbi.1006437.s007.py  folder_with_songs_from_bird_1
for calculating songdkl:
python pcbi.1006437.s006.py folder_with_songs_from_bird_1 folder_with_songs_from_bird_2

Thank you @sthaar --  glad this is working for you now
I just pushed one more commit so that the script file names match what's in the docstrings at the top of each script
so your example would be:
python calc_sylno.py folder_with_songs_from_bird_1
for calculating songdkl:
python Song_D_KL_calc.py folder_with_songs_from_bird_1 folder_with_songs_from_bird_2

update:
after David changed the python version back to 2.7 (as in original published scripts), the scikit version was 0.19.
I manually installed scikit 0.17.1 and it runs without error. However, I get a lower nr of syllables: 2 instead of the 20, 16 or 18 I got before. Two syllables, might make more sense in this case, but I'm not sure if the other packages are now the same as in the publication. There are many differences if I compare the env files. See zip attached.
pcb-scripts_versionsStH.zip

Thank you @sthaar for testing and for providing this .env file.
To be absolutely sure the environments are the same, we would need access to the original machine.
Next best thing would be if we could get the ground truth for the number of syllables computed by the original script, e.g. if @dgmets has a spreadsheet with those values, and then find some combination of dependencies that replicates those numbers.
This would be equivalent to treating the numbers in the spreadsheet as a "derived oracle" as in #28.
If we can't do that, then the next next best thing would be for us to look by eye at the data from the original paper, agree on some number of syllables, and see if we can get an environment where the script that generates those numbers.


CU-gjy9ag Fix payment wait order timeout bug

Fix payment wait order timeout bug

Task linked: CU-gjy9ag Fix payment wait order timeout bug


ENOENT on graph init

Which packages are impacted by your issue?
@graphprotocol/graph-cli
Describe the issue
Trying to create a new subgraph indexing the MORFI token on zkSync Era. I suppose something goes wrong when fetching the ABI, maybe because of how the contract was verified? It looks like it's trying to access the ABI on a weird path.
Logs:
pablo:~/repos/morfi-subgraph (main #)$ graph init --studio
 ›   Warning: In next major version, this flag will be removed. By default we will deploy to the Graph Studio. Learn more
 ›   about Sunrise of Decentralized Data https://thegraph.com/blog/unveiling-updated-sunrise-decentralized-data/
 ›   Warning: In next major version, this flag will be removed. By default we will deploy to the Graph Studio. Learn more
 ›   about Sunrise of Decentralized Data https://thegraph.com/blog/unveiling-updated-sunrise-decentralized-data/
 ›   Warning: In next major version, this flag will be removed. By default we will stop initializing a Git repository.
✔ Protocol · ethereum
✔ Subgraph slug · morfi-subgraph
✔ Directory to create the subgraph in · morfi-subgraph
? Ethereum network …
? Ethereum network …
? Ethereum network …
? Ethereum network …
? Ethereum network …
? Ethereum network …
? Ethereum network …
✔ Ethereum network · zksync-era
✔ Contract address · 0xd9AE1b1Ec5970EaEc4b9EE37E17c7f43D6906deA
✔ Fetching ABI from Etherscan
✔ Fetching Start Block
✔ Fetching Contract Name
✔ Start Block · 40678443
✔ Contract Name · MORFI
✔ Index contract events as entities (Y/n) · true
  Generate subgraph
  Write subgraph to directory
⠋ Create subgraph scaffold/Users/pablo/.config/yarn/global/node_modules/gluegun/build/index.js:15
    throw up;
    ^

[Error: ENOENT: no such file or directory, open 'morfi-subgraph/abis/contracts/MORFI.sol:MORFI.json'] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: 'morfi-subgraph/abis/contracts/MORFI.sol:MORFI.json'
}

Node.js v18.18.2
pablo:~/repos/morfi-subgraph/morfi-subgraph (main #)$ graph --version
@graphprotocol/graph-cli/0.80.1 darwin-arm64 node-v18.18.2

Reproduction
graph cli
Steps to Reproduce the Bug or Issue
See the logs above, it should be reproducible by running graph init witht he same arguments
Expected behavior
I expected graph init to complete without errors, and for all the files to be generated properly. Instead the process was interrupted, and I could not find the ABI in the output.
Screenshots or Videos
No response
Platform
@graphprotocol/graph-cli/0.80.1 darwin-arm64 node-v18.18.2
Subgraph Manifest
No response
Subgraph GraphQL Schema
No response
Additional context
No response

Fixed by #1771


Second permit extension month limit

Description

Context

PV-793
How Has This Been Tested?
Unit tests and manual testing

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

Comparison is base (c0b1a26) 84.59% compared to head (02fe47f) 84.71%.
Report is 1 commits behind head on develop.

Files
Patch %
Lines

parking_permits/models/parking_permit.py
87.50%
1 Missing :warning:

Additional details and impacted files
@@             Coverage Diff             @@
##           develop     #483      +/-   ##
===========================================
+ Coverage    84.59%   84.71%   +0.11%
===========================================
  Files          166      166
  Lines        10227    10301      +74
===========================================
+ Hits          8652     8726      +74
  Misses        1575     1575

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


Handle simple arguments

Oops, no arguments are being included in the calldata yet.

Fixed in https://github.com/shazow/callthis/commit/b5f6227a01400c0f25bedc5a189d7f215b73864f


Process Jobs at job intialization

Currently, without a test framework, jobs with longer intervals require an inordinate amount of time to test. Even upon completion of implementation changes, the first job processing must wait until the interval has passed. To allow more immediate testing and use of improved implementations, the bot could run each job at its initialization. This allows more immediate testing until we can automate the tests, and more timely updates when functionality has changed.

As the commit states, this does reveal other issues. But these are issues that will be resolved as we decouple and make the project Test ready. Since there is not a clear indication as to which will be present as the project gets closer to our goals, I'm not opening specific issues for them. That will change if they are still present afterward
This issue will be closed when a PR can be made for the commit.


score_at_time method available in nflgame?

Is there anything in nflgame that's equivalent to the score_at_time method that's available in the nfldb Game class?

No, sorry.


Fix crash when length is negative

When the len is negative, mujs will crash due to a null pointer de-reference.
char * volatile out = NULL;
...
js_pushstring(..., out);
...
strlen(out);

Here is a POC:
root@90eb8770cb12:/mujs# echo '[].toString.call({length:-1})' | /mujs/build/sanitize/mujs
AddressSanitizer:DEADLYSIGNAL
=================================================================
==2755==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f990b9da675 bp 0x7ffd99feaec0 sp 0x7ffd99fea638 T0)
==2755==The signal is caused by a READ memory access.
==2755==Hint: address points to the zero page.
    #0 0x7f990b9da674  (/lib/x86_64-linux-gnu/libc.so.6+0x18b674)
    #1 0x7f990bc478fb  (/lib/x86_64-linux-gnu/libasan.so.5+0x678fb)
    #2 0x55c921f3d313 in js_pushstring /mujs/jsrun.c:114
    #3 0x55c921efd5ff in Ap_join /mujs/jsarray.c:138
    #4 0x55c921efe662 in Ap_toString /mujs/jsarray.c:428
    #5 0x55c921f45463 in jsR_callcfunction /mujs/jsrun.c:1066
    #6 0x55c921f45e37 in js_call /mujs/jsrun.c:1108
    #7 0x55c921f19e16 in Fp_call /mujs/jsfunction.c:130
    #8 0x55c921f45463 in jsR_callcfunction /mujs/jsrun.c:1066
    #9 0x55c921f45e37 in js_call /mujs/jsrun.c:1108
    #10 0x55c921f49ad7 in jsR_run /mujs/jsrun.c:1539
    #11 0x55c921f451fb in jsR_callscript /mujs/jsrun.c:1049
    #12 0x55c921f45cec in js_call /mujs/jsrun.c:1104
    #13 0x55c921f4baba in js_dostring /mujs/jsstate.c:204
    #14 0x55c921f60c72 in main /mujs/main.c:373
    #15 0x7f990b8760b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
    #16 0x55c921efcb2d in _start (/mujs/build/sanitize/mujs+0x17b2d)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib/x86_64-linux-gnu/libc.so.6+0x18b674)
==2755==ABORTING


Feature/enhance icingadb retention config

This adds the retention configuration parameters to the role.
Adds some tests in the build and via testinfra if the parameters are set in the file.
Adds documentation on every variable.
Adds changelog fragments
fixes #200

This is right, I added them that everyone can use the local-defaults to test and then afterwards run tests on the branch.


[Sqlite] Fix findFirst query for bun:sqlite

This PR fixes bug in bun:sqlite session implementation where findFirst query failed because of differences in return type of bun:sqlite's Statement.get() and Statement.values()
bun:sqlite's Statement.values() returns an array of arrays where as Statement.get() returns an object.
The custom mapRelationalRow function always expects an array of arrays for mapping.
Hence I have changed to the Statement.values() function for PreparedQuery.get() which fixes #1882

Is there any workaround before the fix gets merged?


Use "barcode scanner" to quickly transfer stock

Another possible use for the "imminent" barcode scanning feature.
Scenario
User wishes to transfer multiple items into a particular stock location - this may be a new location. Instead of manually finding and transferring each stock item in the database, there should be a mode whereby the user can simply scan stock item barcodes and each item is automagically transferred to the selected location.

Fixed in https://github.com/inventree/InvenTree/pull/865


gamepad: Index (int)p_button = -1 is out of bounds

Godot version
4.0 beta2
System information
Arch Linux, GTX 1650, Sway+Wayland
Issue description
After following and completing the 2D game tutorial (and adapting it slightly for Godot 4, by using await), the game works great.
However, when pressing one of the buttons on my wireless gamepad, I get the following error in the "Debugger" pane:
core/input/input.cpp:927 - Index (int)p_button = -1 is out of bounds ((int)JoyButton::MAX = 128).
Steps to reproduce

Install Godot 4.0 beta 2 on Arch Linux (any Linux distro is probably fine).
Have a working project ready, like the 2D tutorial game project.
In the "Project Settings" -> "Input Map" add buttons for the joypad (I have a wireless xbox controller): left thumbstick for up/down/left/right, D-pad for up/down/left/right and "A" for starting the game (start_game).
Start the game and press the little button directly right of the left thumbstick (the one with an image of two small rectangles).
Observe the error message in the "Debugger" pane.

Minimal reproduction project
tutorial1.zip

It's the same wireless gamepad as in #67135.

This now works perfectly in 276ab5be07752582b4341c33fb8f53a7887af87a (probably included in 4.0 beta 3).


Ignore primitive casts in ClassCastLambdaUsage check

As using the Class#cast does not implicitly auto-(un)box the primitives.

Suggested commit message:
Ignore primitive casts in `ClassCastLambdaUsage` check (#1385)

Quick fix @mohamedsamehsalah , niceeee!


Guest payments

Hi. I found some strange issue with guest payments.
Description
I try use guest payments for my site and found, that in FF I can pay as guest, but in same page in chrome-based browser can't do this.

Server-side rest integrations
paypal.version "4.0.131"
FF - 56.0 (x64)
Chromium - 64.0.3240.0

my web experience profile:
[
  {
    "id": "XP-T3FE-52A5-G85Y-NUAW",
    "name": "_",
    "temporary": false,
    "flow_config": {
      "landing_page_type": "Billing",
      "user_action": "commit"
    },
    "input_fields": {
      "allow_note": false,
      "no_shipping": 1,
      "address_override": 0
    },
    "presentation": {
      "brand_name": "Akweet",
      "locale_code": "US"
    }
  }
]

Steps to reproduce
Open in different browsers
Affected browsers

[x ] Chrome
[ ] Safari
[ x] Firefox
[ ] Edge
[ ] IE
[ ] Chrome Mobile/Tablet
[ ] Safari Mobile/Tablet
[ ] Web View / Safari ViewController
[ ] Other

If I set  locale: 'en_US',  pages are same.

Thanks for the report. We can track this over here: https://github.com/paypal/paypal-checkout/issues/510 -- I've added @bluelnkd to comment on the decisioning logic for the guest flow.


Fix warnings when building via CocoaPods

Only include headers needed for the Realm.Private module in private_header_files and just preserve_path the assembled include directory. This makes it not copy a whole bunch of files into the framework which don't need to be copied, and in some cases were generating warnings due to headers with the same file name at different paths.
This requires fixing all of the objectstore include paths to not rely on Xcode's header mapping stuff, which needed to be done anyway.
Also put the core headers in a different directory from the obj-c headers to remove the need to do convoluted things to handle case-sensitive filesystems.
Fixes #3178.

Does this help address #3052?

No, that still fails because the project generated by cocoapods 1.0 tries to copy the headers to Realm.framework/Realm (which fails due to that not being a directory) rather than Realm.framework/Headers/.

Ideally we'd reduce how many paths are hardcoded in the podspec, but if we can't for whatever reason, that shouldn't block us from merging. :+1:

:+1:


DB user cannot create extensions during db migrations (using PostgreSQL - Flexible Server in Azure)

Describe the bug
We installed the helm chart on our AKS and we wanted to use an Azure Database for PostgreSQL - Flexible Server. When the container tries to do the DB migrations it throws the following error (see bellow). As discussed here  and documented here the user needs to be member of the azure_pg_admin role (something that we want to avoid). This was introduces in the new updates of the server.
It would be nice to have this create-extension disabled when using Azure Database for PostgreSQL - Flexible Server as host. For other applications we already use a workaround (pod that executes the create extension commands for us). Of course we would need to know which extensions we have to create.
The error that we get is:
django.db.utils.ProgrammingError: Only members of "azure_pg_admin" are allowed to use CREATE EXTENSION

To Reproduce
Steps to reproduce the behavior:

Install the helm chart on AKS

helm repo add heartex https://charts.heartex.com/
helm search repo heartex
helm install my-release heartex/label-studio --values values.yaml

Use Azure Database for PostgreSQL - Flexible Server as host

with the following values.yaml
global:
  image:
  pgConfig:
    dbName: labelstudio #POSTGRE_NAME
    host: examplepsql.postgres.database.azure.com  #POSTGRE_HOST
    port: 5432 #POSTGRE_PORT
    userName: labelstudio #POSTGRE_USER
    password:  #POSTGRE_PASSWORD
      secretName: label-studio-db-credentials
      secretKey: POSTGRES_PASSWORD

  persistence:
    enabled: true
    type: azure
    config:
        azure:
          storageAccountNameExistingSecret: "azure-secret"
          storageAccountNameExistingSecretKey: "azurestorageaccountname"
          storageAccountKeyExistingSecret: "azure-secret"
          storageAccountKeyExistingSecretKey: "azurestorageaccountkey"
          containerName: "label-studio"

app:
  FullnameOverride: label-studio
  ingress:
    enabled: false

postgresql:
  enabled: false

cronjob:
  enabled: false

metrcis:
  enabled: true

Expected behavior
DB migrations to be succesfull
Environment (please complete the following information):

OS: AKS
Label Studio Version: 1.14.0.post0

It's already supported but not well documented:
https://github.com/HumanSignal/label-studio/blob/develop/label_studio/core/utils/common.py#L658-L662
Just add SKIP_TRIGRAM_EXTENSION=true env varible


3B+ technical preview (stable release date?)

When is the stable release for the 3+ going to be available?

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

ID: 9df006b9-0eac-67b8-9f24-e712ec436ec8
Version Independent ID: 491d3781-235d-1ad5-fff4-9185cbc73984
Content: Windows 10 IoT Core Dashboard - Windows IoT
Content Source: windows-iotcore/connect-your-device/IoTDashboard.md
Product: windows-iot
GitHub Login: @saraclay
Microsoft Alias: saclayt

@pk386 We do not have a release date, but likely around late fall 2019.

@saraclay Thanks,
I'm working on a project requiring the wi-fi capabilities. but we can rely on the built in Ethernet until later this year.
Is there a way I can be notified of the stable release?
Thanks in advance.

@pk386 If you're a Windows Insider for Windows IoT, you will likely hear that way. Also, you'll probably hear about it if you're subscribed to the Microsoft IoT newsletter, which you can sign up for here: https://profile.microsoft.com/RegSysProfileCenter/wizardnp.aspx?wizid=78930ef8-d176-4b5e-b49f-2cefcb6b0891&lcid=1033


BUG: PyPI requires on 1.7.1 should allow Python 3.10+

Describe your issue.
With Python 3.10rc2 installed, pip install scipy installs scipy 1.6.1 (the most recent version on PyPI that does not restrict Python <3.10) and not 1.7.1, resulting in a rather broken install. I get a lot of
Undefined symbol: _PyGen_Send
when running ordinary code. It looks like on PyPI scipy 1.7.1 requires Python < 3.10.
Installing master pip install git+https://github.com/scipy/scipy fixes the problems.
Reproducing Code Example
see above

Error message
see above

SciPy/NumPy/Python version information
3.6.1

We don't support Python versions that are not officially released yet that is to say all bets are off. But we try to see if things are doing OK in CI workflows. So any other compliance issues have to wait until the version is released. 1.7.1 is indeed not aware of future Python versions.

@ilayn : Thanks, this makes sense.

This does not really make sense IMO.
I am not suggesting that scipy should properly "support" beta releases of Python i.e. fix issues quickly, but wouldn't it make sense to be ready for when e.g. 3.10 becomes a full release?
And whilst it generally makes sense for latest releases to require >= python 3.x (the version that supports specific language features that the version needs), and for older releases to sometimes require < python 3.y (the version that stopped supporting specific language features that this old version required), I am unclear what the purpose is of putting version < python 3.10 on a current package so that pypi automatically installs a lower version that is less likely to support language features in the new beta.

With Python 3.10 released today, pip install scipy will still install the old scipy 1.6.1, which causes problems (mentioned in the original bug report). Given that Python 3.10 is now officially supported, I consider this a bona fide bug.
I generally agree with @Sophist-UK for why and how this should be fixed -- the current process isn't sustainable for new Python releases, unless scipy updates in lockstep with the latest supported Python.

the current process isn't sustainable for new Python releases

So you'd expect scipy to release a new version immediately with a new python version? That's simply not realistic

That's simply not realistic

@ev-br : Agreed! This bug pertains to PyPI automatically installing scipy 1.6.1 for all Python releases >=3.10. To reproduce:

Install Python 3.10, then making sure that the environment is truly Python 3.10
pip install scipy

The old scipy 1.6.1 will be installed, not the latest version!
From PyPI, scipy 1.7.1 requires Python < 3.10:

@rgommers is probably the expert on setting the max version numbers in setup.py/setup.cfg, and why there is a max for Python version.

@zachetienne ISTR some discussion that this was a pip problem. You can work around it with --only-binary.

What's the path forward then?  Is there a plan to bump the restriction to 3.10?

IFor anyone wondering, I had a long discussion with @rgommers about this here and here.  The long story short is that it seems we're moving towards a world where projects clamp the upper bound on the Python version.

We will release 1.7.2 with Python 3.10 support very soon.
The other part of this is: it would be great to at some point prevent older SciPy versions from being picked up. This is a little tricky to achieve, but can be done by adding a new 1.6.x release which aborts a from-source build immediately with a clear error message. That's something I may get around to at some point, but it needs thorough testing to ensure we're not breaking anything.

We will release 1.7.2 with Python 3.10 support very soon.

This is done now. I'll close this issue, and will open a separate one for the related topic of preventing older SciPy versions being found for new Python versions.

Sorry if this is in the discussion somewhere, but why is it absolutely necessary to upper cap the requires_python?
It has the drawback of causing pip to look for older versions that are not upper capped, and it prevents people from testing with newer Python versions.
It also forces everyone who depends on scipy to similarly upper cap their requires_python, having a cascading effect on all downstream libraries, as you might imagine.
Specifying an upper cap in the setup.py on both dependencies and Python also goes against the goals for what the setup.py is doing. This is the distinction between "abstract" and "concrete" requirements, right?
https://caremad.io/posts/2013/07/setup-vs-requirement/
What would be the downside of not capping it? Do we really expect that every new Python is just going to break scipy?
I don't think users are going to expect that there's an immediate release of scipy for any new Python, simply because it's not  explicitly upper capped in the setup.py file. And again you are kind of limiting the number of people that can help you test or develop with new Python versions, like @Sophist-UK was saying.
I ask because I am running into a problem similar to what @NeilGirdhar describes, where a solver complains because my requires_python doesn't upper cap like scipy does (in spite of me trying to change from poetry to pdm to avoid this :cry: ).
I am definitely not a packaging expert but to me this post from @henryiii makes a pretty compelling case that libraries should not place upper caps on dependencies and Python in particular:
https://iscinumpy.dev/post/bound-version-constraints/
I realize scipy is not exactly a pure Python package, and that's putting it lightly, so maybe there's some complexity in the build that makes this more complicated that I don't understand.

I found some previous discussion on this release PR:
https://github.com/scipy/scipy/pull/12862
(Maybe I should have looked for that before.)
There @rgommers says:

add an upper limit to supported Python versions. That's more obvious, just encodes what we already say in release notes.
any new Python release requires a new SciPy release.

Why does a new Python require a new SciPy release?
Because the build process literally requires that?
Or because scipy maintainers want to test with the new Python release before allowing anyone else to use it?
I think in that same discussion @pganssle is making a case against upper caps here:
https://github.com/scipy/scipy/pull/12862#issuecomment-696396247
where @rgommers replies that apparently the PyData stack has opted for something different
Isn't the last thing we want to do is force domain scientists to think about the complexities of constraints and solvers. I'm not focused on the scientific question I care about if every time I try to add a cool Python package that solves my research problem, I get hung up because it breaks everything inexplicably.
And it's not like semver is actually a guarantee of anything.
https://snarky.ca/why-i-dont-like-semver/
This is half the reason Python switched to calver.
Doesn't the case for not upper-capping apply doubly to Python itself?
Like @pganssle said in that discuss.python.org post about placing any kind of upper bound on Python:

I think the reason there’s not a “right” answer is that there are trade-offs to be made, and each project needs to decide what side of the line to fall on:

If you pin an upper limit on your version support, you are describing the current state of the support as of release time. The danger of doing this is that because PyPI metadata is immutable, if there is a release that breaks your software, you cannot simply add the upper limit pin, because pip will fall back to the most recent version that does not have this pin (which is still broken), and erroneously install it. The only thing you can do remedy the situation is cut a new release that supports the new version.
Of course, even if you could retroactively fix the metadata to add the version pin, all that will do is make it so that pip fails to find your package and fails to install it, so it’s not like it’s a huge improvement for the end users.
By pinning to the upper limit, you don’t necessarily have the above problem, but you do have the problem that you are encoding in python_requires a guess about whether a certain version of Python will break your package. As @pf_moore mentioned, there’s good reason to believe that if a Python 4 release occurs, it will not be a breaking change, and it’s worth noting that minor breaking changes occur in most/all point releases as well (per the deprecation policy), so your software may still be subject to the problems you have by not pinning or the problems you have by erroneously putting in a version pin for a version that works just fine for your project.
I tend to come down on the side of “don’t pin”, because it not only inaccurately reflects the state of Python version support as of release time by suggesting that certain versions will not work even though I have no specific information to that effect, and because even in the situation where a new Python version breaks my software, the advantage of having predicted this is minimal.
The one time I think it makes sense to pin your versions is when you know that there’s a breaking change in a given version. Even then it doesn’t provide too much value unless you’ve had that version pinned from the beginning.

Do we really know that any new Python release will cause breaking changes for scipy?
Sorry for the verbose posts, but I am a bit frustrated with running into this on multiple projects.

Or because scipy maintainers want to test with the new Python release before allowing anyone else to use it?

Because (a) it is very likely to not work out of the box, and (b) the vast majority of users are unable to build from source, and we get a lot of bug reports about building from source. It's a very bad idea for libraries as complex as SciPy to have an sdist but no matching wheels for a new Python version, it's much better to get an immediate clear error message.

Sorry for the verbose posts, but I am a bit frustrated with running into this on multiple projects.

If it's niche packages that release too slowly, then yes they should not use an upper bound. If it's libraries like SciPy, scikit-xxx, PyTorch, TensorFlow or whatever, then you need to adjust your expectations about everything being available shortly after a new Python release. Python's ABI stability window is simply too short to allow preparing binaries in time.

The problem @NickleDave is complaining about is not the fact SciPy doesn't work on 3.10, but rather that SciPy is setting python_requires = "...,<3.10", which is a misunderstanding of how Requires-Python metadata slot works. This was added to allow packages to drop a Python version (2.7) without breaking people on that version - pip would simply scroll back in time and select the final release that included that Python version. It was never intended to cap Python; it was designed to allow dropping Python. If you want to cap Python, you can add a check in setup.py that throws an error if Python is too high. You should not use this metadata slot to cap Python. If you do use it that way, you must always use it or yank any old releases that don't cap, otherwise you'd get the problem above, that pip installing SciPy on Python 3.10 will "work" but get the oldest version that didn't have this cap. This is exactly the intended behavior, and it's exactly wrong.
The good news is this bad solve is only on Python 3.10, where even a good solve would likely not work (assuming SciPy really doesn't support Python 3.10).
This has another unpleasant effect. If you use a locking package manager (Poetry, PDM), then the package manager will see that the lock file has a Python cap in it. It will then force the user to add the matching cap, since the lock file will be invalid on Python 3.10. If you are developing a library and don't have a strong cap on SciPy, this is wrong, but it doesn't matter, these systems are prioritizing the lock file over the library dependencies.
The bad news is this affects all downstream libraries using a locking package manager on any Python version.
IMO, a library's Requires-Python should not depend on the lock file; if a system wants to force you to be truthful for a lock file's sake, that should be a separate way to do this that does not get exported. Or it could just print a warning ("this lock file will only be valid on Python x to y") But nether @frostming's PDM nor Poetry support this, as far as I know.

If you really are more worried about building from source than about actual incompatibilities (as long as you don't see warnings, the next Python release is supposed to work - unless you are depending on private details like bytecode like Numba does), the the correct solution would be to ask users to include a pip flag or environment variable, like --only-binary=scipy. The problem is that requires users read documentation, which they don't. But just pointing that out. ;)

Maybe we start with why we are doing instead of what we are doing.
The thing we have been struggling so far with is that new Python versions without any exceptions were breaking something small or big, every single major version mind you. Hence for us it is not a matter of probability anymore but a certainty that something changes in Windows how DLL is looked up or  some Linux detail or Apple just decides to release an architecture with zero documentation or compilation guideline and ABI changes etc. etc. with every Python release. For that reason, we don't want current versions to be installed on new Pythons that were never meant to be running on. Because we are 100% sure that something will break and we will have users opining bug reports and issues coming in for the next 18 months about it overlapping with yet another release in the meantime. That is the most annoying thing since we don't even know which version is more broken to prioritize the solutions. I wish it wasn't like that but it is what it is.
And obviously, this causes a great deal of influx of bug reports and takes a good amount of maintainer time to even find the problem let alone fixing it. So what we are continuously dealing with is to limit the scope of SciPy version to certain Python versions, certain architectures (ARM, Win 32bit, obscure stuff) and certain 3rd party binaries. We are trying to be as flexible as we can but maintainer time is VERY precious and not getting cheaper anytime soon.
Thus we are, probably wrongly, using certain tools to achieve this. Maybe there are better ways about this, I don't know. But Requires-Python if it is not meant for this, has a very very unfortunate name to it. Because that's exactly what we are reading the name for and using it for. We want to have certain Python versions required. That footnote you have is not very different than what we are stuck with. Python apparently chose a hack and now dealing with consequences.
So given a very brief explanation of what our issue is, I'd like to ask for help from people in this thread, what a the good solution might be instead of discussing one choice we made in particular. Because without an alternative, we cannot stop doing this for reasons I summarized above. Asking users to do anything different than pip install scipy is not going to fly, so let's not waste time on that.

I don't know what the technical solution might be, but as a user of SciPy I know what I want to happen - I want to get the latest version of SciPy that works on my version of Python. If there is no version of SciPy verified for my version of Python (i.e. because it is too new or a beta or too old), I want to be told that I need to use a different version of Python.
What I don't want is for PyPi to install an earlier version of SciPy which is equally invalid for the version of Python I am running because (as actually happened) the earlier version was NOT limited to the Python versions it would install against.
(In other words, to some extent this is an issue with older versions NOT being constrained rather than current version being constrained.)

If you remove the cap, and instead just add the following to the setup.py:
if sys.version_info >= (3, 10):
    raise RuntimeError('Only Python versions >=3.8,<3.10 are supported.')

Now you don't get a back-track of all SciPy versions, and have a customizable error message.

I am not sure that this is the answer either. As I think this will allow Pypi to offer an incompatible version and then give an error message.
I think the answer may be to revisit the definitions of all previous versions and update the Pypi metadata so that it only offers versions of Pypi which match the version of Python that pip is running under.

I think the answer may be to revisit the definitions of all previous versions and update the Pypi metadata so that it only offers versions of Pypi which match the version of Python that pip is running under.

I like this solution a lot.
This should be done not just for Python versions, but also for all dependencies.  Even when projects use semantic versioning, patch versions (of project A) sometimes break other projects (B).  It would be nice for those projects B to be able to retroactively mark themselves as incompatible with the new patch version of project A.  New versions of project B that are compatible can go back to being constrained only by major version.

PyPI metadata is immutable.

PyPI metadata is immutable.

Is it not possible for that to be changed?

What would you expect it to be called?

I don't know exactly what it is supposed to be used for (and apparently not for the thing we used for) but if you call require python, I am expecting it to constrain the python versions to be used with and error out if it is not. Instead we fire up a time travel tree building to find previous versions. This, to my narrow understanding, is overengineering to solve a problem I am not sure exists.

Please read my post. Users are not broken if they need to add constraints. They might be irritated and noisy, but they are not broken. They are broken if they can't solve due to over constraints. And if they are using an old version, it might be because some else capped SciPy.
There have been some ideas about allowing metadata to be updated afterwords, but it's not trivial and breaks security through hashing. You could have a metadata file that "goes along" with the wheel, but that complicates things.
The "solution" you are proposing today would be to yank all previous releases, and then release new patch or post versions of every minor SciPy release. With new binaries.
A better solution is to remove the misusage of Requires-Python, and occasionally release new old patch releases if a really bad dependency failure starts happening.

I am not sure if that is directed to me but I can't understand the rationale for digging the history if the latest version does not support Python 3.10 in the hopes that maybe earlier versions might support it. I have no examples of this in any package I have dealt with so far.

A better solution is to remove the misusage of Requires-Python, and occasionally release new old patch releases if a really bad dependency failure starts happening.

One problem with your solution is that if X depends on scipy<1.6, and X and scipy are both unconstrained on Python version, then pip will happily try to install them on new Python versions.  It shouldn't be X's maintainer's job to figure out that scipy is incompatible with that new version.
You bring up a lot of good points about the complications involved in updating the metadata, but really that is the ideal world solution.

Requires-Python is a free form string that gets parsed into a packaging SpecifierSet. It has no understanding of 'maximum' or 'minimum'. It can only answer one question: does a version of Python (including patch!) match it? It returns true of it does. So if it "fails", pip doesn't know why, and assumes that it needs to keep looking for one that passes.  It was developed for IPython, as they were the first to want to drop Python 2 support from their main releases and just have an LTS release for Python 2. It's now a key component of NEP 29 - the fact the latest libraries don't have new releases for Python X doesn't stop Python X from being used.
This obviously doesn't support upper caps properly. That was never the intention of metadata - it is supposed to help fix a broken solve, not break a solve. That's why there is no requires-arch, etc. Which, by the way, was about half the complaints above - Apple released Apple Silicon on the existing 3.8, so a cap would not have fixed that.
Use setup.py to throw an error if you want to intentionally break something with a nice error.

Yes, this is what I mentioned - you'd have to "yank" every older release of SciPy to get this to "work"

I understand the "older version now gets found" is a problem. The solution is gh-14986, which I hope to revisit during the Christmas holidays. Which is basically the same as you are suggesting @henryiii. Except I think we have better metadata, and I hope the behavior of Pip at all can improve over time.
I don't think downloading an sdist and then erroring out is ideal, but that's all we've got because metadata on PyPI is unfortunately immutable indeed.

A better solution is to remove the misusage of Requires-Python,

I disagree that this is mis-usage. It adds the metadata we want to add. The raising an exception inside an sdist is an unfortunate hack that yes we'll have to do somewhere to stop old versions from being found.
The Poetry/PDM behavior is a usability issue on their side.
The whole "adding an upper bound is wrong": no need to repeat that argument. The bounds are desired for us.
By the way, this kind of thing is the reason that other projects with complex builds don't upload an sdist at all (e.g., TensorFlow, PyTorch). Unless PyPI/pip usability improves (most importantly, allowing us to default to --only-binary at some point), there are NumPy/SciPy devs who will consider doing the same.
@henryiii I know you understand this stuff well, I'd appreciate your comment on gh-14986 as the solution.

Yes - for security reasons, most of the metadata should be immutable except metadata relating to co-dependencies - because you never know when co-dependency constraints are going to need to change.
I haven't fully thought it through - but it might be possible to only allow increased constraints on existing releases, rather than removal of constraints.

It's I think better to have that discussion on Python repo/forum/list. Here it won't solve anything though I am interested to hear the pros/cons

@rgommers everything you just said totally makes sense, and yes after @henryiii explained it more clearly, I agree that it's mainly a usability issue w/Poetry, pdm, et al.
Likewise @ilayn I understand much better now that new Python releases do quite literally break scipy, and you don't want to deal with the fallout from that.
Definitely sounds like #14986 is a short-term fix that address the core issue here.
Sorry for making discussion on this more confusing by jumping on with my concern about lockfiles.

 Every file is standalone and contains its own metadata - wheels and SDists. Files are hashed; you can never upload two different wheels with the same name but different hashes. If you use pip-tool's compile, you'll get a requirements.txt that looks like https://github.com/pypa/manylinux/blob/main/docker/build_scripts/requirements3.10.txt - the hashes are listed for each file. You can't change the files; that's a core security requirement. So the only way to modify the metadata would be to add a new file that sits "alongside" the wheel or SDist file - probably each one, since each file technically could have different metadata, and then modify setuptools, flit, and every other build system to produce them, pip and every other installer to include them, pypi and every other wheelhouse to include them, pip-tools, Poetry, Pipenv, PDM, and every other locking system to handle them somehow, etc. And the incoming PEP 665. And any older version of anything (like pip) would not respect the new metadata.
And, you'd have to be very careful to only allow a very limited subset of changes - you wouldn't want an update of a package to add a new malicious dependency via metadata that you could not avoid via hashes!
Would you be able to get old versions of dependency override files too? Plus other questions would need to be answered. It could be done, but it would be a major undertaking, for a rather small benefit - ideally, everyone should try to avoid capping things, play nicely with deprecation periods, test alpha/beta/rc, and just understand that in the real world, a library can't perfectly specify it's dependencies so that there will never be a breakage. That's only possible when locking, for applications.
You should at least consider the scope of the problem and the other aspects before you call something "crazy stupid". In fact, do other non-Python systems allow changing metadata? I think many of them do not. And it's really easy to "fix" by releasing a new patch release with more limited metadata - this just is not ideal for large binary releases, but is fine for pure Python / smaller packages.
If someone carefully researches this, finds a core-dev sponsor to work with (I can suggest a few), and is willing to push this through, that's what it would take to make it happen.

I think we have better metadata

Currently, Requires-Python is not for upper limits. Trove classifiers are for indicating if something was tested on a newer version of Python, not Requires-Python. This is only for removing Python versions you previously did not support. This is why you are having to come up with workarounds.

The Poetry/PDM behavior is a usability issue on their side.

I agree here. Though it's a major user and I think you should at least think about users being affected by it, rather than just saying it is their fault.

adding an upper bound is wrong": no need to repeat that argument. The bounds are desired for us.

I described a way to add an upper bound in setup.py - I was not saying you should not have one. You can add metadata via classifiers. There's no need to misuse Requires-Python for this. Your workaround still requires pip to "scroll back" and try to install an old version, you are just breaking that old version. Your workaround is not a horrible workaround, and it's only marginally worse than the "ideal" way to do it. It's better than numba, which scrolls back to version 0.51 then breaks because llvm-config is not present to build LLVMLight, never making it to the failure message.
I do have an alternate idea for a workaround. You can upload empty binary packages for the next version of Python once the beta comes out. These empty binary packages have a single dependency on "python310-unsupported" or something like that - remember that I mentioned that dependencies are per-file, not per-release (please tell Poetry that). That has several benefits: you can upload them to an existing release, you can (and must) wait till Python 3.x is in the RC phase, so you can see if it just happens to work before uploading them, it gives the correct result even if some of your dependencies won't build, and it still allows advanced users like packagers to download from source and build if they are testing it out. I've seen this idea floated for the manylinux1 removal.

Now, there is a possibility - we could change the meaning of Requires-Python to also handle upper bounds. I don't know how much traction that would gain - Requires-Python was added (originally at the request of the data science community) to assist with dropping older versions of Python. Making it harder to update to a new version of Python might not go over all that well. But there's enough incorrect usage already that maybe just handling it by ignoring upper caps would be fine. :) Anyway, the "steps" would be to add a way to compute range overlaps with SpecifierSets (I already want this for something else, actually, but it's not trivial), then to add / suggest special handing for installs when the current version + all future versions are excluded by Requires-Python - either it could be ignored, or a message could be generated. This would "remove" the ability to drop a newer version of Python, but that's not really useful to the best of my knowledge.
Or the meaning of the slot can be very specifically clarified to only refer to dropping previously supported Pythons, and Setuptools/flit, etc could start producing warnings if anyone adds an upper cap. I'd be fine with that too. ;)

@henryiii The PEP and the PyPA Core Metadata specification both say:

This field specifies the Python version(s) that the distribution is guaranteed to be compatible with.

The core spec also gives Requires-Python: ~=2.6 as an example, which to me looks an awful lot like specifying an upper bound. If your assertion, "Requires-Python is not for upper limits" is indeed correct, those docs are woefully poor at communicating that and need updating.

I'm going to bring this up and see if the situation can be improved. I think there are three options that all would be better than the current implementation. For two of them, I think that wording needs to be tweaked, too, as it's terrible. I'll try to link the discussion here once I start it (1-2 days).

I've started a discussion here. https://discuss.python.org/t/requires-python-upper-limits/12663

Thanks @henryiii much appreciated.

I'd appreciate your comment on gh-14986 as the solution.

@rgommers Your workaround will not support locking package managers. I've tested both Poetry and PDM. If you add a basic file like this:
[project]
name = ""
version = ""
dependencies = [
  "numba",
]
requires-python = ">=3.8"

[build-system]
requires = ["pdm-pep517"]
build-backend = "pdm.pep517.api"

(Or the matching, non-PEP 621 version for Poetry) (using numba since SciPy currently supports 3.10) then PDM/Poetry will back solve to the last version that "supports" all future versions of Python (the last one without an upper limit, 0.51), and will lock that. Which of course breaks, even if you are currently running on Python 3.9!
Either every single version ever released without a cap has to be yanked[^1], or you could use the fake wheel suggestion I have above. But this hacky solution will not work properly, the metadata still lies. I'd recommend waiting until https://discuss.python.org/t/requires-python-upper-limits/12663 has some sort of resolution.
[^1]: Reminder: yanked packages can still be used, they just can't be automatically selected if not specified.

Thanks for trying that @henryiii!

Reminder: yanked packages can still be used, they just can't be automatically selected if not specified

This is, unfortunately, incorrect. Pip will still pick up yanked sdists for old releases if it cannot find another match. I recent had to hard-delete very old (<= 0.3.1) PyTorch sdists from PyPI because they kept being reported as not working by users despite being yanked.
The relevant PEP (I forgot which one) says yanked versions MAY be removed, not MUST. I think that was a mistake, it makes zero sense to try to install yanked old releases for a simple pip install some_package.

That's the difference between yanking and deleting - yanking tries to avoid selecting the package, but will still select it if no otherwise it would not solve. I would guess in your case someone had a pin or upper cap on an old version of PyTorch (probably from some other dependency so it was not obvious) making the yanked PyTorch SDists the only valid solve. (At least that's supposed to be the way it works, I wouldn't promise no bugs).
"automatically selected if not specified" - so yes, this was simplified. In other words, if the final solve is 0.3.*, and all 0.3.x release are yanked, then the latest 0.3.x release will be selected anyway. But a non-yanked release will be preferred over a yanked release if possible.

Those were the only releases with sdists, so a simple pip install torch would pick them up on platforms without wheels. Not much heartbreak over hard-deleting the files, but it did remove the archival value of those old releases.

Ahh, yes. So if you are asking for an SDist only release or if you are are on a platform with no binaries at all, those would be selected. Without the SDists, they would get a broken solve instead. Yanking does not break a solve, that's the idea.


What is the advantage of using init.R versus installing packages directly in Dockerfile with RUN Rscript -e install.packages...?

I would naively have done the latter, but the dash deployment docs are using init.R. Is this mostly to prevent the entire docker build from crashing if something is wrong with a user installed package or are there other advantages to this approach?

Related, since the dash docks now uses install.packages('dash'), should the deployment docs be updated to use this instead of remotes::install_github('plotly/dashR', upgrade=TRUE)?

Related, since the dash docks now uses install.packages('dash'), should the deployment docs be updated to use this instead of remotes::install_github('plotly/dashR', upgrade=TRUE)?

One advantage I ran into is that when trying to install devtools via the docker image, the build would fail due to an error with the dependency packages gert and usethis. I had to modify apt-packages to include libgit2-dev and libcurl4-gnutls-dev instead of libcurl4-openssl-dev for these packages to install correctly and I am not sure if that has any side effects. When installing devtools via init.R everything works fine with the default apt-packages.

One advantage I ran into is that when trying to install devtools via the docker image, the build would fail due to an error with the dependency packages gert and usethis. I had to modify apt-packages to include libgit2-dev and libcurl4-gnutls-dev instead of libcurl4-openssl-dev for these packages to install correctly and I am not sure if that has any side effects. When installing devtools via init.R everything works fine with the default apt-packages.


Copr: add cast_*_as_time

What have you changed?
Fix rest of cast functions: cast_*_as_time
Don't assume reviewers understand the original issue.
What is the type of the changes?
Pick one of the following and delete the others:

Improvement (a change which is an improvement to an existing feature)

How is the PR tested?
Please select the tests that you ran to verify your changes:

Unit test

/run-all-tests

/merge

Is there any testing for cast_decimal_as_time?

Sorry, I miss that. This will be fix in the next pull request.


Only python and numpy implementations available as reference

python and numpy implementations for deformable convolution (https://github.com/IntelPython/dpbench/pull/168) are too slow and fails by timeout and shouldn't be used as reference. Instead sycl should be used as reference.
But at the moment dpbench doesn't allow to choose reference implementation.

Sorry, this feature is not documented, but you can add reference_implementation_postfix key in benchmark configuration.


Delete downloaded mp4s when clearing the cache

Also,
SDImageCache.shared().clearMemory()
SDImageCache.shared().clearDisk()

and
SDWebImageManager.shared().imageCache?.clearMemory()
SDWebImageManager.shared().imageCache?.clearDisk()

call the same functions (clearMemory() and clearDisk()) so the second pair was removed in this change.

Great fix, thank you!

Also make sure to check out the changes @colejd  made to debug building in #528 @djjcast

Okay, thanks, I'll check it out.


does someone have run successfuly by using Azure Open AI APIs?

i am setting up like this :

but still get 404 errs like this:

could anyboy plz setting an example which really runs open devin up by Azure Open APIs ? love u guys ~

I'm closing this issue, since you already have https://github.com/OpenDevin/OpenDevin/issues/1033 on the same problem. If you want to start a discussion, not an issue, please use Discussions tab. Lets solve the issue in 1033.


Logo Proposal

Hi, I can see that you don´t have a logotype. What do you think about having an image upgrade (A banner for the GitHub project or any other graphics that your app would need).
I can sent you some drafts if you like. I`m thinking about some ideas.
Let me know.

That would be very great. Computer engineers miss sometimes creative people.
:-)

Hi Carlos
I am going to work on luakit. I am just a programmer who does not know anything in graphics, and all those sort of things.
I really think that it would be good to have

Logo
Banner
Icon
Splash screen

if you are ready, please go on :-)


Notification bug on Windows 10

Homework

[yes] I looked at nativefier --help and https://github.com/jiahaog/nativefier/blob/master/docs/api.md
[yes] I searched existing issues, open & closed. Yes, my bug is new.
[yes] I'm using the latest version available at https://github.com/jiahaog/nativefier/releases

Bug description
When I trigger a notification on Windows 10 Pro (20H2 - 19042.541) it shows me some code. Like this:

Also, the notification does not stay in the Action Center. Not sure if that is separate or related.
Steps to reproduce
Run the following command in Windows Terminal (app), via PowerShell 7.0.3 -- run as Administrator so I can install it into C:\Program Files:
nativefier --single-instance --tray start-in-tray --show-menu-bar --verbose "https://messages.google.com" "C:\Program Files\Nativefier"

Running in verbose mode! This will produce a mountain of logs and is recommended only for troubleshooting or if you like Shakespeare.

Performing async options post-processing.
Inferring user agent for electron 10.1.0 / win32
Grabbing electron<->chrome versions file from https://atom.io/download/atom-shell/index.json
Inferring icon for https://messages.google.com/ on win32
Inferring icon from store for https://messages.google.com/ on win32
Allowed icon formats when building for win32 (limited on Windows): [ '.ico' ]
Inferring name for https://messages.google.com/
Got 249 icons from gitcloud
Max icon match score: 2
Downloading https://jiahaog.github.io/nativefier-icons/files/google-messages.ico
Fetched 44.6 kb page at https://messages.google.com/
Inferred title: Messages by Google
Sanitized filename for Messages by Google : Messages by Google
Got an icon from the page.
Writing 361.4 kb icon to C:\Users\corey\AppData\Local\Temp\nativefier-14-43-7-iconinfer--6816-JSmxNAZtkYK5\icon.ico
Associated electron v10.1.0 to chrome v85.0.4183.87
Given chrome 85.0.4183.87 on win32, using user agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.87 Safari/537.36

Preparing Electron app...
Copying electron app from C:\Users\corey\AppData\Roaming\npm\node_modules\nativefier\app to C:\Users\corey\AppData\Local\Temp\nativefier-14-43-7-app--6816-qK4QDPh7m8cJ
Writing app config to C:\Users\corey\AppData\Local\Temp\nativefier-14-43-7-app--6816-qK4QDPh7m8cJ\nativefier.json
No files to inject, skipping copy.
Updating C:\Users\corey\AppData\Local\Temp\nativefier-14-43-7-app--6816-qK4QDPh7m8cJ\package.json 'name' field to messages-by-google-nativefier-a70f30

Converting icons...
Building for Windows and icon is already a .ico, no conversion needed

Packaging... This will take a few seconds, maybe minutes if the requested Electron isn't cached yet...
  electron-packager Electron Packager 15.1.0
  electron-packager Node v12.18.4
  electron-packager Host Operating system: win32 10.0.19042 (x64) +0ms
  electron-packager Packager Options: {"arch":"x64","asar":false,"darwinDarkModeSupport":false,"dir":"C:\\Users\\corey\\AppData\\Local\\Temp\\nativefier-14-43-7-app--6816-qK4QDPh7m8cJ","electronVersion":"10.1.0","icon":"C:\\Users\\corey\\AppData\\Local\\Temp\\nativefier-14-43-7-iconinfer--6816-JSmxNAZtkYK5\\icon.ico","name":"Messages by Google","out":"C:\\Program Files\\Nativefier","overwrite":true,"platform":"win32","targetUrl":"https://messages.google.com/","tmpdir":false,"win32metadata":{}} +1ms
  electron-packager Target Platforms: win32 +0ms
  electron-packager Target Architectures: x64 +0ms
  electron-packager Requiring author in package.json, as CompanyName was not specified for win32metadata +0ms
  electron-packager Inferring appVersion from version in C:\Users\corey\AppData\Local\Temp\nativefier-14-43-7-app--6816-qK4QDPh7m8cJ\package.json +4ms
  electron-packager Inferring win32metadata.CompanyName from author in C:\Users\corey\AppData\Local\Temp\nativefier-14-43-7-app--6816-qK4QDPh7m8cJ\package.json +0ms
  electron-packager Application name: Messages by Google +5ms
  electron-packager Target Electron version: 10.1.0 +0ms
  electron-packager Ignored path regular expressions: [ '/\\.git($|/)', '/node_modules/\\.bin($|/)', '\\.o(bj)?$' ] +0ms  electron-packager Downloading Electron with options {"platform":"win32","arch":"x64","version":"10.1.0","artifactName":"electron"} +0ms
Packaging app for platform win32 x64 using electron v10.1.0
  electron-packager Creating C:\Program Files\Nativefier\win32-x64-template +3ms
  electron-packager Extracting C:\Users\corey\AppData\Local\electron\Cache\httpsgithub.comelectronelectronreleasesdownloadv10.1.0electron-v10.1.0-win32-x64.zip\electron-v10.1.0-win32-x64.zip to C:\Program Files\Nativefier\win32-x64-template +0ms
  electron-packager Initializing app in C:\Program Files\Nativefier\Messages by Google-win32-x64 from C:\Program Files\Nativefier\win32-x64-template template +0ms
  electron-packager Ignored paths based on the out param: [ 'C:\\Program Files\\Nativefier' ] +1s
  electron-packager Renaming electron.exe to Messages by Google.exe in C:\Program Files\Nativefier\Messages by Google-win32-x64 +16ms
  electron-packager Running rcedit with the options {"version-string":{"OriginalFilename":"Messages by Google.exe","CompanyName":"Jia Hao"},"file-version":"1.0.0","product-version":"1.0.0","icon":"C:\\Users\\corey\\AppData\\Local\\Temp\\nativefier-14-43-7-iconinfer--6816-JSmxNAZtkYK5\\icon.ico"} +0ms

Finalizing build...
Copying icons if necessary
Copying icon C:\Users\corey\AppData\Local\Temp\nativefier-14-43-7-iconinfer--6816-JSmxNAZtkYK5\icon.ico to C:\Program Files\Nativefier\Messages by Google-win32-x64\resources\app\icon.ico
App built to C:\Program Files\Nativefier\Messages by Google-win32-x64 , move it wherever it makes sense for you and run the contained .exe file.

Expected behavior
I wouldn't see code.
Also, that the Notification would slide off screen (which it does) and then go into the Windows Notification Center (which it does not).
Actual behavior
I saw code. Notification disappears and does not go into the Notification/Action Center.
Context

Nativefier: 10.1.0
Node.js: v12.18.4
Npm: 6.14.8
OS: Windows 10 Pro 20H2 - 19042.541

Thanks for the report. Closing as probably a dup of https://github.com/jiahaog/nativefier/issues/1036 , and enriching it by mentioning notifications are affected too.


[SPARK-28055][SS][DSTREAMS] Add delegation token custom AdminClient configurations.

What changes were proposed in this pull request?
At the moment Kafka delegation tokens are fetched through AdminClient but there is no possibility to add custom configuration parameters. In options there is already a possibility to add custom configurations.
In this PR I've added similar this possibility to AdminClient.
How was this patch tested?
Existing + added unit tests.
cd docs/
SKIP_API=1 jekyll build

Manual webpage check.

Can one of the admins verify this patch?

@koertkuipers the feature is on the way what we've spoken about. Ping me if you think this area lacks something.

Test build #106513 has started for PR 24875 at commit 348c4ab.

Can one of the admins verify this patch?

Test build #106513 has finished for PR 24875 at commit 348c4ab.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/106513/
Test PASSed.

looks good to me

cc @vanzin

this branch works for me to set ssl.endpoint.identification.algorithm to empty string for admin client

Test build #107072 has started for PR 24875 at commit 30e4dd1.

Test build #107075 has started for PR 24875 at commit 52467de.

@koertkuipers Thanks for testing it!

Test build #107077 has started for PR 24875 at commit 27fde79.

Test build #107072 has finished for PR 24875 at commit 30e4dd1.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/107072/
Test FAILed.

Test build #107077 has finished for PR 24875 at commit 27fde79.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/107077/
Test PASSed.

Test build #107075 has finished for PR 24875 at commit 52467de.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/107075/
Test PASSed.

retest this please

Test build #107488 has started for PR 24875 at commit 27fde79.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/12619/
Test PASSed.

Test build #107488 has finished for PR 24875 at commit 27fde79.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/107488/
Test PASSed.

Merging to master.


Create nodejs.yml

Codecov Report

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

@@           Coverage Diff           @@
##           master      #46   +/-   ##
=======================================
  Coverage   73.04%   73.04%
=======================================
  Files          73       73
  Lines         846      846
  Branches       50       50
=======================================
  Hits          618      618
  Misses        206      206
  Partials       22       22

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 23bb594...2b31a4f. Read the comment docs.


Use u and u_sol for solution vectors

To avoid name clash with the spatial dimension y

More consistent to leave as y


Withdraw bid bug

People are able to withdraw their bid while the auction is still going on. This way of implementation will be wrong as the highest bid will get updated but if it is withdrawn the highest bid will stay the same value. The next bidder would be forced to bid more than the highest bid which has actually been withdrawn.

@kishan79 @parva-jain @Nitishnaidu368 @techpandora