Type up requirements issue for Zoom fixes

From #11 #16 #18 #12 #14

Review the findings
Turn the findings + recommendations into concrete actions/tasks
Assign ticket and work on

This is a summary of the Zoom audit in the latest Jupyterlab interface
Referenced issues

Left sidebar audit
Right sidebar audit
Main content area audit
Menu bar audit
Context menu audit
Settings audit
Status bar audit

Findings

The definition of vertical padding and height are working as they are and they have sense to leave them in px in the sidebars items.
We need to define a new UX for when the left sidebar is taking too much space compared to the main area. My suggestion will be to compress the left pane to give priority to the main content area.
Files in the main content area are wrapping lines instead of having a horizontal scrollbar, which allows to see all the code without any action.
If zoom is activated some filenames are not visible in the tabs, but hovering over them will give the complete information of the file
Opening a lot of files in zoom may cause to just seeing the icon and not being able to even close it
The notebook's toolbar is responsive and all the options are visible and usable
Cell options layout breaks with 400% zoom
Python logo in the launcher pixelates with zoom
Dialogs occupy the complete interface with 400% zoom
The menu items start getting lost as zoom increases
The dropdown menus are not visible or usable with 400% zoom
Modifying to responsive layouts break the menubar and its usability
Automatically we have a scrollbar to navigate through the options in context menus if not visible at first
The size of context menus is fixed in px which occupy a lot of space in small screens or high zoom
Settings is not usable in small screens or with zoom, the options are chopped and not readable
Settings left menu area doesn't resize
Settings is using the same gear icon for multiple entries
The Status bar is responsive for even mobile screen sizes

General questions

Do we want to support changes in the default text size of the browser? This will affect all the UI and right now it is using the minimum text size set in the settings of the browser.
Do we want the dialogs to occupy and block the complete interface when zoom is high?
Accessibility guidelines support the idea to have a button for context menus, do we want to follow it?
The same gear icon in multiple entries of the Settings pane is intentional?

Tasks

[ ] Define a new UX for the left sidebar when they are taking too much space compared to the main area
[ ] Define a new UX for the right sidebar when they are taking too much space compared to the main area
[ ] Define a new UX/UI for the tabs in the main content area, especially the cases where too many of them are opened.
[ ] Make the cell options layout be responsive (it may include removing some options or adding ellipsis when the space is small)
[ ] Change the python logo to a new image that has better resolution
[ ] Dialogs sizes need to be checked for high zoom or small screens
[ ] Add a hamburger menu in the main menu bar when the space is smaller to avoid loosing items.
[ ] Dropdown menus from the main menu bar should open to the left/right depending on the space in the screen
[ ] Check and define the UI/UX for context menus in small screens and/or high zoom
[ ] Define a new UX for the Settings pane to handle small screens and/or high zoom

For more info about each pane please see its particular issue where screenshots and more notes are described.

Thanks for summarizing this!
I have some thoughts and comments about the above which I will cover in no particular order, one quoted line at a time.

If zoom is activated some filenames are not visible in the tabs, but hovering over them will give the complete information of the file

I could check on my Windows laptop to see what happens in similar situations on Windows if you like.

Do we want the dialogs to occupy and block the complete interface when zoom is high?

Ditto, could check something similar on Windows.

The menu items start getting lost as zoom increases

Ditto, could check on Windows.
For the preceding issues,

Accessibility guidelines support the idea to have a button for context menus, do we want to follow it?

Can you show an example of this, a button for context menus?

Settings left menu area doesn't resize

I think I was able to resize settings left menu on mine. I can show in tomorrow's call.

Settings is not usable in small screens or with zoom, the options are chopped and not readable

Good catch on the Settings Editor. I imagine that our planned extension will need to make use of the Settings Editor. On my dev machine, which has a pretty high resolution (3072 × 1920), it starts to get hard to use at around 150% zoom in Chrome.

Modifying to responsive layouts break the menubar and its usability

I'm not sure what you mean by responsible layout breaking the menubar. Also not sure about your comment about the status bar and responsiveness. Perhaps we could cover this in the team call.

Thanks for giving such thorough review and compiling your findings, @steff456! This is so pleasantly skimmable so I can figure out the best places to dive in with the more focused issues.
I'm not sure how much this comment will help, but I do want to say I think all your findings and tasks make sense to me. I think the following apply to me immediately

[ ] Define a new UX for the left sidebar when they are taking too much space compared to the main area
[ ] Define a new UX for the right sidebar when they are taking too much space compared to the main area
[ ] Define a new UX/UI for the tabs in the main content area, especially the cases where too many of them are opened.
[ ] Make the cell options layout be responsive (it may include removing some options or adding ellipsis when the space is small)
[ ] Dialogs sizes need to be checked for high zoom or small screens recommendations for dialogs in small areas
[ ] Dropdown menus from the main menu bar should open to the left/right depending on the space in the screen
[ ] Check and define the UI/UX for context menus in small screens and/or high zoom
[ ] Define a new UX for the Settings pane to handle small screens and/or high zoom

Does that sound correct?
I've been looking into patterns for zoom behavior and small screens in tandem. Zoom is an areas I've worked on less, so I think I'm still synthesizing the info I've gathered there.
I think my direct next step is to provide a low-fidelity visual and pattern for how each content area (from what you've listed) behaves in

a small screen (roughly mobile device sized)
a larger screen at 400% zoom (roughly laptop sized)
the ways they overlap/interact

Does that sound correct?

Yes, it sounds like a good plan :)

Questions to dive into

If zoom is activated some filenames are not visible in the tabs, but hovering over them will give the complete information of the file

Do we want to support changes in the default text size of the browser? This will affect all the UI and right now it is using the minimum text size set in the settings of the browser.

Do we want the dialogs to occupy and block the complete interface when zoom is high?

Accessibility guidelines support the idea to have a button for context menus, do we want to follow it?

The same gear icon in multiple entries of the Settings pane is intentional?

Settings is not usable in small screens or with zoom, the options are chopped and not readable

@isabela-pf  will work on:

[ ] Define a new UX for the left sidebar when they are taking too much space compared to the main area
[ ] Define a new UX for the right sidebar when they are taking too much space compared to the main area
[ ]  Define a new UX/UI for the tabs in the main content area, especially the cases where too many of them are opened.
[ ] Make the cell options layout be responsive (it may include removing some options or adding ellipsis when the space is small)
[ ]  Dropdown menus from the main menu bar should open to the left/right depending on the space in the screen
[ ] Check and define the UI/UX for context menus in small screens and/or high zoom
[ ] Define a new UX for the Settings pane to handle small screens and/or high zoom
[ ] Dialogs sizes need to be checked for high zoom or small screens

@steff456

[ ] Change the python logo to a new image that has better resolution

TBD

[ ] Add a hamburger menu in the main menu bar when the space is smaller to avoid loosing items.
[ ] Need to add this audit and findings to the jupyter/accessibility repo

One question all of this raises for me: should we say that we won't support screens below a certain width?

I was hoping that by taking a look at how Windows handles scaling, we might find solutions for squeezed tabs, dialogs, and file menu bars, since Microsoft has done a lot of work on accessibility. However, the results were a mixed bag. At 400% scaling, I came across multiple dialogs that had content off screen and with no way to reach it. With lots of open tabs in Edge, I found that there was no way to scroll through the tabs, but you could use keyboard shortcuts to cycle through tabs. In Microsoft Word, I discovered that the menu bar had a neat feature of putting little left/right arrow buttons at the left and right ends of the file menu bar; this keeps the bar on a single line, as opposed to wrapping the bar to two or more lines; however, at 400% scale, the fine menu bar disappeared completely and I had no idea how to find it, so that seemed less than ideal. I also noticed that in the settings app, the two-panel layout switched to a single panel after a certain point.
So like I said, mixed bag. But we may want to steal the left/right arrows for the menu bar. And we may also want to adopt the approach of switching a two-panel layout to a single panel with a back button to a one-panel home menu.

Long overdue, here are some ideas on how to approach the reflowing and content prioritizing needed forJupyterLab to zoom up to 400% without losing content. I’ve been noodling over this at a few different levels, but I think we need to start with thinking about how all the parts interact before spending time on how each detail fits in the many JupyterLab regions. That's why we're operating in a neon, quilted JupyterLab land for now.
I think the core problem from @steff456’s review is the conflict of

