New package: Samsung.EasyDisplayManager version <IP_ADDRESS>

[ ] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.4 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: codeflow:open?pullrequest=https://github.com/microsoft/winget-pkgs/pull/111973&drop=dogfoodAlpha

Manifest: The manifest file path must match PackageIdentifier and PackageVersion properties from manifest. actual 'manifests\s\Samsung\EasyDisplayManager\<IP_ADDRESS>', expected 'manifests\s\Samsung\EasyDisplayManager\<IP_ADDRESS>'

/AzurePipelines run

/AzurePipelines run

/AzurePipelines run

#111634

https://answers.microsoft.com/en-us/windows/forum/all/error-1275-this-driver-has-been-blocked-from/71e7cda2-7fa1-4d76-9836-8acc227b1a2a

Thanks for the suggestions. Unfortunately, these steps are beyond the current capabilities of the WinGet package manager. Feel free to open an Issue suggesting that they be added.


[build / ci] Add py38 and Django 3.0 to the test matrix and cleanup

Add support for new python / Django versions.

Coverage decreased (-0.01%) to 71.141% when pulling 821fa5cbe72987dec412887642aff23e0fbbb199 on Djailla:travis into edd461630d1b4708e8ba3ecdc9c9e107e14fbfdb on django-extensions:master.

Please fix the typo in the comment/review above.
Otherwise LGTM.
What do you think about dropping py{34,35,36,37}-flake8 ?
Thinking those don't add that much... if anything having pypy-flake8 would make more sense I guess ;-)

With the last change all the different flake8 builds disappeared :(

@trbs yes fixed with next commit. Trying to code on mobile is a painful experience ;)

haha no problem :-)
I feel your pain, I'll be traveling myself a lot as well these weeks so no need to rush ;-)

It worked with last commit. All good !

I just see flake8 and am missing py27-flake8 and py38-flake8 ?

It’s on purpose. Flake8 will provide the same output whatever python version it’s started with.

Hello @trbs
Any update about the failing CI ?

@trbs up ?

Hello @trbs
Any update about the failing CI ?

For now I disabled the failing test since I cannot fix it at the moment. Don't have time to further investigate, so better to loose a couple of tests then have the entire suite failing ;-)

Wondering why it fails on py38 here and why it does not in the master builds.
On a related note... keyczar should really be deprecated and removed... so I don't see it as too much of a blocker. (eg: skipping the keyczar on py38 or removing them all together would be fine with me as well since nobody should be using keyczar anyways)
That said would be good to know why it's failing here and not on the master builds :-)

@trbs : it also fails with py38 over master

@trbs now it's failing with py34 :'(


BillboardVisualizer.js: dynamic entity position becomes tied to static entity position

Reproduced: Sandcastle
https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Source/DataSources/BillboardVisualizer.js
most recent commit: https://github.com/AnalyticalGraphicsInc/cesium/commit/337ad9d
line 47: var position = new Cartesian3();
...
line 115: position = Property.getValueOrUndefined(entity._position, time, position);

In the case of a CallbackProperty if the author of the callback returns a variable of non-local scope (to their function) then through subsequent loops of this update method the position of other billboard entities gets written back to that variable via this global variable.
In the Sandcastle example the dynamic entity is under the mouse as it moves and then gets set back to the position of the static entity on each render tick.
Suggestion, to clone it if it exists, otherwise preserve current behavior:
var tempPos = Property.getValueOrUndefined(entity._position, time, position);
if(tempPos) {
 Cesium.Cartesian3.clone(tempPos, position);
} else {
position = tempPos;
}

Thanks for the detailed bug report @smlawrence!  This made it really easy to track down the problem.
I've submitted a bug fix here: https://github.com/AnalyticalGraphicsInc/cesium/pull/6815

Thank you for looking into and working on that so quickly :+1:


Can I use (and how) to use multiple pickers in the same view controller?

Maybe this helps, im using several pickers and using tags to provide the numberOfRows and titleForRow methods
Something like this:

(IBAction)showPickerOne:(id)sender {
RMPickerViewController *pickerVC = [RMPickerViewController pickerController];
pickerVC.picker.tag = 10;
pickerVC.picker.delegate = self;
pickerVC.picker.dataSource = self;
//Set a title for the picker
pickerVC.titleLabel.text = @"This is an example title.\n\nPlease choose a row and press 'Select' or 'Cancel'.";
//Set select and (optional) cancel blocks
[pickerVC setSelectButtonAction:^(RMPickerViewController *controller, NSArray *rows) {
NSLog(@"Successfully selected rows: %@", rows);
}];
[pickerVC setCancelButtonAction:^(RMPickerViewController *controller) {
NSLog(@"Row selection was canceled");
}];
[self presentViewController:pickerVC animated:YES completion:nil];
}

(IBAction)showPickerTwo:(id)sender {
RMPickerViewController *pickerVC = [RMPickerViewController pickerController];
pickerVC.picker.tag = 10;
pickerVC.picker.delegate = self;
pickerVC.picker.dataSource = self;
//Set a title for the picker
pickerVC.titleLabel.text = @"This is an example title.\n\nPlease choose a row and press 'Select' or 'Cancel'.";
//Set select and (optional) cancel blocks
[pickerVC setSelectButtonAction:^(RMPickerViewController *controller, NSArray *rows) {
NSLog(@"Successfully selected rows: %@", rows);
}];
[pickerVC setCancelButtonAction:^(RMPickerViewController *controller) {
NSLog(@"Row selection was canceled");
}];
[self presentViewController:pickerVC animated:YES completion:nil];
}

// UIPickerViewDelegates

(NSInteger)numberOfComponentsInPickerView:(UIPickerView *)pickerView {
return 1;
}

(NSInteger)pickerView:(UIPickerView *)pickerView numberOfRowsInComponent:(NSInteger)component {
if(pickerView.tag == 10){
return 10;
}else{
return 4;
}
}

(NSString *)pickerView:(UIPickerView *)pickerView titleForRow:(NSInteger)row forComponent:(NSInteger)component {
if(pickerView.tag == 10){
return [NSString stringWithFormat:@"Row For Picker 1: %lu", (long)row];
}else{
return [NSString stringWithFormat:@"Row For Picker 2: %lu", (long)row];
}
}

Depends on what you want. If you want use multiple pickers at different times, you may use the solution @vincentvillalta provided (using tags).
If you want to show multiple pickers at the same time, tell me ;). Currently I'm working on a new version of RMDateSelectionViewController (see branch MoreButtons).Originally, in this version I wanted to use a UIAlertController-like interface to add custom defined buttons to RMDateSelectionViewController. But at the moment I'm thinking of unifying RMDateSelectionViewController and RMPickerViewController by enabling the user to add custom views instead of only custom buttons.

Closing due to missing response...


Mast: Watch best[\W_]+sites[\W_]+to[\W_]*+watch

Mast requests the watch of the watch_keyword best[\W_]*+sites[\W_]*+to[\W_]*+watch. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

best[\W_]*+sites[\W_]*+to[\W_]*+watch has been seen in 3 true positives, 0 false positives, and 0 NAAs.

Approved by tripleee in Charcoal HQ


Profile_photo dont update

Hi
When you choose a new profile picture, no new path to the picture is written to the database.

Hello @svanberg90 , Thanks for pointing out, I will look it as soon as possible.

@svanberg90 , I have fixed the issue. Now You can edit the profile image and It will save without any problem.

very good job. I have tried different solutions. Found a fix, but it wasn't optimal. Going to do a pull.


Questions regarding CSV input of hybrid heat pumps

Through issue #1556 importing hybrid heat pumps through a csv file was enabled, thanks!
I have some questions on how to properly use this new feature and how to interpret it.

The node to which the technology is attached has a different name than the end node e.g.  households_space_heater_hybrid_heatpump_air_water_electricity@buffer_space_heating_1.
Do I have to use similar names (technology@buffer) if I want to import a hybrid heat pump through a CSV?
The number of units for the technology is 1, instead of 576, which is the number of heat pumps. The capacity is still the same (4.9 for the electric part).
Why is the number of units 1 and not the same as the hybrid heat pump? Is the capacity still 4.9*total number of heat pumps?
The last column of the CSV is new and called export_key. I noticed that in a scenario without hybrid heat pumps this column is not required, in a scenario with hybrid heat pumps it is.
Is that observation correct?
When I fill this column am I correct to assume the formula to do so is "type@buffer"
This question is not really related to the CSV input and might need to be a new issue. @grdw if you agree I will make it one: In real life the same hybrid heatpump supplies both the water and the space heating demand. So, the capacity of the heat pump has to be split between them. Right now it looks to me like the hybrid heat pump for space and water heating are two unrelated technologies.
So the capacity which they represent in the model is bigger in the model than in real life, to me this seems undesirable. Is that indeed the case?

This is a LES containing nothing but hybrid heat pumps.

The node to which the technology is attached has a different name than the end node e.g. households_space_heater_hybrid_heatpump_air_water_electricity@buffer_space_heating_1. Do I have to use similar names (technology@buffer) if I want to import a hybrid heat pump through a CSV?
The last column of the CSV is new and called export_key. I noticed that in a scenario without hybrid heat pumps this column is not required, in a scenario with hybrid heat pumps it is.
Is that observation correct?

To explain. The export_key and the connection are meant to connect the 2 different components of the hybrid heat pump to the hybrid heat pump. To visualize it a little:
<node>
└── <buffer>
     └── <hhp>
          └── <hhp-part>

When I fill this column am I correct to assume the formula to do so is "type@buffer"

Yes

The number of units for the technology is 1, instead of 576, which is the number of heat pumps. The capacity is still the same (4.9 for the electric part).
Why is the number of units 1 and not the same as the hybrid heat pump? Is the capacity still 4.9*total number of heat pumps?

This is a good question. I'm not sure if the number_of_units for a hhp part have any effect, but I can't say for sure. I need to investigate this.

This question is not really related to the CSV input and might need to be a new issue. @grdw if you agree I will make it one: In real life the same hybrid heatpump supplies both the water and the space heating demand. So, the capacity of the heat pump has to be split between them. Right now it looks to me like the hybrid heat pump for space and water heating are two unrelated technologies.

This seems like a good question for @ChaelKruip. It sounds allright to me, but than again I don't know why the initial approach was to have 2 separate technologies.


google wont let me install the app without uploading my ID or giving them credit card info

i'm assuming it's because of the name, but google says it's "restricted content". it would be great if there was a way to install this without the chrome store, because i am not going to do either of those things

Interesting, first I've heard of this... I've always had the "mature content" setting turned on due to the name and Chrome's guidelines. I suppose I can try to disable that setting and see what happens...

I've used your plugin for my personal laptop for years, thank you.
For my work laptop, I have this issue (or similarly related issue).
I'm forced into only being allowed to use my corporate account (managed by google) on Chrome/Brave. This account is managed by the corporation and does not include my birthday in my profile. Goole requests my birthday, but due to it being a managed account, they will not save the information - as it must be done through an admin at my corporation apparently. Of course, requesting access to "restricted content" or "mature content" items is frowned upon by most large corporation policies and often rejected solely on that designation.

I am having the same problem. (I've used the extension for years and this is the first I've encountered this). I cannot gain access to the extension without signing into a Google Account. I figure it's got to the be the name.
Can you please change the name? Maybe Don't F$$$ with Paste? Whatever you want, just make it so we don't have to sign in to install it. It would be much appreciated.


