[HOLD for payment 2023-09-29] [$500]  Report - Conversation history does not scroll down after sending a message and IOU

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:
Preconditions:
Log in using a HIGH traffic account.

Open New Expensify app
Navigate to a chat that has a very long history
Scroll up the conversation history
Send any message or IOU

Expected Result:
When you send a message or IOU in a conversation, the message history should scroll down without artifacts to the newly sent message or IOU
Actual Result:
When sending a message or IOU in a conversation, the message history doesn't scroll down, and on Native apps the conversation history starts scrolling chaotically up to down
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

Version Number: 1.3.60-1
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/78819774/4b0dfdc9-e3cf-44df-bce4-2f212e230f02
Expensify/Expensify Issue URL:
Issue reported by: @rayane-djouah
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1692633002201879
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~016b9e851c8568700f
Upwork Job ID:<PHONE_NUMBER>700506624
Last Price Increase: 2023-09-08
Automatic offers:

mollfpr | Reviewer | 26624598
rayane-djouah | Contributor | 26624600
rayane-djouah | Reporter | 26624601

Thanks @rayane-djouah I'll do the review today!

Sorry for the delay @rayane-djouah
Is there any reason why we remove the listener? Is there any related to the performance improve?

Is there any way without the listener?

@rayane-djouah I try your listener solution, but it's only sometimes working.
https://github.com/Expensify/App/assets/25520267/8709b8a9-1b2c-4c5c-b29f-4011bfd97a15

@rayane-djouah I'm okay with the proposal. To make sure, I am asking for clarification in the PR.

@rayane-djouah Yeah, it seems we are okay to reintegrate the previous logic. Should we use scrollToBottomAndMarkReportAsRead instead to scroll to the bottom and mark the comment as read?

@rayane-djouah I'm testing your solution again on scrollToBottomAndMarkReportAsRead and reportScrollManager.scrollToBottom. My thoughts on scrollToBottomAndMarkReportAsRead seem to send an API ReadNewestAction when the current user sends a message, while I don't think it's necessary.
My other test is using reportScrollManager.scrollToBottom, to send a message while there's an unread message. There's an API call for ReadNewestAction, which I guess it's for the unread message.
So I think it's okay to use only reportScrollManager.scrollToBottom, what do you think?

Thanks @rayane-djouah
Okay, it's indeed regression from https://github.com/Expensify/App/pull/18637 where it's refactoring the unmarked logic. We can reintegrate the report action listener to scroll to the bottom whenever the current user sends a message. Also, it's already confirmed that there's not performance impact from the listener usage.
So the proposal from @rayane-djouah looks good to me 👍
🎀 👀 🎀 C+ reviewed!

Yes, I reviewed the PR timeline and this one qualifies for the efficiency bonus. I'm going through and writing up payments now.

Summarizing payouts for this issue:
Bug reporter: @rayane-djouah $50 (paid via Upwork)
Contributor: @rayane-djouah $750 (paid via Upwork)
Contributor+: @mollfpr $750 (need to confirm preferred payment method)
Above payments include efficiency bonus 🎉
Upwork job: https://www.upwork.com/jobs/~016b9e851c8568700f

@mollfpr can you please confirm if you'd prefer to be paid via Upwork or NewDot? You've already accepted the Upwork contract, so if you'd like to be paid via NewDot I'd have to cancel that.
Also, can you please complete the BZ checklist? Thanks!

@sakluger I think from Upwork is okay, since we already have the contract.

[@mollfpr] The PR that introduced the bug has been identified. Link to the PR:

https://github.com/Expensify/App/pull/18637

[@mollfpr] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:

https://github.com/Expensify/App/pull/18637/files#r1318079323

[@mollfpr] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:

I don't think we can have a checklist to prevent this. The regression step should be good.

[@mollfpr] Determine if we should create a regression test for this bug.
[@mollfpr] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.

Open the app
Navigate to a chat that has a long history
Scroll up the conversation history
Send any message or IOU
Verify that the conversation history automatically scrolls down to the new message.
👍 or 👎

Thanks! Just sent the payment through Upwork @mollfpr.
Regression test steps look good, thanks!

Issue reproducible on latest build - v1.3.96-0
Android / native
https://github.com/Expensify/App/assets/115492554/f3af869a-97f3-4af2-b4af-5162a6ca8cef

We're handling in here https://github.com/Expensify/App/issues/30947


Remove not needed coding keys

merge on green

Warnings

:warning:

Sources/Danger/GitHubDSL.swift#L154 - Enum element name should be between 3 and 40 characters long: 'id' (identifier_name)

:warning:

Sources/Danger/GitHubDSL.swift#L169 - Variable name should be between 3 and 40 characters long: 'id' (identifier_name)

:warning:

Sources/Danger/GitHubDSL.swift#L226 - Enum element name should be between 3 and 40 characters long: 'id' (identifier_name)

:warning:

Sources/Danger/GitHubDSL.swift#L239 - Variable name should be between 3 and 40 characters long: 'id' (identifier_name)

:warning:

Sources/Danger/GitHubDSL.swift#L270 - Enum element name should be between 3 and 40 characters long: 'id' (identifier_name)

:warning:

Sources/Danger/GitHubDSL.swift#L290 - Variable name should be between 3 and 40 characters long: 'id' (identifier_name)

:warning:

Sources/Danger/GitHubDSL.swift#L330 - Enum element name should be between 3 and 40 characters long: 'id' (identifier_name)

:warning:

Sources/Danger/GitHubDSL.swift#L358 - Variable name should be between 3 and 40 characters long: 'id' (identifier_name)

:warning:

Sources/Danger/GitHubDSL.swift#L409 - Variable name should be between 3 and 40 characters long: 'id' (identifier_name)

:warning:

Sources/Danger/GitHubDSL.swift#L433 - Enum element name should be between 3 and 40 characters long: 'id' (identifier_name)

:warning:

Sources/Danger/GitHubDSL.swift#L452 - Variable name should be between 3 and 40 characters long: 'id' (identifier_name)

:warning:

Sources/Danger/GitHubDSL.swift#L486 - File should contain 400 lines or less: currently contains 486 (file_length)

  Generated by :no_entry_sign: Danger Swift against 694594eb0136ee69b0807fdc2613d2754a3c3f3d


Does the config : agent.sample_n_per_3_secs support such a way like this : 10% 、20% and does the config file : agent.config support dynamic loading?

As title

agent.sample_n_per_3_secs support such a way like this : 10% 、20%

No. But if you want, you could contribute a new optional plugin to support this sample mechanism.  Override SamplingService service, by learning from /apm-sniffer/optional-plugins/trace-ignore-plugin. This plugin overrides TraceIgnoreExtendService service to support new feature.
Welcome to join the community.

does the config file : agent.config support dynamic loading

This is not an easy YES or NO question. Because some settings, such as application code, buffer size, are hard to change in runtime. So I suggest you focus on which settings do you want to dynamic reload.

thanks


[BUG] Data mapping with Elastic Common Schema fail

ECS integration/library project(s) (e.g. Elastic.CommonSchema.Serilog): Elastic.Serilog.Sinks
ECS schema version (e.g. 1.4.0): The last one (v8.11.0)
ECS .NET assembly version (e.g. 1.4.2): v8.11.0
Elasticsearch version (if applicable): v8.14.2
.NET framework / OS: Docker Linux with .net 8
Description of the problem, including expected versus actual behavior:
Hello,
I’m trying to replace the previous Serilog Sink Serilog.Sinks.Elasticsearch with the new one Elastic.Serilog.Sinks.
During our process with add elements in LogContext with LogContext.PushProperty().
When I use LogContext.PushProperty("client.nat.ip", “<IP_ADDRESS>”); the value is well set in the Elasticsearch CommonSchema in the client object, but this one no: LogContext.PushProperty("client.ip", “<IP_ADDRESS>”);. client.ip is added in the metadata object.
Another one, if I set LogContext.PushProperty("client.user.id", "regis"); no log are sent to elasticsearch. So, it has to fail somewhere.
Steps to reproduce:

Add LogContext.PushProperty("client.ip", “<IP_ADDRESS>”);` in a controller or a service
Add  LogContext.PushProperty("client.user.id", "regis"); in a controller or a service

Is there a way to me to write tests in Elastic.CommonSchema.Serilog.Tests project ?

I found why "client.user.id" key wasn't processed (but not why it silently crash...)
I start by adding in class Elastic.CommonSchema.LogTemplateProperties :
// [...]
public static string ClientUserId = nameof(ClientUserId);
// [...]
public static readonly HashSet<string> All = new()
{
// [...]
	"client.user.id", ClientUserId,
// [...]
}

And next in class Elastic.CommonSchema. EcsDocument, I add case "client.user.id" in the right part of the switch case and manage it in the method called TrySetClient, like bellow :
public static bool TrySetClient(EcsDocument document, string path, object value)
{
	Func<Client, object, bool> assign = path switch
	{
// [...]
		"client.user.id" => static (e, v) => TrySetString(e, v, static (ee, p) => (ee.User ?? (ee.User = new User())).Id = p),
		_ => null
	};
	if (assign == null) return false;

	var entity = document.Client ?? new Client();
	var assigned = assign(entity, value);
	if (assigned) document.Client = entity;
	return assigned;
}

Is that the right way ?
By the way I add a test method in namespace Elastic.CommonSchema.Serilog.Tests.Repro
public class GithubIssue402 : LogTestsBase
{
	public GithubIssue402(ITestOutputHelper output) : base(output) { }

	[Fact]
	public void Reproduce() => TestLogger((logger, getLogEvents) =>
	{
		using (LogContext.PushProperty("client.nat.ip", "<IP_ADDRESS>"))
		using (LogContext.PushProperty("client.ip", "<IP_ADDRESS>"))
		using (LogContext.PushProperty("client.user.id", "regis"))
			logger.Information("Logging something with log context");

		var logEvents = getLogEvents();
		logEvents.Should().HaveCount(1);

		var ecsEvents = ToEcsEvents(logEvents);

		var (_, info) = ecsEvents.First();
		info.Message.Should().Be("Logging something with log context");

		info.Client.NatIp.Should().Be("<IP_ADDRESS>");
		info.Client.Ip.Should().Be("<IP_ADDRESS>");
		info.Labels.Should().NotContainKey("client.user.id");
		info.Client.User.Id.Should().Be("regis");

	});
}

For the part of the LogContext with "client.ip" key, it’s work in the main git branch...


Add Laravel 7.3 Support

Add Laravel version from 5.4 up to 7.3 support
(optional) Issue number:
Summary of the change:

@streamtw Could you please merge this so Laravel 7.3 is suported?

@streamtw Could you please merge this so Laravel 7.3 is suported?

I have already requested, but not done so far!

Why not release a new version for the latest version of Laravel?
Please

we need update. bump this PR

I'm waiting for confirm and merge my pull request by UniSharp!

This version of package not still to stable for Laravel 7.x :(


Quick fix for description cut off

This won't help app descriptions that are over a page long but those are probably too long anyway... This is a sufficient fix in the short term but I'll add a button to expand descriptions in the future (similar to what exists in the initial mock-ups).

Super rad!

Copy-pasta of remarks elsewhere:
Asheesh:

Interesting; why not remove entirely?
Also: overflow: scroll might be your friend, fwiw.
I'm +1 on a scrollbar for the reason of "if app authors want their page to be ugly, that's great, but we don't have to write code to support it"
Up to you etc. I'm +1 on merging this as-is, too.

Design-wise I'm not a fan of overflow: scroll in this scenario as I think it would be a little uncomfortable to try to scan through content that is being scrolled. Having said that, I won't know what it's really like unless I try it. :)
FWIW this was the intended design with a little "read more" link/button:

See e.g. http://www.w3schools.com/cssref/tryit.asp?filename=trycss_overflow
overflow: scroll is not auto-scroll, but rather, "give the user some
scrollbars", in case that clears up a misunderstanding!

Nope! That's what I expected but thank you for the link. :D

OK, great!


feat(Zone): add support for Zone.js

Add support for Zone.js in a way which should have minimal impact on performance.
Ensures that all callbacks are invoked in the same Zone as the Zone which was current at
the time of the callback registration with the Rx.

Add getZone() method which returs always null if no Zone is present or returrns
the current zone.
All places where the Zone needs to be intered are quarded to only go through zone if the
Zone is different from the current Zone for performance reasons.

Changes Unknown when pulling ba6a2451a2591cade5e8b950122398f7d4adaf61 on mhevery:zone into ** on ReactiveX:master**.

Just curiosity - without this PR, how does RxJS works with zone.js? is there functional differences, or only impact perf?

@mhevery this is a fairly fundamental change. I imagine not all rxjs members are familiar with Zones. Could you perhaps summarize Zones as well as the pros/cons to adding native support vs. the existing interactions with Zone's polyfills?

@kwonoj

Just curiosity - without this PR, how does RxJS works with zone.js? is there functional differences, or only impact perf?

Without this PR the Zone's are incorrectly propagated through RX. So this is a correctness PR with focus on performance. See ZoneSpec to see how the PR changes the Zone propagation behavior.
RX is one of the few libraries which falls into the category of "User Queueing" Libraries. What this means is that RX retains multiple callbacks and then executes them at a later time in a single task. Without this PR all of the callbacks would execute in the same Zone, which is incorrect.

@jayphelps

@mhevery this is a fairly fundamental change. I imagine not all rxjs members are familiar with Zones. Could you perhaps summarize Zones as well as the pros/cons to adding native support vs. the existing interactions with Zone's polyfills?

You can read up on Zones in The Zone Primer. As of now when Rx runs in the Zone environment it will propagate Zones according to VM Tasks. In the case of Rx this is not correct behavior because Rx does its own scheduling and the result is that all callbacks end up running in the same zone as Task zone. This behavior is mostly correct most of the time, but there are cases which will have wrong behavior. This PR addresses those. This PR is needed to enable propre implementation of https://github.com/angular/angular/issues/13248
This PR was authored with @blesh help, and so I think he may be one of the people who should have sufficient context to review it. I am happy to work with anyone else and explain all of the nuances and reasoning.

Push new SHA which adds more comments, and simplifies the code a bit.

Changes Unknown when pulling e87f28f05925c42488d1155c9ff999868b712e00 on mhevery:zone into ** on ReactiveX:master**.

Changes Unknown when pulling e87f28f05925c42488d1155c9ff999868b712e00 on mhevery:zone into ** on ReactiveX:master**.

It's probably a good idea to add a good amount of documentation around what  RxJSs behavior is with Zones and why.
Also perhaps some examples of using RxJS with Zones. I think that this will be interesting when it comes to @jhusain's proposed changes to observable wrt error handling.
Overall looks good, but needs docs for sure. Otherwise it will appear to be magic to some Zones users I'm sure.

I'm not 100% up to speed on zones, but this does seem like something that should go into a zone scheduler, rather than baked into every Subscriber (see also Rx Guidelines 5.8 on synchronize [pdf]).
Also, what's the impact on users (like me) who will never use zones?

@blesh I have updated the documentation, please let me know if it is sufficient.

Changes Unknown when pulling cec81de9f6e20978da8f10c6aa014b30299f4842 on mhevery:zone into ** on ReactiveX:master**.

@trxcllnt

I'm not 100% up to speed on zones, but this does seem like something that should go into a zone scheduler, rather than baked into every Subscriber (see also Rx Guidelines 5.8 on synchronize [pdf]).

The goal of this PR is to ensure that any application callbacks which are passed into the RX run in the same Zone as was active when the callback was passed in. This is too fine grained for the scheduler, since fully synchronous Rx may never use a scheduler, but still must abide by the rule above.
As an example the Observable must ensure that the subscriber callback and teardown must run in the same zone which was active at the time of constructor.
const constructorZone = Zone.current;
const observable = new Observable<string>((subscriber) => {
  expect(Zone.current).to.eq(constructorZone);
  return () => {
    expect(Zone.current).to.eq(constructorZone);
  };
}));

Same rules apply to operators, as well as to subscribe callbacks. These callbacks are too fine grained to be handled by the scheduler.

Also, what's the impact on users (like me) who will never use zones?

It should not have any impact whatsoever. The Zone dependency is optional, and if there is no zone present the code should execute at the same speed as before. The semantics are always the same, the only difference is if the Zones are preserved.

@blesh

I think that this will be interesting when it comes to @jhusain's proposed changes to observable wrt error handling.

This PR does not change the semantics of the Error handling only ensures that a correct Zone is propagated. Therefore any such changes should have no effect on this.

@mhevery looking at the tests, it seems like something that Angular could compose by returning all their Observables with .subscribeOn(CurrentZoneScheduler).observeOn(CurrentZoneScheduler), where the scheduler checks the Subscriber's zone against Zone.current, and switches as appropriate. The try-catch runner seems more inaccessible, but could be resolved by the work to remove that function entirely in favor of running in the context of a global try/catch context, which @blesh has more details about.
I'm not against supporting zones, but would like to find a way that doesn't add extra debugger step commands for people who aren't using zones. Thoughts?

👍

@trxcllnt

I don't mind Angular doing more work, but I don't think what you are proposing would work.
But more importantly our developers can not be required to use Rx in that way. It is one thing for a framework to do extra work, but something harder for the developers. (Also our developers could chose to use a third part Rx library which is not Angular or Zone aware and the code should still work.)

The reason it would not work is imagine this situation.
new Observable(cb1).map(cb2).subscribe(cb3)

The above has three callbacks. It is possible that each callback will run in a separate Zone so there are three Zones involved. The above code has only one scheduler. Hence one scheduler can not be associated with three callbacks.
As I said before the scheduler is too coarse grained for what is needed. Or to think about it differently the scheduler and Zones are orthogonal. The kind of scheduler you choose does not have any influence on the way Zones are propagated. It is possible that a developer would implement and install a custom scheduler, and we still need to have the Zones propagated.

would like to find a way that doesn't add extra debugger step commands for people who aren't using zones.

I'll need to look at the call stacks, because that sort of visibility is an important goal for Netflix.
@trxcllnt Zones support is tricky because there might be discrepancies between the zone the observable is in when it's created, versus when it's subscribed, versus the zone the actual thing producing data is running in. Allowing nature to take it's course with the way observables are currently might lead to seemingly non-deterministic behavior with zones.
@mhevery I must admit though, I'm not entirely sold on the way it's broken down here though... for example, given this:
let observable;

zone1.run(() => observable = new Observable(observer => {
  console.log('subscribing', Zone.current.name);
  observer.next('hi');
  observer.complete();
});

zone2.run(() => observable = observable.map(x => {
  console.log('map', Zone.current.name);
  return x + '!';
});

zone3.run(() => observable.subscribe(x => {
  console.log('next', Zone.current.name);
  console.log('next', x);
});

I would expect this:
subscribing zone3
map zone3
next zone3
next hi!

Because really those things are just functions:
let fn;

zone1.run(() => fn = observer => {
  console.log('subscribing', Zone.current.name);
  observer.next('hi');
  observer.complete();
});

zone2.run(() => fn = observer => fn({
  next(x) {
    console.log('map', Zone.current.name);
    observer.next(x + '!');
  }
});

zone3.run(() => fn({
  next(x) {
    console.log('next', Zone.current.name);
    console.log('next', x);
  }
});

It seems like Zones might have this issue with any function that is created under a zone that might be called at a later time. Is that accurate?

@mhevery ... I guess what I'm saying is: Are we sure that the "correct zone" for an Observable's ctor callback is the zone it was created in? Is that the standard behavior for all functions in JavaScript WRT to Zones?

@blesh It seems like Zones might have this issue with any function that is created under a zone that might be called at a later time.

Yes, this was my first instinct too. It seems like this would be an issue for nearly every library. Is jQuery going to have to ship with zone support as well?

@mhevery Also our developers could chose to use a third part Rx library which is not Angular or Zone aware and the code should still work.

Does this mean someone could drop in most.js in place of Rx, and zones should still work? If so, and considering Rx has to bake in zone support, how would zones still work if most.js doesn't do the same?
Exploring alternatives a bit more, is there a reason Angular can't extend (or worst case, monkey-patch) Observable with a custom lift implementation that creates zone-aware subscribers? Something like this:
class ZoneObservable extends Observable {
  lift(operator) {
    const obs = new ZoneObservable();
    obs.source = this;
    obs.operator = new ZoneOperator(operator);
    return obs;
  }
}
class ZoneOperator {
  constructor(op) { this.op = op; }
  call(subscriber, source) {
    return this.op.call(new ZoneSubscriber(subscriber), source);
  }
}

@trxcllnt I think there is a larger issue here than just Angular, as Zones are on the TC39's docket.
Looking at this now: https://docs.google.com/document/d/1F5Ug0jcrm031vhSMJEOgp1l-Is-Vf0UCNDY-LsQtAIY/edit#heading=h.eijd9xb9zfqx
It seems like the idea is that since using a zone is explicit, then it can be assumed that if someone adds a mapping function to an observable within a zone, their intention is that that function should run in that zone. Is that correct, @mhevery? In other words, if I've gone out of my way to create an Observable in some zone.run() then I must really want the body of it to run in that zone, etc. etc.

@blesh  ... I guess what I'm saying is: Are we sure that the "correct zone" for an Observable's ctor callback is the zone it was created in? Is that the standard behavior for all functions in JavaScript WRT to Zones?

Yes we are sure. I know it is not immediately obvious, so let me try to explain through an example.
Imagine you have an observable on keydown listener and you would like to debounce it before you pass it onto the subscriber.  In our case the subscriber would be an Angular application which should re-render.
It is clear that the subscriber should run in Angular zone so that angular does proper rendering. But if we run the observable registration of keydown in Angular zone, then we will be rendering on each key stroke which is too much since we have debounce. The keydown events happen way more often then the subscriber callback, and we want to apply different rules to them.
var keydown$
ngZone.runOutside(() => {
  keydown$ = Observable.fromEvent(element, 'keydown').debounce(200);
});
ngZone.runInside(() => {
  keydown$.subscribe(...)
});

In the above example what we set up is Rx recipe. Part of the recipe is outside of Angular and part is in Angular. This way we can control which operations have side effects and which do not.

@trxcllnt  Yes, this was my first instinct too. It seems like this would be an issue for nearly every library. Is jQuery going to have to ship with zone support as well?

Good question! No most libraries do not need anything special to work. Some such as Rx, and Promise do. So the obvious question is Why? What is special about Rx and Promise. These libraries do something called user-queueing. This issue arrises only when the library takes callbacks from many different clients, stores these callbacks and then batch executes them in a single VM turn. jQuery does not do that. jQuery passes its callbacks to underling platform addEventListener and it does not batch process them, so there is no issue. Rx is different, it composes many callbacks into chains and then executes them together, taking the output of one and passing to next.
What we are interested in is to be able to know which callback comes from app, framework, or outside the app (such as another app or an ad) So Rx needs to do more work, where as most libraries do not.
This is why the current state sort of works. We correctly retain the Zone for the VM turn, but that implies that all callbacks in that VM turn will have the same Zone. This prevents the debounce example shown above.

@trxcllnt Does this mean someone could drop in most.js in place of Rx, and zones should still work? If so, and considering Rx has to bake in zone support, how would zones still work if most.js doesn't do the same?

Sorry, that is not what I meant. If Angular would support most.js, then we would have to teach most.js how to propagate Zones as well (see above example of user-queueing). What I was getting at is imagine you have a third-party library such as RxFirebase, which was written on top of Rx but without the knowledge of Angular or Zones. An Angular developer should be able just pull that library in and use it in an Angular app.  Therefore, requiring that RxFirebase use a special calling convention which was suggested in original comment would break the Zone support and would make Angular and exclusive club. We want you to be able to use any library wether or not it was written with Angular (or Zones) in mind.

@trxcllnt Exploring alternatives a bit more, is there a reason Angular can't extend (or worst case, monkey-patch) Observable with a custom lift implementation that creates zone-aware subscribers? Something like this:

That would solve the operator case, but not the subscribe callback nor creation callback case.

@blesh It seems like the idea is that since using a zone is explicit, then it can be assumed that if someone adds a mapping function to an observable within a zone, their intention is that that function should run in that zone. Is that correct, @mhevery? In other words, if I've gone out of my way to create an Observable in some zone.run() then I must really want the body of it to run in that zone, etc. etc.

Yes, that is correct.

@mhevery Some such as Rx, and Promise do. So the obvious question is Why? What is special about Rx and Promise. These libraries do something called user-queueing.

jQuery passes its callbacks to underling platform addEventListener and it does not batch process them, so there is no issue. Rx is different, it composes many callbacks into chains and then executes them together, taking the output of one and passing to next.

I see. Wouldn't jQuery Deferred's would still need to include Zone support, since they execute user-code asynchronously, like Promises and Observables. Overall, it sounds like the Zones approach is to monkey-patch all the platform globals that can execute user-code asynchronously to support Zones. Is that accurate?

@mhevery If Angular would support most.js, then we would have to teach most.js how to propagate Zones as well (see above example of user-queueing). What I was getting at is imagine you have a third-party library such as RxFirebase, which was written on top of Rx but without the knowledge of Angular or Zones.

Thanks for clarifying. Based on this knowledge, I have some further questions (I appreciate you bearing with me here):

How do Zones interact with libraries that allow function currying/partial application, like lodash or ramda? Conceivably, one could declare a partially applied function in one Zone, curry some arguments (effectively redefining the function) in a different zone, and then execute the curried function in yet another zone. Which Zone does the original function run in? Do lodash and ramda have to build in zone support (or be monkey-patched themselves) to exhibit the correct behavior?
Are there any benefits to Zones in Rx core if I'm not using Angular 2? If I'm using Rx and React on the client, or running a high performance router and GPU render loop with Rx and websockets, what's this PR buy me?

Without knowing the potential benefits, I only see one big negative: at least one extra conditional per onNext and try/catch (something we're trying not to do). Regardless of whether the VM inlines the result of getZone(), the condition still results in 2x the number of debugger step commands I'll have to issue when I'm stepping through an operator chain.

@mhevery That would solve the operator case, but not the subscribe callback nor creation callback case.

Ok, so it sounds like monkey-patching Observable is an option for Angular. If so, we can extend the monkey-patching example to have logic to run subscribe functions in the proper zone context:
class ZoneObservable extends Observable {
  constructor(subscribe) {
    super(Zone.current.runInContext(subscribe)); // <-- replace `runInContext` with whatever Zone method is appropriate here
  }
  /* ... the rest of the example ...*/
}

@mhevery in talking with @jhusain about this, we determined that the zone should probably be attached to the subscription. In other words, whatever zone the subscribe call was in is the zone the other functions passed to the observable/map/filter/whatever should be run in.
I don't think that's how this PR work though. Am I mistaken?

@trxcllnt Wouldn't jQuery Deferred's would still need to include Zone support, since they execute user-code asynchronously, like Promises and Observables

Yes any implementation of Promise or Rx would need this. But the rest of the jQuery would not need it.

@trxcllnt How do Zones interact with libraries that allow function currying/partial application, like lodash or ramda?

It should have not effect since lodash does not store the callback for later execution. It executes them synchronously.

@trxcllnt  Are there any benefits to Zones in Rx core if I'm not using Angular 2?

Yes, you would be able to get long stack traces, and debug information about which operator executed when etc (I will update the PR to add the string information for better debugger support)
You could also get timing information to identify which streams are slow.

Ok, so it sounds like monkey-patching Observable is an option for Angular.

I don't really see it as an option. It would be very cumbersome. For example we can't patch native Promises and instead we have our own implementations in the Zone. Plus monkey patching has to happen at the right time.
Again having ZoneObservable would not work as it means third party libraries such us RxFirebase would not be usable in Angular since they use new Observable rather then ZoneObservable
I am happy to explore this option more, but given my experience with writing Zone and Promise implementation is think it is very unlikely.

@blesh: @mhevery in talking with @jhusain about this, we determined that the zone should probably be attached to the subscription. In other words, whatever zone the subscribe call was in is the zone the other functions passed to the observable/map/filter/whatever should be run in.

Having subscribe is not the correct behavior. I was alluding to it here: https://github.com/ReactiveX/rxjs/pull/2266#issuecomment-271444203 but let me try again.
Imagine you have a library which creates an observable obs which is shared. We then hand obs to two consumers A and B. A subscribes to obs in AngularZone but B does not. Now the observable constructor will run either in AngularZone or not depending on wether A run before B or vice versa.
Here is another example. Let's say you have a timer observable which counts up periodically. You then add an operator, which only passes on even counts, finally one subscribes to the result.
var o = rootZone.run(() => new Observable((sub) => {
  var count = 0;
  setInterval(() => sub.next(count++));
} )
.even()
);
angulaZone.run(() => {
 o.subscribe((v) => {
    // do some work expect that angular renders
  })
}

If the subscription happens in AngularZone then you want to render the UI only when data arrives on subscribe. You don't want to cause an update on odd values is produced at setInterval since the odd value will not propagate to the final subscription.
A common use case is for example autocomplete inbox. Many events happen, but only some of the events should result in angular render. Running the Observable constructor callback in the same zone as the subscription produces the wrong result.
As a matter of fact the behavior you are asking for is how Rx behaves without support for Zones. Without this PR Rx will execute the Observable constructor callback in the same zone as that of the subscribe which leads to mostly correct behavior until you want to do things which require sub-selection of data, which then results in running AngularZone too often.

@mhevery It should have not effect since lodash does not store the callback for later execution. It executes them synchronously.

This is true of the Array and Set operators, but I'm talking about methods like _.partial, or any method in Ramda, which automatically curries. The point I'm getting at is this seems to be a problem inherent with any library that lets you declare a method in one Zone, and execute it in another.

@mhevery Yes, you would be able to get long stack traces, and debug information about which operator executed when etc (I will update the PR to add the string information for better debugger support)
You could also get timing information to identify which streams are slow.

Assuming this only works if I compile Zones into my app? What about if I can't, say, because I'm in a high-performance GPU environment with gigabytes of data in memory, so the overhead of a global context that tracks and changes how the platform methods execute is a non-starter?

@mhevery If the subscription happens in AngularZone then you want to render the UI only when data arrives on subscribe. You don't want to cause an update on odd values is produced at setInterval since the odd value will not propagate to the final subscription.
A common use case is for example autocomplete inbox. Many events happen, but only some of the events should result in angular render. Running the Observable constructor callback in the same zone as the subscription produces the wrong result.

This has been a solved problem in Rx for years, via Schedulers. Rx.NET synchronizes the events from a throttled stream UI thread scheduler for rendering. In RxJS, we achieve something similar with noisyStream.auditTime(0, Scheduler.animationFrame).subscribe(render).

@mhevery I don't really see it as an option. It would be very cumbersome. For example we can't patch native Promises and instead we have our own implementations in the Zone. Plus monkey patching has to happen at the right time.

Sure, but I'm sure that was considered when Zones were designed? If zones want to globally track and control execution contexts, surely someone acknowledged the impracticality of updating all 400,000 packages in npm with Zones support? Monkey-patching platform globals gets you most of the way there, and since Zones made the decision they want to own the world, it's their responsibility to monkey-patch the rest (or provide alternative solutions, like a Zone-aware transpiler, etc.).

@mhevery Again having ZoneObservable would not work as it means third party libraries such us RxFirebase would not be usable in Angular since they use new Observable rather then ZoneObservable

From what I understand about commonjs and ES6 Modules, Angular should be able to replace the Observable export in rxjs/Rx and rxjs/Observable with one that's aware of Zones, which would solve the RxFirebase issue.

@trxcllnt This is true of the Array and Set operators, but I'm talking about methods like _.partial, or any method in Ramda, which automatically curries. The point I'm getting at is this seems to be a problem inherent with any library that lets you declare a method in one Zone, and execute it in another.

I had a closer look and I don't see anything there which would require Zone interception. This does not fall under the user-queue umbrella.

Assuming this only works if I compile Zones into my app? What about if I can't, say, because I'm in a high-performance GPU environment with gigabytes of data in memory, so the overhead of a global context that tracks and changes how the platform methods execute is a non-starter?

Not sure what you mean by compile. If the Zone is loaded than one can create a Zone which will track the invocation. If the Zone is loaded but the code is run in the default Zone, or Zone which does not create objects, than there is zero overhead. All of these features are opt-in. By default it is indistinguishable from no Zone at all. So I don't see an issue here.

This has been a solved problem in Rx for years, via Schedulers. Rx.NET synchronizes the events from a throttled stream UI thread scheduler for rendering. In RxJS, we achieve something similar with noisyStream.auditTime(0, Scheduler.animationFrame).subscribe(render).

Scheduler and Zones are orthogonal. Its not that you have a ZoneScheduler, it is that you track invocations using zone for any scheduler.

But surely that was considered when Zones were designed? If zones want to globally track and control execution contexts, surely someone acknowledged the impracticality of updating all 400,000 packages in npm with Zones support? Monkey-patching platform globals gets you most of the way there, and since Zones made the decision they want to own the world, it's their responsibility to monkey-patch the rest (or provide alternative solutions, like a Zone-aware transpiler, etc.).

No one is talking about monkey patching 400,00 libraries. We monkey patched the platform which gets us almost all the way there, with few exception of user queuing libraries.
If it was possible to monkey patch Rx, we would have already done that, but we can't which is why I would like to have this PR, which adds almost no overhead, and does it the right way.

From what I understand about commonjs and ES6 Modules, Angular should be able to replace the Observable export in rxjs/Rx and rxjs/Observable with one that's aware of Zones, which would solve the RxFirebase issue.

Unfortunately that is not possible.

Interception the constructor is same as monkey patching the constructor, and that is not sufficient as explained before.
Not everyone uses configurable Modules, there is UMD, Closure Compiler, just loading it using script tags, and we need to support all of them.

So, I think I'm on-board with the zone from the subscription carrying through the async calls... but it seems weird that the zone at the time .map was called is going to be captured. I think the concepts of Observable are being conflated with the concepts of Promises here. I can totally understand why you'd want to capture the zone for then with promises... but since observables are really just functions, map is more of a higher-order function. When you're calling operators you're building functions that get called when you subscribe. It's whatever zone you have at subscribe time that's probably important.
@mhevery I'd really like to see a solid example of a bug with zones this PR solves. I think it would help everyone understand the concerns and the need better than just discussing the academics of it.
To reiterate what I'm thinking, it seems like this should hold true:
let source$;
zone1.run(() => {
  source$ = new Observable(observer => {
    console.log('init', Zone.current.name);
    observer.next(1);
    observer.complete();
  });
});

zone2.run(() => {
  source$ = source$.mergeMap(x => {
    console.log('mergeMap', Zone.current.name);
    return Observable.timer(1000).map(() => {
      console.log('map', Zone.current.name);
      return x;
    });
  });
});

zone3.run(() => {
    source$.subscribe(x => {
      console.log(Zone.current.name);
    });
});

/** output
  init zone3
  mergeMap zone3
  // delay here
  map zone3
  sub zone3
*/

@blesh for context, @mhevery @jayphelps and I got on a call to discuss this last night. Takeaways are that I'm going to try and put together an alternate PR this week/weekend that monkey-patches in Zone support (and would be imported as needed like operators, via import 'rxjs/add/Zone'), then do a perf bake-off between the two, as well as followup discussions on ergonomics.
Neither @jayphelps nor I want to dismiss a feature request that's critical to the success of the Angular team and the hundreds of thousands of engineers they support, and are OK merging this PR into core if we can't find an optimal alternative solution. Sound about right @jayphelps @mhevery?

@trxcllnt that's fine. I'm more concerned that we're doing the wrong thing WRT to zones and Observables after talking with @jhusain about it. Given than both Zones and Observables are proposals before the TC39, I'd like to make sure we're doing the right thing.

@blesh  So, I think I'm on-board with the zone from the subscription carrying through the async calls... but it seems weird that the zone at the time .map was called is going to be captured.

I have been trying to explain this, and I have been failing :-(. Let me try again. The behavior you describe is the current behavior. In other words the constructor runs in the same zone as that of the subscribe invocation. This behavior is not correct.
Imagine we have a subscriber which fires once per second like so:
var obs = new Observable((sub) => {
  var count = 0;
  var id = setInterval(() => next(count++), 1000);
  return () => clearInterval(id);
});

Now imagine you run it through a filter which will only let go even numbers:
obs = obs.filter((v) => v%2 == 0);

And finally someone subscribes to it:
obs.subscribe(() => {
  // do some rendering side-effect which requires Angular
});

By your logic all functions should be running in the Angular zone, which implies that Angular would do Change Detection every 1 second. But that is not what we want. Because of the filter only time when Change Detection is needed is ever 2 seconds.
Our goal is that only the side-effect should be run in Angular Zone and hence have Change Detection only when the subscribe callback is run. The way we do that is this:
var obs;
rootZone.run(() => {
  obs = new Observable((sub) => {
    var count = 0;
    var id = setInterval(() => next(count++), 1000);
    return () => clearInterval(id);
  });
obs = obs.filter((v) => v%2 == 0);
});

angularZone.run(() => {
  obs.subscribe(() => {
    // do some rendering side-effect which requires Angular
  });
});

In the above example we are now guaranteed, that the only time Change Detection will run is when the subscribe callback runs not every time the setInterval fires.

I have been trying to explain this, and I have been failing :-(. Let me try again.

You explained it to me (successfully) offline after I made that comment.

@mhevery do the tests in this PR run on your machine? I'm getting an error deep inside node-zone.js during mocha initialization. A mocha class instantiates an Error in its constructor, which gets intercepted by ZoneAwareError, then ZoneAwareError is throwing this error inside assignAll: TypeError: Cannot assign to read only property 'toJSON' of object 'Error: done() called multiple times'. Curiously, the call to assignAll doesn't exist in zone.js master.

@mhevery also if I patch my local copy of node-zone to try/catch around initialization errors, I can get it to work. But then adding Zones globally breaks all our unit tests that use chai to validate instanceof Error (I get a lot of expected { Object (stack, message, ...) } to be an error failures). Is there a way to test zones without affecting the rest of our tests?

@mhevery I was able to move forward by pinning zone.js to v0.7.4. You can see the changes in https://github.com/trxcllnt/rxjs/commit/53eddb1cca1228fe6d81aa6bec0ee0a57c8f4664, or jump right into the action at rxjs/add/zone.js.
Because zones patch the world, I created a separate build_test_zone step to compile and run the tests with the zone.js import and observable patch. Even if Zones aren't supposed to do anything if they're not used, I think it's best if we can keep running the tests as-is, then have a second step where they're run with zones.
I haven't done any perf tests yet. It will be a bit of a task to update our micro-perf-test-runner to run all permutations of "do/don't include zone.js + do/don't include the patch." In the meantime, feel free to comment on the implementation. I'm shooting somewhat in the dark here, so I'll need your guidance as to correct behavior.

@trxcllnt yes, we are aware of the zone v0.7.5 issue, should be releasing v0.7.6 soon.

@trxcllnt looks like the zone specs are passing, so I assume that the implementation is correct and it is doing what it is supposed to.
I do have to say that the patching is very hard for me to follow, even ofter sort up understanding what is going on.
What is the next step? I assume we need to get the perf numbers?

@blesh Can we just use plain ol' prototype assignment in that code? Just for readability's sake. defineProperties might be slightly more performant in some environments, but I'd be surprised if it is to a degree it's worth the hit to readability.

We have to use Object.defineProperties to turn Observable's source and _subscribe, Subscription's _unsubscribe, and Subscriber's destination fields into getters/setters. Since these fields are set in the constructors (or in lift), we can capture the value of Zone.current.
If these fields aren't set (like when Observable/Subscription aren't called with subscribe/unsubscribe callbacks), we don't read Zone.current, which we only need when the CBs are provided.
The others yeah, I'd prefer proto patching. I originally wrote it that way in ES6, and I can't remember exactly right now, but I think Typescript yelled at me when I made it a TS file.

we should get perf numbers for all scenarios.

👍 for sure. I've been really busy with work lately. The quick and dirty way (I think) would be to add another cmd line arg to perf/micro/index.js to require rxjs/add/zone.js up front. That'll be rough to do a side-by-side though, since we'd be testing this branch of Rx 5 vs. 4, then my patch branch of 5 vs. 4, and have to infer the perf diffs. It could even be totally bogus. Ideally we'd do something like https://github.com/ReactiveX/rxjs/issues/2198.

Also, I have a distinct feeling that there are some operators that will slip under the radar for both of these.

I won't say it's not possible, but I'm pretty sure we got all the bases covered Observable API. The only thing I left out was patching the Schedulers' schedule method, because a. patching lift/Subscriber/Subscription will capture/switch to the right Zone.current, b. they weren't in this PR, and c. I forgot :-P

Are there any updates? It this blocked by something?

@fxck just debating the best approaches and trying to find the time to vet each one.

Please, let us know what's going on about this PR. I think it's quite important for future plans for the Angular  dev-team and users.

What's the status?

@chaosmonster aside from rebasing these PRs from master, the biggest hurdle is we need to work to get versions of the perf tests that allow us to run w/ zones enabled and disabled, then create a comparison matrix that looks something like this:

Rx master
Rx w/ Zones in core
Rx w/ Zones patched

with require('zone)
✔
✔
✔

without require('zone)
✔
✔
✔

thx for the insides

There been any movement on this? We've just hit this and had to add workarounds.

@philjones88 hey, can you clarify what exactly what you hit? AFAIK this is more a correctness thing to reduce some unnecessary diffing when nothing changed. I'm personally skeptical that an app's performance would make or break on this PR but if that's the case I'm interested to know how 👍

@jayphelps This isn't just about Angular though.  It's about making it work in a more sane way with Zone.js, which is super useful for all sorts of things (testing/conformance checks/performance instrumentation/etc.).  Angular's use of zones for change detection is just one aspect of it.

@jayphelps see my GH issue on the zone.js repo:
https://github.com/angular/zone.js/issues/830
I got redirected here after eventually figuring out it was an rxjs + zone.js issue rather than a browser specific problem.

Sorry to bother but is there any news ?

It has already been fixed on Zone.js side.

@trotyl but not so perfectly: https://github.com/ReactiveX/RxJS/issues/1391

If it's fixed then why is this issue still open

@somombo I'm waiting to hear back from the Angular team. As such, this PR is on hold.

@benlesh thanks for the timely feedback, appreciate it

I think this PR is stale, and we all agree that adding Zones to RxJS wasn't what we wanted to do. I'm going to close this one.

(Waits to change teams, closes his boss's PR)


[bug] 2nd time - doesn't run (macOS)

On macOS, after starting Manim and then quitting it - it doesn't run again.

For example:

start a Manim window (with any method)
finish it (with any method)

After that - problems:

"Preview Manim Cell" -
doesn't work, raises a notification:

Simultaneous Manim commands are not currently
supported on MacOS. Please wait for the current
operations to finish before initiating a new command.

"Preview selection" command -
doesn't work, same notification.

start manimgl via a terminal - works (it starts).
But then the "Preview Manim Cell" , "Preview selection" commands continue NOT working - having the same behavior..

I can confirm this bug. Another important fix before release...
@VladimirFokow we should probably dive into the ManimShell.ts code to help @Splines with this implementation. He doesn't have a way to debug things on his end. It's actually quite frustrating these diff behaviors between WSL and MacOS -- I thought Electron was supposed to solve these issues 😂 lol
I suggest tackling some of the MacOS facing integration tests suggested in #47 as we try to resolve these OS conflicts. This is my first extension in VS Code, and it will also be my first attempt at testing in TS 🙈, but it will be very valuable. We can keep the tests local for now (i.e., running the suite on @Splines windows machines and our MacOS machines) and figure out how to integrate a CI pipeline later

Log file:
Manim Notebook.log
Here's what I did:
from manimlib import *
import time

class SquareToCircle(Scene):
    def construct(self):
        #
        ## Test
        circle = Circle()
        self.play(ShowCreation(circle))

reload window
start logging (trace level)
click "run manim cell"
command: "quit preview"
click "run manim cell" -> broken
start manim on line 6
click "run manim cell" -> broken

It's actually quite frustrating these diff behaviors between WSL and MacOS -- I thought Electron was supposed to solve these issues 😂 lol

@bhoov Yes, these differences are frustrating. But I'm not sure it's Electron's fault. We're dealing with a terminal and I suspect that communicating with underlying layers might reveal more difference shere than in other areas where "just" a regular Chromium browser is used and that is abstracted away in higher layers than the "bare-bone" terminal.

Here's what I did:

@VladimirFokow  Thank you very much for the logfile and the enumeration of steps you've performed, this will hopefully make it possible for me to fix the issue in the following days.


FIX: Fixes

orig_format doesn't exist for Epochs/ICA, assume float32
lasso_event is not a real matplotlib event, let's just make our own callbacks and use them (this is in https://github.com/mne-tools/mne-python/pull/9960 but has a backward compat shim here)
When I did group_by='selection', I actually had a matplotlib Qt window show up even though show=False was used in plot_sensors. A cleaner approach I think is just to explicitly use an Agg figure

I drafted the release but will wait until this is merged

Sure I can wait 👍🏻

Have to have this in main for the [circle full] run to pick it up.


[Applications] Meshery Application Upload Fix

Signed-off-by: Abhishek-kumar09<EMAIL_ADDRESS>Description

Able to upload an Kubernetes Yaml
Able to deploy an kubernetes yaml if the component registration is successfully done
While Application is deployed:
A POST request to Pattern enpoint to convert core kubernetes to pattern-file format
An application deploy on the resultant pattern file
This PR fixes #5003

Remains:

URL upload still need application name to be uploaded successfully, we have to chage some meshery-cloud code there for it. @Revolyssup

Notes for Reviewers
Signed commits

[x] Yes, I signed my commits.

@MarioArriaga92, it's here!! 😄


Adjusted workflow triggers

Current dependencies on/for this PR:

main

PR #264

PR #265   👈

This comment was auto-generated by Graphite.

Graphite Merge Job
Current status: ⏳ Queued to merge
This pull request is currently queued to be merged as part of a stack.
This comment was auto-generated by Graphite.

Job Reference: xXXR9ecHRwJ7fjoa6Zut


Error injecting type definitions with auth-helpers-sveltekit

Bug report
Describe the bug
Typescript error "Expected 0 type arguments, but got 1" when doing type injection as described here but with "@supabase/auth-helpers-sveltekit"
There was a previous ticket https://github.com/supabase/auth-helpers/issues/407 which is marked as closed but this does not work for me.
To Reproduce

Run supabase gen types typescript --local > ./app/src/lib/generated/definitions.ts

Add Superbase interface to app.d.ts and reference the generated types

Add type argument to createClient()

System information

Version of supabase-js: 2.8.0
Version of auth-helpers-sveltekit: 0.8.7

No need to add the types in createClient, they are automatically set by the type in app.d.ts

Ah! Thank you!


Repeatedly to start on / turn off the  subscribe node at pc side . Stm32 crashed about at the 3rd times.

log info stop at : Echo recv!

I have got the problem：
XMLRequest* response = new TopicResponse(IP_ADDR, UDP_LOCAL_PORT, connection->getID());
this place  call new operator but not call delete operator. so I added "delete response;" But it still crashed. the memory not released as I test the heap address.
It's really confusing,delete not worked but worked on pc.

problem can be solved like this:

comment this:
//char data[1500];
//char header[256];
//char xml[1024];
change to:
char *data =(char *) malloc(1500);
char *header =(char *) malloc(256);
char *xml = (char *)malloc(1024);
3.add deconstructor:
~XMLRequest()
{
free(data);
free(header);
free(xml);
}
and don't forget to add delete operator .


Update dhall-generic to 0.3.60

Updates us.oyanglul:dhall-generic from 0.3.59 to 0.3.60.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "us.oyanglul", artifactId = "dhall-generic" } ]

labels: library-update, early-semver-minor, semver-spec-patch

Codecov Report

Merging #157 (072b2ed) into master (5be03d0) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #157   +/-   ##
=======================================
  Coverage   98.27%   98.27%
=======================================
  Files           1        1
  Lines          58       58
  Branches        2        2
=======================================
  Hits           57       57
  Misses          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 5be03d0...072b2ed. Read the comment docs.

Superseded by #162.


lhapdf: 6.5.3 -> 6.5.4

Description of changes

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 273276 run on x86_64-linux 1

25 packages built:

apfel
apfelgrid
applgrid
fastnlo_toolkit
herwig
lhapdf (python311Packages.lhapdf)
mcfm
nnpdf (python311Packages.nnpdf)
pythia
python310Packages.fastnlo_toolkit
python310Packages.lhapdf
python310Packages.n3fit
python310Packages.n3fit.dist
python310Packages.nnpdf
python310Packages.validphys2
python310Packages.validphys2.dist
python311Packages.fastnlo_toolkit
python311Packages.n3fit
python311Packages.n3fit.dist
validphys2 (python311Packages.validphys2)
validphys2.dist (python311Packages.validphys2.dist)
sacrifice
sherpa
thepeg
xfitter


TS1109 (TS) Expression expected errors in Razor

In a .NET 8 Blazor application using VS 17.10.0 Preview 3.0, I’m seeing TS1109 (TS) Expression expected errors in Razor files. I do not have any TypeScript files in my project.

@hettigoda This issue is being tracked in the VS Feedback system, as it's caused by code outside of this repository. The best place to track updates is to follow and upvote this issue: https://developercommunity.visualstudio.com/t/TS1109-TS-Expression-expected-error-in/10635769


Remove "settings" from appid.info

Didn't see you already improved it a bit, but this also removes the need for appid.info.settings.
(So now appid.settings.js is hardcoded in the settings app instead of during upload)
So we could get rid of https://github.com/espruino/BangleApps/blob/242c35dfac89f2e962b807292f8e17dc6d0bdc80/js/appinfo.js#L63-L64 once enough(?) people have updated the settings app.

Thanks! I'm not sure memory usage there is such a big deal, but anything we can do to simplify things has got to be a bonus :)
IMO loading the JSON files on demand for sorting will probably be super slow for more than a handful of apps with settings though.
wrt mem usage: I had been working on the assumption that all apps' info files could be loaded into RAM in one go, but it seems that's not really sensible now. Once we load the JSON one bit at a time and keep only what we need, I don't think memory usage is an issue.

Updated the PR to just get rid of settings in appid.info.
I figured that people who are updating apps would also update the settings app, so it was OK to stop adding a settings field to appid.info right away.

Neat - thank you!


Add a web socket call concept for connecting.

Similar to HTTP and Call, the WebSocketCall is a representation of a pending HTTP request and subsequent upgrade to speak web sockets. Upon synchronous execution you are handed a WebSocket instance for synchronous writing and also pass in a WebSocketListener for async callbacks due to reading.
The API changes in this commits also generalize WebSocket such that it's agnostic to being a client or server peer.
Closes #1173.
Missing tests:

[x] Non-101 response
[x] Response with failed web socket upgrade (multiple)

PTAL

PTAL

With tests!

With tests!

LGTM nice work!

LGTM nice work!

One problem with conflating the initial request/response handshake and the websocket's normal operation is that we lose a clean way to handle it in the server context.

One problem with conflating the initial request/response handshake and the websocket's normal operation is that we lose a clean way to handle it in the server context.

Blocking on adding web socket support to MockWebServer for any more of the WebSocketCall testing. Would like to finish getting this PR in before I tackle that (as well as #1241).

Blocking on adding web socket support to MockWebServer for any more of the WebSocketCall testing. Would like to finish getting this PR in before I tackle that (as well as #1241).

I merged 'cause it's a big change and I don't want to review the whole thing again! But there's some comments, particularly on cheating with the reader thread, that I'd like you to follow up on!
WebSockets is already the big feature for OkHttp 2.3.

I merged 'cause it's a big change and I don't want to review the whole thing again! But there's some comments, particularly on cheating with the reader thread, that I'd like you to follow up on!
WebSockets is already the big feature for OkHttp 2.3.


[FEATURE]: Any plan to support train_dreambooth_colossalai with train_text_encoder?

Describe the feature
I found that the train_dreambooth_colossalai script you provide no longer supports train_text_encoder parameter,
but it's gives much better results especially on faces,
so I would like to ask if you have plans to support this parameter?
Thanks again!

+1

Have you solve this problem?

No, ColossalAI's optimizer cannot support multiple network parameters.

You are right. The GeminiDPP can only deal with parameters from a single model, rather than parameters from multiple models. But, you can support train_text_encoder parameter with some code modifications.

We are considering making Gemini more flexible, but we have no such plan in the next two weeks.

+1. It would be much more flexible if we can train multi-modules, which is common when finetuning stable diffusion.

@feifeibear any update for this?

hi @feifeibear ,
thanks for your great job!
Would you explain a little bit about which part I should change for supporting text_encoder parameters?
Any help would be appreciated! Thank you so much!

We have a very intensive discussion on this.
Can could please report the latest conclusion @1SAA , @ver217 .

Hi @feifeibear , @1SAA ， and @ver217 ,
Any advice would be very appreciated since I am stuck here for a long time.
Really looking forward to your reply. Pls feel free to update your solution here, I can validate the idea. Thank you so much!

Hi @feifeibear , @1SAA , @ver217 ,
Any chance to get your discussion here? It will be very helpful. Looking forward to your reply. Thank you so much!

Hi @feifeibear , @1SAA , @ver217 ,
Could you spend a little bit of time describing your discussion here?
Because it is beneficial for many users and in many cases.
Thank you so much!

Hi @feifeibear , @1SAA , @ver217 ,
Hi authors of Colossalai, would you provide some useful suggestions for training text encoder and unet together? Thanks

Hi @feifeibear , @1SAA , @ver217 ,
Any updates for this question? I am still waiting for your answers.
Any answer will be appreciated! Thanks

@Fazziekey Could you answer this question?


Migrate Pangeo Cloud Docs to 2i2c Docs

Description
To go along with #482, I would like to shut down https://pangeo.io/cloud.html and just point users at https://docs.2i2c.org/ instead. We should have one authoritative source of documentation for the hubs.
Value / benefit

Maintaining two documentation sites is extra work and could lead to user confusion
There may be some useful tidbits in the Pangeo docs which will improve the 2i2c docs

Implementation details
Ideally we would just put a link on https://pangeo.io/cloud.html which points to https://docs.2i2c.org/.
Tasks to complete

[ ] Someone read both documentation sites thoroughly and enumerate which items from the Pangeo docs are not covered by the 2i2c docs.

The data 2i2c data management docs say nothing about working with object storage, while Pangeo docs have lots of detail about this.
2i2c docs say nothing about Dask
Probably several others

[ ] Someone makes a PR to https://github.com/2i2c-org/pilot with the documentation updates
[ ] Someone makes a PR to https://github.com/pangeo-data/pangeo/blob/master/docs/cloud.rst redirecting to 2i2c docs.

Updates
No response

I think this is a great proposal Sarah. Something like this would be really valuable for 2i2c.
One challenge would be how to reconcile these docs with @choldgraf self-declared pet peeve:

A pet peeve: when I see blogs and online courses with better learning material than the documentation of a package. We need more people making upstream improvements to docs! That well-written blog post could be a PR to the package!

What would be the boundary between these 2i2c docs and the general jupyterhub docs?
My personal opinion is that, if 2i2c is offering a paid service, it should have dedicated, semi-standalone documentation about how to use that service, rather than just linking out to upstream docs.

Yeah, it's a fine line to walk. Linking out to upstream means the docs are less likely to go stale, reduces our maintenance burden and embodies the value of 2i2c in supporting open source tools. I think if we also want it to be generalisable and reusable across many types of communities, then the only thing we can do is provide the minimal basics to get people up and running and then say "if you're interested, here's a link that shows you how to do the really cool stuff".
If it's being delivered to a user community as part of a broader onboarding with other domain-specific/"this is how you do data science" aspects not provided by 2i2c, it probably needs to be scoped quite tightly so as to not overwhelm the users in terms of info-dump too.

I agree with the content that is in @sgibson91's list. My main question is how this differs from docs.2i2c.org. For example:

Logging on / off (missing)
How to start / stop a server: https://docs.2i2c.org/en/latest/admin/howto/control-user-server.html#stop-or-start-a-user-s-server
Selecting environments (profile-list options): https://docs.2i2c.org/en/latest/admin/howto/environment.html#create-multiple-environments-for-users-to-select
Navigating jupyterlab (missing, more or less)
Install a package at runtime: https://docs.2i2c.org/en/latest/admin/howto/environment.html#temporarily-install-packages-for-a-session
Using nbgitpuller: https://docs.2i2c.org/en/latest/admin/howto/content.html#distribute-content-with-nbgitpuller

Is there something about the content at docs.2i2c.org that makes it seem not scoped for the kind of use-case we have in mind? Maybe we need to change the structure of those docs?
Or, maybe those docs should be in a separate place like learn.2i2c.org, and docs.2i2c.org would be focused on "about the service" style stuff?

(super quick response because I'm on my phone) I think the main difference is audience. The docs we have currently are aimed at people who have admin privileges on the hub, what about the users who don't have admin access and are being exposed to JupyterHub for the very first time through a 2i2c-operated hub? I think there could be some value in having a 2i2c-cheatsheet for how to get up and running with all of these things and then point them to Jupyter* docs for more advanced usage patterns.
(I think we're overloading the word user in this conversation related to a chat we had the other week: Users of JupyterHub the package are actually sysadmins and their users are another node down on the tree relative to us, the engineers who are thinking on a Kubernetes level.)

Right - so is this a good summary of the current thinking:

docs.2i2c.org is for hub administrators, and for people who are trying to learn more about the service in general
learn.2i2c.org would be for hub users and hub administrators
the content currently at docs.2i2c.org is a combination of both user-personas right now, and there would be value in cleanly separating them.

I think learn.2i2c.org could be like a module that hub admins distribute to their users alongside some domain-specific info.

yeah that makes sense to me - basically learn.2i2c.org could be similar content to what is at
I'm pretty sure that you're contractually obligated to use the phrase "Train the trainers" if you put a Carpentries hat on 😄

Yeah, I agree, which is why I think we should curate the minimum to get people going and then link out for anything more complex.


Update specs, remove encoding headers

Removed encoding headers from files
Fixed indentation in lemmatizer_spec
Added before(:all) hook in lemmatizer_spec
Split spec into multiple groups
Use the new expectation syntax

Nice. Thanks.


Bundle for localization files

Added localization files inside a bundle to not interfere with apps localization when LTHPasscode is used via cocoapods.
With the localization files outside a bundle all localizations used on LTHPasscode are considered as languages of the main app when it's published on App Store.
This PR also add the pt-BR localization.
Changes:

Add the localization files inside a bundle.
Change the way to get the localized strings on LTHPasscodeViewController.
Add the pt-BR localization.

Hey, thanks a lot!

Great! :+1:


feat(fee): Adding adjustable fee

:tada: This PR is included in version 1.7.0 :tada:
The release is available on npm package (@latest dist-tag)
Your semantic-release bot :package::rocket:


Allow configuration of MQTT password, base_topic and  network_key through addon config rather than configuration.yaml

Description of problem:
Now that the MQTT password, base_topic, network_key,  is migrated to configuration.yaml, these cannot be retrieved from the home-assistant secret.yaml anymore, which results in plain text passwords and other private data in the configuration file.
As a result the only way to keep these settings private is adding the full config file to the .gitignore of my version control.
Preferably the config file can be kept in version control for restore purposes or when migrating to another server.
Zigbee2mqtt add-on version (if edge, please report commit hash):
<EMAIL_ADDRESS>
Cause: I almost added my zigbee2mqtt to my public git repository due to the breaking changes in 1.25.0-1
I would love to keep my configuration.yaml in a VCS while hiding the configuration elements I want to keep private using the !secret mechanism in the home assistant addon configuration instead of having to exclude the full config file in my .gitignore, as it would make restoring the functionality after hardware failure much easier when having the original config file.

The MQTT password can still be set in the addon configuration. In fact its one of the few things you have to set via the addon configuration since the addon will not start without a valid MQTT configuration. So you can still use !secret there.
That being said, !secret references have always been substituted with the actual secret in plaintext in the configuration.yaml file that Z2M uses. This is because !secret is a home assistant thing, not a Z2M or native YAML thing. Z2M is what is interpreting its own configuration.yaml file and it has no clue what !secret means so that would just fail.
If your goal is to put the configuration.yaml of Z2M in version control then what you should ask for is the ability to set the matching environmental variables. Z2M (like many dockerized applications) supports overriding pieces of its config via environmental variables. So if the addon config provided options to let you set the following environmental variables:

ZIGBEE2MQTT_CONFIG_MQTT_PASSWORD
ZIGBEE2MQTT_CONFIG_MQTT_BASE_TOPIC (why is this a secret?)
ZIGBEE2MQTT_CONFIG_ADVANCED_NETWORK_KEY

Then you could keep those values out of the configuration.yaml file using Z2M's native mechanism for doing so.


Error after Upgrade to Version 20 (from 18.4) with posting Grid Image

For Bug Reports

BookStack Version (Found in settings, Please don't put 'latest'):20.0

PHP Version: PHP 7.0.22-0ubuntu<IP_ADDRESS> (cli) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
with Zend OPcache v7.0.22-0ubuntu<IP_ADDRESS>, Copyright (c) 1999-2017, by Zend Technologies

MySQL Version:mysql  Ver 14.14 Distrib 5.7.21, for Linux (x86_64)

Expected Behavior
When adding an image to the categories for grid view:

Current Behavior
I get the following error when I save:

Steps to Reproduce
During the upgrade I did get this error, but I don't think related.

Application In Production!     *

Do you really wish to run this command? (yes/no) [no]:

yes

[Illuminate\Database\QueryException]
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'comment-create-all' for key 'permissions_name_unique
' (SQL: insert into role_permissions (name, display_name, created_at, updated_at) values (comment-create-all, Cre
ate All Comments, 2018-03-15 23:18:05, 2018-03-15 23:18:05))
[PDOException]
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'comment-create-all' for key 'permissions_name_unique
'

Hi @jacksonp2008
There are two issues here, and the actual issue is hidden behind this issue that you're seeing here.
Can you please post logs from the laravel.log file present under storage/logs folder?
Also are you running the application in development mode?
The actual exception is masked by an exception thrown from here - https://github.com/filp/whoops/blob/master/src/Whoops/Handler/PrettyPageHandler.php#L413

here ya go
laravel.log

Error seems to be that the image_id column is not present.
[2018-03-15 23:37:08] production.ERROR: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'image_id' in 'field list' (SQL: update `books` set `updated_at` = 2018-03-15 23:37:08, `updated_by` = 154, `image_id` = xxxx where `id` = 13)

{"userId":154,"email":"spollock@forescout.com","exception":"[object] (Illuminate\\Database\\QueryException(code: 42S22): SQLSTATE[42S22]: Column not found: 1054 Unknown column 'image_id' in 'field list'

I would run the migrations again.

Same error:
root@dev-wiki:/var/www/bookstack# php artisan migrate
**************************************
*     Application In Production!     *
**************************************

 Do you really wish to run this command? (yes/no) [no]:
 > yes

  [Illuminate\Database\QueryException]
  SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'comment-create-all' for key 'permissions_na
  me_unique' (SQL: insert into `role_permissions` (`name`, `display_name`, `created_at`, `updated_at`) values (comme
  nt-create-all, Create All Comments, 2018-03-20 16:49:37, 2018-03-20 16:49:37))

  [PDOException]
  SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'comment-create-all' for key 'permissions_na
  me_unique'

root@dev-wiki:/var/www/bookstack#

OK, so it appears that this migration ran, but was not recorded as such in the migration table.
Can you please paste the output after running the following command on the database,
-- replace bookstack with your database name
SELECT * FROM bookstack.role_permissions WHERE name LIKE 'comment-%';

It should show you something similar to the below,

If yes, the migration ran properly, but a record was not created in the migration table. This causes the artisan command to think that the migration was never run.
I'd recommend creating a record in the database migration table manually with the following query,
INSERT INTO `bookstack`.`migrations`
(`migration`,`batch`)
VALUES
('2017_08_01_130541_create_comments_table', 2);

After you are done with that, try running the migrations again by php artisan migrate

Indeed it does, are those dates correct?
mysql> SELECT * FROM bookstack.role_permissions WHERE name LIKE 'comment-%';
+----+--------------------+---------------------+-------------+---------------------+---------------------+
| id | name               | display_name        | description | created_at          | updated_at          |
+----+--------------------+---------------------+-------------+---------------------+---------------------+
| 60 | comment-create-all | Create All Comments | NULL        | 2017-11-30 05:27:37 | 2017-11-30 05:27:37 |
| 61 | comment-create-own | Create Own Comments | NULL        | 2017-11-30 05:27:37 | 2017-11-30 05:27:37 |
| 64 | comment-delete-all | Delete All Comments | NULL        | 2017-11-30 05:27:37 | 2017-11-30 05:27:37 |
| 65 | comment-delete-own | Delete Own Comments | NULL        | 2017-11-30 05:27:37 | 2017-11-30 05:27:37 |
| 62 | comment-update-all | Update All Comments | NULL        | 2017-11-30 05:27:37 | 2017-11-30 05:27:37 |
| 63 | comment-update-own | Update Own Comments | NULL        | 2017-11-30 05:27:37 | 2017-11-30 05:27:37 |
+----+--------------------+---------------------+-------------+---------------------+---------------------+

Also inserted the value from above and re-ran the migration:
root@dev-wiki:/var/www/bookstack# php artisan migrate
**************************************
*     Application In Production!     *
**************************************

 Do you really wish to run this command? (yes/no) [no]:
 > yes

Migrating: 2017_08_29_102650_add_cover_image_display
Migrated:  2017_08_29_102650_add_cover_image_display

Then I added an image to the grid view, and it is now working.
Thanks for the assist!

Glad to hear you got this working, Will listen out for similar issues in case the update path broke at some point.
Thanks for your time to support on this one @Abijeet.


macOS: Find TCL libraries automatically

Recent versions of macOS do not ship headers for system frameworks anymore; you
have to use the SDK that is installed by xcode-select --install (or when
installing Xcode). The way to get the path to this SDK is xcrun --show-sdk-path.
It's also possible to have tcl installed elsewhere on the system (such as via
brew install tcl-tk). The current configuration script does not respect the
[info library] output on macOS, so we use that if it's available.
This change updates the TCL configuraiton to find TCL headers from those
locations. This makes --enable-tclinterp work on macOS without additional
arguments.
Homebrew
> PATH=$(brew --prefix tcl-tk)/bin:${PATH} ./configure --with-features=huge --enable-tclinterp --with-tclsh=tclsh --enable-fail-if-missing

Result:
configure:7153: checking --enable-tclinterp argument
configure:7162: result: yes
configure:7167: checking --with-tclsh argument
configure:7172: result: tclsh
configure:7181: checking for tclsh
configure:7199: found /usr/local/opt/tcl-tk/bin/tclsh
configure:7211: result: /usr/local/opt/tcl-tk/bin/tclsh
configure:7394: checking Tcl version
configure:7398: result: 8.6 - OK
configure:7403: checking for location of Tcl include
configure:7413: result: /usr/local/Cellar/tcl-tk/8.6.10/include/tcl.h
configure:7425: checking for location of tclConfig.sh script
configure:7436: result: /usr/local/Cellar/tcl-tk/8.6.10/lib/tclConfig.sh

:tcl info library:
/usr/local/Cellar/tcl-tk/8.6.10/lib/tcl8.6

Command Line Tools
> sudo xcode-select -s /Library/Developer/CommandLineTools
> ./configure --with-features=huge --enable-tclinterp --enable-fail-if-missing

configure:7162: result: yes
configure:7167: checking --with-tclsh argument
configure:7175: result: no
configure:7181: checking for tclsh8.5
configure:7199: found /usr/bin/tclsh8.5
configure:7211: result: /usr/bin/tclsh8.5
configure:7394: checking Tcl version
configure:7398: result: 8.5 - OK
configure:7403: checking for location of Tcl include
configure:7413: result: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Tcl.framework/Versions/Current/Headers/tcl.h
configure:7425: checking for location of tclConfig.sh script
configure:7436: result: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/Tcl.framework/tclConfig.sh

:tcl info library
/System/Library/Frameworks/Tcl.framework/Versions/8.5/Resources/Scripts

XCode
> sudo xcode-select -r
> ./configure --with-features=huge --enable-tclinterp --enable-fail-if-missing

configure:7153: checking --enable-tclinterp argument
configure:7162: result: yes
configure:7167: checking --with-tclsh argument
configure:7175: result: no
configure:7181: checking for tclsh8.5
configure:7199: found /usr/bin/tclsh8.5
configure:7211: result: /usr/bin/tclsh8.5
configure:7394: checking Tcl version
configure:7398: result: 8.5 - OK
configure:7403: checking for location of Tcl include
configure:7413: result: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Tcl.framework/Versions/Current/Headers/tcl.h
configure:7425: checking for location of tclConfig.sh script
configure:7436: result: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Tcl.framework/tclConfig.sh

:tcl info library
/System/Library/Frameworks/Tcl.framework/Versions/8.5/Resources/Scripts

To explain why this is working in CI, currently. We're finding the headers in the system directory:
checking for location of Tcl include... /System/Library/Frameworks/Tcl.framework/Headers/tcl.h
464checking for location of tclConfig.sh script... /System/Library/Frameworks/Tcl.framework/tclConfig.sh
465

This means either:

The CI uses macOS 10.13 or earlier, or
The CI environment has run the "magic package" which re-instates the system framework headers

The later workaround won't exist forever, and in fact, i don't think exists on catalina.


bug: short issue description

What is the problem?
Using Lambda with runtime 3.12 results AwsSolutions-L1 issue.
Reproduction Steps
Create a stack with:
const pythonCode = `
Replace this with your actual Python code
def handler(event, context):
message = "Hello from an inlined Python Lambda!"
return {"message": message}
`;
const myLambda = new lambda.Function(this, 'IotCertificateCustomResource', {
runtime: lambda.Runtime.PYTHON_3_12,
role: iotCertCustomResourceRole,
code: lambda.Code.fromInline(path.resolve(__dirname, './lambda/iot_certificate')),
handler: 'main.handler'
});
What did you expect to happen?
The AwsSolutions-L1 finding should not happen as the python 3.12 is the latest.
What actually happened?
AwsSolutions-L1 error wsa reported
cdk-nag version
2.28.109
Language
Typescript
Other information
These are the runtimes considered during execution:
[
{ value: 'python2.7', family: 'python', version: '2.7' },
{ value: 'python3.6', family: 'python', version: '3.6' },
{ value: 'python3.7', family: 'python', version: '3.7' },
{ value: 'python3.8', family: 'python', version: '3.8' },
{ value: 'python3.9', family: 'python', version: '3.9' },
{ value: 'python3.10', family: 'python', version: '3.10' },
{ value: 'python3.11', family: 'python', version: '3.11' }
]
The python3.12 is missing from the list and the code https://github.com/cdklabs/cdk-nag/blob/main/src/rules/lambda/LambdaLatestVersion.ts pickes the 3.11 as latest.

I can't reproduce this locally. These runtimes are sourced directly from the CDK, and 3.12 is included.
A few questions

What CDK version are you using?
How are you using cdk-nag?

It doesn't make sense to me that you're able to specify PYTHON_3_12 as a runtime in your application, yet its not listed on the available runtimes within the cdk.


 shows high memory usage, but the flamegraph shows just a little portion of it

Bug Report
Current Behavior A clear and concise description of the behavior.
Not sure it's a bug, but, I'm trying to understand why a test allocates lots of memory.
pytest --memray --memray-bin-path=. 'tests/auto-check/core/test_correlation.py::test_correlation[...]'

Then
python -m memray flamegraph --temporal 2e8a7baff95e4d8ba3eb8d06bdece836-tests-auto-check-core-test_correlation.py-test_correlation\[...].bin

and I get the following flamegraph:
memray - temporal flamegraph report.zip
The <root> call says 800+MB, but I can't understand what is allocating that.
Input Code
Unfortunately is confidential :(
Expected behavior/code A clear and concise description of what you expected to
happen (or code).
I'd expect to be able to understand what is allocating these 800Mb of memory
Environment

Python(s): python3.11
Linux ip-172-16-11-13.xxx.el8_8.x86_64 #1 SMP Wed Jun 28 15:04:18 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Possible Solution

Additional context/Screenshots Add any other context about the problem here. If
applicable, add screenshots to help explain.

--native is the answer :)


Cherry-Pick: Lock Pytest to 8.0.2

Issue #, if available: N/A
Description of changes: Cherrypick (#264)
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

/approve

/lgtm


Log command fails,

Log command fails whenever it runs.
Currently on docker 1.12.2-Beta28.
When running amp logs etcd
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x30 pc=0x187ec1]

goroutine 1 [running]:
panic(0x5861c0, 0xc4200120b0)
        /usr/local/go/src/runtime/panic.go:500 +0x1a1
github.com/appcelerator/amp/vendor/google.golang.org/grpc.Invoke(0x8e4f20, 0xc4203805a0, 0x629007, 0xe, 0x5a3700, 0xc4202a3260, 0x5b2a20, 0xc420315880, 0x0, 0x0, ...)
        /Users/jgrahamjones/work/src/github.com/appcelerator/amp/vendor/google.golang.org/grpc/call.go:158 +0x231
github.com/appcelerator/amp/api/rpc/logs.(*logsClient).Get(0xc4200886d8, 0x8e4f20, 0xc4203805a0, 0xc4202a3260, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /Users/jgrahamjones/work/src/github.com/appcelerator/amp/api/rpc/logs/logs.pb.go:118 +0xd2
main.Logs(0xc42033d1e0, 0x9104c0, 0xc42033cb00, 0x1, 0x1, 0xa6b4b, 0x1)
        /Users/jgrahamjones/work/src/github.com/appcelerator/amp/cmd/amp/logs.go:76 +0x604
main.glob..func2(0x9104c0, 0xc42033cb00, 0x1, 0x1)
        /Users/jgrahamjones/work/src/github.com/appcelerator/amp/cmd/amp/logs.go:18 +0x59
github.com/appcelerator/amp/vendor/github.com/spf13/cobra.(*Command).execute(0x9104c0, 0xc42033cac0, 0x1, 0x1, 0x9104c0, 0xc42033cac0)
        /Users/jgrahamjones/work/src/github.com/appcelerator/amp/vendor/github.com/spf13/cobra/command.go:626 +0x443
github.com/appcelerator/amp/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x9106e0, 0xc42026bec8, 0x62935d, 0xe)
        /Users/jgrahamjones/work/src/github.com/appcelerator/amp/vendor/github.com/spf13/cobra/command.go:712 +0x367
github.com/appcelerator/amp/vendor/github.com/spf13/cobra.(*Command).Execute(0x9106e0, 0xc42026bec0, 0x1)
        /Users/jgrahamjones/work/src/github.com/appcelerator/amp/vendor/github.com/spf13/cobra/command.go:671 +0x2b
main.main()
        /Users/jgrahamjones/work/src/github.com/appcelerator/amp/cmd/amp/main.go:79 +0x3b0

Lets make the red cells turn green! Rather than waiting for log events to be generated and queued up, it should be possible to explicitly generate data and then confirm that the data is ultimately received by the client within a certain short time threshold.

I didn't manage to reproduce this behavior neither on tag 0.2.0 nor on master.

Not able to reproduce either (master, Docker 1.12.2 on Ubuntu).
The log looks like the issue we had last week with the stats command failing once in a while.

Unfortunately, it's failing for both @JosephGJ and myself. I'm on the stable version of Docker for Mac (1.12.1) and he's on the beta channel version (1.12.2). Joseph was trying to do some test enhancements, but was blocked by the log tests not passing. As long as you are able to work on augmenting the log tests  and other integration tests per #370, then I guess we're ok.

Is it still necessary to keep this issue ?

Nope!


measure tool issues with some models

In some cases, the measure tool applies to the 3D model surface away from where the user clicks. The measure pins can also be off of the 3D model surface and sitting in empty space.
See these models for example of pins being applied to surface away from where the user clicks:
https://3d-api.si.edu/voyager/3d_package:7e4dcb32-b69c-4905-aca5-05c0bea7019d
https://3d-api.si.edu/voyager/3d_package:d017d594-05fe-4d3f-963c-e9c6fcdaaa57
https://user-images.githubusercontent.com/59068965/167711039-2353bca6-f519-4745-9475-80ed831a37d0.mp4
https://user-images.githubusercontent.com/59068965/167711042-28192495-31ad-4611-87e3-f60e3d2d1dac.mp4
See this model for a dramatic example of pins being showing off the surface of the model:
https://3d-api.si.edu/voyager/3d_package:83043304-8a8b-4d49-af51-9ddc323b5c91

See this model for an example of good/desired experience laying down measure pins precisely where the user clicks:
https://3d-api.si.edu/voyager/3d_package:b64f9c0a-3634-4043-9b1d-a2aaf2823317
https://user-images.githubusercontent.com/59068965/167711095-7916d098-6cf0-41c9-86aa-7d561b1c0c9a.mp4

Fixed in #142


Add option for page title

Adds an option to set the header title of the web page. Defaults to "Streamlit Apps"

Thanks for this!

I have released 0.0.10 including this feature.


2.2.10 版本，什么时候可以发布一个release版本呀

我们鼓励使用英文，如果不能直接使用，可以使用翻译软件，您仍旧可以保留中文原文。另外请按照如下要求提交相关信息节省社区维护同学的理解成本，否则该讨论极有可能直接被忽视或关闭。
We recommend using English. If you are non-native English speaker, you can use the translation software. We recommend using English. If you are non-native English speaker, you can use the translation software. In addition, please submit relevant information according to the following requirements to save the understanding cost of community maintenances, otherwise the discussion is very likely to be ignored or closed directly.
Which Component
eg. Nacos Discovery, Sentinel
Describe what problem you have encountered
A clear and concise description of what you want to do.
Describe what information you have read
eg. I have read the reference doc of Sentinel

在演化一段时间吧，暂时没有具体的 GA 计划。


Switch to numeric component score

After some internal debate, I decided to switch from an enumerated fact type to a range fact type for component scores. The primary driver was that using an enumerated value meant that the user was required to manually create an enumerated fact type with enumeration values that matched what was in the code. This just felt funky...
This PR switches to a range fact type with three ranges (0-20), (20.01-80), and (80.01-100). My goal was to maximize the central range so that we can do something more interesting in the future. I also added project fact type creation during application initialization to remove the manual configuration requirement altogether.

I think the openapi changes from https://github.com/AWeber-Imbi/imbi-openapi/pull/37 need to get into this PR

I think the openapi changes from AWeber-Imbi/imbi-openapi#37 need to get into this PR

I think that I accidentally committed them in https://github.com/AWeber-Imbi/imbi-api/commit/d3116bab864c7b114dea2d9f6a525b66df558747#diff-cf5aaef92a65957d1363e04b9aea031fb8bdd1e3b4e34bf9ba45ee2966147995 🫠


pistol: 0.3.1 -> 0.3.2

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/doronbehar/pistol/releases.
meta.description for pistol is: "General purpose file previewer designed for Ranger, Lf to make scope.sh redundant"
meta.homepage for pistol is: "https://github.com/doronbehar/pistol"
meta.changelog for pistol is: ""
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
/nix/store/29iigfysfv3xcchbwsyvh8h32qhh3zmr-pistol-0.3.2/bin/pistol passed the binary check.
1 of 1 passed binary check by having a zero exit code.
1 of 1 passed binary check by having the new version present in output.
found 0.3.2 with grep in /nix/store/29iigfysfv3xcchbwsyvh8h32qhh3zmr-pistol-0.3.2
found 0.3.2 in filename of file in /nix/store/29iigfysfv3xcchbwsyvh8h32qhh3zmr-pistol-0.3.2

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

4 total rebuild path(s)

2 package rebuild(s)

2 x86_64-linux rebuild(s)
2 x86_64-darwin rebuild(s)

First fifty rebuilds by attrpath
docbookrx
pistol

Instructions to test this update (click to expand)

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

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

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

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

1 package built:

pistol

Maintainer pings
cc @doronbehar @kalbasit for testing.

Result of nixpkgs-review pr 149495 run on x86_64-linux 1

1 package built:

pistol


New Help

Hi Guys, I have doubt how to stop my video when i click the toggle button.

which toggle button ? you can call ' MxMediaManager.getInstance().getPlayer().stop() ' to stop video.

Hi bro, How to auto start playing the video

Hi bro, can you help me , How to auto start the video

You can take a look at the sample code.  call "MxVideoPlayerWidget.autoStartPlay"

This not working to me plz help you
On Mon, 13 May 2019, 11:56 a.m. henryblue<EMAIL_ADDRESS>wrote:

You can take a look at the sample code. call
"MxVideoPlayerWidget.autoStartPlay"
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/henryblue/MxVideoPlayer/issues/19#issuecomment-491691755,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AL65OKQ2JPBRB43KGRQD2WTPVECX3ANCNFSM4HKYZ2GQ
.


web problem

I want to add some C++files, which can't be read in the web project at present. What can I do to solve this problem

Please open a discussion and describe your problem in more detail.


Unexpected token '?'

I am running this example:
import { RateLimiter } from "limiter";

// Allow 150 requests per hour (the Twitter search limit). Also understands
// 'second', 'minute', 'day', or a number of milliseconds
const limiter = new RateLimiter({ tokensPerInterval: 150, interval: "hour" });

async function sendRequest() {
  // This call will throw if we request more than the maximum number of requests
  // that were set in the constructor
  // remainingRequests tells us how many additional requests could be sent
  // right this moment
  const remainingRequests = await limiter.removeTokens(1);
  callMyRequestSendingFunction(...);
}

and i am getting this error:
this.fireImmediately = fireImmediately ?? false;
                                                ^

SyntaxError: Unexpected token '?'

What environment are you running this in?

Fixed in https://github.com/jhurliman/node-rate-limiter/pull/79