Anything greater than 100% zoom limits how much can fit on a screen at once (like character count)
JupyterLab’s dense UI
Limited responsiveness of JupyterLab UI. What I primarily mean is that setting horizontal scrollbars for overflowing horizontal content, while technically means to access all the UI, are not generally best practice. Especially since many of the scroll bars have small target areas to scroll.

Only 2 and 3 are in our control, so my goal is to get us discussing what UI we want to prioritize as visible by default, what UI is collapsed (but not gone) as default, and how to optimize the responsiveness of these areas.
Option 0-3
This approach

Removes side bar tabs
Collapses the Main menu area into a single menu button
Collapses tabs to prioritize the open tab/document name, New Launcher button, and ellipses to expand tabs as a list
Adds all menus and side bar content to the collapsed main menu area
Expanding this mega menu lists commands by region and takes up most of the window

Option 0-5
This approach

Removes side bar tabs
Collapses the Main menu area into a single menu button
Collapses tabs to prioritize the open tab/document name, New Launcher button, and ellipses to expand tabs as a list
Adds all menus and side bar content to the collapsed main menu area
Expanding this mega menu brings up a command palette with commands by region marked a la table of contents

Option 0-9
This approach

Removes side bar tabs
Removes the document menu
Collapses tabs to prioritize the open tab/document name, New Launcher button, and ellipses to expand tabs as a list
The command palette, which can be found via the View menu or the shortcut, is used to access all else

Option 0-4
This approach sets the UI based on how the user is interacting with the document. Command mode is for high-level document traversal and edit mode is activated when a user has entered an editable part of a document (ie. when focus in a notebook moves from outside a cell to the editor region of a cell).
When in command mode, this approach

Removes side bar tabs
Removes the document menu
Collapses the Main menu area into a single menu button
Collapses tabs to prioritize the open tab/document name, New Launcher button, and ellipses to expand tabs as a list
The command palette, which can be found via the View menu or the shortcut, is available

When in edit mode, this approach

Collapses the Main menu area into a single menu button
Collapses the side bars into their narrow variations
The command palette, which can be found via the View menu or the shortcut, is available

Notes
All of the above are very rough explorations to get discussion started, so they all need more ironing out in order to fill out what the user flow would actually need to be from end to end. Please point out missing gaps, but also know I may not have all the answers yet.
I think option 0-4, while pretty logical and following patterns of other dense, document-based interfaces on small screens, probably isn't viable. It's a totally different experience than JupyterLab unzoomed or at a large screen, and it seems wrong for the UX to be that great. Still, I wanted to provide in case it sparks ideas that are more flexible.
As always, feedback and questions are useful. Thanks! 🌻

I also like a lot the option 0-4, I think is the less disruptive one in terms of the current UX in JupyterLab. I think we might need to explore the idea of completely collapsing the main menu, in terms of API flexibility and location of panes.
I think my main concern with options 0-9, 0-5 and 0-3 is how to manage hiding the sidebars, are they going to be always hidden? How are we going to manage all the options that are inside of them?

Thanks @isabela-pf for providing the scaffold for us to have more concrete discussions.
I finally got a chance to re-review these proposals.
I also did a deep dive into WCAG 1.4.10 - Reflow aka 400% zoom. I played with Google Docs and Google Colab at 320 CSS px. On desktop, 320 CSS px means start at 1280px width at 100%, then zoom up to 400%. I also played with JupyterLab on my Windows laptop. And I played with it on my iPhone at various levels of zoom and text sizing.
It reminded me of my findings when I scaled up Windows really high and tried to work with Microsoft Word: disappointing, discouraging.
I'm starting to feel that it simply might not be realistic for us to try to rework JupyterLab to meet guideline 1.4.10.
I'm not saying I think it's impossible for us to conform to the guideline. But I want us to ask if it would be worth it. This guideline might be the hardest of all of them to meet with JupyterLab. I have yet to see a classic desktop-style app that strictly conforms at 320 CSS px. Can someone give me a counter example?
Now, the counter argument is that Isabela's proposed layouts could conform to the guideline. But my guess is that Isabela's suggestions will take a lot of effort to implement. I'm not sure they can be done in an extension, and if they can't, it would require either a fork of JupyterLab or a lot of changes to the core of JupyterLab. Maybe this is where we need an engineer with lots of JupyterLab experience to give us a quick size estimate.
That being said, my alternative suggestion is that instead of trying to conform at 320 CSS px, we try for analogous reflow conformance at 640 CSS px (aka 200% zoom instead of 400%). We will need to do that anyway to conform to guideline 1.4.4: Resize Text. This will still give us a lot of work to do, but it seems more tractable to me. 200% zoom is not half the work of 400%; to me, it's more like a tenth or less. That's because I don't think it will require a complete re-think of the existing UI, which is what I consider Isabela's layouts above to be.
Correct me if I'm wrong but I think 320 CSS px was chosen to ensure that web pages would be responsive across a very broad array of mobile devices. Perhaps it's okay for us to say that it's a higher priority for us to focus on the accessibility of the desktop experience (plus tablet).
I dunno, what are all of your thoughts?

Following up on the discussion from a few hours ago, we will be moving forward with working on this from 200% zoom. I don't think this changes much from a design perspective in the sense of interaction patterns and needing to free up space for the document.

Okay, here’s another idea for review! Please note that this is an opinionated take because I think it’s easier to critique that way. I have some issues with this solution—or at least questions that need more attention—so I’m expecting we’ll end up with a more moderate compromise.
The major changes:

This version continues to put the document area into focus at small sizes by removing some of the surrounding UI and adding it to the command palette.
The command palette is given a button for easy access, and regions that collapsed have sections to group their commands pinned to the top.
Open document tabs are grouped and hidden behind the ellipses, but switching them does not open new browser tabs.
UI areas originally in the sidebar become their own tab in the document area a la the launcher or settings. UI areas that are reliant on a selection in the main area appear as an overlay to the tab, but this should be used with discretion.

All at once, here’s a basic set of interactions for when users zoom and and how they might navigate when the layout changes.
https://user-images.githubusercontent.com/50221806/193075376-bab8ac9f-f409-410f-8228-238fdf1edcdf.mov
Breaking that down, I’ll explain key points with notes.

The main menu and both sidebars disappear at 200% and not before. Document name/open tabs are at the top followed by the document menu if the document type has one. Any document specific UI (like the notebook cell toolbar) would stay.

The command palette stays as an overlapping dialog-like thing. Pinned at the top are sections for easy navigation of the UI areas removed, in this case the main menu and side bars. I do believe this could be open so that extensions could opt in to add themselves as well, so I like the potential for it to scale even if it’s not our main concern. I do think all commands we add should be available in the command palette at all times, but they may not need to be pinned by UI when the main menu and side bars are visible at lower zooms.

Areas from the sidebars that are not document-reliant can open as their own tabs. For example, the file browser can exist totally separate from all open documents. This behavior matches the launcher and settings. Tabs also can be listed for easy switching without relying on the main menu or sidebar options that are less available. I think this should exist for JupyterLab at any zoom level, to be honest.

Areas from the sidebars that are document-reliant can open as some kind of overlap. For example, the table of contents is generated based on the open document selected and can’t work without a document chosen. I don’t love having these two behaviors at once, but it’s what I have for the time being.

Finally, this shows how the approach can scale to 400% browser zoom. I know 200% is the current focus, but I think it’s worth noting. I also think this can work with different screen orientations.
Questions that might help you get the feedback muscles moving!

How do you think this compares with JupyterLab’s current behaviors at 100% zoom and higher?
What problems and edge cases can you think of facing with removing areas of the UI? Or with the ones I’ve proposed adding?
What technical constraints come to mind?
What UI do you think does a good job at this?
What parts do you like? Why do you like them. You can do the same for dislikes.

Thanks @isabela-pf for amazing work, and once again providing the scaffold for us to have concrete conversations.
I have some thoughts that I want to break down into two sections. In the first section I remain a bit abstract. And in the second section, I try to offer thoughts that are more concretely tied to Isabela's idea.
Translating Dimensions
I think one of the biggest challenges we face with WCAG 1.4.10, or making JupyterLab work at 400% zoom (or 320 CSS px) is that much of the JupyterLab UI was built around the assumption of having enough space to work with in both the x and y dimensions. Let's take the Contextual Help feature for example. You can get to it by right-clicking on a code cell and clicking "Show Contextual Help" near the bottom of the context menu that pops up on right click. That opens up a Contextual Help tab to the side of the notebook document tab. So together, the notebook and contextual help are displayed side-by-side. It looks like this:

