Performance issues with BasicAuth and large number of LoginAttempts

Affected Version
silverstripe/framework                                   4.2.1                              The SilverStripe framework

Description
Two functions interact with the LoginAttempt object which when used in conjunction with BasicAuth result in significant performance degradation over time. (30-50sec page load times)
Note: this will only affect you if you're using email addresses and BasicAuth combined along with a large number of active users.
Basic auth calls Member::isLockedOut to determine if the member has been naughty and the last 5 attempts were unsuccessful. This results in the following query which due to the WHERE clause cannot be indexed: (OR)
SELECT DISTINCT LoginAttempt.ClassName, LoginAttempt.LastEdited, LoginAttempt.Created, LoginAttempt.Email, LoginAttempt.EmailHashed, LoginAttempt.Status, LoginAttempt.IP, LoginAttempt.MemberID, LoginAttempt.ID,
			CASE WHEN LoginAttempt.ClassName IS NOT NULL THEN LoginAttempt.ClassName
			ELSE 'SilverStripe\\Security\\LoginAttempt' END AS RecordClassName
 FROM LoginAttempt
 WHERE ((LoginAttempt.Email = "email")
 OR (LoginAttempt.EmailHashed = "email sha1 hash"))
 ORDER BY LoginAttempt.Created DESC
 LIMIT 5

This query is not optimised, and results in a full table scan and file sort (due to the order by). This becomes more of a problem when BasicAuth is enabled, as every request results in LoginAttempt object, which means the table can get very large very quickly.
We can resolve some of the performance issues by adding an index for email hashed, but because the query uses two filter clauses, it can't use any indexes we add :(
Member::getByEmail()  We don't seem to use Email in this class (it's always null) and the setter prevents it's use.
Steps to Reproduce
this will only affect you if you're using email addresses and BasicAuth combined along with a large number of active users (~2 million rows in LoginAttempt)
Resolution
Add indexes across  LoginAttempt->emailHash and remove email from the filter clause on Member::getByEmail(). The query then uses the index and doesn't have a performance hit.

Yeah, the overload prevents it being set anyway, but i guess we can't know about subclasses etc.


Auth.js support

NextAuth moved to  Auth.js with new multi framework API.
We are using with sveltekit and realized this lib no more working.
Please support now Auth.js as well.

I think this should work...
import {
  Adapter,
  AdapterAccount,
  AdapterSession,
  AdapterUser,
  VerificationToken,
} from "@auth/core/adapters";

Could you check if v2.0.0 now has the changes required to support Auth.js?
This PR comes with a couple of migration changes: https://github.com/AmruthPillai/next-auth-hasura-adapter/pull/2

Will test and let you know.
Thanks for your continuous support.


[Bugfix] Streamed tool calls now more strictly follow OpenAI's format; ensures Vercel AI SDK compatibility

This PR fixes tool streaming so that streamed tool call chunks pass the Vercel AI SDK's validations on chunk structure. While the existing chunk structure for tool streaming is OpenAI-compatible for most purposes (including use with the OpenAI SDK), the structure was apparently not 100% correct.
This PR fixes that. vLLM's tool calling API (streaming and non-streaming) is now fully OpenAI-compatible.
This means that you can use vLLM with the vercel AI SDK and the createOpenAI method in that SDK, like so:
import {createOpenAI } from '@ai-sdk/openai'
import {streamText} from 'ai'

const hermes = createOpenAI({
    compatibility: 'strict', // required if you want usage :)
    apiKey: process.env.OPENAI_API_KEY,
    baseURL: process.env.OPENAI_API_BASE,
}).chat(process.env.OPENAI_MODEL!)

const result = await streamText({
    model: hermes,
    tools: {...},
    ...
})

Note that based on testing, setting compatibility: 'strict' is required for some features like usage stats to work out-of-the-box.
I found a related issue vercel/ai#2231 that this should solve.
I promise this is the last fix before I get to Llama 3.1 :P
cc @mgoin @DarkLight1337
BEFORE SUBMITTING, PLEASE READ THE CHECKLIST BELOW AND FILL IN THE DESCRIPTION ABOVE

 PR Checklist (Click to Expand)
Thank you for your contribution to vLLM! Before submitting the pull request, please ensure the PR meets the following criteria. This helps vLLM maintain the code quality and improve the efficiency of the review process.
PR Title and Classification
Only specific types of PRs will be reviewed. The PR title is prefixed appropriately to indicate the type of change. Please use one of the following:

[Bugfix] for bug fixes.
[CI/Build] for build or continuous integration improvements.
[Doc] for documentation fixes and improvements.
[Model] for adding a new model or improving an existing model. Model name should appear in the title.
[Frontend] For changes on the vLLM frontend (e.g., OpenAI API server, LLM class, etc.)
[Kernel] for changes affecting CUDA kernels or other compute kernels.
[Core] for changes in the core vLLM logic (e.g., LLMEngine, AsyncLLMEngine, Scheduler, etc.)
[Hardware][Vendor] for hardware-specific changes. Vendor name should appear in the prefix (e.g., [Hardware][AMD]).
[Misc] for PRs that do not fit the above categories. Please use this sparingly.

Note: If the PR spans more than one category, please include all relevant prefixes.
Code Quality
The PR need to meet the following code quality standards:

We adhere to Google Python style guide and Google C++ style guide.
Pass all linter checks. Please use format.sh to format your code.
The code need to be well-documented to ensure future contributors can easily understand the code.
Include sufficient tests to ensure the project to stay correct and robust. This includes both unit tests and integration tests.
Please add documentation to docs/source/ if the PR modifies the user-facing behaviors of vLLM. It helps vLLM user understand and utilize the new features or changes.

Notes for Large Changes
Please keep the changes as concise as possible. For major architectural changes (>500 LOC excluding kernel/data/config/test), we would expect a GitHub issue (RFC) discussing the technical design and justification. Otherwise, we will tag it with rfc-required and might not go through the PR.
What to Expect for the Reviews
The goal of the vLLM team is to be a transparent reviewing machine. We would like to make the review process transparent and efficient and make sure no contributor feel confused or frustrated. However, the vLLM team is small, so we need to prioritize some PRs over others. Here is what you can expect from the review process:

 After the PR is submitted, the PR will be assigned to a reviewer. Every reviewer will pick up the PRs based on their expertise and availability.
 After the PR is assigned, the reviewer will provide status update every 2-3 days. If the PR is not reviewed within 7 days, please feel free to ping the reviewer or the vLLM team.
 After the review, the reviewer will put an  action-required label on the PR if there are changes required. The contributor should address the comments and ping the reviewer to re-review the PR.
 Please respond to all comments within a reasonable time frame. If a comment isn't clear or you disagree with a suggestion, feel free to ask for clarification or discuss the suggestion.

Thank You
 Finally, thank you for taking the time to read these guidelines and for your interest in contributing to vLLM. Your contributions make vLLM a great tool for everyone!

There are print statements and a TODO comment - is this ready?

sorry about that, just cleaned it up. It is now.

are all AMD tests expected to be failing?

are all AMD tests expected to be failing?

AMD tests are unstable atm, you can ignore them if the failure is unrelated to the PR.


split capture very slow

I've got a project where I'm trying to record high-res h264 encoded video while at the same time do some image processing on a second, downsized rgb stream. I'm capturing the hi-res at the highest full-frame resolution supported by V2 camera, 1640x1232 at 30 fps with a baseline profile, which seems to capture at the 30 fps mark (according to timing metrics in my code). However, I'm opening up a second stream with rgb format on splitter_port 2 with a resize of 640x480 and I'm finding at best, with zero extra processing going on, I get ~15 fps out of that stream. Any ideas as to what's going on or what I'm doing wrong?
Seeing this on both a RPi3 and RPi4 with the V2 camera module, both NoIR and IR versions.
import picamera
import time

class H264Output(object):
	def __init__(self):
		#Gather timing metrics
		self.lastTime = time.time()
		self.smoothedFps = 30.0
		self.counter = 0

	def write(self, buf):
		#This works fine, timing at ~30 fps
		nowTime = time.time()
		dt = (nowTime - self.lastTime)
		self.lastTime = nowTime
		self.smoothedFps += 0.05*((1./dt - self.smoothedFps))

		self.counter += 1
		if(self.counter%30 == 0):
			print("H264 FPS:", "%.2f" % self.smoothedFps)

		return len(buf)

class RGBOutput(object):
	def __init__(self):
		#Gather timing metrics
		self.lastTime = time.time()
		self.smoothedFps = 30.0
		self.counter = 0

	def write(self, buf):
		#This is the issue, only seeing ~15 fps at best
		nowTime = time.time()
		dt = (nowTime - self.lastTime)
		self.lastTime = nowTime
		self.smoothedFps += 0.05*((1./dt - self.smoothedFps))

		self.counter += 1
		if(self.counter%30 == 0):
			print("RGB FPS:", "%.2f" % self.smoothedFps)

		return len(buf)

if __name__ == '__main__':
	with picamera.PiCamera() as camera:
		camera.resolution = (1640, 1232)
		camera.framerate = 30
		camera.rotation = 180
		camera.drc_strength = 'high'
		camera.exposure_mode = 'sports'
		camera.video_stabilization = True

		h264output = H264Output()
		camera.start_recording(
			h264output,
			splitter_port=1,
			format='h264',
			profile='baseline',
			intra_period=30,
			bitrate=0,
			quality=30)

		rgb_output = RGBOutput()
		camera.start_recording(
			rgb_output,
			format='rgb',
			splitter_port=2,
			resize=(640,480))

		#Wait for 60 seconds to see fps results
		time.sleep(60)

		camera.stop_recording(splitter_port=1)
		camera.stop_recording(splitter_port=2)

Im interested to know if this was ever resolved. Having similar issue with my application.
One trick to improve performance is to switch the raw stream to RGBA. This has a performance benefit over RGB due to the way the encoder operates.


Make it more generic

Hi
I am wondering If you can make this plugin more generic by adding element while initializing by remove
var main = document.getElementById('main');

and allow user to select element like
new fullScroll({
	**elem: '#main',**
	displayDots: true,
	dotsPosition: 'left',
	animateTime: 0.7,
	animateFunction: 'ease'
});

Yes, it's done! Thanks


Binary not (!) lexer fix

Signed-off-by: Matt Paras<EMAIL_ADDRESS>Pull request
Description

Fixes the lexer such that the binary not (!) operator gets lexed correctly.
Related

Related Issues: fixes #833

Checklist