Diff lines indented incorrectly

It looks like a GitHub update has caused the easier copy/paste feature from #282 to start indenting diffs incorrectly in some places.
For instance, in the diff of #282 itself:

https://github.com/sindresorhus/refined-github/pull/282/files
The td selector is not vertically aligned with the closing curly bracket.

However, as a counterexample (to show that it doesn't always happen everywhere), the if conditional also in this pull request does line up correctly:

cc @jacobbearden

We just merged in #396, which might fix this issue. Would you mind updating to use master (not the latest version in the Chrome store) and see if it resolves the issue? If you're already using the latest version on master then, yeah, it's a bug. 😀

Looks great @paulmolluzzo ! Sorry, I didn't see this merged PR - just looked through the open ones. When do you think this will be released?
Closing this issue. 😄

I just did a new release. It will take up to an hour to rollout to browsers.


field classess

Number::make('Quantity')
->fieldClasses('w-full px-8 py-6')
->hideLabelInForms(),
fieldClasses for Number does not exist?
Having hard time in applying field and label classes? Please some documentation will be helpful.

You should use
R64\NovaFields\Number
instead of
Laravel\Nova\Fields\Number

Great. Working.  Are you planning to add other fields like Date?
Much appreciated.

Yeah. We want to support every native field in Nova. Only have to find time. Feel free to open a PR implementing whatever need you have.
Thanks!


[QoL] Shard with topic key

As topic grows, it is good to consider horizontal scaling. And perhaps shard it by topic key to make access to a topic faster.
https://weaviate.io/developers/weaviate/concepts/cluster#advantages-when-increasing-sharding

impossible in new topic field


Instead of using textual email and phone number you should use mail and phone icon and link that with your email and phone number repectively so users can easily call or mail you .

use phone and mail icon and link it so user need not use copy

We dont have any email or phone no as of now.
Its just for a temporary purpose

adding icons makes it more attractive

@AnuragRoshan Yes, You can modify the contact page :)


As a player (user/guest) I want to join a game by entering a game code to play with others

Story : As a player, I want to be able to join a game by typing in the game code to play with other users
Acceptance criteria:

[x] sopra-fs23-group-08/client#9
[x] sopra-fs23-group-08/client#10

Priority: Critical
Estimate: 4-8 h

For linked commits see sub-tasks


Audio issues encountered using this mod

We ended up with one players unable to hear another player at random, it wasn't immediate and was after some playing and folks dying, no real clue as to why, but happened mid-game, removing this mod and played 2 more quotas and it didn't happen again. So something seems glitchy, as it seems to be full-muting some players after a while of playing, unsure if due to other player deaths or maybe confused audio streams, etc. We had 6 players using More Company, also I was able to talk to person B who couldn't hear person A, both could hear me fine, just one was muted for the other, and they also reported their volume sliders were locked for 2 people. So many anything above 4 players you aren't accounting for? Hopefully helpful info, it's a solid idea otherwise.

Oh sorry to hear that. Are there any other mods you were using that also affected audio in a similar way? I could see conflicts arising through that.
Other than that, I also use it with More Company in lobbies with 5-6 people and haven't had any problems with it. That mod also doesn't seem to modify audio in any way that could conflict with this mod. This mod literally only changes one volume value when you're dead to either 1 or the custom value. There shouldn't be a way for it to full-mute people (unless you set the volume slider to 0 of course). And if it crashed, it should just ignore my code and play like normal.
I'll look into it though. If this mod is causing full-mutes it kinda defeats the purpose of it

Sorry to not get back sooner, I wanted to get a full list of things present that might have somehow conflicted.
As far as mods that can actively influence audio sources:
LethalResonance (and dependancies)
-LCMaxSoundsFix
-loaforcsSoundAPI
AlwaysHearActiveWalkies
Skinwalkers
Unfortunately this is one of those things where it's significantly harder to test with a group that doesn't always go above 4, to meet that possible criteria, if that is indeed one of them.

From the mods you listed only AlwaysHearActiveWalkies changes the volume of players in a similar way I did. The other mods should only affect sound effects (/music?) and not actual player volume.
I can't seem to find a way for both mods to lead to muted players though, or locked configs. How long did you have my mod installed before these issues occurred?


Issues with consecutive log calls