We could keep going like this, pulling up example after example of how the current UI has been built around the assumption of having horizontal space to work with. (We could also pull up examples of the how the current UI has been built around a similar assumption in the y/vertical dimension. For example, in the left sidebar, if the vertical space reduces too far, some of the buttons disappear and you cannot scroll to them.)
But I think that in order to properly meet the 1.4.10 guideline, we will have to translate that UI paradigm from x and y to y and z, by which I mean, we will have to think about pulling things that are laid out horizontally and stacking them vertically, and whenever we can't stack them vertically, we'll have to stack them on top of each other in the z axis (the axis coming out of the screen). Let's take the Contextual Help feature, as an example. Instead of opening it to the side, we could imagine opening it as a modal. As another example, I don't think we've considered taking the sidebars and laying them out horizontally instead of vertically.
To continue on that last thought, I could imagine getting rid of the top menu bar (File, Edit, View, etc.) and replacing it with a band at the top that acts as a kind of app switcher. The File Browser would be an app, the Open Tabs and Kernels would be an app, as well as the Table of Contents, the Extension Manager, the Debugger, the Property Inspector, the Settings Editor, the Launcher, the Notebook Editor, and so forth.
But I think translating (x, y) to (y, z) is a pretty drastic refactor of the UI, which is why I've had my doubts about being able to meet this WCAG guideline.
More Concrete Thoughts
That said, I'd like to offer some thoughts on Isabela's idea. I'm not sure how to organize my thoughts, so apologies for the stream of consciousness.
First of all, I think the idea of getting all commands into the command palette is a really smart idea. Whatever route we decide to go down, I think having an always-visible button that opens the command palette is an accessibility feature that we should consider adding to JupyterLab.
Secondly, I still see this as a kind of mobile-first renovation of the JupyterLab UI. On Monday, it might be worth discussing the trade-offs of going down that route versus one that attempts to patch reflow issues in a minimally invasive manner. In a previous conversation that I had one-on-one with Isabela, she pointed out that if we go down the route she proposes, it might save as much work as it creates. Specifically, we won't have to spend time fixing the various side panels if they disappear at 200%. But then again if the aim as suggested by the new 200% mocks above is to pull the side panels out from the side and into document tabs and on-top-of-document overlaps (or modals), then we're back to either having to create new UIs (such as the new open tabs UI imagined above) or having to fix these sub-UIs for narrow screens / high zooms (such as in a table of contents overlap at 200% or greater zoom).
Another thing—I'm sure you've already thought about this—but I'm not sure that it's feasible (from a usability perspective) to take the debugger panel out from its side position and into either a modal or separate tab. I'm not sure (perhaps for lack of imagination) how I would use a debugger without seeing two things at the same time: the code that I'm stepping through and the tools to step through that code. That said, I don't want to imply that I think we should abandon Isabela's proposal just because it may or may not work for one or two extensions that ship with JupyterLab by default. Because overall I think Isabela's designs are the best choice we have right now for the end user experience (over and above conforming to WCAG 1.4.10). The question that's been turning in my head, and for which I don't have a very confident answer, is whether it's feasible—or whether there's a more feasible route.
On a smaller note—the mocks above don't show this—but I think we should get rid of the status bar at 200%.
I hope some of that is helpful! :)


Possible to combine loading static xml file with pymjcf interface

I wanted to programatically modify the elements of a static xml file model I had made. For instance, I would want to randomize the radius of the spheres in my model at run-time.
I was wondering if there was a way to programatically modify the elements of a model loaded from an xml file.
That is, I want to be able to wrap a class with accessible mujoco attributes (such as the class Leg example in the tech report) around this .xml model after I load in the latter with,
physics = mujoco.Physics.from_xml_string(simple_MJCF)

Is there currently a way of doing this in dm_control?, since I couldn't find one in the documentation.

Alternatively if I could be pointed to documentation for transferring my .xml file into a pyMJCF model that would be great too

I see that this has been done here for the procedural n-pole cartpole model.
Closing Issue ....


Can AriaNg connect to aria2 service on the same server?

My aria2 deployed on cloud server, and I deployed AriaNg on the same instance. I don't want to expose aria2 on the internet but seems AriaNg can only access to exposed port. Can AriaNg connect to aria2 service on the same server?
Really looking forward to your reply, many thanks!

That's merely the same.
If you use AriaNg or anything to interconnect you and aria2 service, what could prevent others talk to the inter-connector?  You should always protect the interface with a strong token.
If you do not want to expose the fact that you are hosting an aria2 instance, you can protect it with one more layer of browser-persistent authentication like Basic Auth, by interconnecting with reverse proxy (such as Nginx).

Alright, maybe this feature is not compatible with ariang. I will close the issue.

And many thanks for your reply. @no1xsyzy


[FIX] Status bar position after device rotation

