List background swaps when scrolling

Hi,
I've just started using play-midnight (the latest version from the chrome web store) and I stumbled upon a small issue with the background color of playlists.
The color keeps swapping (light and dark) when scrolling past the first few songs.
Here's a screencap to visualize what I mean:

That's actually really weird, haha. I just looked into it and I see why, though. Sadly, there's nothing I can do easily (that I know of) to fix that.
It's because I'm doing the zebra stripes (that Google doesn't do) and the way their playlist scroller works, it's actually removing and adding items as you scroll, which is causing the nth-child css selector to swap between as the items get added and removed.
The only way I know to fix it would be to manually add a class to the rows every time you go to a page which would probably just make Play Music slower than it already is. Or possibly add an option to disable zebra stripes.
Also, appreciate the visual reference, super helpful! :+1:

I wouldn't call this a bug - the cause is out of your control. The even-odd class attributes are being added by Googles libs as you scroll, which gives the alternating row styles.
@chrisxclash You could look at the length of the table each time new rows are added and add an empty row if the number of rows would cause a background change

<tbody data-count="34" data-start-index="7" data-end-index="34"> is the important bit. Just watch for changes in data-count, data-start-index, and data-end-index and modify as necessary to prevent the JS from auto-formatting the rows

@geudrik - Yeah, I definitely had that idea in mind, but it seems like overkill for something as simple as zebra stripe styles. I didn't feel the benefit would outweigh the extra JavaScript that would have to watch and swap classes all the time since Play Music is already slow.
It seems really weird in general how they're using a heightened placeholder and just swapping rows, but I can see it be beneficial performance-wise, idk.

\shrug totally understand your hesitance here. I agree that it's probably not worth the extra effort

Haha yeah. I'll keep it open for now as a reminder.
I'm currently in the works of rewriting all my JavaScript anyways, so I'll have to look into it when I'm putting everything else together.

Is there any way to turn off the zebra stripes? I find the swapping when scrolling to be more detrimental to the experience than including them.


ENH: SciPy vs. concurrent Rust for directed_hausdorff

Here is a performance comparison of the serial SciPy implementation of directed_hausdorff against a concurrent Rust implementation I've been working on as a hobby (they pass similar regression tests). %timeit was used for SciPy, while the closest Rust equivalent I could find was used in the Rust benchmark code.

Comments/Caveats

same data used for each implementation; random floats generated with NumPy
Because random shuffling is a key component of the algorithm, in degenerate data sets the parallel implementation would not be able to guarantee the same identical distance indices are chosen (we saw the same issue with the alternative random backend used by serial Pythran)
it is Rust, so I suppose I'd have to rewrite in C++ if we wanted to use a concurrent implementation, leaning on reviewer expertise instead of compiler borrow checker for parallel robustness
I think it makes sense that the single-threaded Rust implementation is slower because the current API design is to use atomic reference counting regardless of the number of threads chosen (to simplify the first draft at least).

So next PyO3 bindings and a Rust dependency? :)

Indeed if cryptography (and soon, the kernel) can pull it off, why not scipy? 🙃
(Though I believe your tongue was firmly in cheek...)


Typing in the editor is very laggy on Linux

Since the 0.10.1 update, typing anything in the editor is very laggy: characters appear with about 0.5 seconds delay and almost never in the same order I actually typed them on the keyboard.
Possibly related: scrolling to the top of a file in the editor triggers a slower top-down refresh of the contents that apper in the editor. I actually see how the code is refreshed like in a bitmap, line by line, pixel-wise.
I'm using Ubuntu Linux 15.10. This problem didn't occur with previous Visual Studio Code updates.
Later edit: I've tested it again on the same computer, but on a 15 inch screen and it works ok, without any lag when typing. Only when Visual Studio Code is on a 24 inch monitor the typing is lagging.

Had test. It won't appear in OS X. How about reinstall VSCode?

I've reinstalled it. The issue is still there.

I can't confirm this issue, typing in visual-studio-code works without any noticeable delay on Arch Linux machine:
Version 0.10.1
Commit df352367df2efcfa9d602d471e4e2f42140a0f05
Date 2015-11-17T15:21:23.766Z
Shell 0.34.1
Renderer 45.0.2454.85
Node 4.1.1

I'm running it in a LinuxMintDebianEdition (in a vm) and do not experience this issue, so it is not a generic Linux build issue.

I've tested it again on the same computer, but on a 15 inch screen and it works ok, without any lag when typing. Only when Visual Studio Code is on a 24 inch monitor the typing is lagging.

I'm assuming that the 15" screen is the display of your laptop and the 24" model should be an external monitor, so which connection do you use for the external one (VGA,HMDI, DVI, DisplayPort)? Can you cross check if this problem persists with any other browser-based editor, g.e. Atom or Brackets.

The 24" monitor is connected via HDMI.
However, I can confirm that the same issue is present in Atom v1.2.2: Laggy on 24" monitor, smooth on the 15" one.

 Maybe your processor is to slow, because Atom as well as VS Code use quite a lot resources.