Hi,
I tried to implements in my architecture a service wich log some things.
I have a factory wich give in a dependancy my Logger (with the PSR3 adapter) This part works.
class LoggerFactory implements FactoryInterface
{
    /**
     * @param  ServiceLocatorInterface $serviceLocator
     * @return Application\Service\Logger
     */
    public function createService(ServiceLocatorInterface $serviceLocator)
    {
        /**
         * @var Logger
         */
        $logger = new Logger;

        /**
         * @var PsrLoggerAdapter
         */
        $psrLogger = new PsrLoggerAdapter($logger);

        return new MyLogger($psrLogger);
    }
}
```

So in a controller for testing purposes, I tried to do some consecutive logs :

`````PHP
public function testAction() {
        $this->logger->log(\Psr\Log\LogLevel::EMERGENCY, 'urgent fix me !',
            array("source" => get_class() . ':' . __LINE__, "variables" => array($tata, $xd)));

        $this->logger->log(\Psr\Log\LogLevel::INFO, 'a screen alert');

        $this->logger->log(\Psr\Log\LogLevel::NOTICE, 'Contact an admin : {email}',
            array('email' => "toto@sample.com"));
}
```
My problem is, the second log is Inserted twice, one by itself, and the second time, when Notice's log comes out. Because  my service has a single instance of the logger and INFO & NOTICE are registered in the same file.

I tried then to shutdown those writers after I insert the log, no luck!

When I reopen the same file
https://github.com/zendframework/zend-log/blob/master/src/Writer/Stream.php#L82
this line stored for me the old resource wich not exist anymore due to the shutdown call.

The error I got is :

> fwrite(): 751 is not a valid stream resource

And a screen of my var dump in the stream.php's file
![log](https://cloud.githubusercontent.com/assets/1587180/13284132/99112cf6-daf2-11e5-8385-f3dcae024dde.png)

You can see in the last line that $this->stream has 751 in place of 753.

Thanks in advance for you advice / help.

Is this issue supposed to be closed? Was it resolved?

Hi Ocramius.
I solved this by configuring writers into the constructor which I didn't do .
This problem was an architecture issue from my project.
For me this issue deserves to be closed and forgotten ^^'
I don't know how zend-log was supposed to work, so I've posted an issue without asking myself if I've implemented it the right way. I thought that a writer could be removed easily which is not the case.

@jonathangreco alright!

For me this issue deserves to be closed and forgotten ^^'

That's actually why I asked. While it may have been a mistake on your end, this issue may still help others.


.NET Core not installed

Microsoft PowerToys version
"0.37.2"
Running as admin

[ ] Yes

Area(s) with issue?
General
Steps to reproduce
Open the PowerToys program.
✔ Expected Behavior
It should open as usual.
❌ Actual Behavior
Got a message saying that I should install .NET Core but I have already installed it.

Proof of installation:

Other Software
No response

Sorry I forgot to attach the bug files too, in case it might help:
PowerToysReport_2021-06-25-17-41-10.zip

I think the problem is that your .net core is x86. And we require x64 build.
Microsoft.NETCore.App 3.1.16 [C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.16 [C:\Program Files (x86)\dotnet\shared\Microsoft.WindowsDesktop.App]

Is your operation system 64 or 32 bit?

@yuyoyuppe, thoughts?

Omg I can't thank you enough. Must have been tired back then because I chose the wrong one. It works now!

@glisteningcoder
Happy to help. We install .net core with our installer. Any idea why it was not installed for you?
Maybe you have used the MSI to install PowerToys. But we don't distribute it though.

@glisteningcoder
Happy to help. We install .net core with our installer. Any idea why it was not installed for you?
Maybe you have used the MSI to install PowerToys. But we don't distribute it though.

I didn't exactly remember it at the time, but I think it just skipped the step at times. There was also instance where it tries to download but got stuck for quite a while. I stopped the process after a while though because it was running low in memory. I used the normal .exe version you guys distributed.


[BUG] Field resolvers are not generated automatically when using mapper

Describe the bug
Field resolvers are not generated automatically when using mapper
To Reproduce
Mini repo:  https://github.com/guendev/graphql-code-generator-plugins-issue

npm run apollo:build
Go to src/modules/users/resolvers/User.ts
resolvers of id and domain were not generated automatically

Expected behavior
id and domain field resolvers should be generated
https://the-guild.dev/graphql/codegen/docs/guides/graphql-server-apollo-yoga-with-server-preset#adding-mappers-to-chain-resolvers
Additional context
It works well in several previous version

Thanks for report this issue @guendev !
It looks like typesPluginsConfig.typesPrefix breaks static analysis. Could you please try the following alpha version to see if it fixes your issue:
yarn add @eddeee888/gcg-typescript-resolver-files@pr348-run654-1


Get Lut by Node Index

Hi again
I saw on the DR 17.4.6 release notes that they have "Added scripting API support to get node count and LUT by node index"
As usual, no official Resolve documentation of how to do this exactly, but I wondered if you'd looked into this and if you had plans to implement this feature in pydavinci?
My use case would be for doing dailies on multi-LUT shows. We usually create a two-node setup per clip, with CDLs on Node 1, and a LUT or LMT on Node 2. However there is no built-in way of extracting the LUT name from the node and exporting that to an ALE or other metadata file, meaning a lot of manual input and room for mistakes.

Hey Christy!
Thanks for the suggestion. Can you send me a DR 17 project file with that setup and an example LUT you're using?
I'll see how that's possible through the API. Shouldn't be too hard.

Hi Pedro
Multi_LUT_example.zip
Here's an example DR project file using built-in luts, and a demo script showing what i'm trying to do.
This is the link to the release notes where they meake mention of it, hopefully it's in there somewhere!

Hey Christy. Just implemented it in v0.2.3.
Pushed the update to PyPy. You can update using pip install pydavinci --upgrade.
Using your project:
>>> from pydavinci import davinci
>>> resolve = davinci.Resolve()
>>> clip = resolve.active_timeline.items('video', 1)[0]
>>> clip.get_lut(2)
'Sony/SLog3SGamut3.CineToLC-709TypeA.cube'


enchantments.json now contains a list of item NamespacedKeys for which canEnchantItem() is true

Description

enchantments.json contains enchantables, which is a list of NamespacedKeys for every Material item for which canEnchantItem() returns true
This is related to PR 1067 on MockBukkit/MockBukkit, as it generates the new data needed for the mocking of canEnchantItem()

Checklist

[x] Code follows existing style.

Thanks, @Thorinwasher !


Export Animation Clip

Does it support export animation data of skeletal mesh?

No, please see README

Export to FBX, with complete hierarchy, transformations, materials and textures. Geometry is exported with normals, tangents, UV coordinates, vertex colors and deformers. Skeleton nodes can be exported either as bones or dummy deformers

Mesh with skeleton is supported. Animation is not yet.

Is there any plan about this function?
Animation data is very important for a skeletal mesh.

probably not


[kuiper] security-secretstore-setup uses hard-coded YAML with docker network-name

🐞 Bug Report
Affected Services

 The issue is located in: security-secretstore-setup
Is this a regression?
No
Description and Minimal Reproduction
The security-secretstore-setup was modified to additionally configure the Kuiper edgex source configuration file (edgex.yaml) in order to allow Kuiper to read messages from the secure message bus. A new configuration stanza was added ([SecureMessageBus]) which adds the keys:

Type
KuiperConfigPath

Issue #3538 was opened to track support in the snap for this feature. While the snap was updated to 1.2.1 per the issue, the two configuration overrides were not implemented, so Kuiper in the snap is currently broken. What I discovered was that even after  updating the two new options in snapcraft.yaml as follows:
Type="redis"
KuiperConfigPath="$SNAP_DATA/kuiper/etc/sources/edgex.yaml"

...the resulting file always has the following definition for the message bus:
default:
  optional:
    Username: redis5
    Password: xyx...
  port: 6379
  protocol: redis
  server: edgex-redis
.
.

This means this source file will be incorrect in the snap (server should be 'localhost') or native deployments, preventing Kuiper from properly reading events from the message bus.
🔥 Exception or Error

🌍  Your Environment
Deployment Environment: snap
EdgeX Version: 2.0.0
Anything else relevant?

Yep, that needs to change to server: localhost which should not impact Docker since we have it set properly with environment variable. BTW, the snap PR is also overriding this with the EDGEX__DEFAULT__SERVER environment variable

FYI, I've updated the snap PR tp set EDGEX__DEFAULT__SERVER=localhost, however this doesn't solve the problem. See my PR for more details...
I think this is because the last time I checked, these EDGEX__* variables are only used by Kuiper for docker deployment...

@tonyespy Currently the env variable cannot work outside of Docker. Are you able to update the eKuiper/etc/sources/edgex.yaml directly during installation? Or build that conf_util_test.go, set KUIPER_HOME to your kuiper home location and run it.


Add options to toggle QtCustomTitleBar

Description

Adds the option to not render the hide_btn and float_btn in the QtCustomTitleBar of any widget. Previously this was only possible for the close_btn

Users can now toggle the rendering of hide_btn and float_btn in QtCustomTitleBar of any widget. For example:
from qtpy import QtWidgets
import napari

viewer = napari.Viewer()
myWidget = QtWidgets.QWidget()
w1 = viewer.window.add_dock_widget(myWidget)

# toggle by setting the respective button to True or False
w1._close_btn = False
w1._hide_btn = True
w1._float_btn = False

#4027 added support for the close_btn and the feature was also mentioned on image.sc

Type of change
normal

_close_btn hidden

_close_btn  and _hide_btn hidden

_close_btn,_hide_btn, and _float_btn hidden

[ ] Bug-fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

References

How has this been tested?

[x] all tests pass

Final checklist:

[x] My PR is the minimum possible work for the desired functionality
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] I have added tests that prove my fix is effective or that my feature works
[x] If I included new strings, I have used trans. to make them localizable.
For more information see our translations guide.

Thanks for the PR @DannyAlas! I udnerstand the need to prevent closing the widged; but what is the use case for preventing hiding and undocking? I think these things would hust get annoying if plugins started deeming their widgets "too important" to get moved around :P
Depending on the usefulness, we might even expose something like this publicly, rather than with a private attribute.

The purpose is really just to provide further control over custom widgets. In our use case, we're trying to allow the docking of widgets created in napari within our Qt app (e.g. those created by napari plugins).
In doing this, we decided to simply place the napari widget inside a QDockWidget created for our app if we detect an attempt to dock the widget within our app. If the user decides to place the widget back inside napari. We simply pass the widget back to napari and destroy the one created in our app. (this is a workaround so we don't need to design an entire backend for handling napari widgets, though we might endeavor on this in the future)
Ideally, we would like to disable/hide the custom titlebar or at least the rendering of the buttons to prevent them from appearing as below.

I would highly support a push to publicly manipulate the custom titlebar rather than with a private attributes. However, I'd have to familiarize myself further with the codebase before I'd feel comfortable creating a pull request for this. For now, the bare minimum utility of at least being able to disable the button rendering seems quite useful. Thanks!

As mentioned above, I've attempted to add a public-facing flag for users to choose if they'd like to add the custom_title_bar when creating a docked widget using the add_custom_title_bar in add_dock_widget.
For example:
viewer = napari.Viewer(show=False)
widget = QWidget()
dock_widget = viewer.window.add_dock_widget(widget, add_custom_title_bar=False)

would render a dock widget that looks like this

Take this use case:
I'd like to manually dock a napari dock_widget inside a QApplication with the inbuilt hooks and signals napari already integrates for a dock_widget.
class MainWindow(QMainWindow):
    def __init__(self):
        super().__init__()
        # set the main application window
        self._main = QWidget()
        self.setCentralWidget(self._main)
        self.layout = QGridLayout(self._main)

        # create napari viewer
        self.viewer = napari.Viewer(show=False)

        ##############################################
        # this is a workaround for napari issue #5400
        # initialize qt_viewer and qt_window
        self._qt_viewer = self.viewer.window._qt_viewer

        self.qt_viewer = self.viewer.window._qt_window
        ##############################################

        self.layout.addWidget(self.qt_viewer, 0, 0)

        self.init_dock_widget()

    # create a magicgui widget that has layer selections
    @magicgui(image = {'label': 'Pick an Image'})
    def example_func(image: Image):
        # do something with image
        return image

    def init_dock_widget(self):
        # add the magicgui widget to the napari
        # viewer as a dock widget
        napari_widget = self.viewer.window.add_dock_widget(
            self.example_func,
            add_custom_title_bar=False,
            )

        # mannually add the napari dock widget to our main
        # window as a QDockWidget
        self.addDockWidget(Qt.RightDockWidgetArea, napari_widget)

Using the default value of add_custom_title_bar=True when adding a dock widget yields the following result: no button icons and the custom title bar is hard to differentiate from the widget.

changing add_custom_title_bar=True to add_custom_title_bar=False in the napari widget creation now yields

I believe this allows for better implementation of napari widgets within other Qt applications and gives the user more control over dock widgets. I'm quite the novice when it comes to python, so feel free to let me know if I've completely missed something. Thanks!!

Interesting! I think @Czaki might be better suited to help/comment on this, since he's experienced with embedding napari in another qt app.
In my opinion, it's fine if we add this option to add_dock_widget(), but would advise against exposing it to the plugin interface to prevent abuse :)

@Czaki let me know if this makes more sense!

why do you not apply the napari style to the whole application? Now you have incompatible parts of the application if we think about style.

We could apply the napari stylesheet to the application, but for the purpose of a minimal reproducible example for just removing the buttons, I didn't find it necessary. In the future, it may be ideal to apply custom non-napari stylesheets to match the theme of different programs that could integrate napari.

Why did you dock the whole main window not QtViewer?

Docking the entire application was just for the simplicity of having the other dock widgets instead of just the Qt viewer. But we have started to do everything as individual dock widgets, which entails either creating our own stylesheets or using the napari style sheets for everything. For the purpose of hiding the buttons, though, I don't think this makes a difference.

You would like to modify part of the private napari API. We assume that if we need, we could break it without backward compatibility. If you think that QtViewerDockWidget could be helpful for people creating applications based on napari, then it should be reexported in napari.qt module.

If I understand correctly, you're stating that this change should be exported to the napari.qt module as a public-facing element for backward compatibility? If so, having a look at the other files there, I'm not too sure I understand the purpose/structure of the module, is there somewhere that explains this? Should these changes just be implemented as public-facing arguments passthrough to the private elements?

If you want to remove these buttons but keep using QtViewerDockWidget then I understand that Your task is to allow users to rearrange widgets, but not allow them to close them?

No. The purpose of this is to allow for greater customization of the dock widgets created for napari. Our purpose of using napari in a larger application seems to be somewhat unique, but the feature is simply to allow dock widgets to have more control over the title bar. As it stands, this custom title bar is added forcefully to any widgets created in napari, and I believe having the ability to at least disable it could be nice (maybe even allowing users to create their own as well).

If I understand correctly, you're stating that this change should be exported to the napari.qt module as a public-facing element for backward compatibility

No, this is a package for QT elements that we agree to expose so that we will promise to trey to keep a more stable interface. We keep all implementations in napari._qt to avoid circular import.

No. The purpose of this is to allow for greater customization of the dock widgets created for napari. Our purpose of using napari in a larger application seems to be somewhat unique

I don't think. Would Your application be much larger than PartSeg? I also see other screenshots of larger applications that embed napari. This part of usage is not documented but is already present.

No. The purpose of this is to allow for greater customization of the dock widgets created for napari

The whole idea around dock widgets is to allow users to arrange widgets on his own. It looks like you dont like it, so why would you use a dock widget instead of a plain QWidget`?
It is not that I'm against this change. But I know the napari codebase quite well (especially qt part), and it looks like you are trying to do something in a nonoptimal way that may hurt in the future. Because of this, I'm just trying to ask what you would like to achieve, not how you would like to achieve this.

The whole idea around dock widgets is to allow users to arrange widgets on his own. It looks like you dont like it, so why would you use a dock widget instead of a plain QWidget?

I understand. It's not that I don't like napari's dock widgets, I actually really like them, I would just like to have the option to disable the custom title bar. As far as I can tell, this doesn't affect the ability to move the widgets, and the stock title bar still has the float and close buttons, see below

In the future, it may also be nice for users to have the option to create their own custom title bars for dock widgets though that's outside of the scope of this pull request.

As per implementation, this may not be the optimal way to do this feature, so any advice is welcome. I'm very inexperienced with napari and Qt in general, so feel free to critique away! I also don't think our application is necessarily larger than PartSeg, just different.

In the current state of this PR some plugin may add a widget that cannot be moved or removed by a user.
This change is not limited to embedding napari in another application, but in every scenario, that may significantly impact inexperienced users.

Hi @alisterburt! Thank you so much! Our use case isn't even fully fleshed out, and currently, we're just trying to implement methods for manual ROI manipulation, though when we get something working, I'd love to share if there's a place for that.
Here is an example of this PR in action where the widget is created using
import napari
from qtpy.QtWidgets import QWidget

viewer = napari.Viewer()
widget = QWidget()

viewer.window.add_dock_widget(widget, add_custom_title_bar=False, menu=viewer.window.window_menu)

@Czaki, I might be misunderstanding something, but as far as I can tell, this PR would still allow users to close and move the widgets, as seen above. Does this PR change something in the plugin API somewhere I'm not noticing (I haven't used it much)?
Thanks, guys!

I'm also having trouble clearly understanding your motivation.
Yes, we do like minimal examples for implementation demos (the "what", or behaviour of a new change). But to fully understand your motivation (the "why"), knowing the full context & describing a concrete example is very helpful.
Can you explain it using a framework like this?

The broader context

It sounds like you want to stick napari with some dock widgets inside your own Qt application. This application does something to do with manual ROI manipulation.

Your specific aim, and why

You say "I would just like to have the option to disable the custom title bar". Can you explain why you need/want this for your broader goal?

Your current solution/implementation (before this PR)

It sounds like you've embedded napari into your own application, and are using a lot of individual napari dock widgets, and creating your own custom style sheets for this. Is that correct?

Why you don't like this current situation, what is the problem this is currently causing?