This is the source of problem about status bar position issue (#687) in Rocket Chat iOS App.

@falcaoaugustos Great, thank you!

Working fine! Thank you! 👍


One device and two Dev_EUI

Hi.
I have a device registration problem.
Manufacturer sent keys for ABP and OTAA.
On their server, with these keys, the device works fine, it does not work on the lover server.
I registered both ABP and OTAA, it doesn’t work
When I enter Dev_EUI when registering, in the server logs it gives out another maiden with this dev_adr. If I enter that maiden eui, which is issued in the logs, then in the logs it gives another dev_EUI. And in the server logs issued two different dev_EUI with one Dev_Addr
A very strange situation. In the screenshots I put everything
Frame counter disabled

For community support, please use the forum: https://forum.loraserver.io. You will find already some topics related to ABP and OTAA activation issues, so I recommend to use the search first.


How can I get the 2d joints from the SMPL mesh nptyfile

Hi
I want to transfer our 3d smpl mesh to 2d joints so that the generated 2d video could fit the MMPOSE but I don't know the landmark or the corresponding relationship between npy file and the 17 joint points.
It would be appreciate if you could give me some suggestion about  where I can find a way to finish it.
Thanks for your patient and help

You can refer to the writing method of this function:
app.py  load_motion()
to delve into the functions called in this function and refer to them to implement your requirements


More issues with parsing players

Similarly to #67 , we have some more failures due to players that cannot be found. I have attached a replay with the issue. This time it's a Netease replay
moju_vs_fly.zip

Netease appears to use exactly two CommandDataBlocks for metadata. They use an unknown playerId that does not exist as a valid SlotRecord or PlayerRecord. The first CommandDataBlock appears at 66ms of simulation time. The second seems to appear close to or at the end of the replay.
Since its just 2 blocks and they do not refer to playing players, skipping them is an easy to implement option.

Implemented with #72 and published as 2.3.0


EXC_BAD_ACCESS when accessing _moduleDataByName in RCTBatchedBridge.mm

I guess it will crash when reloading RCTBridge randomly. The variable _moduleDataByName is not thread safe.
The implementation of reload method, first stop and release modules, then re-init them.

- (void)reload
{
  dispatch_async(dispatch_get_main_queue(), ^{
    [self invalidate];
    [self setUp];
  });
}

A part of invalidate method, call on JavaScript queue. Set _moduleDataByName to nil.

dispatch_group_notify(group, dispatch_get_main_queue(), ^{
    [self->_javaScriptExecutor executeBlockOnJavaScriptQueue:^{
      [self->_displayLink invalidate];
      self->_displayLink = nil;

      [self->_javaScriptExecutor invalidate];
      self->_javaScriptExecutor = nil;

      if (RCTProfileIsProfiling()) {
        RCTProfileUnhookModules(self);
      }

      self->_moduleDataByName = nil;
      self->_moduleDataByID = nil;
      self->_moduleClassesByID = nil;
      self->_pendingCalls = nil;

      if (self->_flowIDMap != NULL) {
        CFRelease(self->_flowIDMap);
      }
    }];
  });

Then call the initModulesWithDispatchGroup on the main queue, init the value of _moduleDataByName.
For the invalid method has some async logic, setting and releasing _moduleDataByName may execute concurrently. It causes the memory problem.

It is unclear is this true or not, actually. Let's keep in open for visibility.
(T19226372)


Button with MenuFlyout doesn't work in tablet mode after instant drag of application

Describe the bug
In XAML ,a button with MenuFlyout doesn't work for tablet mode after instant dragging the app. Video link is attached. Same happens for tablet,space devices in tablet mode.
Steps to reproduce the bug
Steps to reproduce the behavior:

Go to "Tablet Mode"
Open any app contains button with MenuFlyout
3.Drag the app quickly
4.MenuFlyout won't work

Expected behavior
MenuFlyout should work
Screenshots
github link
https://drive.google.com/open?id=18hhdak4pckIjBIw0XngbmXSvAiPCPGTC
Additional context
Same result is noticed for the "XAML Controls Gallery" app in Microsoft Store

This is definitely broken.

Very weird bug! I debugged this and I can see that the Flyout is being asked to open and the flyout code thinks the popup is open. I also see the popup in the live visual tree so from the controls side we think it's visible. Over to rendering to dig further.

Very weird bug! I debugged this and I can see that the Flyout is being asked to open and the flyout code thinks the popup is open. I also see the popup in the live visual tree so from the controls side we think it's visible. Over to rendering to dig further.

Will it be fixed at later update version?


Cannot use with Stencil!

When installing @ ionic-super-tabs / core and following the example I was not successful!
Can anyone help me with this bug?


Error when using jquery-rails Gem

Hey! I've just tried to include jquery-rails within a project for middleman and I seem to be getting an error when the project builds after running middleman.

Added the following entry to my Gemfile:
gem 'jquery-rails'

Ran bundle install

Running middleman to build and start server throws the following

/Users/myusername/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/bundler-1.12.5/lib/bundler/runtime.rb:89:in `rescue in block (2 levels) in require': There was an error while trying to load the gem 'jquery-rails'. (Bundler::GemRequireError)
Gem Load Error is: uninitialized constant Rails

As far as I know there aren't any issues with the Gem because I was using this Gem on a new Rails project earlier this morning, didn't see any issues. Am I missing an additional step with Middleman or is this a bug?
Thanks very much. Ps - awesome project/tool!

@jbwebesign this isn't an issue with middleman. Middleman has no association with rails, but your gem (jquery-rails) require rails.
If you need jQuery, simply download the file and include it in your javascript directory.
Typically, these types of questions are a better fit for Stackoverflow (since this isn't a bug in middleman). Feel free to close this issue.

Okay cool noted, thanks


Fix typo in CRD doc

There is a typo in docs/custom-resource-defintion.md. filesystem in the FileSystem section should be fileSystem. It is trivial but can be misleading.

Why has this issue been closed? It is still wrong in the documentation.


Move Shortcut Context to control and fix shortcut_input with shortcut_context

Fixes #66356
When iterating nodes for handling shortcut_input:

Skip nodes which have no shortcut_context and leave them until the end.
This ensures that all nodes which do have a shortcut_context are tried first, then the "global" shortcuts.
Skip calling shortcut_input if the focus is not within the shortcut context.

See the reproduction project from the linked issue. If you run that without this PR, you should see the problems as explained in the issue. Build this PR and those issues are resolved.

Thanks!


Add 'Typed' Trove classifier

As we distribute our type hints it would make sense for us to add the new Typing :: Typed trove classifer to our setup.py

Awesome! I'll do that in a minute.


assets: branding rework

Closes #14
New homescreen icon:

Splashscreen:

Icon background color is the same as enyo/moonstone accent.
Up for comments.

Alt, a little bowed maybe? Seems a little more fitting to other homescreen icons maybe? Not sure.

Taking into consideration Korean origin of this software I'd like to propose to call it Kimchi Channel

Taking into consideration Korean origin of this software I'd like to propose to call it Kimchi Channel

Soju channel lol
I must say this design & color scheme looks amazing to me!

I've fixed logo offset as per last comment, merging.


Show path label on diff editors when other file with same name but different path is open

@bpasero implemented a path label for diff editors as discussed in #110694:

I found the following edge case in which the label doesn't work as expected and was asked to treat this as a separate issue:

Here, there are two different workbenchTestServices.ts files opened, one in .../common and one in .../browser, but only one of them is in a diff. I think both tabs should have a label here, because they would if both of them were a normal tab.

With other words: when two files with the same name but different paths are opened, I would expect both tabs to have a label with their respective path, even when one of the files is opened in diff.

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.
If you wonder what we are up to, please see our roadmap and issue reporting guidelines.
Thanks for your understanding, and happy coding!


Ars Nouveau spellbook/mana gets disabled when passing through an immersive portal

Is it a mod compatibility issue?
Yes
If it's a mod compatibility issue, please provide the link(s) to the incompatible mod(s)
https://modrinth.com/mod/ars-nouveau/
Minecraft version
1.20.1
Describe the issue
The Ars Nouveau mana system and spellcasting items become non-functional when the player passes through an Immersive Portals-style nether portal, with or without carrying the item in question. As a workaround, I found that passing through a vanilla-style nether portal fixes it (until the next time the player passes through an immersive portal).
Tested in singleplayer; I have no idea what happens in multiplayer.
I know that using Sinytra Connector (and thus, Ars Nouveau) is unsupported with Immersive Portals, so I'm submitting this mainly as an informational "this compat issue exists, here's a workaround" in case anyone else tries the same thing.

tested myself, the workaround for multiplayer is to just rejoin the server or also go thru a regular vanilla portal.

can confirm that this happens for most mods that tie-in directly with the player inventory. in my experience so far, this includes:

tetra toolbelt access, quick switch do not function and cause clientside desyncs
sophisticated backpacks hotkey and access do not function and cause clientside desyncs
weapon master weapons do not function at all

it's likely that most inventory-based effects break completely due to the lack of a proper loading screen because of the seamless nature of the cross-dimensional portals. i wouldn't be surprised if bauble effects and armor effects also break, too!
though as stated above, this is definitely sinytra jank and is easily fixable by reconnecting. just felt i should air this, too, as the issue is technically easily workaroundable but extremely widespread along many mods and quite annoying too


Update README.md

$callbacks example now uses callbacks directive

@ceetee can you explain this? The callbacks should still be passed via the ui-tree directive from what I can see.


Fold the comment section

The uttarances comment section doesn't fold. So when the number of comments is high, it gets tedious to scroll all the way down.

An option to hide and fold the comment section can improve readability here.

This is something you will have to contribute upstream to uttarances


Error code messages?

I'm wondering why the responds do not have a "error-message" that contains "The response parameter is invalid or malformed." just as one example.
e.g.
{
"success": false,
"error-codes": ["invalid-response"],
"error-message": "The response parameter is invalid or malformed."
}

I have a case open at https://www.drupal.org/node/2599804 we need to catch and handle where the HTTP connection may fail, too. I think error handling could be optimized in the library as it seems very inflexible or at least I'm not sure where to place the error handling.
If the submit post the content in Drupal7Post class it may return these predefined error codes, but drupal_http_request can also fail like fsocket does and may return a http status code like stdClass Object ( [code] => -101 [error] => Network is unreachable ). In such a case the libary tells the user invalid-json = "The json response is invalid or malformed" what is highly misleading to the root cause. The issue is the http request and not the responds from google.
I could now add a lot of error handling inside RequestMethod->submit(), but it looks strange that error handling is done in submit() and fromJson().
Where would you add it?

Closing super old issues. Please re-raise if still relevant.

Can you reopen this case, please? It is still valid.

Could you raise a new issue for this against the most recent version of the library. Additionally, you may want to try some of the other request methods, e.g.
$recaptcha = new \ReCaptcha\ReCaptcha($secret, new \ReCaptcha\RequestMethod\SocketPost());

That is waste of time. Please reopen the case. I cannot use SocketPost as we use Drupal8Post().

If the connection failed, would it work for you if the service returned this?
{
  "success": false,
  "error-codes": [
    "bad-connection"
  ]
}

That should work fine. Can you create a new release soon?

v1.2.1 released.


Rename is Patient Mobility and Health Assessment Form as Nurse-lead Home Care Form

Rename is form as Nurse-lead Home Care Form

can I work on this issue @athulmanuel

Is this issue in progress or shall i raise a PR? @bodhish

Is this issue in progress or shall i raise a PR? @bodhish

This is in the form-field-v1 branch, which is not yet open to interns and contributors :)

This is a database change and not a code change;

Sure...


feat(client): ecrecover accelerated precompile

Overview
Adds a host-accelerated precompile for ecrecover with the FPVM backend.

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#342  👈
#340
#339
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @clabby and the rest of your teammates on  Graphite

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 77.8%. Comparing base (7294773) to head (86a65d3).

Additional details and impacted files

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


hilbert: implement paper version of MJ's 1dPart()

Tried to implement the 1DPART function from multijagged paper. It mostly works imbalance-wise, though there might be some edge cases that need to be covered and off-by-one errors to be fixed, I'm not 100% sure about the split indices.
TODO

[x] perf tests

Closes #201

Splitting a 3D mesh (30 million cells) into 64 parts:

non-generic: https://github.com/LIHPC-Computational-Geometry/coupe/pull/240/commits/d409b6fe78bc675df5231514d6f47b4cf3056945
generic: https://github.com/LIHPC-Computational-Geometry/coupe/pull/240/commits/8e9cd0556f2437081612d56db6f30c4ec0397ec3

generic impl incurs a 15-30% penalty, maybe because of (lack of) vectorisation.
non-generic impl has x2.5 speedup compared to master

It seems on high core counts, generic vs non-generic doesn't matter

Results on a 93-million-cell 3D mesh, split in 4096 parts really show the duplicate work bug in low core count runs:


Cannot decode BASE64 generated string into image

PHP:
header('Content-Type: image/jpeg');
$data = file_get_contents("pic.jpg");
echo base64_decode($data);

If you specify OutputType as BASE64, the ENTIRE new html document (as a string) will be coded as base64 - not just the image data.
The images inside your web page are coded to base64 data url in any case, no matter what you specify as the desired output type for the whole web page.


Generalize similars resources in one route

Hi, we have a resource credit-card-payments and another resource wire-transfer-payments. We want them to be accessible through a general payment endpoint:
POST /payments
PATCH /payments/:id
GET /payments
GET /payments/:id

When creating or updating the resources, we specify the type so the server knows which resource (wire-transfer-payments or credit-card-payments) is dealing with. Also, when fetching all the payments, we get a mixed list of wire-transfer-payments and credit-card-payments, so there's no problem there either.
The problem comes when fetching a specific payments resource. Where the type of the resource (wire-transfer-payments or a credit-card-payments) be passed so the server can handle it?
We thought of using a query-param like GET /payments/:id?type='credit-card-payments' but it doesn't feel like the best approach.
What would you recommend?

Questions like this are best posted to our discourse: http://discuss.jsonapi.org/
Thanks!

So I've been with my discuss account on hold for 20 days now. What can I do about it?

@chamini2 sorry! I just approved your post on discuss. Not sure why it got flagged - usually that does not happen.
http://discuss.jsonapi.org/t/generalize-similars-resources-in-one-route/617

Thanks!


Update Readme

Readme can be updated with details of mentors,admins,slack channels and details of gssoc. Please assign me this issue.

This is not a GSSOC specific project, I don't think we need that in README.


create_model with fields using Field and default_factory fails due to missing field type

Checks

[x] I added a descriptive title to this issue
[x] I have searched (google, github) for similar issues and couldn't find anything
[x] I have read and followed the docs and still think this is a bug

Bug
Output of python -c "import pydantic.utils; print(pydantic.utils.version_info())":
             pydantic version: 1.8.2
            pydantic compiled: True
                 install path: /Users/<snip>/Documents/virtual-environments/<snip>/lib/python3.9/site-packages/pydantic
               python version: 3.9.5 (default, May  4 2021, 03:36:27)  [Clang 12.0.0 (clang-1<IP_ADDRESS>)]
                     platform: macOS-11.4-x86_64-i386-64bit
     optional deps. installed: ['devtools', 'dotenv', 'typing-extensions']

searched for instances of create_model in open issues and none looked like they matched.
Example of issue:
import pydantic

countries = ['us', 'nz', 'au']

class Child(pydantic.BaseModel):
    score: float = 0

Parent = pydantic.create_model(
    'Parent',
    **{cc: pydantic.Field(default_factory=Child) for cc in countries},
)

test = Parent()

results in:
Traceback (most recent call last):
  File "<input>", line 8, in <module>
  File "pydantic/main.py", line 990, in pydantic.main.create_model
  File "pydantic/main.py", line 323, in pydantic.main.ModelMetaclass.__new__
  File "pydantic/fields.py", line 411, in pydantic.fields.ModelField.infer
  File "pydantic/fields.py", line 342, in pydantic.fields.ModelField.__init__
  File "pydantic/fields.py", line 445, in pydantic.fields.ModelField.prepare
  File "pydantic/fields.py", line 467, in pydantic.fields.ModelField._set_default_and_type
pydantic.errors.ConfigError: you need to set the type of field 'us' when using `default_factory`

the create_model doc string suggests this code should work:
:param field_definitions: fields of the model (or extra fields if a base is supplied)
    in the format `<name>=(<type>, <default default>)` or `<name>=<default value>, e.g.
    `foobar=(str, ...)` or `foobar=123`, or, for complex use-cases, in the format
    `<name>=<FieldInfo>`, e.g. `foo=Field(default_factory=datetime.utcnow, alias='bar')`

from datetime import datetime
import pydantic

Test = pydantic.create_model(
    'Test',
    xxx=pydantic.Field(default_factory=datetime.utcnow)
)

test = Test()

however this also results in:
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "pydantic/main.py", line 990, in pydantic.main.create_model
  File "pydantic/main.py", line 323, in pydantic.main.ModelMetaclass.__new__
  File "pydantic/fields.py", line 411, in pydantic.fields.ModelField.infer
  File "pydantic/fields.py", line 342, in pydantic.fields.ModelField.__init__
  File "pydantic/fields.py", line 445, in pydantic.fields.ModelField.prepare
  File "pydantic/fields.py", line 467, in pydantic.fields.ModelField._set_default_and_type
pydantic.errors.ConfigError: you need to set the type of field 'xxx' when using `default_factory`

Misunderstood documentation, turns out the following works:
import pydantic

countries = ['us', 'nz', 'au']

class Child(pydantic.BaseModel):
    score: float = 0

Parent = pydantic.create_model(
    'Parent',
    **{cc: (Child, pydantic.Field(default_factory=Child)) for cc in countries},
)

test = Parent()

This line in the docs appears incorrect the way I read it, and is in line with your initial report. Looks like that could use a fix?


Grunt upgrades and API improvements

upgrades grunt dependencies to v1.0.1
removes the pkg.name requirement, but leaves it as a fallback.

the new option is mainService. It may be specified if the name of the "main" service isn't equal to (package.json).name field

adds logTail option. Defaults to 10 lines. May be set to specify the number of lines to tail initially when logging. This fixes the appearance of the log command "hanging" if there are no new lines to log.

👍


Refactors all common from MultiResource and Equippables

This includes events, all internal variables except for resources and all functions which do not require access to resources, since structs are different in both implementations.

This is the new layout


Back to top button implemented

Fixes issue ##97
what I did :

Button component imported to footer component from chakra-ui/react
Button component added to the footer
ArrowTopIcon imported from chakra icons and added to the Button component
Arrow icon styled to be responsive
Button component Styled to be at the top left of the footer
Button component Styled to be responsive
Functionality added to footer component as handeGoToTop function and added to onClick event on Button component
For details check the code

GIF of result ( wait for load )

Consideration
I highly recommend refactoring your code to make it more scalable, maintainable, and testable. It should also adhere to best practices such as component reusability, composition, SOLID principles, DRY, and clean code.
If you have any questions, please feel free to ask. Otherwise, let me know if you are satisfied with the changes BY merging this PR. Thanks., sky-De

Thank you! It looks good, I just added a tiny bit more to clean up some UI issues from our old code. And thanks for the considerations, too, we didn't expect to add this much this quickly, but we'll definitely work on cleaning it up in the future.

@unkn-wn thank you, your welcome

@unkn-wn , may I ask you a favor? I'd appreciate it if you could take a look at my Portfolio   and other projects. Please let me know what you think about them, and if you like them, please give them a STAR. All public projects can be found in the PROJECTS section of my portfolio. Within that section, you can find live demo links as well as repository links related to each project. And if you like my project please mention other colleagues of these projects here to check my Portfolio , thanks


Further step_or_park implementations [WIP]

This PR is a work in progress of await_events methods for communicators which enable the step_or_park functionality. The first commit adds preliminary support for the intra-process allocator (not the serializing one). It has not been tested beyond the standard test suite (which has a few multi-worker tests, but not many).

Heads up to @comnik @ryzhyk @benesch
The current version seems to work with the examples/barrier.rs using multiple workers, using step_or_park rather than step.
The downside is that it slows things down in this benchmark, from about 6s using two workers to about 9s. Something like this is to be expected, as threads may now be parked where they would otherwise be just about to receive some more work to do, and so get unparked, and .. it wasn't going to go faster for sure.
So, latency has the potential to increase, significantly in tight loops, which may mean that users need to be smart (only park after so many microseconds of no work). We may need to communicate more back to the user (I don't think they can tell if there was no work).
If anyone wants to take this out for a spin and see how it looks, that would be great. There are still certain operators that will keep a worker live and spinning (e.g. replay, and sources that poll without smarter timeouts), but folks could plausibly get timely to chill out when there are no new inputs and outputs have caught up.

Oops. Except some tests fail now that I actually started calling the code correctly. Await further instructions!

I believe this is now in a plausibly functional state. I'll look in to adding the other implementations soon; it was surprisingly easy for the MPSC case (modulo bugs we haven't found yet)!

So David (I can't seem to tag him here) reports that the original single-threaded step_or_park implementation is working for us. He did run into the missing implementation for the generic allocator, but that shouldn't be a problem on this branch. We haven't tried this one yet, but the basic usage model seems to fit our needs.
Thanks a lot for this!

Yes, that missing implementation meant that for a while default timely wasn't even using any of the new code. That got added and things should be actually parking now. :)

Ok, we swapped Declarative around to make use of this. We settled on this: https://github.com/comnik/declarative-dataflow/blob/7c344c5496d7b7a1040c3552a661312e1e2f7e96/server/src/main.rs#L712, where we perform a fixed number of non-parking steps, then advance traces, and only after that step_or_park until the next scheduled activation.
The reasoning was that doing step_or_park() in the loop seemed a bit wasteful, and potentially dangerous in terms of blocking network inputs further up the loop. And advancing before the final step_or_park gives us a chance to do some useful work (merging) before going to sleep.
Unfortunately the dependency mess foiled my attempt at running this with this PR included, I'll try that again later.

[...] and potentially dangerous in terms of blocking network inputs further up the loop.

My guess is that the right idiom here will probably be to have any thread calling step_or_park(None) first hands out a copy of its Thread to anyone who wants to point IO at it. If you have a connection handling thread, it should probably be able to wake up the worker thread just after enqueueing something for it to read.
If the worker threads wants to regularly perform network IO itself, then it should probably call either step() or step_or_park(Some(small)).
Any pushback on the appropriateness of the threading model is welcome, of course, but everyone wants to be the one to own blocking and unblocking of threads, so it is hard... :)

No I think the trade-off is good that way :) Our only risk now is a bit of delay in accepting client inputs (which are not latency critical anyways), I think, and we can always move to a dedicated networking thread.