[ ] The RFC, if required, has been submitted and approved
[ ] Any user-facing impact of the changes is reflected in docs.tremor.rs
[x] The code is tested
[ ] Use of unsafe code is reasoned about in a comment
[x] Update CHANGELOG.md appropriately, recording any changes, bug fixes, or other observable changes in behavior
[ ] The performance impact of the change is measured (see below)

Performance

This should not affect performance as it is simply a bug fix in the lexing stage of tremor-script.

Coverage increased (+0.01%) to 81.715% when pulling 7f4bcea5d566fd7c2307ad6583078cffb75a380d on mattwparas:binary_not into f078ab76590d42655ad96a06089626e8cc47376f on tremor-rs:main.


Objects initialized before the Logger cannot log anything.

This effects only things initialized before the main loop is entered; i.e., all the most crucial high-level objects, most of which are declared statically, on the stack. Soln: initialize them on the heap after the logger is initialized.

Irrelevant in other cases. Will change if need be.


add script for updating common/ in container repositories

The script would pull specified SCLORG container image git repositories,
commits there an update of common/ submodule to the latest origin/master
commit or a specified commit. Then the changes would be pushed to the
repositories with the user's ssh key.
The script should meet the following rules:

run by the user, not a bot
be easy to configure and run

in most cases should be sufficient to run make push-to-containers

user is able to choose which container repositories to update

with editing array with containers

doublecheck if the commit is OK to push

WDYT?

@zmiklank One nitpick ;) Why is it not written in Python? Tests are missing and it would be easier to write them in python. We need some GitHub token or credentials for pushing PR, right? Do you count on testing them?

@phracek, thanks for the review.
I've chosen shell, as all of the container-common-scripts are written in shell.
I can of course add some tests, as you suggested.
We do not need token on credentials, as this script is meant to be run from localhost, using the credentials of the user.

@phracek thanks again, could you please look into the replies I wrote?
Also, I changed the container image name format from s2i-base to s2i-base-container, etc.

[test-all]

[test-all]

[test-all]

[test-all]

[test-all]

@zmiklank Please rebase this pull request against master. Thank you.

[test]


types-plugin: a_attr/li_attr are not merged to nodes

It seems that the a_attr- and li_attr-objects in the types-plugin-configuration are not merged into the node-objects:
  $("#test").jstree({
    core: {
      data: [
        { "id":"fldr0000", "text":"Folder 1", "parent":"#","type": "folder" },
        { "id":"doc0000", "text":"Document 1", "parent":"fldr0000", "type":"doc" }
      ]
    },
    plugins: ["types"],
    types: {
      folder: {
        a_attr: { title: "Its a Folder" },
        li_attr: { class:"folderClass" },
        icon: false
      },
      doc: {
        a_attr: { title: "Its a Document" },
        li_attr: { class: "docClass" },
        icon: false
      }
    }
  });

Result:
Neither title- nor class-attributes where rendered into the li-/a-tags:

jsFiddle:
https://jsfiddle.net/a7jyx94w/4/

Seems to work fine with 3.3.16 (the latest version from a few months ago)


Page does Not appear - Waypoint: Use Bracket Notation to Find the First Character in a String

Challenge http://freecodecamp.com/challenges/waypoint-use-bracket-notation-to-find-the-first-character-in-a-string has an issue. Please describe how to reproduce it, and include links to screenshots if possible.
The code screen for this page does not apear
Waypoint: Use Bracket Notation to Find the First Character in a String

I couldn't reproduce this. Can you give more information or a screenshot?

Oddly enough the page reappeared. Strange
Sent from my iPhone

On Aug 26, 2015, at 8:32 PM, Den McHenry<EMAIL_ADDRESS>wrote:
I couldn't reproduce this. Can you give more information or a screenshot?
—
Reply to this email directly or view it on GitHub.


无法启动服务器

latest.log
1.16.5 fabric

This is a warning because they do not like my version number for the bugfix release ("30c").   It should run fine for now but going forward I'll need to change to a 3 tuple system.
(30.0.1, 30.0.2, etc.)

OK，Thank you for your

There should be an update for Fabric soon.   I'm just waiting for 1.19.1 to be released.


Swap 3714 scicat in scientificmetadata table edit existing

Description
Validating duplicate name in the Scientific metadata field name. Earlier, this validation was done for the scenario, when a new row of scientific metadata has been added. But for the existing row, if we try to change the field name to an already existing field name, the validation doesn't happen and it allows duplicated values.
Motivation
Scientific Metadata validation
Fixes:
Duplicate validation of the Scientific Metadata field Name.
Changes:
Added validation trigger not only for the new Scientific Metadata Row but also for the existing row. Also, optimization has been done to avoid redundant definitions of the Form fields on the Scientific Metadata form.
Tests included/Docs Updated? Yes

[ ] Included for each change/fix?
[x] Passing? (Merge will not be approved unless this is checked)
[ ] Docs updated?
[ ] New packages used/requires npm install?
[ ] Toggle added for new features?
[ ] Requires update of SciCat backend API?

The error suggets

Datasets
Add metadata item
should not be able to edit the existing metadata with a duplicate name:
CypressError: cy.type() failed because the page updated as a result of this command, but you tried to continue the command chain. The subject is no longer attached to the DOM, and Cypress cannot requery the page after commands such as cy.type().

Common situations why this happens:

Your JS framework re-rendered asynchronously
Your app code reacted to an event firing and removed the element

You can typically solve this by breaking up a chain. For example, rewrite:

cy.get('button').click().should('have.class', 'active')

to

cy.get('button').as('btn').click()
cy.get('@btn').should('have.class', 'active')


Support LaTeX output and linking to bibliography