This is what I don't understand. You don't want the float and hide buttons displayed on the docked widget(s)... but you don't actually care whether the user can move or hide the widget(s)? Why? Is it just because you want it to "look nicer" in some way, and/or because you don't want to use style sheets? What is the current problem?

Suggested change, and how this fixes the problem

The suggested change is this PR, but because I don't understand what the problem is, it's hard to see if this fixes it! (It also makes it hard to judge whether it's likely to be useful for many other users or not, which changes how likely it is for the PR to be accepted)

Hi @GenevieveBuckley! I'll attempt to explain my original motivations using the framework you provided. I'm very new to Qt and GUI development in general, so please let me know if I'm missing something.
The broader context:

I have a Qt application that I would like to integrate Napari into to handle manual ROI manipulation. As this was only a small part of a larger feature, I was hoping to somehow dock the entire Napari application with its dock widgets inside my app. This is as opposed to what I've now done, which is to write a proper API to handle and dock the individual widgets in my app.

Specific aim:

While the Napari application works fine inside another Qt app, the dock widgets have a custom title bar that would require special handling and styling if placed in another Qt app, as seen in 5407#issuecomment-1352524956, the rest of the dock widget still works fine, including all the event handlers. The aim of this PR was to fix this by allowing users to choose if they would like to use the QtCustomTitleBar or stick with the standard Qt TitleBarWidget.

What is the problem:

The QtCustomTitleBar is forcefully added to a dock widget without a public method to manipulate it, remove it or pass a custom one. If a user wishes to dock these widgets in another app they'll end up with the aforementioned issue and if a user wishes to just add or manipulate the title bar of a widget there is no method to do so without accessing the private _qt_viewer class.

Suggested change:

I thought the simplest method to fix these issues was to give the user the option to use the QtCustomTitleBar or the standard Qt TitleBarWidget within the viewer.window.add_dock_widget method.

With that said though, as @Czaki mentioned  this issue seems to be hitting a more fundamental problem, which is that

there is a need to make docking-related class part of public API

I'd be more than happy to move forward on creating a public API for docking widgets in this PR or if you all agree I think we should open a new feature PR for this.


Original videos still not playing for many signs...

e.g.  FARM

I confirmed that the original videos are playing for FARM and a few other examples.

still not working for me...

These are playing for me now.


"Failed to initialize from the network." when running in LocalMode

I have a functional test environment where I set LocalMode = true in the options.
However, the begging of my test output always shows

Failed to initialize from the network. See https://docs.statsig.com/messages/serverSDKConnection for more information

Can this be not emitted when in LocalMode?
There have been a lot of recent changes that have made the library way more verbose than before that we've noticed and we've had to make updates to the options to stop it from contaminating our logs in tests.
Is there a better way to do this?

Hey @Tadimsky this has been resolved in the latest version v1.21.0


to_cnf() failed test

Test case for to_cnf() in logic.py gives an error.
Running to_cnf(Fig[7, 13] & ~expr('~P12')) causes AttributeError.
The above test case was included in logic.py

#152 should fix this


Pass string data from js to ios

Hi Marcus, thanks for yours great code. I was wondering if it would be possible to send String data from js to ios like this ,bridge.callHandler('testiOSCallback', 'string data', function(response) {
log('JS got response', response, 'js')
})
I got nil retrun value ,ios side.
Many thanks,
Lwin

of course you can.

this repository is still maintain？ the latest release version is on 9 Nov 2017


Add support for creating reproducers for the LTP skipfile

Add support for rerunning the tests in the LTP skipfile via the squad-create-skipfile-reproducers script.
By default, if only the group parameter is provided, the script will create a TuxPlan of reproducers for all supported QEMU devices and branches.
Builds on https://github.com/Linaro/squad-client-utils/pull/21

Traceback (most recent call last):
  File "/home/anders/src/squad-client-utils/./squad-create-skipfile-reproducers", line 251, in <module>
    sys.exit(run())
             ^^^^^
  File "/home/anders/src/squad-client-utils/./squad-create-skipfile-reproducers", line 240, in run
    reproducer = squadutilslib.create_tuxsuite_plan_from_tuxsuite_tests(
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/anders/src/squad-client-utils/squadutilslib.py", line 282, in create_tuxsuite_plan_from_tuxsuite_tests
    plan = yaml.load(test_yaml_str)
           ^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: load() missing 1 required positional argument: 'Loader'

When I run this command I see the following traceback ./squad-create-skipfile-reproducers --group lkft --branch linux-next --device-name fvp-aemva --build-names gcc-12-lkftconfig --suite-name ltp-syscalls
Traceback (most recent call last):
  File "/home/anders/src/squad-client-utils/./squad-create-skipfile-reproducers", line 251, in <module>
    sys.exit(run())
             ^^^^^
  File "/home/anders/src/squad-client-utils/./squad-create-skipfile-reproducers", line 240, in run
    reproducer = squadutilslib.create_tuxsuite_plan_from_tuxsuite_tests(
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/anders/src/squad-client-utils/squadutilslib.py", line 282, in create_tuxsuite_plan_from_tuxsuite_tests
    plan = yaml.load(test_yaml_str)
           ^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: load() missing 1 required positional argument: 'Loader'

"Works on my PC :shrug: " ;)
Things seem to work in my environment but looks like we are probably using different pyyaml versions. Easy to fix (by picking and setting a pyyaml version requirement; adding the loader parameter to load() or using full_load() rather than load()).
I added the parameter Loader=yaml.FullLoader as the current fix.
As an extra point here - we might want to use the ruamel.yaml library instead. This library has been picked for the later patches that deal with updating the skipfiles as it has features that we need but pyyaml doesn't support. Perhaps it doesn't make sense to be using two different yaml parsers in the same project.

Other changes made outside of review comments:

Added skipfile URL as parameter
Changed “temp” to “tmp” in variable names for consistency with project, and other minor variable renaming
Return -1 if a reproducer is not found rather than skipping it
Removed unnecessary “tests” entry in yaml file
Added the group name to the plan file name
Changed to print errors to the terminal rather than to a file.

$ tuxsuite plan skipfile-reproducer-lkft-linux-next-master-plan.yaml
Running Linux Kernel plan 'skipfile-reproducer-lkft-linux-next-master-plan.yaml': 'Run tests from customised reproducers.'
Plan https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/anders/plans/2Rn2PMNxGVvaq5gG1VSR0Xxz4bP
uid: 2Rn2PMNxGVvaq5gG1VSR0Xxz4bP
⚙  Provisioning: [boot] qemu-i386 @ https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/anders/tests/2Rn2PMNU1EDdrw4O4Ph2bKS25r3
⚙  Provisioning: [boot] qemu-i386 @ https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/anders/tests/2Rn2PLhtuVdurJx4wBTSYGSdedL
🔧 TuxTest error: [boot] qemu-i386 @ https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/anders/tests/2Rn2PMNU1EDdrw4O4Ph2bKS25r3
🔧 TuxTest error: [boot] qemu-i386 @ https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/anders/tests/2Rn2PLhtuVdurJx4wBTSYGSdedL
Summary: https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/anders/plans/2Rn2PMNxGVvaq5gG1VSR0Xxz4bP

$ tuxsuite plan skipfile-reproducer-lkft-linux-next-master-plan.yaml Running Linux Kernel plan 'skipfile-reproducer-lkft-linux-next-master-plan.yaml': 'Run tests from customised reproducers.' Plan https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/anders/plans/2Rn2PMNxGVvaq5gG1VSR0Xxz4bP
uid: 2Rn2PMNxGVvaq5gG1VSR0Xxz4bP ⚙ Provisioning: [boot] qemu-i386 @ https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/anders/tests/2Rn2PMNU1EDdrw4O4Ph2bKS25r3 ⚙ Provisioning: [boot] qemu-i386 @ https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/anders/tests/2Rn2PLhtuVdurJx4wBTSYGSdedL 🔧 TuxTest error: [boot] qemu-i386 @ https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/anders/tests/2Rn2PMNU1EDdrw4O4Ph2bKS25r3 wrench TuxTest error: [boot] qemu-i386 @ https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/anders/tests/2Rn2PLhtuVdurJx4wBTSYGSdedL
Summary: https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/anders/plans/2Rn2PMNxGVvaq5gG1VSR0Xxz4bP

It seems like the change in the quotes required by tuxsuite broke this PR's current's code use of '"..."' around the commands. This error appears to be fixed by updating the quotes to '...'. I will update the tuxplan code to use single quotes.
However, there also seems to be an issue where the boot-args parameter is being dropped and doesn't appear in the tuxtest and tuxrun reproducers https://tuxapi.tuxsuite.com/v1/groups/linaro/projects/katie/tests/2Ro7n69rDIon9u4UZIhVp6uTCZw
I have asked about this in comments of the ticket adding support for single quotes https://linaro.atlassian.net/browse/STG-4704

Updates:

Renamed "tuxrun" variable to "reproducer" as it is used for both tuxrun and tuxtest reproducers
Changed import style from import X to from X import Y to minimise imports
Changed reproducer functions to return strings rather than the file name - allowed for less temporary files to be created when generating the skipfile reproducers
Changed some info logging to debug to reduce noise in outputs

@roxell see updates - should be ready for review :+1:

This is what I see
ERROR:__main__:No reproducer could be found for lkft linux-next-master qemu-i386 ['gcc-12-lkftconfig'] ```

But I can see a job from tag next-20230714
https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230714/testrun/18305409/suite/ltp-syscalls/test/sendfile07/details/

This is what I see $ ./squad-create-skipfile-reproducers --group lkft --branch linux-next --device-name qemu-i386 --build-names gcc-12-lkftconfig --suite-name ltp-syscalls ERROR:main:No reproducer could be found for lkft linux-next-master qemu-i386 ['gcc-12-lkftconfig']
But I can see a job from tag next-20230714 https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230714/testrun/18305409/suite/ltp-syscalls/test/sendfile07/details/

'--allow-unfinished' fixes the issue =)


Tbas adapter

IMPORTANT: Please do not create a Pull Request without creating an issue first.
Before submitting (must do checklist)

[ ] Did you read the contribution guide?
[ ] Did you update the docs? We use Numpy format for all the methods and classes.
[ ] Did you write any new necessary tests?
[ ] Did you update the CHANGELOG?

Type of Change

[ ] Examples / docs / tutorials / contributors update
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] Improvement (non-breaking change which improves an existing feature)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Proposed Changes

Related Issue

Closing issues

Codecov Report

Merging #734 (f95c8c3) into master (e33f583) will increase coverage by 0.06%.
The diff coverage is 92.50%.

:exclamation: Current head f95c8c3 differs from pull request most recent head 0870005. Consider uploading reports for the commit 0870005 to get more accurate results

@@            Coverage Diff             @@
##           master     #734      +/-   ##
==========================================
+ Coverage   83.66%   83.73%   +0.06%
==========================================
  Files         120      121       +1
  Lines        6631     6669      +38
==========================================
+ Hits         5548     5584      +36
- Misses       1083     1085       +2

Impacted Files
Coverage Δ

etna/models/tbats.py
92.50% <92.50%> (ø)

etna/pipeline/base.py
94.44% <0.00%> (-0.03%)
:arrow_down:

etna/datasets/tsdataset.py
90.08% <0.00%> (+0.24%)
:arrow_up:

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Update: Graph API changes

The Graph API is now in public preview, and the contracts are changing (still in progress). Notably, the consistently unique identifier (cuid) has been removed in lieu of the new "descriptor" values.
Need to update the API response interface and other areas of the code accordingly

this has been finalized and fixed. updated flow now needs to include an additional API call to the storagekey api using the respective descriptor in order to obtain the key required for utilization/usagesummary


Add the code of conduct

For https://github.com/kubernetes/community/issues/3053
The content is from https://github.com/kubernetes/kubernetes-template-project.
/assign @Bradamant3

/lgtm

11919

Can we get this in? This is the only repo without CoC today. :grimacing:

/approve
Let's see if i have karma here


Z-index | stacking order system

Description

Create a stacking system for all of the elements in vocabulary.
Problems solved

Where elements like sticky footers or headers have to play nice with each other it can be difficult for teams to know what elements take priority. In many cases you may have elements popping up where they don't belong. exp: buttons being viewed over header elements.
Alternatives

Other design systems take advantage of Z-index variables like the morning star design system here
http://designsystem.morningstar.com/visual-language/layering.html
Additional context

Want to take up?

[Yes]

@rashadmad this is a solid idea, get on it!

The feature falls outside our current plan for the project, even more so with the removal of the token system entirely from Vocabulary. Therefore closing.


[OpenVDB] Update to V9.0 (from 7.x)

Is your feature request related to a problem? Please describe.
The openVDB port is now two full versions behind the current release.   NanoVDB has also been officially released as part of V9.0 to allow for GPU support.
Proposed solution
Update the vcpkg version would...well...make the library up-to-date.
Describe alternatives you've considered
Waiting so far hasn't gotten it updated so I am putting this request in.
Additional context
V9.0:
NanoVDB, which offers GPU support
Improved compilation times
Support for OpenEXR version 3

Can anyone that understands how version number work explain why this shouldn't have been closed?
Updating it to 8.2 doesn't cover the request for a 9.0 update.

@cgolchert ,The latest version of openvdb currently released is the rolled back version 8.2.0, but in fact its latest version is the last released version 9.0. We are going to submit a new pr to upgrade the version to 9.0.

I'm not following what you mean...  It IS v9.0 with the incorrect versioning number in vcpkg?
The fact that a request for v9 being closed BECAUSE of 8.2.0 was how the closure was worded.

Sorry to make you confused, I mean we will submit a new pr to upgrade openvdb to version 9.0 soon

Can anyone that understands how version numbers work explain why this shouldn't have been closed?

It got closed because in the PR https://github.com/microsoft/vcpkg/pull/22184 the author said "fix #21095" which caused GitHub to automatically close it when that PR was merged.

Cool.  I meant "explain why it got closed."  That is what happens when you are tired and edit only have the sentence. :)

Did interest in this port die?


Use the SI EvaluationContext by default for Expression properties

I believe rather than using the BeanFactory for lookup, the "integrationEvaluationContext" should be injectable via @Autowired. cc @artembilan @garyrussell

It's always a decision between the lookup approach (urghh) and relying on a name (which could change)
But I'm definitely eager to know what we consider to be the best approach

I don't think that bean name will change, but perhaps a compromise is to use IntegrationContextUtils.INTEGRATION_EVALUATION_CONTEXT_BEAN_NAME within the @Qualifier. That cannot change for backwards compatibility reasons.

Changed, added test

LGTM; merging

merged as https://github.com/spring-cloud/spring-cloud-stream/commit/80b1d28be1c8b9a23099b145fe2dcf472bfa9697 (added a newline at the end of the test class)


Patch dist barrier

Make sure that all processes exit at the same time (so that remote is synced properly).

This looks good to me but did you get a chance to test @GeorgiosSmyrnis?

Yes I did a run and it does not hang - I think that is sufficient for this.

approved - go ahead and merge after tests pass!

@GeorgiosSmyrnis version bump for downstream?

@sagadre thanks for pointing it out - added one!


Modal closes after mouse moving to overlay

Bug report
Modal window from component  closes after mouse moving to overlay
Describe the bug
If user starts the click inside the modal content and moves the pointer outside the content area to the overlay area, then it behaves like the click was fired on the overlay area and the modal window closes.
To Reproduce

Go to https://ui.supabase.com/components/modal
Click on 'Open Modal'
Press mouse button inside the content area of the modal, move pointer outside to the overlay and release the mouse button
Modal closes

Expected behavior
Modal window should not close if the mouse pointer movement starts inside the content area. Typically that is done with the check of target event nodes

Supabase UI is being deprecated.
As part of that, we are closing issues in this repo that are perhaps outdated.
If you'd like to still make an issue, you could consider making an issue for our package in our monorepo https://github.com/supabase/supabase/tree/master/packages/ui

We are moving the components to the main mono repo at https://github.com/supabase/supabase.
The auth component has been moved to it's own repo and package. https://github.com/supabase-community/auth-ui. You can also read the docs for auth ui here.


The landing page components don't seem to work

The hero animation is stopped and the counter example is disabled for now.

Browser error here:

Deno Deploy error logs (with my fork):

And error line is here:

<EMAIL_ADDRESS>it seems failed to fetch wasm binary.

src/server/esbuild-wasm/esbuild.wasm is deleted at #151, then it should be hosted somewhere.

whoops, i'll fix this.

Oh I made PR just now but if you fix by yourself, please close the PR.

🤦♂ sorry folks

@tylerbrostrom Not your fault! I didn't review as well as I should have. No big deal :-)


Update Makefile default AMI to LTS AL2 AMI

Today, the Makefile references the AL2 Candidate AMI as the default. We should update that to reference the latest LTS AL2 release.

the other issue I saw, is that the Makefile will only work in a us-west-2 region. I made a few changes to allow to pass the region as an option to make
make REGION=[us-east-1|us-west-2] ami


[SWA] Support SWA in pagedKVCache, remove backward compatible code

This PR supports SWA under PagedKVCache, and with this, now all models running on WebLLM will be compiled with PagedKVCache (rather than the old KVCache that is no longer maintained).
Hence, we removed codes in llm_chat.ts that were for backward compatibility. However, old wasms would still work with npm <= 0.2.29 since wasm versioning will be introduced with 0.2.30.
Note that API for forwardTokensAndSample() is changed since we no longer need curPos.
Relevant PRs:

https://github.com/mlc-ai/mlc-llm/pull/1967
https://github.com/apache/tvm/pull/16729

Performance wise: Llama and Mistral have the same performance M3 MacBook to decode 32 tokens:

non-SWA: 47 tok/s
SWA: 42 tok/s


Update README.md

Point to main Bokeh docs site, not dev version

this will be mooted by #700 I think, as the list in the README will go away


Replacing "Select your feedback" dropdown with a text box in Feedback page.

I will replace the "Select your feedback" dropdown with a text box in the feedback page to enhance the quality and functionality of the feedback page.
It will help to give and receive more accurate and descriptive feedbacks instead of selecting mere options.

Can you share any sample screenshot... Connect in discord and send there with you issue number or link


Encapsulate backend code

@EvaWMwangi Since the stacks are different for backend (Python) and botend (NodeJS) codes, putting all backend code and files in a folder (that can be called server for example) will make the repo more organized.

Okay sure will. Thanks John


Imports within package

Provide a way to have "absolute" imports within a package. The current proposal is to use @ in place of the source folder ( src in most cases ). So that given this structure:

src/Main.mad
src/Utils/Math.mad
src/Views/Grid.mad
We can easily do can easily do @/Utils/Math.mad and @/Views/Grid.mad from any file.

Closed by #47


gradio_app.py crashes after image and question submit

Traceback (most recent call last):
  File "C:\Users\user\.pyenv\pyenv-win\versions\3.9.10\lib\site-packages\gradio\queueing.py", line 536, in process_events
    response = await route_utils.call_process_api(
  File "C:\Users\user\.pyenv\pyenv-win\versions\3.9.10\lib\site-packages\gradio\route_utils.py", line 322, in call_process_api
    output = await app.get_blocks().process_api(
  File "C:\Users\user\.pyenv\pyenv-win\versions\3.9.10\lib\site-packages\gradio\blocks.py", line 1935, in process_api
    result = await self.call_function(
  File "C:\Users\user\.pyenv\pyenv-win\versions\3.9.10\lib\site-packages\gradio\blocks.py", line 1532, in call_function
    prediction = await utils.async_iteration(iterator)
  File "C:\Users\user\.pyenv\pyenv-win\versions\3.9.10\lib\site-packages\gradio\utils.py", line 671, in async_iteration
    return await iterator.__anext__()
  File "C:\Users\user\.pyenv\pyenv-win\versions\3.9.10\lib\site-packages\gradio\utils.py", line 664, in __anext__
    return await anyio.to_thread.run_sync(
  File "C:\Users\user\.pyenv\pyenv-win\versions\3.9.10\lib\site-packages\anyio\to_thread.py", line 56, in run_sync
    return await get_async_backend().run_sync_in_worker_thread(
  File "C:\Users\user\.pyenv\pyenv-win\versions\3.9.10\lib\site-packages\anyio\_backends\_asyncio.py", line 2441, in run_sync_in_worker_thread
    return await future
  File "C:\Users\user\.pyenv\pyenv-win\versions\3.9.10\lib\site-packages\anyio\_backends\_asyncio.py", line 943, in run
    result = context.run(func, *args)
  File "C:\Users\user\.pyenv\pyenv-win\versions\3.9.10\lib\site-packages\gradio\utils.py", line 647, in run_sync_iterator_async
    return next(iterator)
  File "C:\Users\user\.pyenv\pyenv-win\versions\3.9.10\lib\site-packages\gradio\utils.py", line 809, in gen_wrapper
    response = next(iterator)
  File "C:\Users\user\Desktop\2\Infini-Megrez-Omni\gradio_app.py", line 147, in bot
    for subtext in iterable_streamer:
  File "C:\Users\user\.pyenv\pyenv-win\versions\3.9.10\lib\site-packages\transformers\generation\streamers.py", line 223, in __next__
    value = self.text_queue.get(timeout=self.timeout)
  File "C:\Users\user\.pyenv\pyenv-win\versions\3.9.10\lib\queue.py", line 179, in get
    raise Empty
_queue.Empty

Are you using a GPU to infer the model? According to the logs you provided, the model inference has timed out. You may try increasing the value of the timeout here.

thanks! that fixed the issue. i put 60 sec as timeout.


[Help Wanted] Selection Color?

Currently I'm using "Dark Contrast++"
as for text selection, i simply change the background to shade+, is it the correct color?

in "Intended Usage" section, it is recommended that use "sun" and "shade-" as selection colors, but it is very weird:

so what is the intended usage for selection?

I think for the VSCode theme, I used Sun with transparency to get an effect similar to using Shade+ (but with more warmth).
If you do not want to use transparency, it’s meant to be used inverted, so with the text in Shade- and the highlighting in Sun. This can have very high contrast though.
In general, all of these are only the intended use where generally the Sun and Shade colors are meant to be used to contrast each other naturally. So for example something being selected is like “light shining onto it”, either by use of transparency, or by “casting hard shadows” along the “contours” of the text.
Readability should always come first though!


[PE-D][Tester B] List of doctors disappears after addition of new patient.

I'm not sure if it is intended but the displayed list of doctors becomes blank when I input a new patient. However it reappears when I use the list-doc command.

Labels: severity.Low type.FeatureFlaw
original: Yaladah/ped#3

This is a repeat bug


Add a !website (alias !koa) command

That was a rather simple thing to add. I'm open for any suggestions on how to prettify it if needed!
Closes #16

Looks good! Thanks so much for your contribution. 🤖


html copies to new line

Jodit Version:  3.5.2
Browser: Chrome
OS:  Windows
Is React App:  False
Code
        html=""
         html="<a href='//" + window.location.hostname +"<?= $data['vidLink']; ?>" + d.id + "'> " + html + "";
     editor.editor.appendChild(editor.createInside.fromHTML(html));

Expected behavior:
Once this runs, it should inject the image at the end and any new lines should be just ''
Actual behavior:

The last 3 are new lines

Also, forgot to mention, you may also want to check out #579 as that's what I used to get the data inserted in the first place.

Also, forgot to mention, you may also want to check out #579 as that's what I used to get the data inserted in the first place.


Display a limited number of entries

Hi! @Faryshta @neverabe
The widget displays the default number of records equal to that set in the inherited "dataProvider". This number is equal to 20.
The solution to the problem is setting the limit while forming the "dataProvider".
new ActiveDataProvider([
    'query' => self::find(),
    'pagination' => [
        'pageSize' => 365,
    ],
])

However, this is not quite the right decision. How much should I set? 365? Then it will be only for a year, and if it is necessary for the previous year, or next year?
Corrections:

I suggest or enter a separate parameter for setting the limit.
Disable hangout

If necessary I will send pull request.

The limit is for the amount of events you are expecting. If you want to handle a huge amount of events I advice you to combine PJax and this widget to display the results month by month.
If you have another idea do send pr


NPM Documentation Incorrect

The documentation on Sigma's NPM page is ... misleading:
How to use it
To use it, clone the repository:
git clone git@github.com:jacomyal/sigma.js.git

Since I'm pretty sure anyone running npm install sigma should not be running git clone git@github.com:jacomyal/sigma.js.git, it'd be nice if this documentation could be updated.
In particular it would be nice to see how NPM users can/should access plugins (are they part of the main package, do you need to install separate packages for them, etc.).

thats correct, i think the document should really update to say
"npm install sigma" or mention it to add it in the dependency package.json file as "sigma": "jacomyal/sigma.js" and run npm install.


howto: compile on Windows

 Issue by Erkan-Yilmaz
Monday Apr 03, 2017 at 13:09 GMT
Originally opened as https://github.com/Erkan-Yilmaz/Gridcoin-tasks/issues/98

"if it is feasible you could maybe write a short manual on how to compile for windows. Or ask Rob if could publish some of the scripts?"
"Don't know maybe there is a reason for not self compiling on windows but it would be great for testing now and then."
cc @denravonska @gridcoin

 Comment by denravonska
Monday Apr 03, 2017 at 13:12 GMT

We have a wiki somewhere, right? It should cover building for all the platforms in the future.

 Comment by Erkan-Yilmaz
Monday Apr 03, 2017 at 13:15 GMT

there's also:
WINDOWS BUILD NOTES in the sources
(last changed: 2015 Dec)
can someone verify that building works with that ?

 Comment by denravonska
Monday Apr 03, 2017 at 13:23 GMT

@Erkan-Yilmaz I remember seeing that as well but couldn't get it running in msys2. Though these layers (msys, cygwin, msys2 etc) for Windows confuse me so it might as well be my fault.

 Comment by gridcoin
Monday Apr 03, 2017 at 14:24 GMT

Yeah, building on windows is not as trivial as some bashers say it is.  Some of the windows dependencies have to be built in a certain way to be compatible (IE noobs would have trouble compiling BOOST with the right flags to even get the windows dlls to be valid and in the right target directory etc).
I am planning on giving Denravonska my entire build zip library that should remove the ambuiguity on building this current version of Gridcoin on windows.  Im going to do this definitely over the next few days as this is the next high priority item for me to at least give him the ability to build the windows MSI.
In the mean time, I wanted to mention, one quick way to resolve about 80% of the windows build problems is search google for Building Litecoin on Windows.  Since litecoin has a large support base that actually gets one very close as it resolves the windows dependencies.

 Comment by Erkan-Yilmaz
Monday Jul 24, 2017 at 16:35 GMT

see also:

How to Compile the VB.NET (Neural Network) Code on Windows 10

 Comment by LokiToki
Tuesday Apr 04, 2017 at 06:37 GMT

I tried to build the wallet on windows from scratch. Downloaded newest and/or needed versions of boost, OpenSSL etc, but i didn't make it in 2 days (effective 4 - 5 hours). There are so many different (as mentioned) layers and libraries...it drove me crazy af tbh. ^^ If there is a high need i would try it again and write everything down noob-style but it will take a bit (very busy atm).

Can be closed, new build process on windows is well documented.


@conda-forge-admin, please add bot automerge

Issue:

Environment (conda list):

$ conda list

Details about  conda and system ( conda info ):

$ conda info

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I added bot automerge in conda-forge/gsoap-feedstock#29.


add udeb support

Sometimes we need udeb support, that provide it in template.
Signed-off-by: Vasiliy Tolstov<EMAIL_ADDRESS>

merged manually with https://github.com/sous-chefs/reprepro/commit/b9f560884137bd5e1547598dc22e39a38b199472

thanks!


More levels of grouping

Hello,
Is it possible to have more than one level of grouping? For example: building/room/occupancy, and It would be many room groups per one building  group.

Yes, Please take a look at this https://codesandbox.io/s/k9qyx9zp2o
I am gonna close this for now if you have a question or feature request please follow the template provided for you when you created the issue


Fix api key regeneration with mobile apps

retest this please

Please CR @juanignaciosl
For some reason, tests are not being triggered...

👍

Tested in staging, coming in :fire:


Support for the create-apps scope

Left a few minor comments here, but +1 looks good. Thanks!

oops, fixed! thanks :}

Sweet! Pulling this in.

@pedro Should now be live.

Sweet! Testing the whole thing.
Thank you!


Issue encountered in solving 2D Heat Equation with needing mx.eval to avoid segmentation fault

I have implemented a simple solution of the 2D Heat Conduction Equation with 2 Neumann and 2 Dirichlet BCs. I have the code implemented both using PyTorch and the MLX framework and I am testing the relative performance on an M2 Ultra with 128GB memory.
The MLX code is included below. So far, performance in various tests (on the same machine) show the MLX version to be somewhere between X2 and X10 faster depending on the problem size.
However, I have an issue that I need to understand.  Depending on the problem size, I need to include the line
    if step % 15000== 0:         mx.eval(T)
to avoid segmentation fault. I imagine this has to do with the lazy evaluation and arrays being in buffer? My issue is that currently I figure each time how often I need to mx.eval empirically. Is there some programmatic and more elegant way to automatically issue the  mx.eval at the right frequency based on the problem size?
Here is the complete code below. Thank you for all your help @awni !
# Solving the 2D Heat Conduction Equation with 2 Neumann and 2 Dirichlet PCs
import numpy as np
import matplotlib.pyplot as plt
import time
import mlx.core as mx

# Convergence tolerance to stop early (currently disabled)
#convergence_tolerance = 1e-8

# Grid size and material properties setup
nx, ny = 5000, 5000  # Set grid dimensions
k = 1.0              # Thermal conductivity

# Time-stepping parameters
desired_dt = 0.01  # Desired time step
max_steps = 10000 # Maximum number of time steps

# Creating a linearly spaced grid
x = mx.array(np.linspace(0,1,nx))
y = mx.array(np.linspace(0,1,ny))
dx = x[1] - x[0]   # Grid spacing in x direction
dy = y[1] - y[0]   # Grid spacing in y direction

# Function to calculate the maximum stable time step for the explicit Euler method
def calculate_max_stable_dt(alpha, dx, dy):
    return (1 / (2 * alpha)) * (1 / (1/dx**2 + 1/dy**2))

# Material properties for stability calculation
rho = 1.0  # Density
cp = 1.0   # Specific heat capacity
alpha = k / (rho * cp)  # Thermal diffusivity

# Compute maximum stable time step
dt_max = calculate_max_stable_dt(alpha, dx, dy)
dt = min(dt_max, desired_dt)  # Use the smaller of the desired or maximum stable time step

# Initializing the temperature field on the GPU
T = mx.zeros([nx, ny])
T_old = mx.zeros_like(T)

# Applying Dirichlet boundary conditions
T[:, 0] = 0.0   # Set left boundary temperature
T[:, -1] = 1.0  # Set right boundary temperature

# Time-stepping loop for the heat equation

start_time = time.time()  # Capture start time
for step in range(max_steps):
    T_old = mx.broadcast_to(T,shape=T.shape)

    # Update interior points using finite difference method
    # Pad the interior points for broadcasting
    T =  mx.pad(mx.pad( (T_old[1:-1,1:-1] + dt * k * (
        (T_old[2:, 1:-1] - 2 * T_old[1:-1, 1:-1] + T_old[:-2, 1:-1]) / dx**2 +
        (T_old[1:-1, 2:] - 2 * T_old[1:-1, 1:-1] + T_old[1:-1, :-2]) / dy**2
    )), ((0,0),(0,1)),1),((0,0),(1,0)), 0)

    # Update Neumann boundaries (zero-flux) at top and bottom
    T = mx.concatenate([mx.expand_dims(T[0, :], (0)), T, mx.expand_dims(T[-1, :], (-0))], axis=0)

    if step % 15000== 0:
        mx.eval(T)

end_time = time.time()  # Capture end time
elapsed_time = end_time - start_time
print(f"Elapsed time: {elapsed_time:.2f} seconds")

#  Visualizing the temperature field using matplotlib
plt.imshow(T, cmap='hot', interpolation='nearest')
plt.colorbar()  # Add a color bar to indicate temperature scales
plt.show()

It should never segfault, so that's not something you are doing sub-optimally with eval. It looks like a bug to me.. but we'll have to investigate further.

Ok knowing that, I will try to do some debugging and see if I can provide some additional feedback.

So for some reason it segfaults if I don't put the mx.eval(T) at the beginning (e.g. before starting the loop). That definitely smells like a bug. But otherwise you don't need an eval until the end.
Also I made a couple of slight modifications, it should be noticeably faster (assuming I didn't mess anything up).
# Solving the 2D Heat Conduction Equation with 2 Neumann and 2 Dirichlet PCs
import numpy as np
import time
import mlx.core as mx

# Grid size and material properties setup
nx, ny = 5000, 5000  # Set grid dimensions
k = 1.0              # Thermal conductivity

# Time-stepping parameters
desired_dt = 0.01  # Desired time step
max_steps = 10000 # Maximum number of time steps

# Creating a linearly spaced grid
x = mx.array(np.linspace(0,1,nx))
y = mx.array(np.linspace(0,1,ny))
dx = x[1] - x[0]   # Grid spacing in x direction
dy = y[1] - y[0]   # Grid spacing in y direction

# Function to calculate the maximum stable time step for the explicit Euler method
def calculate_max_stable_dt(alpha, dx, dy):
    return (1 / (2 * alpha)) * (1 / (1/dx**2 + 1/dy**2))

# Material properties for stability calculation
rho = 1.0  # Density
cp = 1.0   # Specific heat capacity
alpha = k / (rho * cp)  # Thermal diffusivity

# Compute maximum stable time step
dt_max = calculate_max_stable_dt(alpha, dx, dy)
dt = min(dt_max, desired_dt)  # Use the smaller of the desired or maximum stable time step

# Initializing the temperature field on the GPU
T = mx.zeros([nx, ny])
T_old = mx.zeros_like(T)

# Applying Dirichlet boundary conditions
T[:, 0] = 0.0   # Set left boundary temperature
T[:, -1] = 1.0  # Set right boundary temperature

# Time-stepping loop for the heat equation

dysq = dy**2
dxsq = dx**2
mx.eval(T)

start_time = time.time()  # Capture start time
for step in range(max_steps):
    # Update interior points using finite difference method
    # Pad the interior points for broadcasting
    T_mid = T_old[1:-1,1:-1]
    T =  mx.pad(mx.pad((T_mid + dt * k * (
        (T_old[2:, 1:-1] - 2 * T_mid + T_old[:-2, 1:-1]) / dxsq +
        (T_old[1:-1, 2:] - 2 * T_mid + T_old[1:-1, :-2]) / dysq
    )), ((0,0),(0,1)),1),((0,0),(1,0)), 0)

    # Update Neumann boundaries (zero-flux) at top and bottom
    T = mx.concatenate([mx.expand_dims(T[0, :], (0)), T, mx.expand_dims(T[-1, :], (-0))], axis=0)

mx.eval(T)
end_time = time.time()  # Capture end time
elapsed_time = end_time - start_time
print(f"Elapsed time: {elapsed_time:.2f} seconds")

It runs orders of magnitude faster (438 sec vs 2.37 sec for 100K steps) !!! And whatever the bug is,  it's not surfacing any more.  I'm thrilled with the speedup 👍

I was too quick to respond. The T_old temperature field  (see the code below) needs to be updated in each time step, that's why I had the line T_old = mx.broadcast_to(T,shape=T.shape) at the beginning of each time step, which I found was a bit faster than setting T_old=T. Once I include again this line the problem resurfaces and the speeds go back to more or less what I was having before.
    T_mid = T_old[1:-1,1:-1]     T =  mx.pad(mx.pad((T_mid + dt * k * (         (T_old[2:, 1:-1] - 2 * T_mid + T_old[:-2, 1:-1]) / dxsq +         (T_old[1:-1, 2:] - 2 * T_mid + T_old[1:-1, :-2]) / dysq     )), ((0,0),(0,1)),1),((0,0),(1,0)), 0)

Oops, sorry about that!

Following your remark, I tested again  T_old = mx.broadcast_to(T,shape=T.shape) and  T_old=T and they are about the same (within load noise).  I must have been misled by some other change I made in parallel before. So, this does not be to checked. Sorry for the wrong claim 🫣

Ok, I did some basic debugging using the debugger in PyCharm (PyDev). I inserted a breakpoint at the iteration step that I would normally need to execute mx.aval(T) to avoid segfault. Stepping though all values in the arrays look normal and nothing weird happens. However, when I make the fist step forward from the break-point it takes a long time for variable values to load on the debugger. I can step through the code and complete execution correctly. I am not sure, if this adds any useful hints. Suspicion: Am I effectively, using an eval by loading the values in the debugger and that's why the code completes correctly without need the explicit  mx.aval(T) 🤔?   To my non-expert eyes this looks like a low-level error in MXL as there is nothing funny happening in the actual array values. Probably something with the dynamic graphs and memory ?

I'm not able to reproduce the segfault. Does it segfault for you using the settings you have in the example above?
Also what hardware / OS are you using?

Yes, but below I also provide the latest version (have added your suggestions) which still segfaults if I don't mx.eval(T) or mx.eval(T_old) at step % 150000 == 0.  The exact frequency of needing to 'mx.eval' depends on the problem size (nx,ny).
Hardware
Model Name:	Mac Studio
Model Identifier:	Mac14,14
Model Number:	Z180000DEB/A
Chip:	Apple M2 Ultra
Total Number of Cores:	24 (16 performance and 8 efficiency)
Memory:	128 GB
System Firmware Version:	10151.41.12
OS Loader Version:	10151.41.12
OS Version
macOS Sonoma Version 14.1.2
Python Environment
Python 3.11.6
numpy  1.26.2
mlx        0.0.4
Conda    23.11.0
libblas                   3.9.0           20_osxarm64_accelerate    conda-forge
libcblas                  3.9.0           20_osxarm64_accelerate    conda-forge
liblapack                 3.9.0           20_osxarm64_accelerate    conda-forge
Segfault Message
Elapsed time: 2.99 seconds

Process finished with exit code 139 (interrupted by signal 11:SIGSEGV)

Current version of code
# Solving the 2D Heat Conduction Equation with 2 Neumann and 2 Dirichlet PCs
import numpy as np
import time
import mlx.core as mx

# Grid size and material properties setup
nx, ny = 5000, 5000  # Set grid dimensions
k = 1.0              # Thermal conductivity

# Time-stepping parameters
desired_dt = 0.01  # Desired time step
max_steps = 50000 # Maximum number of time steps

# Creating a linearly spaced grid
x = mx.array(np.linspace(0,1,nx))
y = mx.array(np.linspace(0,1,ny))
dx = x[1] - x[0]   # Grid spacing in x direction
dy = y[1] - y[0]   # Grid spacing in y direction

# Function to calculate the maximum stable time step for the explicit Euler method
def calculate_max_stable_dt(alpha, dx, dy):
    return (1 / (2 * alpha)) * (1 / (1/dx**2 + 1/dy**2))

# Material properties for stability calculation
rho = 1.0  # Density
cp = 1.0   # Specific heat capacity
alpha = k / (rho * cp)  # Thermal diffusivity

# Compute maximum stable time step
dt_max = calculate_max_stable_dt(alpha, dx, dy)
dt = min(dt_max, desired_dt)  # Use the smaller of the desired or maximum stable time step

# Initializing the temperature field on the GPU
T = mx.zeros([nx, ny])
T_old = mx.zeros_like(T)

# Applying Dirichlet boundary conditions
T[:, 0] = 0.0   # Set left boundary temperature
T[:, -1] = 1.0  # Set right boundary temperature

# Time-stepping loop for the heat equation

dysq = dy**2
dxsq = dx**2
mx.eval(T)
mx.eval(T_old)

start_time = time.time()  # Capture start time
for step in range(max_steps):
    #T_old = mx.broadcast_to(T, shape=T.shape)
    T_old = T
    # Update interior points using finite difference method
    # Pad the interior points for broadcasting

    #### Segfault Control ####
    # if step % 15000 == 0: mx.eval(T_old)  (When commented out it should cause a segfault)

    T_mid = T_old[1:-1,1:-1]

    T =  mx.pad(mx.pad((T_mid + dt * k * (
        (T_old[2:, 1:-1] - 2 * T_mid + T_old[:-2, 1:-1]) / dxsq +
        (T_old[1:-1, 2:] - 2 * T_mid + T_old[1:-1, :-2]) / dysq
    )), ((0,0),(0,1)),1),((0,0),(1,0)), 0)

    # Update Neumann boundaries (zero-flux) at top and bottom
    T = mx.concatenate([mx.expand_dims(T[0, :], (0)), T, mx.expand_dims(T[-1, :], (-0))], axis=0)

end_time = time.time()  # Capture end time
elapsed_time = end_time - start_time
print(f"Elapsed time: {elapsed_time:.2f} seconds")

mx.eval(T)

# Visualizing the temperature field using matplotlib
import matplotlib.pyplot as plt
plt.imshow(T, cmap='hot', interpolation='nearest')
plt.colorbar()  # Add a color bar to indicate temperature scales
plt.show()

One more observation that might provide a clue. These two slightly different implementations (with the problem size nx, ny kept the same between them , require different frequencies of mx.eval(T_old) to avoid segfault. The difference between the two is that in the first case mx.pad is used to add the top and bottom rows and then assignment is made for the Neumann  BCs, while in the second, the rows are added and assigned values via  mx.concatenate
**Implementation 1: eval every 21000 steps **
    if step % 21000 == 0:
        mx.eval(T_old)

    T_mid = T_old[1:-1, 1:-1]

    T = mx.pad(mx.pad((T_mid + dt * k * (
            (T_old[2:, 1:-1] - 2 * T_mid + T_old[:-2, 1:-1]) / dxsq +
            (T_old[1:-1, 2:] - 2 * T_mid + T_old[1:-1, :-2]) / dysq
    )), ((1, 1), (0, 1)), 1), ((0, 0), (1, 0)), 0)

    # Update Neumann boundaries (zero-flux) at top and bottom
    T[0, :] = T[1, :]
    T[-1, :] = T[-2, :]

**Implementation 2: eval every 16000 steps **
    if step % 16000 == 0:
        mx.eval(T_old)

    T_mid = T_old[1:-1, 1:-1]

    T = mx.pad(mx.pad((T_mid + dt * k * (
            (T_old[2:, 1:-1] - 2 * T_mid + T_old[:-2, 1:-1]) / dxsq +
            (T_old[1:-1, 2:] - 2 * T_mid + T_old[1:-1, :-2]) / dysq
    )), ((0, 0), (0, 1)), 1), ((0, 0), (1, 0)), 0)

    # Update Neumann boundaries (zero-flux) at top and bottom
    T = mx.concatenate([mx.expand_dims(T[0, :], (0)), T, mx.expand_dims(T[-1, :], (-0))], axis=0)

I am able to reproduce the segfault on my machine.
Current (and likely) hypothesis is that the segfault is a result of a stack overflow during the eval when we recurse on the inputs to build the compute graph. It definitely makes sense that it depends on the size of the graph..
For now, I would recommend just doing a fixed amount of compute per eval, so adding something like:
if step % 1000 == 0:
    mx.eval(T_old)

I am not sure if we should fix this.. we could try using an iterative graph construction to compute the graph, but at the same time I don't recommend letting graphs get so big. It's usually a sign that eval should be used more frequently and/or the number of operations should be reduced.
Another comment:
You should see if it's possible to replace the whole inner computation with something like a convolution or matmul with the appropriate kernel. It would dramatically reduce the number of operations which in this case would speed things up substantially. I think the whole update from T_old to T is linear so it should be very doable with the right operation.

Ok, at least I now have some level of understanding as to what is going.
The idea to use a convolution kernel is a great one I will try it because it connects to the next project I want to tackle with MLX for my computational engineering course. I know how I can do that with Torch I'll see if I can make it work with MLX and will come back for help if I run into trouble.
BTW, if you like the idea, it might be useful to have a section of examples on engineering/physics applications (not necessarily falling directly under the ML/AI area) to provide a easy entry point for people wanting to leverage MLX for science.  I would be happy to contribute in this direction.
Here's the latest Blackened version of the code before I implement the suggested change:
2D_Heat_Equation_MLX_A.py
1    # Solve the 2D Heat Conduction Equation with 2 Neumann and 2 Dirichlet BCs
2    # with the Apple MLX framework.
3    # Stavros Kassinos
4    # Example for course MME 419 @ UCY, December 2023
5    import time
6    import mlx.core as mx
7
8    # Select Execution Device
9    mx.set_default_device(mx.gpu)
10
11   # Grid size and material properties setup
12   nx, ny = 1_000, 1_000  # Set grid dimensions
13   k = 1.0  # Thermal conductivity
14
15   # Time-stepping parameters
16   desired_dt = 0.01  # Desired time step
17   max_steps = 50_000  # Maximum number of time steps
18
19   # Creating a linearly spaced grid
20   x = mx.arange(0, 1.0, 1.0 / nx)
21   y = mx.arange(0, 1.0, 1.0 / ny)
22
23   dx = x[1] - x[0]  # Grid spacing in x direction
24   dy = y[1] - y[0]  # Grid spacing in y direction
25
26
27   # Function to calculate the maximum stable time step for the explicit Euler method
28   def calculate_max_stable_dt(alpha, dx, dy):
29       return (1 / (2 * alpha)) * (1 / (1 / dx**2 + 1 / dy**2))
30
31
32   # Material properties for stability calculation
33   rho = 1.0  # Density
34   cp = 1.0  # Specific heat capacity
35   alpha = k / (rho * cp)  # Thermal diffusivity
36
37   # Compute maximum stable time step
38   dt_max = calculate_max_stable_dt(alpha, dx, dy)
39   dt = min(
40       dt_max, desired_dt
41   )  # Use the smaller of the desired or maximum stable time step
42
43   # Initializing the temperature field on the GPU
44   T = mx.zeros([nx, ny])
45   T_old = mx.zeros_like(T)
46
47   # Applying Dirichlet boundary conditions
48   T[:, 0] = 0.0  # Set left boundary temperature
49   T[:, -1] = 1.0  # Set right boundary temperature
50
51   # Time-stepping loop for the heat equation
52
53   dysq = dy**2
54   dxsq = dx**2
55
56   start_time = time.time()  # Capture start time
57   for step in range(max_steps):
58       T_old = T  # Update previous step T-field
59
60       # Eval to keep execution graph efficient
61       if step % 20_000 == 0:
62           mx.eval(T)
63
64       # Update interior points using finite difference method
65       #    Pad the interior points for broadcasting to T.shape
66       #    Enforce Dirichlet BCs
67
68       T_mid = T_old[1:-1, 1:-1]
69
70       T = mx.pad(
71           mx.pad(
72               (
73                   T_mid
74                   + dt
75                   * k
76                   * (
77                       (T_old[2:, 1:-1] - 2 * T_mid + T_old[:-2, 1:-1]) / dxsq
78                       + (T_old[1:-1, 2:] - 2 * T_mid + T_old[1:-1, :-2]) / dysq
79                   )
80               ),
81               ((1, 1), (0, 1)),
82               1,
83           ),
84           ((0, 0), (1, 0)),
85           0,
86       )
87
88       # Update Neumann boundaries (zero-flux) at top and bottom
89       T[0, :] = T[1, :]
90       T[-1, :] = T[-2, :]
91
92   end_time = time.time()  # Capture end time
93   elapsed_time = end_time - start_time
94   print(f"Elapsed time: {elapsed_time:.2f} seconds")
95
96   mx.eval(T)
97
98   # Visualizing the temperature field using matplotlib
99   import matplotlib.pyplot as plt
100
101  plt.imshow(T, cmap="hot", interpolation="nearest")
102  plt.colorbar()  # Add a color bar to indicate temperature scales
103  plt.show()

It looks like we have some work to for those shapes for our conv2D. I think your implementation has much more potential to be fast. If we can make the conv comparable to torch it should really sing!  In the meantime, bear with us..we're a small team with a lot to do. But things will only get much better from here!
I wrote a little benchmark and for the sizes in your problem we are > 10x slower than Torch's conv2d. CC @jagrit06 who will hopefully have some time to work on this in the near future.
import numpy as np
import torch.nn.functional
import mlx.core as mx
import time

### Time Torch
T = np.random.randn(1000, 1000).astype(np.float32)
W = np.array([[0, 1, 0], [1, -4, 1], [0, 1, 0]], np.float32)

T = T.reshape(1, 1, 1000, 1000)
W = W.reshape(1, 1, 3, 3)

device = torch.device("mps")
T = torch.tensor(T).to(device)
W = torch.tensor(W).to(device)

for _ in range(5):
    T = torch.nn.functional.conv2d(T, W, padding="same")
torch.mps.synchronize()

tic = time.time()
for _ in range(100):
    T = torch.nn.functional.conv2d(T, W, padding="same")
torch.mps.synchronize()
toc = time.time()

print(f"Torch: {toc - tic}")

### Time MLX
T = np.random.randn(1000, 1000).astype(np.float32).reshape(1, 1000, 1000, 1)
W = np.array([[0, 1, 0], [1, -4, 1], [0, 1, 0]], np.float32).reshape(1, 3, 3, 1)
T = mx.array(T)
W = mx.array(W)

for _ in range(5):
    T = mx.conv2d(T, W, padding=(1, 1))
mx.eval(T)

tic = time.time()
for _ in range(100):
    T = mx.conv2d(T, W, padding=(1, 1))
mx.eval(T)
toc = time.time()
print(f"MLX: {toc - tic}")

it might be useful to have a section of examples on engineering/physics applications

That's a great idea! We could potentially put a physics/ directory in the MLX examples repo, or make something standalone. Since I don't know much about those use cases, if you're are interested in this, maybe a good starting point is to make your own repo with some of these examples + comments / explanations, and we can go from there.

Great it would be awesome to have a fast conv2d, but I do realize how full your hands are right now, it is actually amazing how fast things are progressing   @jagrit06

I forked the repo and will try to create a library of engineering/physics examples of increasing complexity and once I have sufficient material in place you could review and decide whether to merge or keep it separate.

Forgive my ignorance, but I'm trying to understand the following: if you move the
torch.mps.synchronize()  and mx.eval(T)
statements after the respective toc = time.time() actually MLX is way faster (30X). Does this mean that MLX is faster in creating the comp graphs but MLX conv2D is slower when it is time to do the actual computation?  @awni
import numpy as np
import torch.nn.functional
import mlx.core as mx
import time

### Time Torch
T = np.random.randn(1000, 1000).astype(np.float32)
W = np.array([[0, 1, 0], [1, -4, 1], [0, 1, 0]], np.float32)

T = T.reshape(1, 1, 1000, 1000)
W = W.reshape(1, 1, 3, 3)

device = torch.device("mps")
T = torch.tensor(T).to(device)
W = torch.tensor(W).to(device)

for _ in range(5):
    T = torch.nn.functional.conv2d(T, W, padding="same")
torch.mps.synchronize()

tic = time.time()
for _ in range(100):
    T = torch.nn.functional.conv2d(T, W, padding="same")
toc = time.time()
torch.mps.synchronize()
print(f"Torch: {toc - tic}")

### Time MLX
T = np.random.randn(1000, 1000).astype(np.float32).reshape(1, 1000, 1000, 1)
W = np.array([[0, 1, 0], [1, -4, 1], [0, 1, 0]], np.float32).reshape(1, 3, 3, 1)
T = mx.array(T)
W = mx.array(W)

for _ in range(5):
    T = mx.conv2d(T, W, padding=(1, 1))
mx.eval(T)

tic = time.time()
for _ in range(100):
    T = mx.conv2d(T, W, padding=(1, 1))
toc = time.time()
mx.eval(T)
print(f"MLX: {toc - tic}")

Torch: 0.005361795425415039
MLX: 0.00016999244689941406

Process finished with exit code 0

Does this mean that MLX is faster in creating the comp graphs but MLX conv2D is slower when it is time to do the actual computation?

Exactly right.

To add to the conversation about conv2D - it's a process of creating and optimizing many specialization
Even currently, the shapes that our Winograd conv supports will run faster than alternatives
It's work in progress to get a wider range of shapes to good speeds and it is no small priority for us!

So great to hear and much appreciated!

By the way the same kind of benchmark for mx.matmut vs torch.dot shows that MLX is about 15X faster than Torch for the dot product of two vectors.

I am able to reproduce the segfault on my machine.
Current (and likely) hypothesis is that the segfault is a result of a stack overflow during the eval when we recurse on the inputs to build the compute graph. It definitely makes sense that it depends on the size of the graph..
For now, I would recommend just doing a fixed amount of compute per eval, so adding something like:
if step % 1000 == 0:
    mx.eval(T_old)

I am not sure if we should fix this.. we could try using an iterative graph construction to compute the graph, but at the same time I don't recommend letting graphs get so big. It's usually a sign that eval should be used more frequently and/or the number of operations should be reduced.
Another comment:
You should see if it's possible to replace the whole inner computation with something like a convolution or matmul with the appropriate kernel. It would dramatically reduce the number of operations which in this case would speed things up substantially. I think the whole update from T_old to T is linear so it should be very doable with the right operation.

Just adding an additional observation that perhaps points to how the graphs are evaluated. The two implementations below differ by just a superfluous set of parentheses, but the one with the extra parentheses seems to group operations differently and results in being able to eval with half the frequency compared to the implementation without the extra set of parentheses.
#Version with extra parentheses
    T = mx.pad( mx.pad(
        (T_mid + (
          dt_alpha_ov_dxsq * ( T_old[2:, 1:-1] - 2 * T_mid + T_old[:-2, 1:-1] )
        + dt_alpha_ov_dysq * ( T_old[1:-1, 2:] - 2 * T_mid + T_old[1:-1, :-2] ))),
        ((0, 0), (0, 1)),1), ((1, 1), (1, 0)),0)

# Version without the superfluous parentheses
    T = mx.pad( mx.pad(
        (T_mid +
          dt_alpha_ov_dxsq * ( T_old[2:, 1:-1] - 2 * T_mid + T_old[:-2, 1:-1] )
        + dt_alpha_ov_dysq * ( T_old[1:-1, 2:] - 2 * T_mid + T_old[1:-1, :-2] )),
        ((0, 0), (0, 1)),1), ((1, 1), (1, 0)),0)


odd context resetting problem and question

For a long time, I've been able to completely reset the bot's user context in my (botkit-based orchestration) app by performing this sequence of steps 1- saving an empty context object directly in (botkit) persistent storage and then 2- calling watsonMiddleware.interpret() on the message. However, I just noticed that this sequence failed to work properly in one occasion recently (that is, Watson continued the conversation with the user instead of starting one from scratch). Can you help me understand what could have gone wrong? (this bot is still using the older botkit/botkit-middleware-watson combo, although I'm working on a botkit4-based update,)
In addition, I'd like to understand whether this sequence of steps should be expected to work with the latest botkit and watsonMiddleware code or whether I should use something else instead.  I am aware of the 'sendToWatson' method, but I don't know whether it can be used to completely clear the user's context, which is the desired result (so that a new conversation can get started).

sendToWatson can't be used to clear the context, it takes contextDelta parameter which is merged with context object stored in storage.
updateContext method replaces entire context object, use it instead.

Ah, that's great to know @Naktibalda . Thanks for explaining that!. I'm curious though, would it still work to do the manual context clearing first (outside of Watson, just accessing botbuilder storage), and then calling watsonMiddleware.interpret() ?

I don't see any reason why it shouldn't work.