Tried again on this branch. With a single process, everything seems to work fine, with significantly reduced cpu usage. However in intra-process configurations, weird things happen.

With n2 w1, the Timely sequencer is suddenly routing inputs incorrectly, s.t. they arrive at the worker whence they came from.

With n>2, w1, all processes panic (once they are all connected), claiming a "Failed to send MergeQueue".

I've clearly screwed something up then. :)  I'll take a peek on Thursday at the earliest, I'm afraid!

Peek taken, and at least one bug fixed. Small examples seem to work at the moment, in multi-process mode.

Things seem to work correctly now :) Tested all configurations.


[SPARK-25556][SPARK-17636][SPARK-31026][SQL][test-hive1.2] Nested Column Predicate Pushdown for Parquet

What changes were proposed in this pull request?

DataSourceStrategy.scala is extended to create org.apache.spark.sql.sources.Filter from nested expressions.
Translation from nested org.apache.spark.sql.sources.Filter to org.apache.parquet.filter2.predicate.FilterPredicate is implemented to support nested predicate pushdown for Parquet.

Why are the changes needed?
Better performance for handling nested predicate pushdown.
Does this PR introduce any user-facing change?
No
How was this patch tested?
New tests are added.

Test build #119057 has started for PR 27728 at commit 79c2b29.