My laptop's specifications are: Intel Core i5 (model 460M, up to 2.53 GHz), 4 GB RAM, SSD, Intel i5's GPU (even though the laptop has a GeForce GT 325M discrete graphics card, it's not used under Ubuntu Linux).
The issue that I reported never occurred to me before, and I've been using Visual Studio Code since the very first public release.

@eugen-v
What if you use the 24" monitor and resize the VSCode window to be smaller? What if you open 3 editors side-by-side in VSCode in the 24" monitor, and type in one of them... (i.e. is the problem one of the viewport size and the size of the GPU layers?)
How does it work when opening Chrome (you can also help by mentioning the Chrome version you try with) and typing in the editor at http://www.typescriptlang.org/Playground . Do you see such strange differences between the 15" / 24" or the window size?

The editor at http://www.typescriptlang.org/Playground works good in Chrome (Version 46.0.2490.86 (64-bit)) on the 25" monitor.
I get good performance in VSCode in a smaller window on the 24" monitor, even with 3 editors side-by-side.
Interestingly enough, on the 24" monitor, I get bad performance in a maximized window, but good performance in full-screen (even with 3 editors side-by-side).

You mean 15" right?
It's a shot in the dark, but it sounds like bug/performance problem in Unity. If your window is maximized, then Unity doesn't have to render window borders etc.

Nope, I mean 24" :)
I think it's an issue with (large) maximized windows. If I resize a non-maximezed window to be almost as large as a maximized one, the editor's performance is still good.

@eugen-v
Given this only happens on Ubuntu 15.10 when the window is maximized, but it doesn't happen when the window is almost maximized, and also not when in full-screen mode, I'm thinking it is a bug in Chromium...I have found a relevant issue on atom/atom#9724 which again hints this is a problem with Electron/Chromium.
On the Chromium side, I could find this comment which hints Chromium has issues with Intel opensource MESA drivers.

@alexandrudima I've tested VScode on the same computer.
System configuration: (Dell xps 15-9530)
Ubuntu 15.10
Resolution 3200x1200
Intel HD Graphics 5000
Intel Core i7-4702hq
16 GB ram
SSD drive
And the behaviour is laggy when maximized, and fine in fullscreen and non-maximized. Same issue as in atom/atom#9724, so it's probably related to Chromium/electron.

Filed against ubuntu here: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1525207

@leifcr thank you! Keeping the issue open to track the upstream problem.

@egamma Looks like it is a confirmed driver issue of Ubuntu, not of Chromium/Electron

@leifcr thanks you so much!


Make deployment.yaml ignore .ENABLE_CONFIGMAPS|SECRETS vars

This is to fix presubmits. It will be switched back in https://github.com/kubernetes/perf-tests/pull/767

/assign @wojtek-t

/lgtm


Build a minion

Build a minion plugin just to establish how they will work.

Minions will likely have a different execution path.  On configuration they will need to fork a background process to run continuously.  They should also have start and stop functions.  They should be cataloged along with whether they are running or not in the local app instance database.

Done with commit [master 1df165a].  Notes on minion plugins can be found in examples/plugins_template.py


Match the Arcana Todo Icons with the Arcana Card + Change the App's Color Theme

I realize that the Color Theme of my app is still the generic blue. Change it to anything other than that! Also, so that this can be a full pull request, change the Todo List icon to match the color of the Arcana card that it was chosen from. For example, The Bole is green, make the icon in the Todo List also green. Heck, even make the letter in the icon replaced by the card icon itself if you want!

I'll claim this issue.


FEAT: make sql_from_csv externally callable

The util function sql_from_csv is very useful for external use but failed when called externally for its local reference to sql_from_csv_input. The reference is made global.

Hi @pruoff, Thanks for the collaboration. We'll check the tests and merge the PR afterwards.


Support flake8 6.1.0?

flake8 6.1.0 has been released: https://flake8.pycqa.org/en/latest/release-notes/6.1.0.html
Will pyproject-flake8 support the minor version 6.1.0 in the sense of allowing the users to use pip install pyproject-flake8==6.1.0?
Or should the users use pip install pyproject-flake8==6.0.0a1 (which is compatible with flake8>=6.0.0)?

Sorry for the delay, 6.1.0 and 6.1.0a are out.


Add docker-compose file for separate containers.

Demonstrate that this pattern works.
This is based on the example at
https://github.com/fatk/docker-letsencrypt-nginx-proxy-companion-examples/blob/master/docker-compose/v2/simple-site/docker-compose.yml.

Thanks @ryneeverett!

i don't understand why the given example creates two networks :(

@huiwang I only get one -- "nginxproxy_proxy-tier".

@huiwang by example you mean https://github.com/fatk/docker-letsencrypt-nginx-proxy-companion-examples/blob/master/docker-compose/v2/simple-site/docker-compose.yml? that example involves two networks, the external network "nginx-proxy" (has the name "proxy-tier" in the config file) and the default network created by docker-compose named based on project name  ...in this case i would guess  "simple-site_default"
@ryneeverett you sure there is a "nginxproxy_proxy-tier" network? not "nginx-proxy"?

@ryneeverett you sure there is a "nginxproxy_proxy-tier" network? not "nginx-proxy"?

@wader In this PR, yes. But if @huiwang was referencing the single-container example in the README that would clear up the confusion.

@wader and @ryneeverett I thanks for your reply. I'm referring to the example at https://github.com/fatk/docker-letsencrypt-nginx-proxy-companion-examples/blob/master/docker-compose/v2/simple-site/docker-compose.yml
I still don't see the advantage to create two networks.

@huiwang Are you asking about "proxy-tier" vs. "nginx-proxy" in the example? They are the same network but nginx-proxy is the name it was created with prior to running compose (see that project's README). If you look in the diff for this PR I've eliminated the external part so you don't need to create the network manually.

@ryneeverett Indeed, I was talking about proxy-tier vs nginx-proxy. Thx for the clarification, there is indeed only one network.
Regarding the compose file in the PR, I don't find it necessary to specify networks because we are just using the default one. Refer to the section Specifying custom networks in https://docs.docker.com/compose/networking/

Regarding the compose file in the PR, I don't find it necessary to specify networks because we are just using the default one. Refer to the section Specifying custom networks in https://docs.docker.com/compose/networking/

You're right. I just pushed an update.


Add AsPrimitive trait for generic casting with as

This is my personal attempt at #7. It is fairly similar to what can be found in asprim, although implemented from scratch. Please let me know of what you think. Could it use more tests? Should I also leave a safety notice that some conversions with as are currently UB (rust-lang/rust#10184)?

I agree with the conversion from bool to integer types, just punched them in.
I might also add that this implementation has this tiny catch (does asprim have this as well?):
let pi: f64 = 3.1415926535897932384626433832795;
if pi.as_() == 3_u16 {
    println!("All good");
}

The compiler cannot resolve to AsPrimitive<u16> here, because there could be another AsPrimitive<T> where T: PartialEq<u16>. Making it explicit or performing the comparison the other way around works.
let pi: f64 = 3.1415926535897932384626433832795;
if 3_u16 == pi.as_() {
    println!("All good");
}

Just a heads-up: I forgot to add a Safety section the other day, so I added it now. What do you think?
I configured the new doctests in the description to be ignored, although they compile fine. I'm not sure whether testing whether it's important to compile some UB-inducing code.

Lgtm. Give it a thought -- is this an interface that others can implement, should they, or should they not? Documenting that rule would be good. Most probable rule is that the impl is only "admitted" if there is an corresponding as cast.

As always, the best method for implementation isn't necessarily the best interface for calling. Trait into incidentally also has this problem. What I think of as the best interface for calling is something that admits foo.as_::<NewType>()

Thanks for the feedback, @bluss.

Give it a thought -- is this an interface that others can implement, should they, or should they not? Documenting that rule would be good. Most probable rule is that the impl is only "admitted" if there is an corresponding as cast.

Agreed. It's hard to imagine good use cases for external implementations, though. Would it be for primitive newtypes (say, struct Foo(u32))? I wonder if expressions such as (5.0).as_().into() can be resolved unambiguously.

What I think of as the best interface for calling is something that admits foo.as_::(). AsPrim has that, incidentally, but it has the other drawbacks of that.

Yep, I am aware of this issue. This sounds like a blue-red pill decision between having more possible conversion sources/targets (char and bool) or having a better user-facing API. Whichever is more appealing to the community, I'll make the necessary changes if need be.
On the other hand, given that asprim seems to be well maintained right now, choosing to keep this API here would give users the power to choose either one as they wish (or both, but that would be pointless and just terrible 🙃).

The noisy_float crate comes to mind as an example that might implement this.


Tab Removal only by admin

Can we disable removing the tab based on user context. i.e. Only allow admins to remove the tab not the user. I tried doing it based on the context but it enables the remove button after 5 seconds on its own.

What do you mean by admin user here?
If you mean team owners then it is available as part of team setting:


SlickToGo not working on cloned slide

Hello!
I have a slider defined as follows:
slider1.slick({
				arrows: true,
				dots: false,
				centerMode: true,
				slidesToShow: 2,
				slidesToScroll: 1,
				variableWidth: true,
				asNavFor: '#slider2,
});

This displays a list of several slides and one is centered. A click event has been added on each slide which use the 'slickGoTo':
$('#slider1 img').click(function() {
				var pos = $(this).parent().attr('data-slick-index');
				slider1.slick('slickGoTo',[pos, true]);
			});

The issue we have is that when clicking on elements located at the left (cloned element) on the center element (just after initialization), nothing happen (means no slide). With console.log, I verified that the click was attached to all elements (cloned and non-cloned).
Any idea on the cause?
Thx in advance.

Hey I'm going to close this because there's no fiddle, and it's kind of a support request but if you still feel like it's an actual bug you can whip it up in a fiddle.  For implementation help stack overflow is a safer bet. Thanks @ldecoker


Added polars engine to load data faster!

Added a polars engine to load data faster.

I kind of feel like we should just get rid of the csv files and turn them into parquet files and rewrite this so we use less memory and also load them more quickly in both pandas and polars. But we can discuss if there is a preference for keeping these as csv for some reason. It just is less effecient.

I agree. I just did that to
Get some data in there but in reality we should load in parquet and that will avoid the need to format date columns as date.


Error after installing via pip

Got this error when trying to run freshen -i after installing using pip:
ModuleNotFoundError: No module named 'yaml'

Hello!
It appears I forgot to realize that the yaml parser I used was not built-in. This issue is really easy to fix however, simply run
pip install pyyaml
and it should work. I will add this on the README so this confusion won't happen again.


[modify] hide cms columns form mobile size check when mobile disabled

Coverage decreased (-12.1%) to 72.57% when pulling 6323bec80b0d485f5d79e72fb138d750f80ec842 on HiraiY:fix/hide_mobile_size_check_when_mobile_state_disabled into d89912b6b11d83cd12ddc78fb771da19b22b0289 on shirasagi:master.


BindingPattern can't be marked optional using question mark in implementation signature

In the section <IP_ADDRESS>:

A parameter can be marked optional by following its name or binding pattern with a question mark (?) or by including an initializer. Initializers (including binding property or element initializers) are permitted only when the parameter list occurs in conjunction with a function body

However, following code:
function d1([a,b,c]?) {}  // Error; binding pattern parameter can't be optional in an implementation parameter
function d1([a,b,c]?);  // Allow

We should update the spec to indicate this difference because by only indicating that "A parameter can be marked optional by following its name or binding pattern with a question mark" is a bit misleading since it is only allow in non-implementation signature

❗
This would be ridiculously useful! 😃
I have no idea how to submit a PR for this issue, but would be more than willing to put in the work if someone could give a little guidance!

Just realized it is possible to accomplish this!  Just use the following:
function d1([a,b,c]=[]) {}

This issue could probably be closed, unless I'm missing something else.  (Which I might be 😉 )

Why was this issue closed without explanation?


Assignment1/linus

Finished basic CRUD functions for Assignment 1. @SeekSaveServe, please review!

I'm not sure if we have to support images, because some of the problem descriptions contain images.
If so, frontend has to implement a way to upload images 🤔


[WIP][RHCLOUD-18182] Database DAO for authentications

This PR:

Creates a new config option, "VaultOn", which gets set to true if the VAULT_ADDR environment variable has been set.
Creates a database DAO to query the authentications table.
Adapts the response depending on whether Vault is online or not. The only difference in the model is the ID field, which will either be filled with Vault's ID or the database's auto generated ID.

Links
[RHCLOUD-18182]

Ok I'd like to get this moving - if the tests are the problem lets just remove them so we can get this merged. That way we're one step closer to doing the cutover.


Automatic cancellation support for Promises

I have been working with abort signals and the biggest issue in practically using it was to make sure that all the pieces of code i wrote pass-on the signals properly. Missing on passing meant that a whole part of my code could be cut-off and it is rather stressful to test all the edge cases.
This made me think of an extended API that could make the process a lot easier: Assuming we had a .cancel(token: CancellationToken): this and a means to name a given token for the Promise it could be possible to create nice zones for promises:
// the @-token is to declare a "token" variable for the foo scope.
async@token function foo () {
  token.throwIfCancellationRequested()
  // Note that the signal is not specifically passed on here
  await bar()
}

const source = new CancellationTokenSource()
await (foo().cancel(source.token))
<EMAIL_ADDRESS>foo() // syntax sugar for the previous operation

await foo() // could automatically connect to the process closing signal of node.

async function bar () {
  // Even without specifying the signal, the
  await baz()
}

async@myvarname function baz () {
  // Using a non-conflicting variable name
  myvarname.throwIfCancellationRequested()
}

This could be built in with Promise.race where the promises after the first promise get automatically cancelled.

This seems to conflate the two distinct uses for "cancellation" - "registering disinterest", ie, an unthen method; and "aborting the work".
An individual Promise is supposed to confer no privileges except reacting to the final fulfillment - as such, a cancel method on Promises would imo be inappropriate, except perhaps as an unthen (ie, promise.then(f); promise.unthen(f);)

Yes, there is an ambiguity in the intent. Is it just disinterest or an active cancellation. Though I don't see how this distinction has an impact for the implementor. The implementor just needs to make sure that the work is stopped in either case.
How else would this distinction have impact?
As for the "cancel" naming: yes this should be called differently. I didn't find a better name but I generally meant to illustrate that instead of the syntax sugar this could also be a method. unthen seems better.

The only thing a method on a Promise should do imo is "unthen" - which should not notify the creator of the Promise, for example.

@ljharb for what it's worth that issue is pretty simple and can be addressed:

Async functions perform an action, so cancellation and aborting them makes sense.
Promises are just a result + time, so disinterest makes sense but actually aborting actions makes less sense since there is now a notion of a "promise's underlying value obtaining mechanism". I agree that breaks the abstraction.
Async functions return a Promise and await promises (well, thenables), so it is impossible to return extra information about cancelling an action on them without violating the "just a value" semantic of promises.

If these async functions returned something that is not a Promise but is either a subclass (worse) or a thenable but not a subclass (better IMO because LSP) we wouldn't have an issue:
Specifically in the context of this proposal:
async function foo() { } // calling this returns a Promise
async@token function foo () {} // calling this returns a CancellableTask

With a CancellableTask not having the same "promise" expectation, and awaiting a CancellableTask in a regular async function making it fall-back to a regular promise (just because it's a thenable.
No promise functions would be "cancellation aware", no user expectations regarding promises would change and this would strictly be an extension.
Note: I am not saying TC39 should do this, that this is how cancellation should proceed or that I think this is a Good Idea™. I am also not saying that the fact a Promise should contain only value state is fact (it's an opinion I sometimes hold too) nor that it's consensus (it is however a valid concern IMO).
I am only trying to explain how we can reconcile cancellation with that constraint with the discussion :]
As a side note,

I agree that syntax to make an otherwise async function return a cancellabel Task instead of a Promise would address the issues i mentioned in this thread (not endorsing that idea necessarily either).

While I agree with:

An individual Promise is supposed to confer no privileges except reacting to the final fulfillment

I disagree that implies they shouldn't be cancelable, in fact given Promise is the primary mechanism for asynchronous operations in the spec, if cancellation is added then Promises should be cancelable.
However I don't think someone who has reference to a Promise should be able to cancel it. I think cancel() should be something controlled by whoever creates the Promise.
For example in the Promise constructor:
function delay(time, cancelToken=null) {
  return new Promise((resolve, reject, cancel) => {
    const timeout = setTimeout(resolve, time);
    cancelToken?.register(() => clearTimeout(timeout));
  });
}

This is basically the status quo with AbortSignal, however I think it'd be good if cancellation signals automatically propagated through the call stack.
For example through the new metaproperty like function.cancelToken:
function delay(time) {
  const cancelToken = function.cancelToken;
  return new Promise((resolve, reject, cancel) => {
    const timeout = setTimeout(resolve, time);
    cancelToken?.register(() => clearTimeout(timeout));
  });
}

async function dobuleTimeout() {
  await delay(1000);
  await delay(1000);
}

const { cancelToken, cancel } = CancelToken.create();
const doubletTimeoutPromise = doubleTimeout.start(cancelToken);

// Some time later, this can abort whichever delay is currently happening
cancel();

If you already hold the reject(..) capability for a promise, why do you need a separate cancel(..) capability?
Are you implying that consumers of a promise need to be notified of a promise cancellation distinct from a rejection, and thus we need to extend promises with a third final-state and accept a third callback to .then(..) (and/or expose a canceled(..) convenience method like catch(..))?
I've done an awful lot of cancellation (via AbortController tokens) propagated through as promise rejections over the last 2-3 years (via my CAF lib), and I've been quite happy to signal this cancellation via specific error classes/messages (as the promise-rejection reason) and then try..catch them as needed up the call-stack.
This has been totally sufficient so far; I haven't come across any need to split a promise into a third final-state. Am I missing something other than a light semantic flourish driving that?
Furthermore, if promise-cancellation didn't map to synchronous-flow-control as a catchable exception, then try..catch itself would need to be extended to declaratively handle this third state to preserve the strong trend of async..await style sync-async flow control (over promise chains).

If you already hold the reject(..) capability for a promise, why do you need a separate cancel(..) capability?

I'm ambivalent as long as there's a concrete way of detecting a cancellation reliably from other errors. Personally I'd be a fan of just seeing CancellationError and the DOMException for abort just inheriting from it.

Magical propagation of cancel tokens through the call-stack is cool (function metaproperty, etc). But I don't see why promises themselves need to be changed in any way to support cancellation. A promise rejection can carry whatever sort of cancellation "signal" you want.

But I don't see why promises themselves need to be changed in any way to support cancellation.

Mostly I was meaning that Promises themselves should contain the cancellation (whether through another state or not I don't really care), rather than some other abstract thing like the proposed Task in another comment.

@Jamesernator i agree only the creator of the promise should initially have the ability to cancel anything; i'm saying a Promise instance method wouldn't achieve that.

@Jamesernator I think there is little point to arguing for promise cancellation with the Promise type when we can reconcile the concern by not putting it on the promise type.
If you look at my comment https://github.com/tc39/proposal-cancellation/issues/28#issuecomment-609052378 I think we can reconcile these concerns so everyone wins.

@getify

This has been totally sufficient so far; I haven't come across any need to split a promise into a third final-state. Am I missing something other than a light semantic flourish driving that?

That's a valid concern. Mostly, using rejection for cancellation semantics can be dangerous at times. We used to call this the "don't wake me up" criterion" in the old proposal.
Let's say I have an async action:
async function cancelMe(token) {
  try {
     await someAsyncAction(token);
  } catch (err) {
     instrumentation.track(err);
  }
}

If the token is cancelled, the } catch { is hit and the instrumentation is updated. Now every single catch block needs to guard against cancellation exceptions - and worse: catch clauses with await might cause finally blocks to not run.
Is this terrible or worse than no cancellation? Not really, it would still be an improvement.
Did I suffer using languages that picked this design? Yes, it actually did in fact wake me up at night once or twice when Cancellation errors made their way through the instrumentation.
If we look a bit at other languages - C# does reject semantics - that has multiple issues (like triggering catch blocks) but is better than not doing anything.
F# does what Martin's proposal suggests - it checks cancellation tokens automatically at every await (well, do!) - if it was cancelled a CancellationException is thrown (so a bit like your proposal). I encourage you to check out F# cancellation to see how it behaves   :]
Several places in JavaScript (namely generators) already have third state.
To sum up my opinion:

Third state is probably a good idea. It is useful so that non-exceptional cases don't go through exceptional flows and end up triggering instrumentation.
Not having third state is not terrible and is still probably better than no cancellation. We have examples of languages with similar cancellation semantics without this proposal (like C#) and with this proposal (like F#).
Whether or not we want to have third-state is probably a trade-off between correctness and simplicity. Having fewer states is easier while having states that incorrectly map the user expectation is more "correct". I don't think there is a a right answer here.
If we look at historical data when tools had a choice they switched from reject semantics to third state (I can share some insights from bluebird if that helps).
I don't think anyone is pursuing third-state anyway at this point - so probably better to focus on two-state less-correct-but-simpler cancellation in the context of Martin's proposal.

Okay, this discussion quickly swung in a lot of directions. First off big 😍  for the lots of responses here. In an attempt that probably leaves me sweating tonight let's see if I can address all the issues in an order that could in the end somehow make sense. 😅
(I am sorry for the length. I spent all day writing on it, don't know how to shorted it further and am running out of time. 😢 )

if these async functions returned something that is not a Promise but is either a subclass (worse) or a thenable but not a subclass (better IMO because LSP) we wouldn't have an issue:

Thank you @benjamingr for coming up with this example:
async function foo() { } // calling this returns a Promise
async@token function foo () {} // calling this returns a CancellableTask

this could be very agreeable to implement, and as a short note I think we would run into the question to do either type-check the result of await bar() to see if the token can be passed-on or not or we need to specify this with every await@token call manually.
However, what makes this approach very problematic to me is that all sub-operations of the given promise may never become cancel-able tasks as @Jamesernator illustrated nicely in the "delay example".

I think there is little point to arguing for promise cancellation with the Promise type when we can reconcile the concern by not putting it on the promise type.

Passing a token to a async function or Promise replaces an API with an convention. The convention of passing-in the token is prone to ...

... manual errors: people forgetting to pass down a token, pass the wrong token or name it badly
... problem invisibility: as it is optional to pass a signal, not passing it is a valid case
... purposeful ignorance: some users may not need the tokens but underlying api's support it

Most of my proposal was supposed to focus on preventing to manually passing down that token to all sub-operations. @getify notes:

done an awful lot of cancellation (...) propagated through as promise rejections over the last 2-3 years...

but propagating those rejections is only one direction, passing the signals down the chain is the harder issue to me. I like to avoid two different return types for await and await@token and because of that am trying to see if alternative routes can be better.
With this in mind, looking at the alternative syntax proposed:
async function dobuleTimeout() {
  await delay(1000);
  await delay(1000);
}

here dobuleTimeout does not specify the cancellation-control of the two promises created. We are assuming that there is a pass-through happening here. I also assume that the await is just coincidental. This should be functional(, right?):
async function dobuleTimeout() {
   const p = delay(1000)
   await p
   await delay(1000)
}

... and that would mean that every call inside of dobuleTimeout would pass the cancellation-context to every subsequent call! And, even more troublesome, the question arises: Is this also true for regular functions?
function dobuleTimeout() {
   return delay(1000).then(() => delay(1000))
}

Does it pass on the context similarly? Or do I need to manually operate here?
function dobuleTimeout() {
   const ctx = function.context
   return delay.start(ctx, 1000).then(() => delay.start(ctx, 1000))
}

My assumption again is that it should also work for non-async functions as well. As such, we are talking here about a "general function context" or "domain" which could also be implemented as a general-purpose context like dobuleTimeout.start({[cancelSymbol]: token}).
This might have a slew of horrible side-effects. I tried to avoid this a scary concept as these side-effects are generally hard to identify (debugging hell?!) and I am not sure if its worth the risk.

Another (smaller) thing I wanted to avoid is this:
cancelToken?.register(

as this means that there might be the possibility for the .cancelToken to not exist, which could result in (unnecessary) null errors. Using an optional parameter could make sure that those tokens are only created if necessary by the implementer:
async@token function foo() {
   token.register(...)
}

async function bar () {
   // Doesn't use the token, token is not created.
}

Having it be a separate async syntax also highlights that this only affecting the async/Promise system and does not interact with general function calls. Regular Promise instantiations would have it as third argument:
new Promise((resolve, reject, token) => {})

this could avoid the aforementioned debugging hell by moving the magic from a function call to the await operation with a utilizing the token of every promise. We would only need to "link" those tokens up to create the same conceptual domain.

If you already hold the reject(..) capability for a promise, why do you need a separate cancel(..) capability?

Sorry for the confusion, in my initial proposal I was trying to suggest that the inappropriately named .cancel method would do following that has nothing to do with reject:
function cancel(token) {
   bindTokens(token, this.token)
   return this
}

where bindTokens would connect the cancel call to the promises token:
const p = delay(1000)
const { cancel, token } = createToken()
bindTokens(token, p.token) // p.token and token form a graph, cancel will also inform the promise's token - this is a domain

Promises would need to pass it on manually, to keep the magic small.
new Promise((resolve, reject, token) => {
  const otherPromise = doAsyncThing()
  bindTokens(token, otherPromise.token) // very rare case
  otherPromise.then(resolve, reject)
})

Note on naming
I chose bindTokens as it is quick to write and easy to read. But it should probably be something like CancelToken.connectTokens(token, p.token).
Also bindTokens is a functional implementation. This could be a member operation of cancelToken, e.g. token.addChild(p.token).
I went with a placeholder .token variable name here. Probably something like .cancelToken or even [CancelToken.symbol] would be better.

@Jamesernator

I think cancel() should be something controlled by whoever creates the Promise.

Honestly, I hadn't thought of this. Thank you for pointing it out!
To make sure that the creator stays in control, bindTokens could be a one-time operation; throwing an error if that token was already bound.
const p = delay(1000)
const { cancel, token } = createToken()
bindTokens(token, p.token)
bindTokens(createToken().token, p.token) // throws CancelTokenBindError() - or something like that

Note: An additional function bindTokenIfUnbound could be neccessary, as this is how await is supposed to behave.
@ljharb

The only thing a method on a Promise should do imo is "unthen" - which should not notify the creator of the Promise, for example.

I didn't understand the purpose of unthen in the first comment. This has cleared it up quite a bit. Thanks!
If I understand you right then unthen means to achieve that the system could clean up memory and drop certain operations as they become unnecessary (no one awaiting the response).  an operation that an operation like this does have benefits, but I was solely concerned with cancel here. I think with the one-time binding it should be cleared that I only meant the cancel case and not the un-registration.

Are you implying that consumers of a promise need to be notified of a promise cancellation distinct from a rejection, and thus we need to extend promises with a third final-state and accept a third callback...

My naming might have caused this confusion: I am sorry 😓 . The third state should imo. be a separate discussion.

here dobuleTimeout does not specify the cancellation-control of the two promises created. We are assuming that there is a pass-through happening here. I also assume that the await is just coincidental. This should be functional(, right?):
Does it pass on the context similarly? Or do I need to manually operate here?

Yes, it would simply pass it down the stack, everything on the call stack gets the cancelToken.

As such, we are talking here about a "general function context" or "domain" which could also be implemented as a general-purpose context like dobuleTimeout.start({[cancelSymbol]: token}).

This might have a slew of horrible side-effects. I tried to avoid this a scary concept as these side-effects are generally hard to identify (debugging hell?!) and I am not sure if its worth the risk.

The idea of this is only propagate cancellation, as such to avoid people abusing it as a general purpose context function.cancelToken should be a different object in each frame on the call stack. Which is to say, they cannot be used to share data:
function b() {
  console.log(function.cancelToken.foo); // undefined
}

function a() {
  const { cancelToken } = CancelToken.create();
  cancelToken.foo = 'foobar';
  b.start(cancelToken);
}

Which is to say, they cannot be used to share data.

Thank you for adding this! It is a neat solution and makes that approach feel significantly better! But it doesn't resolve my fears of a slippery slope here. Once people see that this way of passing down control for cancelTokens, other side-effects might be added using the same route which might be less considerate.

@martinheidegger

to see if the token can be passed-on or not or we need to specify this with every await@token call manually.

However, what makes this approach very problematic to me is that all sub-operations of the given promise may never become cancel-able tasks as @Jamesernator illustrated nicely in the "delay example".

Thanks for the detailed response :]
To clarify, the semantics I envisioned reconciling this proposal with the expectation of promises not carrying state about their originating operation is:

Cancellation propagates automatically in AsyncFunctions. I'll go over an examples and how it works below.
Cancellation does not work with regular promises at all, it is impossible to "cancel a regular promise". In addition once you go through a promise combinator the result of that is not cancellable unless you explicitly went through CancellableTask.
You never have to write .register or pass tokens explicitly.

// here doubleTimeout is an asyncFunction with a token, so it returns a CancellableTask
// and not a regular promise
async@token function doubleTimeout() {
  // if delay returns a CancellableTask, it is cancelled automatically when doubleTimeout is and
 // invoking it automatically passes the token inside.
  await delay(1000);
  // if delay returns a regular promise, doubleTimeout is exited after cancelling but nothing
  // happens to the promise itself, except perhaps `unthen` if we choose to do that.
  await delay(1000);
}

Note that in this sort of design the token is determined based on being called in an async function with a token and not by awaiting.
In:
function dobuleTimeout() {
   return delay(1000).then(() => delay(1000))
}

I would recommend not supporting cancellation propagation of promises at all and sticking to async functions - but in the above case since no token is passed to the function dobuleTimeout is only "as cancellable" as delay inside it and is not "cancellation aware" (it's just a regular function - that didn't change). In the above case the question is "does chaining thens preserve cancellation/token and does that token pass to delay".
I would not pass the token to delay above (eventhough technically it is possible since we know what the token is and we can chain them automatically) because I think that complicates things significantly when dealing with assimilation and that's not the "interesting" case for most people who use async functions and need to cancel.

Just throwing this out there, but it'd be cool if we could pass a token as the third argument to .then which would enable the promise to listen to it for cancellation if it could / do nothing if it can't.
It'd be cool if thennables that support this third parameter could then pass it on to any calls to .then that they make.
So when you call an async function, you can pass the token to .then or automatically do it if you're an async function that got a token passed to it already.
This approach probably doesn't work too well for sync cancellation though since there could be a bit between calling the function and invoking .then where no token is present for the function to pass to it's own invocations of .then. 🤷
Maybe there could be a token created internally and it's listening on any subsequent calls to .then?
Oh jeeze, if two places are listening on a promise I'd imagine you wouldn't want the cancellation of one to affect the other. I guess that's why unthening is the safest option. 🤔

@ljharb How is disinterest anything other than cancelling a request to retrieve a value? You're already effectively scheduling a job to retrieve that value by using .then (which is a lot of ceremony for just retrieving a value IMHO - it's not a simple .getValue() method call, and the spec internals make that clear in painstaking detail), and cancellation could be arguably viewed as cancelling that request (or cancelling the reaction job, in ES spec speak).

@isiahmeadows disinterest is "go ahead and finish the work, i don't care, don't notify me when you're done". Cancelling is "stop the work!".
A Promise represents a placeholder for a future value for work that has already begun.

I wish there was a way to determine how many usages of userland "cancellation" semantics on promises are about affirmative cancellation vs just disinterest. My intuition (based mostly just on some anecdotal observations in different code bases) is that the later is greater than the former. But it seems like if there was any way to gather evidence like that, it would help inform the design decisions here. If the majority use-case is actually dis-interest, unthen(..) might be enough.

@getify I agree with your intuition, and "disinterest" is something that wouldn't violate any mental models around Promises - but "abort the work" is something that only the creator of the Promise must be able to control (or, ofc, explicitly delegate).
The trick with .unthen is that const b = a.then(c) doesn't actually mutate a, so a.unthen(c) wouldn't make any sense. b is a brand new promise, so what would b.unthen(c) do? Would it just make sure b never settles? What about if someone had done const e = b.then(d); b.unthen(c) - would e also never settle? or would e silently "become" a.then(d)?

@ljharb I didn't dispute that. But cancelling your request of that data is showing disinterest to it. I feel you're looking higher level than I am - I'm looking at what .then does, not what the promise itself does. And I agree with you it shouldn't affect promise resolution - that's not what I'm talking about.

The trick with .unthen is that const b = a.then(c) doesn't actually mutate a, so a.unthen(c) wouldn't make any sense. b is a brand new promise, so what would b.unthen(c) do? Would it just make sure b never settles? What about if someone had done const e = b.then(d); b.unthen(c) - would e also never settle? or would e silently "become" a.then(d)?

a.then(func) does mutate a if it's pending - see step 9.a/9.b of PerformPromiseThen. That's how the value is propagated. And here's the semantics I'd expect of both cancellation and of a conceptual .unthen method:

Cancelling a.then(c), if c was not yet invoked, would result in b never resolving, as the promise reaction that would eventually resolve b would never end up executing.
Cancelling a.then(c), if c was already invoked, would observably do nothing as the job to cancel was already executed and b either is already being resolved or was already resolved.
Cancelling b.then(d) would not do anything to a.then(c), as a and b are different promises, and cancellation would only mutate the immediate promise itself.
When a.then(c) is cancelled and c was not yet invoked, c can be dereferenced as well as everything b references, avoiding a whole class of associated memory leaks with it.

And BTW, using cancellation would make useless things like b.unthen(c) and a.unthen(d) unrepresentable, so that's a question that wouldn't need answered. It also avoids the question of what to do in cases like this, as it doesn't have any knowledge of the function to be invoked (or even the resulting promise, for that matter):
const p1 = a.then(foo)
const p2 = a.then(foo)
a.unthen(foo) // ???

@getify

I wish there was a way to determine how many usages of userland "cancellation" semantics on promises are about affirmative cancellation vs just disinterest.

Maybe a poll? Also, it might be worth doing a couple things special in that poll:

Make it clear you're not talking about the new Promise(...) stuff and similar, only p.then(f).
Allow people to specify both disinterest and cancellation independently of each other, not just leaving it as a binary option (as some, like me, would likely consider the two to be synonymous and would respond accordingly).

It doesn't mutate it in a way that's observable. You can't tell, in your example, whether a got a then callback or not (for the purposes of this discussion, unhandled rejection hooks don't exist, since engines aren't required to implement them)

@ljharb You can observe such cancellation asynchronously very easily by taking advantage of callback order:
let handlerRemoved = true
let child = a.then(() => {
    handlerRemoved = false
})
runWithDifferentCancelToken(() => {
    a.then(() => {
        console.log(handlerRemoved)
    })
})

While it can't be observed synchronously, cancellation isn't just for things that start synchronously - it's just as useful for aborting multi-step asynchronous tasks that otherwise run in the background.

Let me rephrase :-) short of the promise settling, you can't observe it.
The word "cancel" continues to conflate the two separate concepts - whether it's useful to abort multi-step async tasks isn't in dispute, but whether it's feasible to allow that in the Promise security model is.

I can ask Node to run a survey though we just ran one for unhandledRejection.
Anyway I didn't realize abort semantics were even on the table. I thought that disinterest semantics were consensus as abort semantics are dangerous.
That's why bluebird switched to disinterest like 5 years ago.

I suspect you're right. Unfortunately it's very difficult to use the word "cancel" and not create confusion as to which semantics are being described :-/

Long time lurker here who'd like to add some thoughts to this discussing but I should ask permission first. Would that be ok?

I'm coming from C# background and I've been using token-based cancellation in .NET ecosystem since it was introduced there. It might not be perfect, but it has worked really well for us, and I just had to replicate it for JavaScript-based projects.
As many others, my naïve implementation allows to pass a cancellation token to the promise constructor.
Gist and RunKit (using Prex for its CancellationToken and Deferred):
class CancellablePromise extends Promise {
  static get [Symbol.species]() { return Promise; }
  // ...
  constructor(executor, token) {
    executor({
      resolve: value => deferred.resolve(value),
      reject: error => deferred.reject(error),
      token: linkedToken
    });
  // ...
  }
}

An example of use:
// await new Delay(1000, token)
function delay(delayMs, token) {
  return new CancellablePromise(r => {
    token.throwIfCancellationRequested();
    const id = setTimeout(r.resolve, delayMs);
    r.token.register(() => clearTimeout(id));
  }, token);
}

Or:
// await new Delay(1000, token)
class Delay extends CancellablePromise {
  static get [Symbol.species]() { return Promise; }

  constructor(delayMs, token) {
    super(r => {
      const id = setTimeout(r.resolve, delayMs);
      r.token.register(() => clearTimeout(id));
    }, token);
  }
}

A child linked token source is created inside CancellablePromise and its token gets passed to the executor function. This way, if CancellablePromise is used, the executor never gets a null token. Moreover, the executor's logic doesn't have to clean up the linkedToken.register() registration, if it decides to take advantage of it to abort the actual operation.
Then CancellablePromise gets automatically rejected with CancelError if the parent token is signalled, but not before all linkedToken.register() callbacks have been invoked.
If it's chained via await, we don't have to worry about continuations, as CancelError will be thrown and it will break the chain:
await new Delay(1000, token)
await somethingAsync() // might not get here

If chained via then, it's IMHO the responsibly of the continuation code to observe cancellation:
new Delay(1000, token).then(value => {
  token.throwIfCancellationRequested();
  return somethingAsync();
}, error => {
  throw error;
})

This way, we don't introduce something controversial like Promise.cancel(), but the promise will still be automatically cancelled when the token's source is cancelled. I believe that's close enough to the "disinterest" concept being discussed in this thread. However, the promise's executor logic still gets the chance to abort the pending operation it has created and clean up properly.
As a developer, If I create an API that can naturally be cancelled, I'd choose CancellablePromise. Or I could also use it to wrap an existing API that doesn't support cancellation, to emulate cancellation in the "disinterest" way.
I'm pretty sure something like this has been discussed before. If it was decided against, I'd interested to know why.
Thank you.

@benjamingr

Anyway I didn't realize abort semantics were even on the table. I thought that disinterest semantics were consensus as abort semantics are dangerous.

Yeah, I was also confused when that was assumed by @ljharb, and that's probably what led to the communication disconnect between us. My bad - I should've been way clearer in that I was specifically not referring to cancelling the original promise, only .then scheduling its reaction job for removal upon cancellation.
@ljharb

The word "cancel" continues to conflate the two separate concepts - whether it's useful to abort multi-step async tasks isn't in dispute, but whether it's feasible to allow that in the Promise security model is.

If it helps, here's what I'm thinking:
function delay(ms) {
	return new Promise(resolve => {
		const timer = setTimeout(() => resolve(), ms)

		// In this case, we're cancelling the timer and leaving the promise resolved,
		// something already well within scope of the proposal
		onCancel(() => clearTimeout(timer))
	})
}

// Think of this as like a spec implementation.
function PerformPromiseThen(promise, onFulfilled, onRejected, resultCapability = undefined) {
	let promiseData = getInternalData(promise)

	if (promiseData.state === "pending") {
		let fulfillReaction = new PromiseReaction({
			type: "fulfill",
			handler: typeof onFulfilled === "function" ? HostMakeJobCallback(onFulfilled) : undefined,
			capability: resultCapability,
		})

		let rejectReaction = new PromiseReaction({
			type: "reject",
			handler: typeof onRejected === "function" ? HostMakeJobCallback(onRejected) : undefined,
			capability: resultCapability,
		})

		promiseData.fulfillReactions.push(fulfillReaction)
		promiseData.rejectReactions.push(rejectReaction)

		// Cancel the reaction directly - no need to notify anyone.
		onCancel(() => {
			promiseData.fulfillReactions.splice(
				promiseData.fulfillReactions.indexOf(fulfillReaction),
				1
			)
			promiseData.rejectReactions.splice(
				promiseData.rejectReactions.indexOf(rejectReaction),
				1
			)
		})
	} else {
		let reason = promiseData.result

		if (promiseData.state === "fulfilled") {
			reaction = new PromiseReaction({
				type: "fulfill",
				handler: typeof onFulfilled === "function"
					? HostMakeJobCallback(onFulfilled)
					: undefined,
				capability: resultCapability,
			})
		} else /* if (promiseData.state === "rejected") */ {
			if (!promiseData.isHandled) HostPromiseRejectionTracker(promise, "handle")
			reaction = new PromiseReaction({
				type: "reject",
				handler: typeof onRejected === "function"
					? HostMakeJobCallback(onRejected)
					: undefined,
				capability: resultCapability,
			})
		}

		let {job, realm} = new PromiseReactionJob(reaction, reason)
		HostEnqueuePromiseJob(job, realm)

		// Cancel the promise reaction job - the host may do anything it wants provided
		// the job is never invoked.
		onCancel(() => {
			HostCancelPromiseJob(job, realm)
		})
	}
}

The former, delay, is obviously userland, but the latter is a rough semi-optimized JS approximation of that spec algorithm. And adding in the onCancel calls in each of those (that function being hypothetical, of course) is concretely what I'm suggesting here.


Cannot export keys with p256 plugin

Context
I'm trying to use the EcdsaKeyPair as a utility to generate a stable keypair. For testing purposes I'm:

Creating a keypair with exportable = true
Exporting that keypair
Loading the private key so I have a stable key to reuse across tests / experiments

This works fine using the EdKeypair, but fails with "key is not extractable" when using the p256 plugin.
I believe the problem is that, when creating a new key, the static method does not allow you to specify exportable and hardcodes the extraction parameter to "false" when creating the key.
I have a PR that addresses this issue that I will reference here.

On further inspection it could be that I'm misunderstanding the use of the methods on this class. With the provided fix, I can successfully export the key, however it exports it in pkcs8 format. There doesn't seem to be a symmetrical way to import this key material. The import function uses the jwk format instead of a raw format. In order to make this change useful, we would need to also add an importFromRaw type of method to this class. This may start to diverge from the original intent of these classes. Happy to add if it makes sense.


In certain cases underscore in text strings is causing italics

See
https://ux-dev.data.humancellatlas.org/releases/2020-mar/methods#cell-type-annotations

See the markdown for that.
https://github.com/HumanCellAtlas/data-portal/blob/ux-dev/content/releases/2020-mar/methods.md
"cell" is not meant to be in italics.  It's apart of the label and has an underscore.
There may be some funny character in the markdown file? Or... github seems to display the markdown file ok tho.

Let me look at this for a bit...

We will put the offending file names in code blocks to prevent this.


Audio desynchronized when using framerate jitter alternative fix.

What it says in the title. When I play the game without any fix the sound is perfect but the framerate keeps switching between 60 and 30 like crazy, it's unplayable. Using the 30fps cap from this mod, whenever I start a new game or load a save, I get stuck in the loading screen forever. Using the alternative fix I get 58/59 fps and it plays great, but on cutscenes the voices get completely out of sync.
Also, no matter what I do, I can't get into the in game options menu. Game stops working and I have to Ctrl alt del out of it. (Not a problem with the patch though, it happens in a clean copy of the game)
My pc:
Intel core i7 4771
Gigabyte GTX 970 G1 gaming
16gb Ram
Windows 10

I had the same desync issues, using the methods of hacking the EXE manually (#1). Do you play in windowed or fullscreen mode btw?
The options menu does work, but it actually takes about 15-20 seconds to enter/exit for some reason.

Fullscreen.
And thanks for the options menu tip. You're right, it opens after 15 seconds.

You Wanna hear the weirdest thing? I just opened the game and now everything works flawlessly. Weird. I literally did nothing.


Fix restoring a cache on macOS 11

This thing happens occasionally.
https://github.com/nix-community/cache-nix-action/actions/runs/7343243615/job/19993608165#step:5:35

This issue can be deprecated because macos-11 isn't used anymore in this repository.


License

It look like this doesn't have any license. What license do you plan to have?

Up to you, only index.* and README is not generated or compiled, so could just put notices in those files with Ebiten authors and link to Ebiten repo.


:seedling: Update TopoLVM chart

What type of PR is this?
/kind other
What this PR does / why we need it:
Updates the TopoLVM helm chart.

This needs to be checked and re-implemented:

https://github.com/topolvm/topolvm/pull/913 introduced in topolvm-chart-v15.0.0


chat: New DM invites don't show up anywhere

I received a DM from someone I hadn't DM'd with before, and I noticed it in the grid notifications section, but it didn't show up anywhere in talk.  After seeing it once in the grid notifications it also disappeared from there, so I couldn't click on it.  I remembered the name, so I created my own DM to them, and after sending the first message it showed the page asking me if I wanted to accept their DM invite.  @galenwp reported the same issue.
Ubuntu/Chrome/syncing %talk, %groups, and %base from ~binnec

This happened again today.  It's making me paranoid that I'm missing all new DMs, not sure how long this has been the case.

Were you able to see the DM they originally sent after you sent yours and got past the "Accept" page?

Yes
On Wed, Mar 15, 2023, 12:59 patosullivan @.***> wrote:

Were you able to see the DM they originally sent after you sent yours and
got past the "Accept" page?
—
Reply to this email directly, view it on GitHub
https://github.com/tloncorp/landscape-apps/issues/2117#issuecomment-1470755530,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABKLYGHRCDIE2DWXNXDTQX3W4INRRANCNFSM6AAAAAAVZVGBS4
.
You are receiving this because you authored the thread.Message ID:
@.***>


[usbdev] Predictor of usbdev

This request contains the usbdev_TransactionManager class of the usbdev predictor (reference model).In this class the whole flow for the usb predictor is done. It also consist of a modified packet classifier class in which the pid identifier values are changed according to the new usb20_item.

@jdonjdon kindly review it. Thanks

@jdonjdon I have amended the code as per your suggestion.

Hi there. I'm afraid that I hadn't looked at this PR before it was merged.
The code is pretty heavy on style errors.
@sarahmazhar-impare: Please could you file a follow-up PR that sorts them out?
@jdonjdon: Please could you try to look for silly style problems before merging code? It would be a pity if we dropped the general coding style standard just for silly reasons.
I should say: I haven't spent time looking at this from a functional perspective. Presumably, @jdonjdon has done so already.

Hi there. I'm afraid that I hadn't looked at this PR before it was merged.
The code is pretty heavy on style errors.
@sarahmazhar-impare: Please could you file a follow-up PR that sorts them out? @jdonjdon: Please could you try to look for silly style problems before merging code? It would be a pity if we dropped the general coding style standard just for silly reasons.
I should say: I haven't spent time looking at this from a functional perspective. Presumably, @jdonjdon has done so already.

@rswarbrick , my apology for missing out style issues.
@sarahmazhar-impare , from hw/ip/usbdev/dv/env/usbdev_TransactionManager.sv,
can you add space after comma and resubmit PR?
There are a few others but this seems prevailing one I can catch after a quick scan.

To give you an idea, these were the results when using the release from https://github.com/chipsalliance/verible/releases/tag/v0.0-3460-g4e8133d1
--- a/hw/ip/usbdev/dv/env/usbdev_TransactionManager.sv
+++ b/hw/ip/usbdev/dv/env/usbdev_TransactionManager.sv
@@ -5,23 +5,23 @@
 class usbdev_TransactionManager extends uvm_object;
   `uvm_object_utils(usbdev_TransactionManager)

-  usbdev_packetiser m_usbdev_packetiser;
-  usbdev_packet_classifier m_usbdev_packet_classifier;
-  usbdev_data_integrity  m_usbdev_data_integrity;
-  token_packet      m_token_pkt;
-  data_packet       m_data_pkt;
-  hand_shake_packet m_handshake_pkt;
-  logic [1:0]state;
-  logic [6:0] address;
-  logic [3:0] endpoint;
-  bit data[];
-  bit [7:0] pid;
+  usbdev_packetiser              m_usbdev_packetiser;
+  usbdev_packet_classifier       m_usbdev_packet_classifier;
+  usbdev_data_integrity          m_usbdev_data_integrity;
+  token_packet                   m_token_pkt;
+  data_packet                    m_data_pkt;
+  hand_shake_packet              m_handshake_pkt;
+  logic                    [1:0] state;
+  logic                    [6:0] address;
+  logic                    [3:0] endpoint;
+  bit                            data                       [];
+  bit                      [7:0] pid;

-  function new(string name  = "TransactionManager");
+  function new(string name = "TransactionManager");
     super.new(name);
     m_usbdev_packetiser = new;
     m_usbdev_packet_classifier = new;
-    m_usbdev_data_integrity =new;
+    m_usbdev_data_integrity = new;
     m_token_pkt = new();
     m_data_pkt = new();
     m_handshake_pkt = new();
@@ -31,112 +31,109 @@
     endpoint = 4'b0;
   endfunction

-  task transaction_manager( input bit t_pkt[], input bit d_pkt[],
-  input bit h_pkt[]);
+  task transaction_manager(input bit t_pkt[], input bit d_pkt[], input bit h_pkt[]);
     m_usbdev_packet_classifier.checkPacket(t_pkt);
-    if (m_usbdev_packet_classifier.packetType == usbdev_packet_classifier::TOKEN_SETUP)  begin
-        setup_transaction(d_pkt,h_pkt);
+    if (m_usbdev_packet_classifier.packetType == usbdev_packet_classifier::TOKEN_SETUP) begin
+      setup_transaction(d_pkt, h_pkt);
     end
     if (m_usbdev_packet_classifier.packetType == usbdev_packet_classifier::TOKEN_IN) begin
-        in_transaction(d_pkt,h_pkt);
+      in_transaction(d_pkt, h_pkt);
     end
-    if(m_usbdev_packet_classifier.packetType == usbdev_packet_classifier::TOKEN_OUT) begin
-        out_transaction(d_pkt,h_pkt);
+    if (m_usbdev_packet_classifier.packetType == usbdev_packet_classifier::TOKEN_OUT) begin
+      out_transaction(d_pkt, h_pkt);
     end
   endtask

   task setup_transaction(input bit d_pkt[], input bit h_pkt[]);
-    case(state)
-       0: begin
-         if(m_usbdev_packet_classifier.pid == 8'b1101_0010) begin
-           pid = m_usbdev_packet_classifier.pid;
-           address = m_usbdev_packet_classifier.address;
-           endpoint = m_usbdev_packet_classifier.endpoint;
-           m_token_pkt.send_token_packet(pid,address,endpoint);
-           state = 1;
-         end
-       end
-       1: begin
-         m_usbdev_packet_classifier.checkPacket(d_pkt);
-         if(m_usbdev_packet_classifier.packetType == usbdev_packet_classifier::DATA_0 ) begin
-           pid = m_usbdev_packet_classifier.pid;
-           data = m_usbdev_packet_classifier.data;
-           m_data_pkt.send_data_packet(pid,data);
-           m_usbdev_data_integrity.write(pid,address,endpoint,data);
-           state = 2;
-         end
-       end
-       2: begin // wait for handshake Assuming HANDSHAKE packet is sent by the device as an ACK TODO
-         `uvm_info(get_type_name(),"ACK Handshake",UVM_LOW);
-         state = 0;
-       end
-       default: state =0;
+    case (state)
+      0: begin
+        if (m_usbdev_packet_classifier.pid == 8'b1101_0010) begin
+          pid = m_usbdev_packet_classifier.pid;
+          address = m_usbdev_packet_classifier.address;
+          endpoint = m_usbdev_packet_classifier.endpoint;
+          m_token_pkt.send_token_packet(pid, address, endpoint);
+          state = 1;
+        end
+      end
+      1: begin
+        m_usbdev_packet_classifier.checkPacket(d_pkt);
+        if (m_usbdev_packet_classifier.packetType == usbdev_packet_classifier::DATA_0) begin
+          pid  = m_usbdev_packet_classifier.pid;
+          data = m_usbdev_packet_classifier.data;
+          m_data_pkt.send_data_packet(pid, data);
+          m_usbdev_data_integrity.write(pid, address, endpoint, data);
+          state = 2;
+        end
+      end
+      2: begin  // wait for handshake Assuming HANDSHAKE packet is sent by the device as an ACK TODO
+        `uvm_info(get_type_name(), "ACK Handshake", UVM_LOW);
+        state = 0;
+      end
+      default: state = 0;
     endcase
   endtask

   task in_transaction(input bit d_pkt[], input bit h_pkt[]);
-    case(state)
-      0: begin // address and endpoint sent to data_integrity
-        if(m_usbdev_packet_classifier.pid == 8'b1001_0110 ) begin
+    case (state)
+      0: begin  // address and endpoint sent to data_integrity
+        if (m_usbdev_packet_classifier.pid == 8'b1001_0110) begin
           pid = m_usbdev_packet_classifier.pid;
           address = m_usbdev_packet_classifier.address;
           endpoint = m_usbdev_packet_classifier.endpoint;
-          m_token_pkt.send_token_packet(pid,address,endpoint);
+          m_token_pkt.send_token_packet(pid, address, endpoint);
           state = 1;
         end
       end
-      1: begin // Getting data from data integrity
-        m_usbdev_data_integrity.read(pid,address,endpoint,data);
-        m_data_pkt.send_data_packet(pid,data);
+      1: begin  // Getting data from data integrity
+        m_usbdev_data_integrity.read(pid, address, endpoint, data);
+        m_data_pkt.send_data_packet(pid, data);
         state = 2;
       end
       2: begin
         m_usbdev_packet_classifier.checkPacket(h_pkt);
-        if(m_usbdev_packet_classifier.pid == 8'b0010_1101 ) begin
-          `uvm_info(get_type_name(),"ACK Handshake",UVM_LOW);
+        if (m_usbdev_packet_classifier.pid == 8'b0010_1101) begin
+          `uvm_info(get_type_name(), "ACK Handshake", UVM_LOW);
           state = 0;
-        end
-        else if(m_usbdev_packet_classifier.pid == 8'b1010_0101 ) begin
-          `uvm_info(get_type_name(),"NAK Handshake",UVM_LOW);
+        end else if (m_usbdev_packet_classifier.pid == 8'b1010_0101) begin
+          `uvm_info(get_type_name(), "NAK Handshake", UVM_LOW);
           state = 0;
-        end
-        else if(m_usbdev_packet_classifier.pid == 8'b1110_0001 ) begin
-          `uvm_info(get_type_name(),"STALL Handshake",UVM_LOW);
+        end else if (m_usbdev_packet_classifier.pid == 8'b1110_0001) begin
+          `uvm_info(get_type_name(), "STALL Handshake", UVM_LOW);
           state = 0;
         end
       end
-      default: state =0;
+      default: state = 0;
     endcase
   endtask

   task out_transaction(input bit d_pkt[], input bit h_pkt[]);
-    case(state)
-      0: begin //address and endpoint sent to data_integrity
-        if(m_usbdev_packet_classifier.pid == 8'b0001_1110 ) begin
+    case (state)
+      0: begin  //address and endpoint sent to data_integrity
+        if (m_usbdev_packet_classifier.pid == 8'b0001_1110) begin
           pid = m_usbdev_packet_classifier.pid;
           address = m_usbdev_packet_classifier.address;
           endpoint = m_usbdev_packet_classifier.endpoint;
-          m_token_pkt.send_token_packet(pid,address,endpoint);
+          m_token_pkt.send_token_packet(pid, address, endpoint);
           state = 1;
         end
       end
-      1: begin // Sending data to data integrity
+      1: begin  // Sending data to data integrity
         m_usbdev_packet_classifier.checkPacket(d_pkt);
         if(m_usbdev_packet_classifier.packetType == usbdev_packet_classifier::DATA_0 ||
         m_usbdev_packet_classifier.packetType == usbdev_packet_classifier::DATA_1) begin
-          pid = m_usbdev_packet_classifier.pid;
+          pid  = m_usbdev_packet_classifier.pid;
           data = m_usbdev_packet_classifier.data;
-          m_data_pkt.send_data_packet(pid,data);
-          m_usbdev_data_integrity.write(pid,address,endpoint,data);
+          m_data_pkt.send_data_packet(pid, data);
+          m_usbdev_data_integrity.write(pid, address, endpoint, data);
           state = 2;
         end
       end
-      2: begin // TODO Simulate the reception of a HANDSHAKE packet from the device.
+      2: begin  // TODO Simulate the reception of a HANDSHAKE packet from the device.
         // Currently assuming that the HANDSHAKE packet is an ACKNOWLEDGE
-        `uvm_info(get_type_name(),"ACK Handshake",UVM_LOW);
+        `uvm_info(get_type_name(), "ACK Handshake", UVM_LOW);
         state = 0;
       end
-      default: state =0;
+      default: state = 0;
     endcase
   endtask
 endclass

There is at least one oddball line in there, but for the most part, it did the right thing.


Settings section of documentation has incorrect default value for output-format

"documentation", "default settings", "output-format", 0.5.2 version
Settings section for toml files still shows concise as default (https://docs.astral.sh/ruff/settings/#output-format):

The style in which violation messages should be formatted: "full" (shows source), "concise" (default), "grouped" (group messages by file), "json" (machine-readable), "junit" (machine-readable XML), "github" (GitHub Actions annotations), "gitlab" (GitLab CI code quality report), "pylint" (Pylint text format) or "azure" (Azure Pipeline logging commands).
Default value: "concise"

While cli outputs full as a default:

--output-format <OUTPUT_FORMAT>    Output serialization format for violations. The default serialization format is "full"

And ruff actually uses full if a user doesn't specify it.

Thank you -- it looks like we forgot to update crates/ruff_workspace/src/options.rs. Are you interested in submitting a PR?

@charliermarsh would love to!


Publish it on Will Bond's package manager for ST2/ST3 please?

Hi,

[ ] You provide no insight on how this plugin should be installed, and what are its dependencies (redpen? pyredpen?).
[ ] Also, please try to publish it on Will Bond's package manager for ST2/ST3 please!

Any update ?

Would also appreciate this. (although not too much hassle to add this as a repo)


suggestion to expand the android code samples for kotlin and static linking of vulkan

The android code sample uses only a native activity in C++.
You could improve the sample by adding the possibility use a SurfaceView from kotlin, and only use a part of the screen.
I made a working code sample of the idea.
https://github.com/MagicPoulp/display_vulkan_from_kotlin_or_swift.git
Moreover, linking Vulkan dynamically is quite buggy (lots of compilation errors). It can be interesting to have a simpler way to link statically, with a flag.
The link below illustrates that lots of hacks might be needded to link dynamically vulkan, with missing symbols, and so on.
https://marcelbraghetto.github.io/a-simple-triangle/2019/06/16/part-17/
Using Vulkan allows to compute more efficiently and save battery life. So Vulkan on mobile is key.

Moreover, linking Vulkan dynamically is quite buggy (lots of compilation errors). It can be interesting to have a simpler way to link statically, with a flag.

Can you elaborate on this? We're already using Volk as a function loader, and linking Vulkan static could introduce other headaches like loader incompatibilities.
From my experience I have heard little of problems with dynamic linking on Android, and also never ran into such problems myself. Or is that specific to using Vulkan with Kotlin?

Thanks for your interest. I remember your name with the first Vulkan samples when vulkan came out.
It was many months ago I wrote this so my memory is not fresh.
In the link above (marcel soemthing) there are many many failures and ways to fix them. IT shows the sort of mess, and thigns that depend on development software only.
I was using the latest LunarG code sample, the first one found on the internet, and there was no Volk at that time. Not that I remember. I had to use static, instead of dynamic to move on on the specific thing I was doing.
I was building using the Android NDK, they have their own C++ compiler. You can see exactly what I did if you clone my repo. It is fully documented, and runnable. The Android NDK has like a cmake build integrated.
Vulkan C is prboably more robust. But if I remember I could only use C++ with the android NDK. I failed when I tried C.
The technology to make graphics programming directly available in apps is there (cf the surface view). In the Javascript world there is pIXI, you can drow with a turtle pointer and it graphics accelerate on its own using OpenGL. it would be could to have in kotlin a library where you can drow on the rectangle and it uses Vulkan.
It seems to me it that gaphics could then use less battery. And also I had a problem with lag inside the graph library charts_flutter
It needs to show thousands of points in a graph that is dynamic based on touch. Just a pet project. I am still hesitating if Vullkan would help or if I need to rewrite the flutter library to be smarter by sampling.
https://github.com/MagicPoulp/audio_analyzer/blob/master/lib/FftPlot.dart
If you make graphics programming more mainstream you have potentially million of dollars of consulting contracts for Lunar G and all the gurus of this cool open source stuff.

I used the wrong repo. And in the wrong repo from LunarG, they do not use Volk. I will investigate more and then close this.


python3 "Found duplicated packages in closure"

Describe the bug
Hi there,
I've been having difficulties with the master lately.
Basically I had this custom python3.override that applies a patch to cython = super.cython.overridePythonAttrs(old: { patches = old.patches ++ [ ./some.interpreter.hack.patch ]; }); but lately unrelated packages started failing.
For example, here is a log for pyopenssl:
/nix/store/q2zpnf017gccs9w9mb0ikdqhkf0k5v82-catch_conflicts.py:1: DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html
  import pkg_resources
Found duplicated packages in closure for dependency 'sphinx':
  sphinx 5.3.0 (/nix/store/jwkrn9p7i0r5kkdpc39c9ywfzbmvmvd0-python3.10-sphinx-5.3.0/lib/python3.10/site-packages)
  sphinx 5.3.0 (/nix/store/7l4cj4g6ysi1dmz2yxl6nsq8abgiipai-python3.10-sphinx-5.3.0/lib/python3.10/site-packages)
Found duplicated packages in closure for dependency 'snowballstemmer':
  snowballstemmer 2.2.0 (/nix/store/l5246ajqbmc48q792rf9xg3sqi0syfry-python3.10-snowballstemmer-2.2.0/lib/python3.10/site-packages)
  snowballstemmer 2.2.0 (/nix/store/zcrf0d6by8dyrs1zmqwixrbkxpr2gpkk-python3.10-snowballstemmer-2.2.0/lib/python3.10/site-packages)
Found duplicated packages in closure for dependency 'PyStemmer':
  PyStemmer 2.2.0 (/nix/store/r33m03rghvpqgz75zc8gxsgkk3w9klz2-python3.10-pystemmer-2.2.0/lib/python3.10/site-packages)
  PyStemmer 2.2.0 (/nix/store/hh3pcdmca80bdvjg38s2ri9f448wvkg5-python3.10-pystemmer-2.2.0/lib/python3.10/site-packages)

Any ideas? No idea why it happens or how to approach the problem.
thnx.

Here is for pyjwt 2.8.0:
Found duplicated packages in closure for dependency 'sphinx':
  sphinx 5.3.0 (/nix/store/jwkrn9p7i0r5kkdpc39c9ywfzbmvmvd0-python3.10-sphinx-5.3.0/lib/python3.10/site-packages)
  sphinx 5.3.0 (/nix/store/7l4cj4g6ysi1dmz2yxl6nsq8abgiipai-python3.10-sphinx-5.3.0/lib/python3.10/site-packages)
Found duplicated packages in closure for dependency 'snowballstemmer':
  snowballstemmer 2.2.0 (/nix/store/l5246ajqbmc48q792rf9xg3sqi0syfry-python3.10-snowballstemmer-2.2.0/lib/python3.10/site-packages)
  snowballstemmer 2.2.0 (/nix/store/zcrf0d6by8dyrs1zmqwixrbkxpr2gpkk-python3.10-snowballstemmer-2.2.0/lib/python3.10/site-packages)
Found duplicated packages in closure for dependency 'PyStemmer':
  PyStemmer 2.2.0 (/nix/store/r33m03rghvpqgz75zc8gxsgkk3w9klz2-python3.10-pystemmer-2.2.0/lib/python3.10/site-packages)
  PyStemmer 2.2.0 (/nix/store/hh3pcdmca80bdvjg38s2ri9f448wvkg5-python3.10-pystemmer-2.2.0/lib/python3.10/site-packages)

typeguard-2.13.3, wrapt 1.14.1 have similar errors.

Happens to me too from overriding certifi to inject my own cert.  sphinx shows the same error you have.

Removing sphinxHook in the packages failing to build fixes my issue, but that's not very practical to do for the volume of packages I need.

I've found another way to the suppress warnings hence the errors. Apply the following to the packages that throws conflicts in your override:
   pyopenssl = super.pyopenssl.overridePythonAttrs(old: {
        catchConflicts = false;
      });

Obviously this doesn't fix the double packages in the closure problem. Let me see if it works.

Please post a reproducer which can be run in the nixpkgs dir
{ pkgs ? import ./. { } }:

...

Could be because of https://github.com/NixOS/nixpkgs/commit/a3916398458f9dee7efb6cc12bc2b1d28980d38e
will have to be investigated with nix-diff
CC @kip93

The reason for me creating that PR was because of wrapt failing to cross compile due to the sphinx hook, so I tested that it both compiled and cross compiled. Plus beautiful soup since I removed the explicit workaround. So it's not the package themselves that are failing here.
From what I can see, wrapt uses sphinx-rtd-theme, which that propagates sphinx. So does the hook. So now you have 2 inputs propagating the same dependency. That's probably where the confusion is coming from?

Please post a reproducer which can be run in the nixpkgs dir

Certainly!  Sorry I should have done this with the initial post.
# foo.nix
{pkgs ? import ./. {}}: let
  python3 = pkgs.python3.override {
    packageOverrides = final: prev: {
      certifi = prev.certifi.override {
        cacert = pkgs.cacert.override {
          # openssl genrsa -out my_ca.crt 2048
          extraCertificateFiles = [./my_ca.crt];
        };
      };
    };
  };
in
  python3.pkgs.pyjwt

I bisected the failure to a3916398458f9dee7efb6cc12bc2b1d28980d38e.
Not sure how to properly fix it.  For now I just reverted that commit in a fork of the nixpkgs repo and things are working again.

Well as I said that commit is just exposing an error somewhere else not the error itself, but if you're not cross compiling reverting it won't break anything for you.

Well as I said that commit is just exposing an error somewhere else not the error itself

Do you have a solution to fix this then?  I'm happy to put in time to fix this on nixpkgs, I just don't know how to fix it aside from reverting the commit.

Haven't had the time to properly look into it, but my intuition tells me that we should remove sphinx as a propagated build input in sphinx themes. I feel like a theme is just resource files, nothing more; having sphinx there does not make sense to me.

I tried to remove sphinx from sphinx-rtd-theme, but it is not so easily done.  sphinx-rtd-theme, it uses the sphinx logging facilities, locale, and it has a number of places where HTML generation is dependent on sphinx version.  Not impossible to remove, but it would likely break locale functionality.
Additionally sphinx-rtd-theme uses sphinxcontrib-jquery which uses sphinx and has similar difficult-to-remove dependencies.

Ok, had a little time for debugging this morning, and found something interesting. While it shows a conflict, one of them does not seem to be in the closure.
$ nix why-depends -a /nix/store/n9nb3f5py32xqbgc11png2q6drdfzy5q-python3.10-pyjwt-2.8.0.drv /nix/store/z9p4x8rw1kd99lkg70rc7crw2n70jdb4-python3.10-sphinx-5.3.0.drv
'/nix/store/n9nb3f5py32xqbgc11png2q6drdfzy5q-python3.10-pyjwt-2.8.0.drv' does not depend on '/nix/store/z9p4x8rw1kd99lkg70rc7crw2n70jdb4-python3.10-sphinx-5.3.0.drv'
$ nix why-depends -a /nix/store/n9nb3f5py32xqbgc11png2q6drdfzy5q-python3.10-pyjwt-2.8.0.drv /nix/store/4nfkn104vk6q6c1h991nxn1l6dm1833v-python3.10-sphinx-5.3.0.drv
/nix/store/n9nb3f5py32xqbgc11png2q6drdfzy5q-python3.10-pyjwt-2.8.0.drv
└───/nix/store/9cs5cgli2pf71b3gpfr7n75i7mgq1npk-python3.10-sphinx-rtd-theme-1.2.0.drv
    ├───/nix/store/4nfkn104vk6q6c1h991nxn1l6dm1833v-python3.10-sphinx-5.3.0.drv
    ├───/nix/store/993c1vcna986z0fhikqqwiqd4h9z3lxq-python3.10-sphinxcontrib-jquery-3.0.0.drv
    │   └───/nix/store/4nfkn104vk6q6c1h991nxn1l6dm1833v-python3.10-sphinx-5.3.0.drv
    └───/nix/store/q8xsvmq2hvcj6z9klp6lbpk7fp1c4419-python3.10-readthedocs-sphinx-ext-2.2.0.drv
        └───/nix/store/4nfkn104vk6q6c1h991nxn1l6dm1833v-python3.10-sphinx-5.3.0.drv

So I went ahead and tried a little something
diff --git a/pkgs/development/python-modules/pyjwt/default.nix b/pkgs/development/python-modules/pyjwt/default.nix
index cef52b754ad..4005dc840d2 100644
--- a/pkgs/development/python-modules/pyjwt/default.nix
+++ b/pkgs/development/python-modules/pyjwt/default.nix
@@ -4,9 +4,7 @@
 , cryptography
 , pytestCheckHook
 , pythonOlder
-, sphinxHook
-, sphinx-rtd-theme
-, zope_interface
+, python
 }:

 buildPythonPackage rec {
@@ -31,7 +29,7 @@ buildPythonPackage rec {
     "doc"
   ];

-  nativeBuildInputs = [
+  nativeBuildInputs = with python.pythonForBuild.pkgs; [
     sphinxHook
     sphinx-rtd-theme
     zope_interface

aaand it just works :tm:. But I'm not sure why, since unless you're cross compiling these should be the same. And indeed, they seem to be
$ nix build .#python3.pkgs.sphinx --print-out-paths
/nix/store/nscmi1vzj2m3sm99060pxw5fkl9vgd70-python3.10-sphinx-5.3.0
$ nix build .#python3.pythonForBuild.pkgs.sphinx --print-out-paths
/nix/store/nscmi1vzj2m3sm99060pxw5fkl9vgd70-python3.10-sphinx-5.3.0

Same for the hook and the theme
$ nix build .#python3.pkgs.sphinxHook --print-out-paths
/nix/store/hs8fpi0cfsqlw03q844mkmavq22z05y6-python3.10-sphinx-hook
$ nix build .#python3.pythonForBuild.pkgs.sphinxHook --print-out-paths
/nix/store/hs8fpi0cfsqlw03q844mkmavq22z05y6-python3.10-sphinx-hook
$ nix build .#python3.pkgs.sphinx-rtd-theme --print-out-paths
/nix/store/2isqzc5axx7mgwvg1lxm22f6n6xfljcm-python3.10-sphinx-rtd-theme-1.2.0
$ nix build .#python3.pythonForBuild.pkgs.sphinx-rtd-theme --print-out-paths
/nix/store/2isqzc5axx7mgwvg1lxm22f6n6xfljcm-python3.10-sphinx-rtd-theme-1.2.0

Unfortunately don't have more time today to look into this, but maybe if by the weekend noone else has chimed in I can try to find where is the phantom sphinx coming from

The issue could be that the packageOverrides aren't getting passed to pythonForBuild

From what I can see the overrides are passed to pythonForBuild, so the why of the certificate not being there eludes me.
What I tested and seems to work is to not propagate sphinx, since most packages (with 4 exceptions) know to not depend on the propagated sphinx anyway and included either sphinx or sphinxHook explicitly. So this patch may be a better fix than the one above
diff --git a/pkgs/development/python-modules/sphinx-rtd-theme/default.nix b/pkgs/development/python-modules/sphinx-rtd-theme/default.nix
index 613f1998121..835e74bc992 100644
--- a/pkgs/development/python-modules/sphinx-rtd-theme/default.nix
+++ b/pkgs/development/python-modules/sphinx-rtd-theme/default.nix
@@ -27,10 +27,13 @@ buildPythonPackage rec {

   propagatedBuildInputs = [
     docutils
-    sphinx
     sphinxcontrib-jquery
   ];

+  buildInputs = [
+    sphinx
+  ];
+
   nativeBuildInputs = [
     pythonRelaxDepsHook
   ];

Tested for both native and cross compilation and they both build. Not sure how to check if the certificate is properly overriden tho.
Here's the 4 exceptions that needed to be patched (testing them rn, but don't see how they could fail)
diff --git a/pkgs/development/python-modules/django-payments/default.nix b/pkgs/development/python-modules/django-payments/default.nix
index 577a2ca5132..d9d7a5a9489 100644
--- a/pkgs/development/python-modules/django-payments/default.nix
+++ b/pkgs/development/python-modules/django-payments/default.nix
@@ -9,6 +9,7 @@
 , pythonOlder
 , requests
 , setuptools-scm
+, sphinx
 , sphinx-rtd-theme
 , stripe
 , xmltodict
@@ -56,7 +57,7 @@ buildPythonPackage rec {
     all = [ braintree /* suds-community */ mercadopago cryptography xmltodict stripe ];
     braintree = [ braintree ];
     cybersource = [ /* suds-community */ ];
-    docs = [ sphinx-rtd-theme ];
+    docs = [ sphinx sphinx-rtd-theme ];
     mercadopago = [ mercadopago ];
     sagepay = [ cryptography ];
     sofort = [ xmltodict ];
diff --git a/pkgs/development/python-modules/imantics/default.nix b/pkgs/development/python-modules/imantics/default.nix
index 3b02ac44034..05ac7299d58 100644
--- a/pkgs/development/python-modules/imantics/default.nix
+++ b/pkgs/development/python-modules/imantics/default.nix
@@ -3,6 +3,7 @@
 , lib
 , numpy
 , opencv3
+, sphinx
 , sphinx-rtd-theme
 , lxml
 , xmljson
@@ -22,6 +23,7 @@ buildPythonPackage rec {
   propagatedBuildInputs = [
     numpy
     opencv3
+    sphinx
     sphinx-rtd-theme
     lxml
     xmljson
diff --git a/pkgs/development/python-modules/omrdatasettools/default.nix b/pkgs/development/python-modules/omrdatasettools/default.nix
index 4448a686e1a..5f2b51b7701 100644
--- a/pkgs/development/python-modules/omrdatasettools/default.nix
+++ b/pkgs/development/python-modules/omrdatasettools/default.nix
@@ -10,6 +10,7 @@
 , pillow
 , pytestCheckHook
 , scikit-image
+, sphinx
 , sphinx-rtd-theme
 , sympy
 , pandas
@@ -39,6 +40,7 @@ buildPythonPackage rec {
     tqdm
     twine
     sympy
+    sphinx
     sphinx-rtd-theme
     pandas
     ipython
diff --git a/pkgs/development/python-modules/pydash/default.nix b/pkgs/development/python-modules/pydash/default.nix
index 14e7ffdfcd6..d05f6686c30 100644
--- a/pkgs/development/python-modules/pydash/default.nix
+++ b/pkgs/development/python-modules/pydash/default.nix
@@ -6,6 +6,7 @@
 , mock
 , pytestCheckHook
 , pythonOlder
+, sphinx
 , sphinx-rtd-theme
 }:

@@ -26,6 +27,7 @@ buildPythonPackage rec {
   nativeCheckInputs = [
     invoke
     mock
+    sphinx
     sphinx-rtd-theme
     pytestCheckHook
   ];

Ok, the builds took a while but this does not seem to break anything that wasn't already broken (3 out of 4 failed to cross compiled, but nothing related to sphinx and failed even before this change).

Does the hook even have to propagate sphinx instead of using only the binary

With the current design, hooks can't not propagate inputs (I guess it's just a matter of adding the argument, but maybe it was done this way for a reason?);

With the current design, hooks can't not propagate inputs (I guess it's just a matter of adding the argument, but maybe it was done this way for a reason?).

I mean just using substitutions to use a absolute path to the binary

Oh, right, that makes sense. I'll go and make that change and create a PR (against staging of course) since this would be a large change and building it all on my PC would take too long.


Improving error message for the use of the chaining operator in a non-behavior property

Draft PR for now. Issue #392 .
A few things that I need some suggestions on:

Translation: I created a new error message to the en-us file. What the steps to get all other language files updated
_ShortMessage, _LongMessage and other sufixes: Do I need to create them all? How to identify the necessary ones?
Extra test cases.

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Interpreter.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.LanguageServerProtocol.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Transport.Attributes.dll

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Interpreter.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.LanguageServerProtocol.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Transport.Attributes.dll

We'll leave this issue as a one-off fix, and we'll use #548 to track the broader issue of proper localization support.

We'll leave this issue as a one-off fix, and we'll use #548 to track the broader issue of proper localization support.

Pull Request Test Coverage Report for Build 316882

0 of 0   changed or added relevant lines in 0 files are covered.
51 unchanged lines in 2 files lost coverage.
Overall coverage increased (+0.008%) to 63.825%

Files with Coverage Reduction
New Missed Lines
%

/src/libraries/Microsoft.PowerFx.Core/Localization/Strings.cs
1
94.49%

/src/libraries/Microsoft.PowerFx.Core/Parser/TexlParser.cs
50
89.06%

Totals

Change from base Build 316809:
0.008%

Covered Lines:
24209

Relevant Lines:
37930

💛  - Coveralls

:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Connectors.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Core.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Interpreter.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.LanguageServerProtocol.dll
:heavy_check_mark: No Binary Compatibility issues for Microsoft.PowerFx.Transport.Attributes.dll


Relay still sending canceled chat messages

While using a chat filtering plugin that stop chat events, when the chat filter is triggered, the message is still sent to the Discord relay chat, even through the chat message has been canceled.
Debug log: https://bin.scarsz.me/f819bb30-55e5-4284-99e9-23b8c0fc682b#mslDRf4vJZ1zPTCG1clWZ6IRezzKX6H1
Versions overview:
Minecraft version: 1.21.1-47-e2da65c (MC: 1.21.1)
Bukkit API version: 1.21.1-R0.1-SNAPSHOT
plugin version: DiscordSRV v1.28.0
config version: 1.28.0

Wrong repo, moved to https://github.com/DiscordSRV/DiscordSRV/issues/1777


[Driver] NFC: Added some comments around incremental compilation.

Based on my own investigation, and conversations with Jordan, have added some comments. Zero changes to actual code. Pay particular attention to the comment for InitialOutOfDateCommands, where (if I read the code right) I had to reverse the sense of a comment. Either the code or the comment was wrong before.

@jrose-apple Thank you for take the time to look at these comments. So helpful to get a review!

@swift-ci please smoke test

@jrose-apple @graydon I'd like to land this if it's OK with you. Any more suggestions? TIA.


Flux Limiting in Thermal diffusion

Dear All,
I was going through the example "ex16.cpp" for nonlinear thermal diffusion. I wanted to modify this example in such way that the heat flux (k grad T, where k is the conductivity and T is the temperature) at each face (3D) or edge (2D) can be limited (flux limiter) based on some physics models (e.g. a fraction of maximum physically allowed heat flux). This will help to limit the diffusion within the physically acceptable limit via flux limiting (at locations where steep temperature gradients exist). How it can be implemented, either by defining scaled edge/face conductivity (I am not sure about edge based conductivities are defined or used in this example) or limiting the edge/face flux itself.
Regards
--Sijoy C.D.

Sijoy C.D.,
your desire of limiting the heat flux makes complete sense, however, why would you target the skeleton only? Also, ex16 uses H1 elements without a notion of faces.
I would suggest simply scale the \kappa coefficient according to \kappa grad T values as you said. The problem already uses a nonlinear solve, so the solution should pretty much straightforward.
Milan

Thanks Milan,
Infact I want to develop and couple an electron thermal diffusion (higher order) module with multi material hydrodynamics (modified Laghos). The energies in the hydrodynamics defined via discontinuous L2 FE space. The face/edge integrators for diffusion operators in that case makes sense. Also for discountuous L2 FE space, wouldn't make sense to have edge based conductivities (some kind of average from the shared zones) assuring flux conservation?

We are glad your work builds on and extends Laghos! In that case you either want to use

the mixed finite element formulation for diffusion (Hdiv + L2) presented in ex5 and Joule miniapp
DG diffusion formulation from ex14

Both cases will require a nonlinear iteration of the “limited” diffusion coefficient. Case 1) will work with your piece-wise continuous coefficient. You can check if the case 2) work based on the definition of DGDiffusionIntegrator.

Dear Milan,
Thank you for your suggestions..
Let me go through the examples you suggested ..
Regards
--Sijoy

Thanks Milan!
@cjoycd -- I will close this now, please reopen if you have further questions.


5. Add MarkOpalski's file

6. created a branch, created a file and made a commit, and opened a pull request

that was a fun tutorial


⚠ Bofrost.be has degraded performance

In 4f0475a, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 823 ms

Resolved: Bofrost.be performance has improved in 9d10a40.


Add CHONNAM NATIONAL UNIVERSITY

Add CHONNAM NATIONAL UNIVERSITY

website : https://webgs.jnu.ac.kr/IndexMain.aspx

@moondubu I am sorry, the domain jnu.ac.kr is removed from our trusted domains list because it was abused in the past. If you are the student of this school, please enroll to GitHub Student Developer Program. Then apply for JetBrains educational subscription with your GitHub account (GitHub tab at https://www.jetbrains.com/shop/eform/students).