Closes #16 (without bibtex support which is something we should consider in the future).
It should alleviate the issues of users trying to convert notebooks to PDF via the LaTeX intermediary (whether explicitly as in #39 or implicitly as in #38) by providing a proper LaTeX support.
Also, allows (and enables by default) jumping from citations to to bibliography when output format is HTML.

+1 for bibtex support because

Quarto's autocomplete in VS Code and RStudio is more sophisticated than what's available in JupyterLab.
https://github.com/quarto-dev/quarto-cli/discussions/6674


Roll new release with strong mode fixes

It looks like we have already fixed these internally, but need an external release for DDC to be able to run.

Tried to infer 'dynamic' for 'T' which doesn't work:
Type parameter 'T' declared to extend 'num'.
The type 'dynamic' was inferred from:
Parameter 'a' declared as     'T'
but argument is 'int'.
Parameter 'b' declared as     'T'
but argument is 'dynamic'.
Consider passing explicit type argument(s) to the generic.
(package:intl/src/intl/date_format_helpers.dart, line 143, col 42)
Please fix all errors before compiling (warnings are okay).

Well that's interesting. Running dartanalyzer --strong doesn't show this error, but compiling with DDC does.

https://github.com/dart-lang/sdk/issues/29857

I believe this has already been fixed in 0.15.0 of Intl.


Refactor generics across Engine

Isn't it simpler, or you have any reasons to do it in the way you pick?

Hi @KrSerhiy, thanks.
That looks simpler, however, I'm afraid this makes changes to the code more fragile since changes to the type constraints could be breaking changes to the clients of the framework.
For example, if we remove one of the associated types from the Router protocol in the future, we would have to fix all the call sites (clients). By keeping it as is, we only have to change the internal type constraints, leaving the clients untouched.
In short, I don't think we can assume that the Router associated types will always match the Flow and other types.
I'm still thinking about it, so let me know if you agree or have other concerns.

Hi @caiozullo, you are doing good materials, thanks for that.
Removing one of the associated types from Router can't be done without affecting clients, cause you need to replace removed associated type with some concrete type, which may not match to the client's implementation of the protocol.
Addition of a new placeholder type to the Flow, Game classes, and to the startGame(questions: router: correctAnswers: ) function, instead of using the associated type of the Router,  in some cases, will be resolved by type inference, and in others - client will need just to specify additional type parameter, in a variable definition. Not too much.
Maybe, the thought, that use of separate placeholder types decouples, in some way, the Router from the Flow,  has some sense. But now, I can't figure out the real example, where does it really come in handy.

@KrSerhiy you're right, changes to the Router protocol would affect the clients, but only in the types that implement the protocol. This still can be safer and affect fewer clients when compared to changes that might affect method invocations and return types. Type inference should cover most of it though!
That's when types can get in the way – in dynamic languages that would not be a problem.
The Flow is internal to the project, so I believe it's fine to use the Router associated types there.
The Game is public and makes me wonder if it's the correct thing to do. Your changes already affected the outside boundary, so maybe we're looking at the wrong problem here. Maybe the Game should act as a type eraser and not expose any types. That would give us more flexibility for changes and be safer for clients. What do you think?

@caiozullo, I guess, in your implementation, you are using the technic similar to the type eraser, but it's not exactly the type eraser. The purpose of the type eraser to move the emphasis from the concrete type that implements the protocol to the concrete associated types:
// the router variable erases concrete type that implements Router protocol and cares only about concrete parameter types
var router: AnyRouter<Question<String>, Set<String>> = AnyRouter(NavigationControllerRouter(...))
router = AnyRouter(AnotherRouter(...)) // AnotherRouter is an implementation of the Router protocol in which also Question == Question<String> and Answer == Set<String>.

And in your implementation, a concrete type, that implements the Router protocol, isn't erased nor from the Game, either from the Flow.
But your comment inspired me to try the implementation with exactly the type eraser of the Router protocol, and I think that it's what we are looking for. I have already committed those changes. What do you think?
I have one more refactoring suggestion. We can replace the startGame(questions: router: correctAnswers: ) function whit initializer and a start method of the Game class, and the start method will use a factory method to create a new Flow instance inside. And also we can move the scoring(_: correctAnswers:) function inside the Game class if you don't consider that scoring shouldn't belong to the Game class responsibilities (I don't). That will remove the Question, Answer placeholder types from those functions, and makes them more readable. If you don't exactly get what I mean, I can provide the implementation. Let me also know what do you think about this.

To @caiozullo. I have already implemented the refactoring suggestion from the previous comment to be more clear.

Hey @KrSerhiy sorry for the late response – been super busy here.
I think my analogy with the type eraser was a bad one and generate some miscommunication, sorry.
What I was trying to say is to find a way to remove the generic types from the Game. Something like:
public class Game {
    private let flow: Any

    init(flow: Any) {
        self.flow = flow
    }
}

By making the property private, I don't mind what type it is for now. I just care about saving the clients to deal with the generics. It's a pain!
The AnyRouter you implemented looks neat but I don't think we need it. I'm happy to have your previous commit, with the Flow generic types simplified with types taken from the Router protocol. That's an internal implementation and should be fine.
About the start game inside the Game class, I think it's a good idea. Any reason why you prefer an initializer and a start method for the Game though? I think a public static start method could do fine and avoid clients having to have the extra step to create, then start. I'm fine with both actually but want to know your opinion.

I prefer the start and scoring methods instead of the free functions, cause, in this situation, it allows us to remove the type parameters from definitions of functions and use the type parameters of the Game class for methods:
// INSTEAD OF:
// with type parameters for class
public class Game <Question, Answer, R: Router> where R.Question == Question, R.Answer == Answer {
...
}

// with function's type parameters
public func startGame<Question, Answer: Equatable, R: Router>(questions: [Question], router: R, correctAnswers: [Question: Answer]) -> Game<Question, Answer, R> {...}

// with function's type parameters
private func scoring<Question, Answer: Equatable>(_ answers: [Question: Answer], correctAnswers: [Question: Answer]) -> Int {...}

// WE HAVE THIS:

// only type parameters for class
public class Game <Question, Answer: Equatable, R: Router> where R.Question == Question, R.Answer == Answer {
...
// without function's type parameters
public init(questions: [Question], router: R, correctAnswers: [Question: Answer]) {...}

public start() {...}

// without function's type parameters
private func scoring(_ answers: [Question: Answer], correctAnswers: [Question: Answer]) -> Int {...}
}

So, @caiozullo,  in your opinion, the better solution will be to leave Game class, as it was in the beginning, and to change the Flow class in the way to use the Router's associated types instead of the separate type parameters?

To @caiozullo. I understand, that this is an example project for your video course, and there is no real reason to do this refactoring stuff, only if you are just interested in it. So, if you are not interested in it, or you haven't really time for that, or something else, you can just say it, and I will not take your time.

Hi @serhiikrivtsov, yes I'd prefer to leave the Game class as it was. We have plans to change this class for future videos and it will solve these issues.
If you revert it back, I'm happy to merge the initial changes you did for the Flow.
Thanks!

To @caiozullo. I have done it. Please check it, to be sure, that I understood you correctly.

@serhiikrivtsov awesome! Merging.

@serhiikrivtsov we're really glad for people to use this codebase to share knowledge. We're openly inviting people to participate but we're still going to be reviewing and maybe not all changes will be accepted/merged.
I might not have time to check this every day but will be looking every time possible.
You've done great work, thank you very much for sharing!


your carousel does not work in responsive mode

your carousel does not work in responsive mode

@amirheydari9  yes. It doesn't work for me either

@amirheydari9 @guliyevravan Same here :(

@amirheydari9 @guliyevravan Same here :(

npm uninstall vue-owl-carousel
npm install vue-owl-carousel2 😄😄😄
All config is same 😄


Incorporate Kurble's work for bevy 0.4 and fix shader panic with bevy_webgl2

Opening this PR for discussion / discoverability. It switches tiled to my fork that I likely won't maintain, so it's not really mergeable.
I preferred Kurble's fork over https://github.com/StarArawn/bevy_tiled/pull/30 because of this: https://github.com/StarArawn/bevy_tiled/commit/014b8fdfa1588137d6c420f428b3cb3f6731194b and it seems to work fine, but there are other differences and I don't know enough about bevy internals to say more.
This might save some effort if you or someone else is trying to get bevy_tiled working with bevy 0.4 and bevy_webgl2.

rs-tiled merged my PR, so it is now wasm-compatible in the same way my fork was. So I have un-forked it in this branch.
https://github.com/mattyhall/rs-tiled/commit/8d25d2510fd4f63d1b920126c5db4ab210eb9ad5

I have sort of accidentally turned this fork into one that's tracking bevy master, so I updated the title/body to reflect that.
If you'd welcome separate PRs for the webgl2 fixes or a PR that's compatible with bevy 0.4, I'm more equipped to handle that sort of thing than when I originally opened this.

Going to close this and open a new PR


Implement modPow variant that performs constant time exponentiation

I don't have any data to back this up, but based on a few other issues that I've seen (and my own experience), I think that a number of users use this library for cryptography (including algorithms like SRP).
To prevent timing attacks, these algorithms must perform exponentiation in a constant time such that the exponent cannot be calculated.
Currently modPow uses the "square and multiply" method, which performs an extra multiplication with each 1 in the exponent. It'd be great if a more secure alternative could be implemented, perhaps with a different name, for these applications.

I guess the critical part is
if (exp.isOdd()) r = r.multiply(base).mod(mod);

If you perform the multiply and mod every time it far more difficult to measure if the current bit in the exponent was odd. Something like
const q = r.multiply(base).mod(mod);
if (exp.isOdd()) r = q;

But of course this would increase the average run time, but if you want to hide your exponent from spying eyes, it would be an improvement.


[] update to <3.16>

Library name:
wxWidgets
New version number:
3.16
Other information that may be useful (release notes, etc...)

@weather-tracker
Isn't the latest version currently 3.1.6, not 3.16?
https://github.com/wxWidgets/wxWidgets/releases
So, if it's a typo, then please fix the incorrect title and opening post and edit them to look more common as other port update requests.

...wxwidgets>] update to <3.16>

Better title would be:

[wxwidgets] update to 3.1.6

Better opening would be:

Library name: wxWidgets
New version number: 3.1.6
https://github.com/wxWidgets/wxWidgets/releases

Fixed by #24483


Kernels 2021-07-25

[x] Fits CONTRIBUTING.md.

Now that 5.12 is EOL, we should also remove it.

I was going to do that it another pull request, but don't have time right now.

Diff LGTM, building 5.13.5

@OfBorg test simple


Update package_url in setup.py

Looks like this failed CI

Looks like this failed CI

Just needed a rebase.


Paypal input field issue in in-app browser

I have an ionic app which uses paypal in-app browser for checkout. As soon as the user is redirected to the paypal page and they to click on email field or the password field, cursor to add, edit email or entering password dont show up. The issue happens at the selected area of the text fields, means if I click on the top selected area as in the screenshot.
This seems to happen only on Android.

To reproduce the issue, just load the paypal in in-app browser on android device and try to click on the top area of the text field or password field.

@walmik can you take a look?

@brijendratiwari Hello Brijendra, could you please help me understand the issue correctly... is the email or password cut off visually at all times? Or is it something that happens only when you click in the input field to edit or enter an email or password.
Typically iframe integrations on devices seem to have quirks that are not easily identifiable just with a screenshot. Would it be possible for you to create a video/animated gif of the issue? It can help me seeing the exact issue and the way to solve it. (Android has free apps to record screen activity)
Also please share the integration pattern used to initiate checkout - @bluepnume it seems like the older integration pattern for login is served.

Hello @walmik ,
This is a random issue which users are facing with paypal when used in in-app browser. The issue is with certain click area. As mentioned in the screenshot, if by any chance user click in that area, cursor dont appear and whole page is freezed. If user click on below area, cursor appears and user is able to type in the email address.

I figured out the issue. The issue was with the old version of in-app browser plugin for Ionic.

That’s good to know @brijendratiwari :) Thanks for sharing the root cause.

Great, thanks!


Update documentation (README)

Correct title for the endpoint that lists cities
Clarify that the rate limit of requests is specific to each user.

For rate limiting i use express-rate-limit package it's a Basic IP rate-limiting middleware for Express. Use to limit repeated requests to public APIs
Rate limiting is generally more common, especially in production. Once an effective rate limit has been chosen, rate limiting is a clear way to block malicious and unwanted requests. Rate limiting is also useful for public APIs. People that offer APIs often provide a rate limit for users without an API key, or users who haven’t paid a fee for a certain number of requests.
I hope this is helps ☺


Ability to stream data (for non-serverless adapters like adapter-node)

Is your feature request related to a problem? Please describe.
I have APIs built with Sapper that I'd like to migrate to SvelteKit, but some endpoints rely heavily on using Node streams to pipe data to the response, as there can be gigabytes of data that are too large to serialize to a string server-side in memory. Some of this data is coming from a database, other data is coming from streaming and processing large files that live on AWS S3.
Describe the solution you'd like
I'd like to be able to return an async iterator in the body attribute of the response. I realise streaming isn't possible with most (all?) serverless adapters or adapter-static, but would certainly be possible with adapter-node and possibly other adapters that don't yet exist.
Describe alternatives you've considered
adapter-node and the development server could expose the Node res object to the request so I could pipe directly to the res object inside the request handler.
Otherwise, I will have to split off the API into a standalone Node server that does not live within SvelteKit, or continue to use Sapper and have a much slower build process during development.
How important is this feature to you?
I would love to keep my API in SvelteKit as I currently do in Sapper. It's really nice having the API endpoints live in the same router. To split it off into a separate server will incur extra complexity, such as dealing with sharing authentication, keeping the servers in sync, multiple code bases, etc. I would really rather not stay with Sapper long term.
Additional context
Add any other context or screenshots about the feature request here.
EDITED: changed the preferred solution from stream object to async iterator, because Node Streams in v10+ are also async iterators.

Heavily related to https://github.com/sveltejs/kit/issues/1491 and https://github.com/sveltejs/kit/issues/887.

If we wanted to ensure that returning a stream in the body remains compatible with all adapters, so that this isn't a special adapter-node-only feature, it is possible to collect the contents of a stream in a string for compatibility with adapters that will never support streaming. See stream-to-string for one implementation of this. (Obviously this would have memory limitations but would work with serverless adapters otherwise.)

I've thought about this problem before, and my first idea for the API design for this in endpoints is something along these lines:
export async function* get() {
    yield {
      status: 200,
      headers: {
        "Connection": "keep-alive",
        "Content-Type": "multipart/mixed",
        "Transfer-Encoding": "chunked",
      },
    };

    // ... every time you get new data to send (so suppose this is in a for/while loop or waiting for another promise)
    yield {
      headers: {
        "Content-Type": "application/json; charset=utf-8",
      },
      body: newData,
    };
    // return from the function when done
}

// this was modeled after https://github.com/contrawork/graphql-helix/#basic-usage

(Disclaimer: I honestly haven't done streamed responses in Express myself before so I might have missed something about how they work). The original sample has some work with chunk boundaries and Content-Length, but I think it's reasonably simple for SvelteKit to have abstracted this away like above.
This was just an initial thought for someone else to refine / reject; hope it's constructive.

@babichjacob using a generator function for the body instead of a Node Stream is a great idea - though it wouldn't send new headers on every iteration, so it would just be for the body contents. I like the idea of leaning on JavaScript and away from Node, so that this would be more universal and compatible with Deno as well (and other non-Node JavaScript runtimes that may arise in the future).

Converting an asynchronous iterator to a string (for serverless & static adapters) would be as simple as this:
async function iteratorToString(iterator) {
   let string = '';
   for await (let chunk of iterator) {
      string += String(chunk);
   }
   return string;
}

@benmccann that's great! I'd be very happy to help with the implementation of this - I'll try to put together a pull request in the next week or so.

that's great! I'd be very happy to help with the implementation of this - I'll try to put together a pull request in the next week or so.

Don't forget to wait until multiple team members have commented to figure out what the API should look like—and other things related to that.

Ah, I had searched for an issue (which didn't exist) and went ahead with an experimental implementation before opening what is now a duplicate issue. Happy to help here if I can. I concur with @jesseskinner's design sensibilities.

Literally the only missing puzzle piece for me. If there is anything I can do to help, ping me.

I'm pretty comfortable with JavaScript, but it isn't my primary language, so I haven't used async iterators before and don't have any opinion on whether or not it's the best design choice. If you'd like to send an implementation, please feel free as long as you don't mind getting some feedback about reworking it. If you'd rather have that feedback up front I can try to ask some of the other maintainers about this ticket

@benmccann feedback up front would be ideal, but I'll probably end up starting an implementation sometime soon even if I don't hear back. Thanks!

There is an implementation linked in the issue I created. See here:
https://github.com/sveltejs/kit/compare/master...kjmph:feature/event-source?expand=1
I didn't open a pull request because it suggests opening an issue prior to a PR.

It would be fine to open a PR referencing this issue, but I do think that you should try to make it more generic than text/event-stream first

I would vote for having some way of accessing the raw request object on whatever the platform you are. That would allow not  only to use streaming on other environments apart from NodeJS but also allow any other use case that requires access to this objects or even any future development or features that will be available on every particular platform. It would mean that the sveltekit team will not have to think too much when new requests to support new things comes in as having access to this objects means that there will always be ways to workaround any problem until a more "user friendly" solution is develop.
In my particular case I want to try streaming on cloudflare workers, but if that doesn't work I might also try vercel. I also need to pipe the requests through a number of transform streams before using the final result. The goal would be to bypass the part in which the rawBody is filled as it's the kind of thing you want if you're using streaming. In any case I will have to use some proxy to send this requests outside sveltekit or may be use CORS. So there are some options but It's a little bit of an inconvenience.

Hello @benmccann; @jesseskinner and I synced on what a more generic solution would look like. We updated the experimental branch to be generic. Still seen at the same repo/branch: https://github.com/sveltejs/kit/compare/master...kjmph:feature/event-source?expand=1
We'll open a PR referencing this issue after a final review by @jesseskinner.
RE: @juanmait; while I understand the comment, I think this issue is focused on using the same function signature with a different returned object to support streaming through async iterators. The suggestion to add the request and/or response object into the function signature would change the design of endpoints in SvelteKit. Perhaps you should open a new issue to address that?

RE: @juanmait; while I understand the comment, I think this issue is focused on using the same function signature with a different returned object to support streaming through async iterators. The suggestion to add the request and/or response object into the function signature would change the design of endpoints in SvelteKit. Perhaps you should open a new issue to address that?

Having some support is very welcome. I'm wondering if this solution will fit in an environment like cloudflare workers. The stream API is different from nodejs, it's basically the same API that ships in modern browsers. I'll try this option anyways in nodejs. Thanks!

Access to raw response object looks like must have.
Async iterables are cool, but could cause some hard to find issues, like you can't just write to a stream i.e.
for await (const event of rendered.body) {
   res.write(event);
}

you need to handle backpressure in this case, end etc events. All needed processing can be achieved easily by using pipeline from 'node:stream' but in case of event streams flush is needed.

Hello @istarkov, a few points to address in regards to your comment. I'll break them out into a numbered list.

Should request/response be accessible to the endpoint handler? I believe this has been discussed via #334. That's not the objective for this issue.
Attempting to extend the endpoint handler using async iterable objects is precisely what we are experimenting with here.
We should handle back pressure, and we haven't implemented that yet. We will make the change before a pull request is opened.
We believe end events can be handled when the sequence completes or in the case of infinite sequence, when the connection is destroyed.
Using pipeline from node:stream would ensure this solution would only live in adapter-node. Is there a package that implements the Streams API so this could be more agnostic?
We are currently experimenting with flush via checking the content-type header and using compressible to decide if flushes are required. Works for EventStream.
Micro is an interesting project; yet does not conform with the endpoint design as-is.

Since you had asked after it @istarkov; completed the back pressure changes. I needed the push from you, since the compression bug was outstanding. :)
https://github.com/sveltejs/kit/commit/38c0d4a2bc51bf7f4a0da05df9a5c6e9b1da3a76

I think that we will end up exposing the ability to add middleware in adapter-node (https://github.com/sveltejs/kit/pull/2051)

Ok great. Sounds like a much more flexible solution, for now at least.

I think that we will end up exposing the ability to add middleware in adapter-node (https://github.com/sveltejs/kit/pull/2051)

Does this mean that the accompanying pr won't be merged?, because having direct access to add middlewares is awesome and a more simple way to add web sockets.
But isn't the ability to stream responses still valid?
Cloudflare workers also support such use cases, so it doesn't have to be exclusively for adapter-node

Even if we don't merge https://github.com/sveltejs/kit/pull/2051, I'd still like to find a way to let people add middleware

My apologies, I've been out of pocket for a while with work. @jesseskinner wanted to add support for adapter-static, which is what delayed this patch. I'll rebase and sort conflicts; then perhaps we can open the pull request and move the conversation there? I concur @AndreasHald, this change still seems useful.

The proposed PR would support serverless too? Sounds great!

@benmccann yeah, the idea is that all adapters would have to support apps returning an async iterator in the body. Most adapters would do the same as adapter-static and collect as a string. But any adapter could stream the response instead.

While async iterators make for a nice interface, it seems things are converging on WHATWG's Streams API for cross-environment streams. They are being used at least on Service Workers, Cloudflare Workers, and Deno. For Node, there's a reference implementation, a pretty popular polyfill and even experimental official support.
What are the reasons to go with async iterators in this case? Unless we're pragmatically picking them, Streams seem like a safer bet for compatibility.
That said...
I understand SvelteKit is supposed to provide a common interface regardless of the underlying platform — but is that a hard requirement or would adapter-specific functionality ever be valid? I ask because in this case we're indirectly dealing with platform details. Users will rarely create streams out of thin air: while they could have generators pumping out data algorithmically, they'll most likely get data from somewhere else, and in that case, they'll get the platform's stream implementation.
In other words, right now, an endpoint using fetch will get either a web or a node stream depending on the deployed platform. Same for reading files. So apps would need platform-specific code to create a platform-agnostic iterator or stream anyway!
What do you think about adapter-provided stream handling? SvelteKit could handle strings, objects, and async iterators out of the box. Adapters could add support for platform-specific types like Node/Web streams and buffers. As long as user code dealt with streams opaquely, it would work regardless of the platform. Unfortunately, if in-flight manipulation was required, they'd need API-specific code.
Unless the idea was to eventually ship with platform-specific wrappers to normalize all IO so that SvelteKit apps are truly environment-agnostic? In that case, an adapter-provided fetch would have a SvelteKit Stream/Iterator body, the same type expected of endpoint responses.

Async iterators can be converted to streams for adapters that support the Streams API (we could support Cloudflare Workers and I can add that if we want to see it). I don't know the maintainers philosophy, yet I'm hesitant to suggest a feature that is dependent on non-LTS versions of Node.js or dependencies that would be foisted on downstream developers. Plus, where Node.js 16.6.2 has experimental support, the ReadableStream is still converted to a Node Stream via async iterator support to send the ServerResponse.
I am not a maintainer, but I think the SvelteKit design is one that the endpoints are emitting data, and the async iterator promotes that design choice. Regardless of my opinions, here are two demonstrative endpoints for comparison. (Tested on Node.js 16.6.2 on experimental branches in my fork)
Streams API:
import type { RequestHandler } from '@sveltejs/kit';
import type { Locals } from '$lib/types';
import { ReadableStream } from 'node:stream/web';

const wait = ms => new Promise(resolve => setTimeout(resolve, ms));

// GET /es.json
export const get: RequestHandler<Locals> = async (request) => {
    // Handle setup here..
    const es = new ReadableStream({
        async start(controller) {
            while (true) {
                controller.enqueue(`event: time\ndata: ${(new Date()).toISOString()}\n\n`);
                await wait(1000);
            }
        },
        cancel() {
            // Handle cleanup here..
        }
    });

    return {
        headers: {
            'Cache-Control': 'no-cache',
            'Connection': 'keep-alive'
        },
        body: es
    };
};

Async Iterators:
import type { RequestHandler } from '@sveltejs/kit';
import type { Locals } from '$lib/types';

const wait = ms => new Promise(resolve => setTimeout(resolve, ms));

// GET /es.json
export const get: RequestHandler<Locals> = async (request) => {
    // Handle setup here..
    async function* es() {
        try {
            while (true) {
                yield `event: time\ndata: ${(new Date()).toISOString()}\n\n`;
                await wait(1000);
            }
        } finally {
            // Handle cleanup here..
        }
    }
    return {
        headers: {
            'Cache-Control': 'no-cache',
            'Connection': 'keep-alive'
        },
        body: es
    };
};

The only caveat is that the import of ReadableStream from node would have to be injected by SvelteKit into the global namespace per adapter. I don't know how to accomplish that. I suppose this is another reason why I like async iterators, they are more universally available today..

the import of ReadableStream from node would have to be injected by SvelteKit into the global namespace per adapter. I don't know how to accomplish that

We do that with fetch already. See:

https://kit.svelte.dev/docs#writing-an-adapter
https://github.com/sveltejs/kit/blob/7faf52f2fd8a0321397856f3d12bc9aa9f64435b/packages/kit/src/install-fetch.js
https://github.com/sveltejs/kit/blob/master/packages/adapter-netlify/files/shims.js

@mrkishi good to see you! long time.
Just chiming in to say that I think using async iterators rather than ReadableStream is ultimately the right choice, for a couple of reasons:

it's the pragmatic choice — as @kjmph mentioned, support for web streams is still very new in Node. the polyfill for ReadableStream (which Lambda wrappers etc would need) is quite substantial
i also have some concerns about the amount of confusing junk you get if you google 'readablestream node' — documentation around streams in Node has always been confusing IMHO, but it's much worse now that 'readable stream' could refer equally to the node API or the web API
the ReadableStream API is... a lot. not that generators are the easiest concept, but simple things like cleanup are much simpler. For example I'm pretty sure that the example above...const es = new ReadableStream({
    async start(controller) {
        while (true) {
            controller.enqueue(`event: time\ndata: ${(new Date()).toISOString()}\n\n`);
            await wait(1000);
        }
    },
    cancel() {
        // Handle cleanup here..
    }
});

...would just keep enqueuing data long after the connection had closed, so a fairer comparison would look like this —let timeout;
const es = new ReadableStream({
    start(controller) {
        function enqueue() {
            controller.enqueue(`event: time\ndata: ${(new Date()).toISOString()}\n\n`);
            timeout = setTimeout(enqueue, 1000);
        }
    },
    cancel() {
        clearTimeout(timeout);
    }
});

async function* es() {
    while (true) {
        yield `event: time\ndata: ${(new Date()).toISOString()}\n\n`;
        await wait(1000);
    }
}

— in many cases no cleanup work is necessary with generators, and where it is, the relevant pieces aren't scattered around outside the stream definition (unlike the timeout above), they're in scope. And when writing a generator you don't really need to worry about backpressure.
IIUC, you'll one day be able to do this anyway: for await (const chunk of stream.getIterator())

It really seems like a lot of effort is going into making svelte-kits capabilities uniform across the spectrum of adapters. I understand that, to a degree. It makes documenting and migration easier. I think an important question is, what do you lose by doing so?
In reading through this issue and related (people requesting middleware or file uploads), I'm sort of left with confusion over what Svelte Kit aims to be. @Rich-Harris, you've called SvelteKit a "serverless framework" and have voiced opposition to exposing the underlying connect-style req / res from polka in the node-adapter because you're concerned people will default to using it over alternatives due to its capabilities.
This makes sense if the objective of project is to be a serverless framework. It would make sense that you'd rather people abandon node or serverful environments as that's just another thing that needs to be maintained.
If the objective is for SvelteKit to be agnostic of where a person's application resides, be that a kafka cluster, netlify, vercel, or the next trend, then I think you may want to consider how it can be perceived from folks who are not going with serverless environments. It seems as though you are limiting yourself to the lowest common denominator while devoting energy to construct work arounds which conform to that standard.
I understand that some of the defacto packages in the node ecosystem can be confusing or less than desirable. In fact, it is somewhat surprising to me that many haven't been supplanted over the years. Having said that, they are clearly still viable and heavily depended upon. This means that adoption and/or forcing people to re-invent the wheel will add yet another developer tax on using Svelte / SvelteKit.
I think it may also limit folks to address kit-specific challenges. For example, I'd like to be able to generate static files, house them in GCS, and stream them down upon request. That's not feasible with kit as-is.
The usage of async generators may make part of that problem solvable but it'll require more effort on my part than utilizing node streams today or web streams in the future.
I'm not sure I would have chosen Kit with these  it if my API weren't being built in another language despite my opinion that Svelte is the best option available for front-end frameworks. I would have probably rolled with Next and called it a day.

The goal is to make SvelteKit apps as portable as possible, which definitely doesn't preclude adding non-portable things like direct access to underlying primitives like res eventually. I do think it's worth holding off as long as possible so that we're able to clearly articulate the problems we're trying to solve and see how well we can solve them in a portable way.
This thread is a wonderful example of that. If res was freely available, people would have just used it for streaming responses, and we wouldn't have #2212 which to my mind is a better solution.
It's definitely tempting to think 'if we have the escape hatch, not only will we be able to solve $THIS_PROBLEM, we'll be able to solve a bunch of $OTHER_PROBLEMS in future, but what I've often found is that when you actually sit down and think about $OTHER_PROBLEMS it turns out to be a finite list where we already know the general shape of the solutions; we just have to implement them. Sometimes there are problems you couldn't anticipate, and in those cases escape hatches are useful, but it does need to be an escape hatch rather than a blessed solution otherwise it ends up being used for everything.
The consequence of relying on res isn't just that code becomes less portable (though that is very much the case). It's that Node becomes the default way to use SvelteKit, because the ecosystem hardens around existing middleware packages etc. Ultimately that will just make it harder to use things like Cloudflare Workers and Deno Deploy, even though they will likely have better cost/performance characteristics for many apps. (Case in point: if you had rolled with Next, those platforms wouldn't be an option for you.) I think that would be a shame. Node is the present but it isn't the future (at least, it won't enjoy its current monopoly on server-side JS), and so I think we want to avoid being Node-centric in our assumptions.

The usage of async generators may make part of that problem solvable but it'll require more effort on my part than utilizing node streams today or web streams in the future.

Could you elaborate on this part? You would be able to use node streams like so...
return {
  body: fs.createReadStream('data.csv')
};

...and web streams like so:
// today
return {
  // https://jakearchibald.com/2017/async-iterators-and-generators/#making-streams-iterate
  body: streamAsyncIterator(readable)
};

// tomorrow
return {
  body: readable.getIterator()
};

I'm going to back-peddle on my reply above a bit. Both Fastify and Koa departed from the traditional connect/express approach to server middleware and did just fine. Micro, the server for Next, is different. In the case of Koa and Micro, middleware could be modified to work. Fastify has done quite well despite the fact that node's legacy middleware are all but incompatible and require ports, such as fastify/fastify-passport.

My hope is that many use cases could be addressed via an adapter that converts Connect middleware, not unlike how serverless-http mocks req/res objects so you can use them inside Lambda event handlers. It's exactly the kind of grotesque mad science that lets you ship today, but makes you feel sufficiently grubby that you're motivated to adopt (or build) a leaner, more idiomatic solution:
// src/hooks.js
import { sequence } from '@sveltejs/kit/hooks';
import { convert } from 'svelte-kit-middleware-adapter';
import foo from 'express-foo';
import bar from 'express-bar';

export const handle = sequence(
  convert(foo()),
  convert(bar()),
  ({ request, resolve }) => resolve(request)
);

Sorry, I posted my backtrack above without seeing that you had responded to me.

It's definitely tempting to think 'if we have the escape hatch, not only will we be able to solve $THIS_PROBLEM, we'll be able to solve a bunch of $OTHER_PROBLEMS in future, but what I've often found is that when you actually sit down and think about $OTHER_PROBLEMS it turns out to be a finite list where we already know the general shape of the solutions; we just have to implement them.

Thats certainly true. It'll slow adoption considerably but perhaps thats not a bad thing. If the framework provides viable mechanisms to employ the logic, its just a matter of time before the solution bank is built up. It puts more on early adopters but that's always the case.

Could you elaborate on this part? You would be able to use node streams like so...
I stand corrected. That'll be clean enough for me.

My hope is that many use cases could be addressed via an adapter that converts Connect middleware, not unlike how serverless-http mocks req/res objects so you can use them inside Lambda event handlers.

That'll work.
Thanks for taking the time to explain your stance and reasoning. And for Svelte/Kit.

I’m glad to see the alignment solidifying. I concur that canceling the timeout is a fairer comparison, if a more robust example was helpful, we could move on that.. I must make the callout that I’m running a company and could use any assistance on getting that pull request over the hump; otherwise I’ll continue to be fitful with progress. In what way can I be the most helpful?

@kjmph No worries, I was hoping to give it a shot this week, either rebasing your branch or maybe starting a new branch if it's easier, and try to get this done soon. Will keep you all posted.

And @Rich-Harris big thanks for giving this your feedback and blessing, it's exciting to be reassured we're on the right track with this approach.

Great discussion, everybody.
I think I should've skipped the first part of my comment as I realized midway async iterators were a good default, but ended up only mentioning it in passing.
After testing some async iterators behavior, I'm wary about the stream to async iterator to stream conversion that's going to be necessary on Node/Deno/Web when doing IO. There's a subtle but important mismatch in that async iterators don't support cancellation. I don't think we can guarantee cleanup in the general case. Check out people trying to deal with cancellation and how finicky it can be. I'm not sure how to deal with that.
Note that it'd be possible to leak resources even without crazy pipelines:
const req = await fetch('/sparse-stream');
return { body: streamAsyncIterator(req.body) };

When the downstream connection closes, at most we could call body_iterator.return(), but that wouldn't propagate to fetch until the next chunk of data arrives. If they're infrequent updates, the orphaned connections would just accumulate until timeout. This isn't too serious, but I'm traumatized by Node Streams and wouldn't be surprised to find worse edge cases.

@mrkishi good point, there would be no way to know a connection was closed and thus no opportunity to abort and release resources early other than timeouts. Note this would also be the case if you tried to create a massive string response asynchronously - even if the connection is lost, the async endpoint will continue working away. So you have a good point, that async iterators are an imperfect and incomplete proxy for streams, and so hooking into the res object would allow listening to events and saving resources. But I think async iterators will end up being good enough most of the time, certainly for my use cases.

Just a follow question because I may have misunderstood the use case here. If I want to serve video files to the browser, would I be able to use iterators to stream that data or would I have to write an endpoint that understands http-range headers? I can see iterators or streams serving data from 0 -> content-length, but if a user skips around a video it seems like streams could not help here.

RE: AbortController; I fully believe this lines up with the SvelteKit portability goals, yet I highly suggest we look at that independently from this issue. That's because converting from a readable stream to an iterator is introducing the need for cancellation. Maybe that is an edge case better solved with middleware through some of the other proposed PRs?
RE: http-range; usage of an iterator will just conveniently allow us to stream data from the normal endpoint handling. You are correct that one would need a custom endpoint that understands http-range headers to decide where to start the stream from. I believe createReadStream does support start and end options for this purpose. This would necessitate  cancellation support.

I created a separate issue about streaming requests on endpoints but it was closed by maintaner. Does this issue mention this use case? If not then here's my input on data streaming https://github.com/sveltejs/kit/issues/2992

That's correct, this issue focuses on responses. Requests are limited to parsing in some restricted cases, as the documentation clarifies. Here is an example of the runtime, and a Cloudflare Worker Request Context constructing the rawBody. There is an expectation that streams aren't a valid input for rawBody. I'd suggest clarifying that in your linked issue @quentincaffeino, perhaps it can be re-opened and investigation can commence on if it is feasible to stream a request body.

Hi folks, I wanted everyone to know that Rich posted a mini-RFC regarding file uploads, which overlaps quite a bit with the discussion here around async iterators, etc. Please take a look

I've opened #3419 which covers the use case discussed here as well as multipart forms (#70), in light of the changes in #3384. tl;dr @mrkishi convinced me that ReadableStream is preferable even if the ergonomics aren't quite as nice, and now that we've switched to returning standard Response objects from handle, it makes sense for handlers to return a valid Response body, which means ReadableStream.
Closing this in favour of that issue — thanks for the valuable discussion everyone!


Unreal: launching on Linux - 2.x backport

This is fixing issues of launching Unreal on Linux.
⏩ OpenPype 3 PR: #1672
|---|

This is no longer need in 2.x


component with useSelector unnecessarily get rendered even if state return by useSelector is not updated

Do you want to request a feature or report a bug?
BUG
(If this is a usage question, please do not post it here—post it on Stack Overflow instead. If this is not a “feature” or a “bug”, or the phrase “How do I...?” applies, then it's probably a usage question.)
What is the current behavior?
component with useSelector get re-rendered even though state return by useSelector is not updated,
this was not case with using connect
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to a CodeSandbox (https://codesandbox.io/s/new) or RN Snack (https://snack.expo.io/) example below:
redux hook example -  https://codesandbox.io/s/cocky-ardinghelli-epto4
https://epto4.codesandbox.io/
redux connect example - https://codesandbox.io/s/redux-react-connect-1-6pgfg
What is the expected behavior?
component with useSelector should not get re-rendered when state return by useSelector is not updated,  behavior should be same like connect
Which versions of React, ReactDOM/React Native, Redux, and React Redux are you using?  Which browser and OS are affected by this issue? Did this work in previous versions of React Redux?

It looks like you're returning a new object from useSelector every time.  Per the [`useSelector` API docs`](https://react-redux.js.org/api/hooks#equality-comparisons-and-updates), `useSelector` relies on reference equality, not shallow equality.  You should either change your selector to return just the counter value ( `(state) => state.counterState.counter`), or pass `shallowEqual` as the second argument to `useSelector`.


try to run mongo db official image

can't start the mongo db image with these error
2015-03-26T08:03:43.810+0000 I STORAGE  [initandlisten] exception in initAndListen: 98 Unable to create/open lock file: /data/db/mongod.lock errno:13 Permission denied Is a mongod instance already running?, terminating
2015-03-26T08:03:43.810+0000 I CONTROL  [initandlisten] dbexit:  rc: 100

The permission of these folders are USERNAME:staff
Any idea?

Thanks for the issue. Duplicate of #209, so I'll close this for now. Look out for a fix soon!


Detailed Placement Error

Hi,
When I ran the iccad2017 benchmark without fence region, the following problems occurred in three cases: They are pci_bridge32_b_md2, pci_bridge32_b_md3, def_perf_a_md2, but when I use the same lef def to run your ripple, it works fine.I don't know the reason, could you please explain it?
[   1.641] ------- Start DP -------
[   1.645] Finish setup database. #siteX: 4000 #siteY: 400
[   1.645] Start running Macro Legalization... #Macros: 954, #MovMacros: 585.
[   1.645] WARNING Including fixed macros. LP formula may be infeasible.
/lib/python3.11/site-packages/numba/np/ufunc/parallel.py:371: NumbaWarning: The TBB threading layer requires TBB version 2021 update 6 or later i.e., TBB_INTERFACE_VERSION >= 12060. Found TBB_INTERFACE_VERSION = 12050. The TBB threading layer is disabled.
warnings.warn(problem)
Traceback (most recent call last):
File "/project/Xplace/main.py", line 106, in
main()
File "/project/Xplace/main.py", line 102, in main
run_placement_main(args, logger)
File "/project/Xplace/src/run_placement.py", line 41, in run_placement_main
run_placement_single(args, logger)
File "/project/Xplace/src/run_placement.py", line 10, in run_placement_single
res = run_placement_main_nesterov(args, logger)
File "/project/Xplace/src/run_placement_nesterov.py", line 419, in run_placement_main_nesterov
node_pos, dp_hpwl, top5overflow, lg_time, dp_time = detail_placement_main(
File "/project/Xplace/src/detail_placement.py", line 757, in detail_placement_main
node_pos, dp_hpwl, lg_time, dp_time = default_detail_placement(
File "/project/Xplace/src/detail_placement.py", line 698, in default_detail_placement
node_pos = run_lg(node_pos, data, args, logger)
File "/project/Xplace/src/detail_placement.py", line 374, in run_lg
macro_legalization_main(node_pos, data, args, logger, lg_rawdb)
File "/project/Xplace/src/detail_placement.py", line 354, in macro_legalization_main
run_macro_legalization(node_pos, data, lg_rawdb, args, logger)
File "/project/Xplace/src/detail_placement.py", line 332, in run_macro_legalization
macro_pos, solve_success = macro_legalization_multi(macro_info, args, logger)
File "/project/Xplace/src/core/macro_legalization.py", line 909, in macro_legalization_multi
edge_type, _, _ = longest_path_refinement(macro_pos, macro_size, macro_fixed, die_info, die_ll, die_ur,
File "/project/Xplace/src/core/macro_legalization.py", line 372, in longest_path_refinement
g_x = ig.Graph.Adjacency(adj_matrix[:,:,0], mode= "directed")
NameError: name 'ig' is not defined. Did you mean: 'g'?

This is igraph python library. Please use pip or conda to install it. My version is 0.11.5.

This is python library. Please use pip or conda to install it. My version is .igraph``0.11.5

Thank you for your answer.
I would like to ask another question, can you provide the Modified ISPD 2015 Benchmark used in your paper TCAD2021 on Pin-Accessible Legalization for Mixed-Cell-Height Circuits.


Remove obsolete -I flag from bwa aln (handled by seqtk now).

I was encountering strange errors in bwa when aligning shorter reads in Illumina 1.5 FASTQ format.  I tracked it down to bwa backtrack (aln + samse / sampe) and the fact that (as far as I can tell) it tries to convert the FASTQ quality scores twice.  The first time is the -I flag to bwa aln, and the second is with seqtk -V in fastq_convert_pipe_cl (in alignprep.py).  I'm not sure how the quality scores are encoded in the intermediate .sai files, but I observed that giving bwa aln an Illumina 1.5 file with -I and the subsequent bwa samse command an Illumina 1.9 file (the effect of the seqtk pipe, which converts based on input format) crashed bwa or gave invalid bams.
For reference, the error messages included "SEQ and QUAL are of different length" from bwa, "Invalid alignment: Quality string contains invalid quality value" from libmaus, and "Cannot encode phred score" from fastqc, depending on the input data.
Taking out the -I flag to bwa aln fixes the problem and yields correct bams (Sanger / Illumina 1.9 format from both standard and illumina input formats).  I thought that was a lighter-weight solution than changing / complicating the seqtk logic, which is used by more paths through the pipeline.

Matt -- apologies about the issue and thanks much for the fix. I really appreciate someone looking after processing of files with older quality scores. Please let us know if you run into any other issues at all. Thanks again.


Stop autoplay

Autoplay is defined in options. Is it possible to stop autoplay from outside ?

Yes, please use jssor_slider1.$Pause()


Replace "master/slave" in 05_train_controller.py with "leader/follower" (or "primary/replica")

From PR #2692 to Django made in 2014:

The docs and some tests contain references to a master/slave db configuration.
While this terminology has been used for a long time, those terms may carry racially charged meanings to users.
This patch replaces all occurrences of master and slave with 'leader' and 'follower'

I'd be happy to make the PR if the owners of this repo are interested!

Done 👍


pull-request -p pushes to upstream instead of origin

Command attempted:
❯ hub pull-request -p
What happened:
After writing the PR text, the branch got pushed to upstream instead of origin:
❯ git pull-request -p
Enumerating objects: 30, done.
Counting objects: 100% (30/30), done.
Delta compression using up to 8 threads
Compressing objects: 100% (8/8), done.
Writing objects: 100% (16/16), 1.12 KiB | 575.00 KiB/s, done.
Total 16 (delta 6), reused 0 (delta 0)
remote: Resolving deltas: 100% (6/6), completed with 6 local objects.
remote:
remote: Create a pull request for 'fix-restDatastoreContentType' on GitHub by visiting:
remote:      https://github.com/eclipse/kapua/pull/new/fix-restDatastoreContentType
remote:
To github.com:eclipse/kapua
 * [new branch]          HEAD -> fix-restDatastoreContentType
Branch 'fix-restDatastoreContentType' set up to track remote branch 'fix-restDatastoreContentType' from 'upstream'.
https://github.com/eclipse/kapua/pull/2834

More info:
❯ git remote -v
origin	git@github.com:lorthirk/kapua.git (fetch)
origin	git@github.com:lorthirk/kapua.git (push)
upstream	git@github.com:eclipse/kapua.git (fetch)
upstream	git@github.com:eclipse/kapua.git (push)

hub --version
git version 2.25.0
hub version 2.13.0

on macOS 10.15.2

I do wish that hub by default pushed to origin rather than upstream
Based on the documentation, is this really a bug though?  Perhaps insteasd we should try and make this a feature. Maybe we could add some sort of hub config option where you could specify the default remote for the -p flag?
 -p, --push
Push the current branch to HEAD before creating the pull request.

Uh... Did I misunderstand the convention then?

In case there are multiple git remotes that are all pointing to GitHub, hub assumes that the main one is named "upstream", "github", or "origin", in that order of preference.
When working with forks, it's recommended that the git remote for your own fork is named "origin" and that the git remote for the upstream repository is named "upstream". See https://help.github.com/articles/configuring-a-remote-for-a-fork/

@lorthirk There is really no established convention for where the preferred push target should be.
If I have write access to "upstream", I prefer pushing there. Some other people prefer pushing to their fork. Some projects even require that all PRs come from a fork, even those authored by people who have write access to the upstream repo. Whatever we decide as a default, we end up disappointing some people https://github.com/cli/cli/issues/350
I'm not sure if I want to add an option to select the push target, because you can just as easily push the branch yourself before invoking git pull-request. Does that seem like an appropriate workaround?


ThinEngine.MinimizeMemoryFootprint

Sketch of mechanism for bouncing the texture loaders to release those resources when they're not being used.
Not sure the best way to characterize this without exposing implementation details, hence the generic "MinimizeMemoryFootprint" name. Philosophically, what this is trying to do is let developers inform the engine that a change in the engine's usage is about to happen (for example, we might be done loading the scene now and expect to go into a long period of rendering without loading) such that this is a good time to let go of certain resources that may have been cached. Right now, it's a generic name with a specific purpose, so this isn't a great fit; we should probably either decide to make specific and consequently expose (at least indirectly) the existence of the _TextureLoaders through the contract, or we should go generic and decide (even if we don't do it now) that this method may also release other kinds of resources in the future, too. Assuming we want this change at all, that is 😃; would love to discuss the preferred direction.
This came up while looking into a forum question about KTX2, during which it became clear that the texture loaders can hold onto substantial resources statically. This isn't a fix for that issue -- there appears to be a memory leak in the KTX2 loader Web worker, and fixing that leak is the actual fix -- but this could be used as a workaround for that issue as well, especially if the leak turns out to be inside one of the KTX2 WASMs itself, which we don't produce ourselves and so can't fix directly.

I do not think the lazy loading part is necessary (how much do we save ?), when building with ES6 you can consume only what you need already.
I guess the uninitialized part is the important one for the current workaround ?

@sebavan I think the utility of the lazy loading part of it depends both on what you're using and when, because the loaders themselves vary in what they contain. The KTX2 loader in particular creates up to four (!) Web workers and holds onto them statically. Under the current architecture it does this as soon as Babylon.js loads, and there's no way to get rid of them. Thus, if you have an app that loads a single KTX2 texture in the first second of its execution, then goes on to render and operate for another ten minutes without loading any more KTX2s, the cost of the loader in memory and Web workers will impact the entire runtime, not just the load time, and there's nothing the consuming app can do about it because the KTX2 loader isn't exposed. I don't know if other loaders also hold onto heavy long-lasting resources, but if they do (or can), then the same problem applies.
So it really isn't the lazy loading that matters so much as the ability to enforce some kind of lifespan on these resources that otherwise live forever simply because they don't know when it's safe to die. That may have up to two benefits: (1) long-living heavy resources can be disposed so that they don't impact parts of the execution that don't need them, which becomes more useful if/as we add more resources like this to this capability; and (2) the fact that they won't live forever eases some constraints on certain resources, allowing us to do heavier things if we need to because we now have a mechanism for developers to tell the Engine, "You can get rid of your heavy tools now."

sounds good to me, but let s ask @RaananW what pattern you should use on this one to prevent rebuilding it when he will move to es for those functions if it is early enough to built it only once ?

sounds good to me, but let s ask @RaananW what pattern you should use on this one to prevent rebuilding it when he will move to es for those functions if it is early enough to built it only once ?

The general gist of future changes would be to move all of those static methods to be external functions in the Engine/ThinEngine module that receive an engine as the first variable (if needed). No more private or public static, but functions that can be called outside of the engine context. This way they will be included in the build if used, but will be tree-shaken out if not.
For example, this line:
private static _textureLoaders: Nullable<IInternalTextureLoader[]>;

will be
const _textureLoaders: Nullable<IInternalTextureLoader[]> = []

outside of the ThinEngine class, and the functions would look like this:
export function MinimizeMemoryFootprint(): void {
        if (_textureLoaders) {
            for (let idx = 0; idx < _TextureLoaderFactories.length; ++idx) {
                _TextureLoaderFactories[idx].dispose(_textureLoaders![idx]);
            }
            _textureLoaders = null;
        }
    }

static functions don't need the actual engine, so it is simpler to pull them out of the class. I know that in this case we are talking about ca. 50 lines of code that is added, but all of those static functions accumulate.
In order to use them, a developer using esm would be able to:
import { MinimizeMemoryFootprint } from "@outModulesPackage";

// or

import * as ThinEngineModule from "@outModulesPackage/Engines/ThinEngine";

// and then

ThinEngineModule.MinimizeMemoryFootprint(); // or the function, if imported directly

For back-compat, static functions that were added prior to the change will be added to the class (so that you could still use ThinEngine.MyWonderfulStaticMethod), but only in the LTS version. Side-note - this sentence is still TBD. I assume not all static methods will be thrown out, but I didn't dive into the engines yet.

What is the current status here folks?

@deltakosh I think the impetus to check this in has died down. I'm checking whether this will be valuable in the short term, in which case I'll push it forward, but most likely I'll just close it tomorrow as we can always reopen it later when it's more immediately relevant again.

Closing this for now. I think the idea is still sound, but the need for it isn't currently clear and immediate. We can reopen it again later when/if it becomes tangibly relevant again.


Neovim: Nvim-surround plugin installation

Need to install this plugin to surround with delimeters.

No need.


French babel break contemporary style

Describe the bug
When using the contemporary style, it display "west:" before the year in the cventry
Expected Behavior
Display correctly the years as in English
Actual Behavior
Display year with west and a bad padding
Minimum Working Example to Reproduce the Problem
\documentclass[11pt,a4paper,sans]{moderncv}

\moderncvcolor{cerulean}
\moderncvstyle[]{contemporary}

\usepackage[hmargin=0.5in,vmargin=10pt]{geometry}
\ifxetexorluatex
  \usepackage{fontspec}
  \usepackage{unicode-math}
  \defaultfontfeatures{Ligatures=TeX}
  \setmainfont{Latin Modern Roman}
  \setsansfont{Latin Modern Sans}
  \setmonofont{Latin Modern Mono}
  \setmathfont{Latin Modern Math}

\else
  \usepackage[utf8]{inputenc}
  \usepackage[T1]{fontenc}
  \usepackage{lmodern}
\fi

\usepackage[french]{babel}  % FIXME: using spanish breaks moderncv

% personal data
\name{John}{Doe}
\title{Résumé title}                               % optional, remove / comment the line if not wanted
\begin{document}
\makecvtitle

\section{Education}  % for 'contemporary' style use optional argument for displaying an icon, e.g. \section[\faGraduationCap]{Education}
\cventry{year--year}{Degree}{Institution}{City}{\textit{Grade}}{Description}  % arguments 3 to 6 can be left empty
\cventry{year--year}{Degree}{Institution}{City}{\textit{Grade}}{Description}
\end{document}

Specifications

moderncv version and source: 2024-07-18 v2.4.1
LaTeX compiler (pdfLaTeX, XeLaTeX, etc.) and version: This is pdfTeX, Version 3.141592653-2.6-1.40.26 (TeX Live 2024)
Platform (operating system, LaTeX editor, etc.): Ubuntu (tex is installed manually not via system package)

Thanks, @guillomep for reporting this and also providing a solution.
Actually I tried to reproduce your issue, but so far I was not able to do so - at least with pdfTeX 3.141592653-2.6-1.40.25 (TeX Live 2023/Debian) on my Ubuntu 24.04 VM.
Maybe this is an issue with TeXLive2024. Therefore my question:
Did you install TexLive2024 directly from their website? https://tug.org/texlive/quickinstall.html
Then I also will try to download version 2024 and do a re-test.
Maybe this could be a problem in your case:
https://github.com/moderncv/moderncv/blob/14deb59ddb03b7c5e9325198833a1e4fddfbcb88/moderncvverticaltimeline.sty#L25
I would be glad if you could give me another hint towards reproduction.
After that we can try to fix that, maybe just inserting
%-------------------------------------------------------------------------------
%                required packages
%-------------------------------------------------------------------------------
\RequirePackage{tikz}
\usetikzlibrary{babel}

into https://github.com/moderncv/moderncv/blob/14deb59ddb03b7c5e9325198833a1e4fddfbcb88/moderncvverticaltimeline.sty#L16-L19 could help.


bugfix for loading Template from URL

NSURL.absoluteString includes "file://", which Path() doesn't expect.

Ah, that's a good point. Thanks for the pull request.


feat: Add selectable FilterChip

📋 Changes
Add FilterChip for content filtering
🤔 Context
Use a dedicated component instead of tricking with:
fun Modifier.semantics {
    this.selected = selected
    this.role = Role.Tab
}

✅ Checklist

[x] I have reviewed the submitted code.
[x] I have tested on a phone device/emulator.
[x] If it includes design changes, please ask for a review spark-design GitHub team.

📸 Screenshots

@soulcramer @McGalanes Why this ticket is not merged/closed yet?

I need to rework the chip API before we can add the selectable api


Path parameters parsing problem: string is not parsed after number

Hello!
This does not work:
  /reports/{frame_id}/{what}:
    get:
      operationId: "reports.get_image_test"
      parameters:
        - name: frame_id
          in: path
          required: true
          schema:
            type: "number"
        - name: what
          in: path
          required: true
          schema:
            type: "string"
      responses:
        '200':
          description: success
          content:
            image/png:
              schema:
                type: string
                format: binary

It raises BadRequestProblem(): Missing path parameter 'what'
But this works:
  /reports/{what}/{frame_id}:
    get:
      operationId: "reports.get_image_test"
      parameters:
        - name: frame_id
          in: path
          required: true
          schema:
            type: "number"
        - name: what
          in: path
          required: true
          schema:
            type: "string"
      responses:
        '200':
          description: success
          content:
            image/png:
              schema:
                type: string
                format: binary

Please help and explain what am I doing wrong here?
Connexion version is 2.14.1
Flask is 2.2.3
Thanks!

Connexion 2.14.1 is more than a year old and no longer supported. Please try with Connexion 3.x and feel free to reopen if the issue persists.


Add prettier

Fixes #32
Also, renames test files to index.test.js

Codecov Report

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

@@          Coverage Diff          @@
##           master    #33   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           1      1
  Lines           1      1
  Branches        1      1
=====================================
  Hits            1      1

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 d241bd4...ef28de6. Read the comment docs.


@me and @playername issue.

I'm having the same issue but the @me and @playername BOTH don't work, so I'm at a loss. They both just put the items in the facility,

Use it without the () these are just there to emphasize that they are optional in the description
So like /spwscr PillBottle a=5 p=@me v=10000

The default value of a is 1 so if you just want one you can leave that away and the default of v is 1000

I'm having the same issue but the @me and @playername BOTH don't work, so I'm at a loss. They both just put the items in the facility,

And for p=@"playername" you would replace "playername" with your name or the players one you want to spawn it on, for example: /spwscr cog p=LethalCompanyEnjoyer


chore(ci): move to the right CI folder

What is this PR doing?
It defines the right directory at the JJBB level
Why is it important?
Consistency, as other Go libs live in the target directory.
Related issues

Closes #162

Follows-up

[ ] Manual remove the old CI job from Jenkins UI

:green_heart: Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

Start Time: 2021-09-06T09:12:01.607+0000

Duration: 7 min 16 sec

Commit: 84cbd29aa5d3a993e5e07cc4a169409633862f31

Test stats :test_tube:

Test
Results

Failed
0

Passed
261

Skipped
7

Total
268

Trends :test_tube:


BUG: overlapping of buttons

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?

I want to fix that issue.
Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

Hi @anuragverma108 i would like to work on this issue ? Please assign me this issue ?

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


Introduce cross platform build in CMake

CMake build has been introduced but it is not yet cross platform.
https://github.com/cmdevries/LMW-tree/commit/4ed6c10277c72b58fc145217d0e48483f55ae651

Cross platform issue is at https://github.com/cmdevries/LMW-tree/commit/4ed6c10277c72b58fc145217d0e48483f55ae651.


New UKHPI: missing graph

From user testing:

The graph function under ‘HPI by funding status’ was not showing, but displayed data when ‘View as data’ was selected

@MalcolmShazell proposed fix now on dev server. This one was trickier than I expected!

confirm working


Flexible session

Summary
Prototype of a new Session that allows multiple calls to the same or different primitives. Had to create a new class to avoid circular import. Does not do data caching.
Details and comments
Fixes #

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

-40 of 184 (78.26%)  changed or added relevant lines in 11 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-1.8%) to 60.6%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

qiskit_ibm_runtime/runtime_program.py
1
2
50.0%

qiskit_ibm_runtime/utils/deprecation.py
14
16
87.5%

qiskit_ibm_runtime/runtime_options.py
18
24
75.0%

qiskit_ibm_runtime/session.py
39
51
76.47%

qiskit_ibm_runtime/sampler.py
49
68
72.06%

Files with Coverage Reduction
New Missed Lines
%

qiskit_ibm_runtime/sampler.py
1
72.09%

Totals

Change from base Build<PHONE_NUMBER>:
-1.8%

Covered Lines:
2867

Relevant Lines:
4731

💛  - Coveralls

@tmittal947 could you take a look at the latest comments here?


question: changing the sw internal behavior

Library Affected:
workbox-window + workbox-build
Browser & Platform:
Google Chrome v98.0.4758.82 for Windows, not yet tested on other browsers and SO.
Issue or Feature Request Description:
It is a problem about changing the workbox-* internals when using workbox-build::generateSW (should have the same problem using a custom sw and workbox-build:injectManifest): from auto update to prompt strategy.
The current sw is using:
self.skipWaiting();
workbox.clientsClaim();

and we change it to use:
 self.addEventListener('message', event => {
    if (event.data && event.data.type === 'SKIP_WAITING') {
      self.skipWaiting();
    }
  });

The browser will keep the new sw in skip waiting state: see https://github.com/antfu/vite-plugin-pwa/issues/228#issuecomment-1037545037
You can clone the vite-plugin-pwa repo, then execute pnpm install + pnpm run build (pnpm installed globally and node 14+), then pnpm run examples, then follow the cli using:

Open the browser and enter https://localhost, wait to App ready to work offline toast/dialog message, the sw will be installed with previous self.skipWaiting and workbox.clientsClaim (you can see opening workbox-**.js on source tab, sw.js/localhost folder).
Stop the server, but keep the page in the browser, run again pnpm run examples then follow cli options but now change Select a behavior with Prompt for Update instead Auto Update:

Refresh the browser page and you'll see the sw is on skip waiting state. The only way to make it work is closing all browser windows and reopen the url again.

I'd recommend reading through https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle#updates, which describes what happens when there's an updated service worker.
To summarize, if an updated service worker enters the waiting state, it will remain in that state until either a) all of the open client pages controlled by the currently active service worker are closed or b) the update service worker calls skipWaiting().
So what you're seeing is the expected behavior, based on the service worker specification. Workbox will attempt to help by automatically adding that message handler to the service worker it generates when configured with skipWaiting: false, so that there's a standard way of triggering skipWaiting() from any client page.


Broken links | reference content | arcappliance extension | showing in azure-cli-extensions-list.md

Describe the bug
Bug category:
Broken links
Document URL:
https://learn.microsoft.com/en-us/cli/azure/azure-cli-extensions-list
Broken links
https://msazure.visualstudio.com/AzureArcPlatform/_git/arcappliance-cli-extensions
Reference commands
https://learn.microsoft.com/cli/azure/arcappliance
Related command
az arcappliance
Errors
404 for customers without permissions to https://dev.azure.com/msazure/
Issue script & Debug output
n/a
Expected behavior
n/a
Environment Summary
GitHub issue created during Azure CLI 2.62.0
Additional context
No response

Thank you for opening this issue, we will look into it.


Remove unused imports

Complete - But had to keep Router in App.js to be able to render the words on the other pages?


update docs with help on using contrib modules

This may seem obvious to some but took me awhile to figure out that the easy-thumbnails wasn't self-contained and that I had to pip install easy-thumbnails for it to work. I imagine others will assume the modules themselves are bundled in the contrib.

Thanks! I'll update the online docs tomorrow!


Fix the db connections settings for external databases when the db user has no rights to manage user accounts

Implemented by 59c620df136253ab185f8be682844908368a01dd / 900ec11ee9bf55c33b5a19c66240e0fd5dea737f


problems with using the library with celery

Hi, I have flask app with following extensions used:
Python 3.7.2
Flask 1.0.2
Celery 4.3.0rc2
Face-recognition 1.2.3

And when I'm running this:
face_recognition.face_locations(image, model='cnn)
my worker fails with this output:
[2019-03-06 19:51:15,454: ERROR/MainProcess] Process 'ForkPoolWorker-8' pid:93763 exited with 'signal 11 (SIGSEGV)'
[2019-03-06 19:51:15,472: ERROR/MainProcess] Task handler raised error: WorkerLostError('Worker exited prematurely: signal 11 (SIGSEGV).')

I know, that celery workers are not fork safe but still hope that there's a solution for my case
Any help appreciated

I've figured that it only fails while using with 'cnn', otherwise the problem doesn't occur

This is my issue as well. Funny thing is it works outside celery


luci-mod-status: IPv4 Neighbours: Some IF names fail to resolve properly in  "Status → Routing" section

Steps to reproduce:
Example: Replace the following lines and remove this

Create various VLANs on BR interface.
Configure individual seperate networks on those interfaces (/24 /28 /29 etc. randomly).
Save & Apply
go to: "Status → Routing" section.

Actual behavior:
Some interfaces under "IPv4 Neighbours" are represented with their physical interface names ( br.xxx as an example) instead of their "virtual luci" interface names (lets say "lan" or "guests" as an axample).

Expected behavior:
As with all other pages, interface names should resolve properly. (interface names are resolved properly in other functions as an example interfaces in "Interfaces tab").

Additional Information:
OpenWrt version information from system /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='23.05.2'
DISTRIB_REVISION='r23630-842932a63d'
DISTRIB_TARGET='ipq807x/generic'
DISTRIB_ARCH='aarch64_cortex-a53'
DISTRIB_DESCRIPTION='OpenWrt 23.05.2 r23630-842932a63d'
DISTRIB_TAINTS=''

Please provide the complete output of ubus call network.interface dump

The information in both the screenshot and in the ubus dump are too redacted to work with. Logical interfaces are matched by address, the neighbor entries associated IP address has to be contained within one of the logical interface ipv4-address, ipv6-address, ipv6-prefix, ipv6-prefix-assignment or route arrays and the device or l3_device property of the logical interface has to match the device value of the neighbor entry. If no logical interface fulfills this condition, the raw netdev is shown in parens. Maybe there‘s a bug in the matching code but that‘s not possible to tell with the data provided

Taking the (br-lan.66) example, does the IPv4 address shown in the table fall into the 10.xx.xx.1/30 subnet?

So which IPv4 address is shown exactly for the broken br-lan.66 entry? And which IPv4 subnet is configured exactly on "seedbox"? Note that is makes little sense to censor RFC1918 IP addresses

Please show a screenshot of the affected table row with the device name in parens and the uncensored IP address, not the cli output.

Thanks, will try to reproduce tonight. Needed the screenshot to confirm that it is a gui issue.


The time period selector should be disabled when loading data

Try rapidly clicking between '1 Hr' and 'Daily' ... you get a 429 HTTP response after a while.

Throttled in PR #476

The rate limit for the Coinbase API is 1 request / second.
We decided to debounce the API requests (in #476), which avoids the limit being reached, rather than disabling the selectors. We thought this would provide a better experience for the user, so they can still change period whilst the data is loading.
Please reopen if this isn't a suitable solution :)


Support for async tests

The rusty_fork_test! macro does not accept async fn. I need to test some async functions that share global data structures. It would be very useful that this could be done via rusty-fork :).

I wouldn't be surprised if there were some tricky corner cases with this. For now the obvious workaround works:
let rt  = tokio::runtime::Runtime::new().unwrap();
rt.block_on(async {
    [...]
})


kele-{context,resource}: Wait for kubeconfig sync completion

Closes #110.

Codecov Report
Base: 66.16% // Head: 66.27% // Increases project coverage by +0.11% :tada:

Coverage data is based on head (2fd9b65) compared to base (87d0e87).
Patch coverage: 70.00% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #126      +/-   ##
==========================================
+ Coverage   66.16%   66.27%   +0.11%
==========================================
  Files           2        2
  Lines         594      599       +5
==========================================
+ Hits          393      397       +4
- Misses        201      202       +1

Impacted Files
Coverage Δ

kele.el
74.50% <70.00%> (+0.05%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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


"TemplateDoesNotExist" this error was occurred while move on to add information.

Issue
When I am going to add a course or professors details or other information that send's a error like this.
        TemplateDoesNotExist at /add-professor/

Solution
To solve this problem we need to install the package "crispy-bootstrap4" package first of all.
        pip install crispy-bootstrap4

And in settings.py
        INSTALLED_APPS = [
                ...,
                'crispy_forms',
                'crispy_bootstrap4',  # Forgetting this was probably your error
        ]

And then at the bottom of the page of settings.py
        CRISPY_ALLOWED_TEMPLATE_PACKS = "bootstrap4"
        CRISPY_TEMPLATE_PACK = "bootstrap4"

This worked for me solving the TemplateDoesNotExist error.

Thank You, it helped.
And were you able to generate the timetable? Mine was empty when clicked view timetable even after providing all the necessary details

i have also try to generate the timetable after fix this issue. But i still can't able to generate the new table.


support for timm models

Are timm encoders already supported?

No, I haven't added them yet.

I added support for timm models. Feel free to use )