Merged build finished. Test PASSed.

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

Test build #119057 has finished for PR 27728 at commit 79c2b29.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
public final class NestedFilterApi

Merged build finished. Test FAILed.

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

cc @dongjoon-hyun @rdblue @gatorsmile @cloud-fan @hvanhovell @viirya @MaxGekk @HyukjinKwon

Merged build finished. Test PASSed.

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

Test build #119059 has started for PR 27728 at commit 400aebe.

Test build #119060 has started for PR 27728 at commit 3a2fb39.

Merged build finished. Test PASSed.

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

Test build #119061 has started for PR 27728 at commit 4b27c82.

Merged build finished. Test PASSed.

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

Thank you, @dbtsai !

Test build #119061 has finished for PR 27728 at commit 4b27c82.

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

Merged build finished. Test FAILed.

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

Test build #119059 has finished for PR 27728 at commit 400aebe.

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

Merged build finished. Test FAILed.

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

Test build #119060 has finished for PR 27728 at commit 3a2fb39.

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

Merged build finished. Test FAILed.

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

Test build #119102 has started for PR 27728 at commit 0ae261d.

Merged build finished. Test PASSed.

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

Test build #119102 has finished for PR 27728 at commit 0ae261d.

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

Merged build finished. Test FAILed.

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

Test build #119104 has started for PR 27728 at commit 6972b54.

Merged build finished. Test PASSed.

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

Merged build finished. Test PASSed.

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

Test build #119106 has started for PR 27728 at commit a1b0c32.

Test build #119107 has started for PR 27728 at commit 2da3737.

Merged build finished. Test PASSed.

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

Merged build finished. Test PASSed.

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

Test build #119108 has started for PR 27728 at commit 784d372.

Test build #119109 has started for PR 27728 at commit c706fe5.

Merged build finished. Test PASSed.

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

Test build #119107 has finished for PR 27728 at commit 2da3737.

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

Merged build finished. Test FAILed.

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

Test build #119104 has finished for PR 27728 at commit 6972b54.

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

Merged build finished. Test FAILed.

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

Test build #119106 has finished for PR 27728 at commit a1b0c32.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
public final class NestedFilterApi

Merged build finished. Test FAILed.

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

Test build #119109 has finished for PR 27728 at commit c706fe5.

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

Merged build finished. Test FAILed.

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

Test build #119108 has finished for PR 27728 at commit 784d372.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
public final class NestedFilterApi

Merged build finished. Test FAILed.

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

Test build #119185 has started for PR 27728 at commit af72b3b.

Merged build finished. Test PASSed.

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

Overall, this looks good to me. Only a couple minor points.

Test build #119185 has finished for PR 27728 at commit af72b3b.

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

Merged build finished. Test FAILed.

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

Test build #119192 has started for PR 27728 at commit 2eafaf3.

Merged build finished. Test PASSed.

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

Test build #119193 has started for PR 27728 at commit c170288.

Merged build finished. Test PASSed.

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

Test build #119194 has started for PR 27728 at commit 77ea177.

Merged build finished. Test PASSed.

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

Test build #119192 has finished for PR 27728 at commit 2eafaf3.

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

Merged build finished. Test PASSed.

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

Test build #119193 has finished for PR 27728 at commit c170288.

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

Merged build finished. Test PASSed.

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

Test build #119194 has finished for PR 27728 at commit 77ea177.

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

Merged build finished. Test PASSed.

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

Retest this please.

Test build #119248 has started for PR 27728 at commit 77ea177.

Merged build finished. Test PASSed.

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

Test build #119248 has finished for PR 27728 at commit 77ea177.

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

Merged build finished. Test FAILed.

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

@dbtsai . You can address the above comments in the spin-off PR.

https://github.com/apache/spark/pull/27778

Retest this please.

Test build #119253 has started for PR 27728 at commit 77ea177.

Merged build finished. Test PASSed.

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

Test build #119256 has started for PR 27728 at commit 77ea177.

Test build #119260 has started for PR 27728 at commit 3fde48c.

Merged build finished. Test PASSed.

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

Test build #119260 has finished for PR 27728 at commit 3fde48c.

This patch fails Scala style tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
public final class SparkFilterApi

Merged build finished. Test FAILed.

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

Test build #119266 has started for PR 27728 at commit 2c65b17.

Merged build finished. Test PASSed.

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

Test build #119253 has finished for PR 27728 at commit 77ea177.

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

Test build #119256 has finished for PR 27728 at commit 77ea177.

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

Merged build finished. Test FAILed.

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

Merged build finished. Test FAILed.

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

Test build #119266 has finished for PR 27728 at commit 2c65b17.

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

Merged build finished. Test PASSed.

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

Test build #119350 has started for PR 27728 at commit 78b1a71.

Merged build finished. Test PASSed.

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

Test build #119353 has started for PR 27728 at commit ea2c495.

Merged build finished. Test PASSed.

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

Test build #119350 has finished for PR 27728 at commit 78b1a71.

This patch passes all tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
public final class SparkFilterApi

Merged build finished. Test PASSed.

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

Test build #119353 has finished for PR 27728 at commit ea2c495.

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

Merged build finished. Test PASSed.

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

Test build #119492 has started for PR 27728 at commit 078b5b5.

Merged build finished. Test PASSed.

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

Test build #119492 has finished for PR 27728 at commit 078b5b5.

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

Merged build finished. Test PASSed.

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

Merged build finished. Test PASSed.

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

Test build #119627 has started for PR 27728 at commit 393d88d.

Merged build finished. Test PASSed.

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

Test build #119627 has finished for PR 27728 at commit 393d88d.

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

Merged build finished. Test PASSed.

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

Test build #120117 has started for PR 27728 at commit 8d9ab48.

Merged build finished. Test PASSed.

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

Test build #120117 has finished for PR 27728 at commit 8d9ab48.

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

Merged build finished. Test PASSed.

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

Merged build finished. Test PASSed.

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

Test build #120225 has started for PR 27728 at commit 22a7a00.

Test build #120225 has finished for PR 27728 at commit 22a7a00.

This patch fails PySpark pip packaging tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Jenkins, test this again.

Test build #120304 has started for PR 27728 at commit c40f5d0.

Merged build finished. Test PASSed.

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

Test build #120305 has started for PR 27728 at commit e9944e5.

Merged build finished. Test PASSed.

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

Test build #120307 has started for PR 27728 at commit 44b310e.

Merged build finished. Test PASSed.

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

Test build #120307 has finished for PR 27728 at commit 44b310e.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Test build #120305 has finished for PR 27728 at commit e9944e5.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Test build #120304 has finished for PR 27728 at commit c40f5d0.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Merged build finished. Test FAILed.

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

Merged build finished. Test FAILed.

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

Retest this please.

Test build #120323 has started for PR 27728 at commit 44b310e.

Merged build finished. Test PASSed.

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

Test build #120323 has finished for PR 27728 at commit 44b310e.

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

Merged build finished. Test PASSed.

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

Test build #120393 has started for PR 27728 at commit 4883e68.

Merged build finished. Test PASSed.

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

Merged build finished. Test PASSed.

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

Test build #120401 has started for PR 27728 at commit f732664.

Looks fine to me too

Test build #120401 has finished for PR 27728 at commit f732664.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Test build #120393 has finished for PR 27728 at commit 4883e68.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

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

Merged build finished. Test FAILed.

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

Retest this please.

Test build #120410 has started for PR 27728 at commit 5fd97c0.

Merged build finished. Test PASSed.

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

Test build #120410 has finished for PR 27728 at commit 5fd97c0.

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

Merged build finished. Test FAILed.

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

retest this please

LGTM pending jenkins

Test build #120422 has started for PR 27728 at commit 5fd97c0.

Merged build finished. Test PASSed.

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

Test build #120422 has finished for PR 27728 at commit 5fd97c0.

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

Merged build finished. Test PASSed.

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

thanks, merging to master/3.0!

Hi, @cloud-fan .
Could you fix the build failure in branch-3.0? It's a conf version issue which occurred multiple times before.

https://github.com/apache/spark/commits/branch-3.0

[ERROR] [Error] /home/runner/work/spark/spark/sql/catalyst/src/main/scala/org/apache/spark/sql/internal/SQLConf.scala:1867: value version is not a member of org.apache.spark.internal.config.ConfigBuilder

I made a hotfix PR.

https://github.com/apache/spark/pull/28046

Thanks @dongjoon-hyun.

Thank you, @cloud-fan @HyukjinKwon @rdblue @viirya @dongjoon-hyun and @holdenk, etc for reviewing!!!

Ping @MaxGekk , are you interested in working on ORC version of it?

@dbtsai Great work! Could you show some perf number ?

It really depends on the data and if we can skip most of the row group by having a predicate in nested field. For our production jobs, we are able to get 20x speed-up in clock time, and 8x less data being read. I will create a synthetic benchmark for this feature.

Do you know the perf number for the worst case (e.g., no row can be filtered out)?

It's true that it can depends on the nature of data or workloads of course but I think it makes sense to at least have a benchmark though.

For the worst case, we don't see extra overhead from parquet side. I agree that we should have benchmark suite for best (filtering out everything in a row group) and the worst case that nothing is filtered out in a row group.


Dependency of future

Hello. I see that the project depends on future. I can find only a single usage of it in the codebase.
https://github.com/theojulienne/PySignals/blob/832b2c6733fd8e25dcfa893c8b9929e13e7c6352/pysignals/dispatcher.py#L6
Do you think it's still useful? I'm asking because future is broken with the latest Python 3.12 and will be even more with 3.13 so it might be a good idea to get rid of it.

It's been a while since I've looked at the codebase, but you're right it looks like pysignals just uses the range function one time.
I'm not opposed to rewriting this.
However, have you contacted the authors of the python-future project to determine when they plan to resolve the issue?
It looks like this is a known issue and indeed there is even a PR to fix, at least one problem, with python 3.12:
https://github.com/PythonCharmers/python-future/issues/618
What environment are you working in?
I can see in Fedora that this patch has been applied and python-future is building fine for that distro:
https://src.fedoraproject.org/rpms/future/blob/rawhide/f/future.spec#_36

You are right, we've managed (in Fedora) to patch the sources and also create a new Python package called zombie-imp which contains the imp module removed from the standard library to make the future package work with Python 3.12. However, the plan for 3.13 is to also remove lib2to3 from the standard library, which is I'd say the core of future and I'd rather remove the dependency on future in projects where it's possible and doesn't mean a lot of work rather than fix the old library.
Moreover, many packages have future in the list of dependencies even if they do not use it at all or they use one little thing from it and it's simple to rewrite even without dropping Python 2 support.

And it!s already removed: https://github.com/python/cpython/issues/104780

Understood. Thank you for the explanation.
I'll get this fixed in this upstream repo then build a new pysignals package in Fedora repos.

Because we are using range in a For loop, it turns out this project didn't even need python-future after-all. The native behavior of range in python 2 or 3 will work just fine.


Enhance tspline surface evaluation (connect patches to one mesh)

Evaluate vertices in face with given resolution and connect them with a grid.
Evaluate vertices on edges and link them to grid vertices in both faces.
Calc resolution by distance between control points/face size.

Do research with keywords "rendering nurbs tesselation"


No consistent code examples. Some in C++, some in C#.

Some of the code examples on this page are only in C++, and some are only in C#. Why not both languages, like the rest of the examples.

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

ID: 0c0e5014-68c8-fb33-bf35-117c7b217c56
Version Independent ID: 0c0e5014-68c8-fb33-bf35-117c7b217c56
Content: Quickstart App notifications in the Windows App SDK - Windows apps
Content Source: hub/apps/windows-app-sdk/notifications/app-notifications/app-notifications-quickstart.md
Product: reunion
Technology: ****
GitHub Login: @vaheeshta
Microsoft Alias: vmehrshahi

@loneursid @drewbatgit

@pbruins84 Thanks for the feedback, and I agree that this is an issue. We are currently working on re-creating this page entirely. The new page will have C# and C++ code sample tabs. It will also work standalone from empty project to working app rather than using snippets from the github code sample that don't work in isolation. This is part of a larger reorganization of the app notifications content, so I don't have an ETA for when these updates will be live. But they are in progress.

@pbruins84 Thanks for the feedback, and I agree that this is an issue. We are currently working on re-creating this page entirely. The new page will have C# and C++ code sample tabs. It will also work standalone from empty project to working app rather than using snippets from the github code sample that don't work in isolation. This is part of a larger reorganization of the app notifications content, so I don't have an ETA for when these updates will be live. But they are in progress.

This is great news! I can't tell you how many times I'd wanted to use sample code from either the WinUI 2 or WinUI 3 Gallery apps only to later find that I was missing a large amount of context and that code wouldn't actually function despite being advertised as a "copy-paste-go" solution.

Sorry for the delay in getting these code samples updated. This is still planned work, but it has just been deprioritized against other work. It is planned to restart this effort in the coming months. As we transition to a new feedback system, we are closing all outstanding issues, but this issue will continue to be tracked internally.


Logout doesn't work properly

Auth token is not invalidated when user logs out using UI

open demo.almighty.io, login and open console
in console: let auth_token = localStorage.getItem('auth_token')
log out using link in top-right corner
in console: localStorage.setItem('auth_token', auth_token)
refresh the page
create new item using quick add component

@ppitonak yes, we don't have expiration in backend right now. Your steps would clearly make the user logged in again. In order to fix this we need to have an endpoint where we can expire the token from backend itself on login.
@aslakknutsen what do you think?

Points to be noted:

The token needs to be stored locally until the user logs out. This is one of the UX requirements where the user remains logged in even if they close the browser.

The token is a Github token. The same token is generated based on who logs in. In this scenario, currently the core cannot invalidate the token.

@ppitonak @joshuawilson @aslakknutsen could you let us know on how do we proceed with this?

@kbsingh do you have any insight into this?


Calibrating locked controller into 100%

Basically, I wanted to calibrate my Dualsense, and when I finished the find midpoint steps. My controller has now been locked into a 100% state, only Diagonal corners. I hit reset on the web, and it didn't help. This is a brand-new controller, BDM-040(CFIZCT1B) - firmware 0458 that's been used less than a month. Just wanted to test seeing if I can get Err % down. But, unfortunately, I've encountered the reverse.
I only used the GUI of the website to calibrate alongside gamepad-tester when this happened. Here's an image of the 100% in diagonal directions, only the corners I'm able to move and when I press a direction, it holds it.
Seeing that, it is likely to brick a controller if one was using the DS4-tool python. But, possible through the GUI as well? I only did midpoint steps when this happened after finishing. Any fix, or lost cause?

Something must have been wrong with my Chromium Browser. I switched to another browser, Chrome, and were able to calibrate the stick range permanent. I was able to do the test without it auto-completing the test.

I am also having this issue even using chrome

Hi, do again the range calibration following the instructions (aka click on the button, slowly rotate the sticks and click continue when done). If the window opens and closes instantly, there are issues with your browser. Clear the caches, try in incognito or change browser.


Change string formats to closer to Rust syntax?

The dtypes already look like Rust (u32, f64 etc.) The current string syntax is rather arbitrary and basically what looked good to me, but it's pretty much covered by similar Rust constructions.
Field:
dtype <name> = value -> name: dtype = value
FieldArray:
dtype * items <name> = value -> name: [dtype; items] = value
Unlike Rust the name: here is optional and the dtype is compulsory.
There may well be a need for an equivalent to the Rust struct. Basically that would be a Format that's limited to containing Field and FieldArray types??
Compare
struct User {
    active: bool,
    username: String,
    email: String,
    sign_in_count: u64,
}

to
user = Struct([
    'active: bool',
    'username: bytes',
    'email: bytes',
    'sign_in_count: u64'
])

The expression syntax with the {value} already looks quite Rust-like.
The Format I think should stay the same as it's more the overall logic. Perhaps Repeat has a better name or format?

Done, except for separate Struct, which I don't think is needed.


mpv-quality-menu

Project description
The mpv quality menu is an userscript for MPV that allows the user to change the streamed video and audio quality (ytdl-format) on the fly.
The mpv quality menu is the successor to the package youtube-quality that is currently broken when used with the last mpv versions.
You can see the error below (i don't know enough lua to understand the problem myself):
[youtube_quality]
[youtube_quality] stack traceback:
[youtube_quality] 	...nstable-2020-02-11/share/mpv/scripts/youtube-quality.lua:210: in function 'download_formats'
[youtube_quality] 	...nstable-2020-02-11/share/mpv/scripts/youtube-quality.lua:81: in function 'fn'
[youtube_quality] 	mp.defaults:230: in function 'fn'
[youtube_quality] 	mp.defaults:65: in function 'handler'
[youtube_quality] 	mp.defaults:380: in function 'handler'
[youtube_quality] 	mp.defaults:510: in function 'call_event_handlers'
[youtube_quality] 	mp.defaults:552: in function 'dispatch_events'
[youtube_quality] 	mp.defaults:503: in function <mp.defaults:502>
[youtube_quality] 	[C]: in ?
[youtube_quality] 	[C]: in ?
[youtube_quality] Lua error: ...nstable-2020-02-11/share/mpv/scripts/youtube-quality.lua:210: attempt to concatenate global 'err' (a nil value)

I propose to introduce https://github.com/christoph-heinrich/mpv-quality-menu to nix to provide a working alternative.
Metadata

homepage URL: https://github.com/christoph-heinrich/mpv-quality-menu
source URL: https://github.com/christoph-heinrich/mpv-quality-menu/releases/tag/v3.0.1
license: gpl2+
platforms: unix, linux, darwin
(it should work everywhere mpv can )

I tried to make a derivation, I should have something that look likes https://github.com/NixOS/nixpkgs/blob/nixos-22.11/pkgs/applications/video/mpv/scripts/youtube-quality.nix soon.
{ lib
, stdenvNoCC
, fetchFromGitHub
, oscSupport ? false
}:

stdenvNoCC.mkDerivation rec {
  pname = "mpv-quality-menu ";
  version = "v3.0.1";

  src = fetchFromGitHub {
    owner = "christoph-heinrich";
    repo = "mpv-quality-menu";
    rev = "${version}";
    sha256 = "1ds7sssi8gcm6bvya8wj6p8s05nbcwrrwizylgx64d8rxs5p3dp9";
  };

  dontBuild = true;

  installPhase = ''
    runHook preInstall
    ls
    mkdir -p $out/share/mpv/scripts
    cp quality-menu.lua $out/share/mpv/scripts
  '' + lib.optionalString oscSupport ''
    cp quality-menu-osc.lua  $out/share/mpv/scripts
  '' + ''
    runHook postInstall
  '';

  passthru.scriptName = "quality-menu.lua";

  meta = with lib; {
    description = "A userscript for MPV that allows you to change youtube video quality (ytdl-format) on the fly";
    homepage = "https://github.com/jgreco/mpv-youtube-quality";
    license = licenses.gpl3Plus;
    platforms = platforms.all;
    maintainers = with maintainers; [ ];
  };
}%

#179743

#243354


Add mechanism for remapping device-specific module imports

This is motivated by #4509. The crux of the problem is that the Triton code generator needs to inspect a function's arguments / attributes / types in order to determine how it should be called. This meant that "implementation details" like whether a function is a builtin needed to be exposed in the "interface" tl.extra.libdevice module, instead of just residing in tl.extra.cuda.libdevice. Moreover, this meant that libdevice functions marked as @core.extern in the interface could not be implemented via JitFunctions.
Allowing each backend to provide its own module map solves this problem as the code generator can inspect the actual function implementation.

I initially tried to tackle #4509 with a purely "userspace" solution by changing @dispatch from a runtime-rebinding decorator to a declaration-time-rebinding one. But this wasn't possible because we don't know which backend will be used at declaration time. I then drafted https://github.com/int3/triton-cpu/tree/resolve which allows for user-defined dynamic symbol resolvers. Ultimately I settled on this PR because it seems simpler and doesn't actually change the semantics of the language.

fixed test