[SPARK-31757][CORE] Improve HistoryServerDiskManager.updateAccessTime()

What changes were proposed in this pull request?
The function HistoryServerDiskManager.updateAccessTime() would recompute the application store directory size every time it's triggered, this effort could be avoided because we already computed the new size outside the function call.
Does this PR introduce any user-facing change?
No
How was this patch tested?
Existing test cases.

Test build #122840 has started for PR 28579 at commit f212f33.

Merged build finished. Test PASSed.

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

Test build #122840 has finished for PR 28579 at commit f212f33.

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

Merged build finished. Test FAILed.

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

retest this please

Test build #122853 has started for PR 28579 at commit f212f33.

Merged build finished. Test PASSed.

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

Test build #122853 has finished for PR 28579 at commit f212f33.

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

Merged build finished. Test PASSed.

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

retest this please

Test build #122951 has started for PR 28579 at commit f212f33.

Merged build finished. Test PASSed.

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

Test build #122951 has finished for PR 28579 at commit f212f33.

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

Merged build finished. Test PASSed.

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

Thanks, merged to master!


feature: Introduce Validating Emulators with Noise Models to the SDK

Issue #, if available:
Description of changes:
This PR introduces the notion of device emulators and emulation passes to the BDK; device emulators provide some form of program compilation and validation and may apply a noise model to the program before simulating the program on the BDK LocalSimulator.
AwsDevice specific emulators are created based on the device properties and capabilities; noise models for gate-based QPUs are created based on calibration data retrieved from Braket service when creating an AwsDevice.
Testing done:
Unit testing covers 99% of emulator passes and noise model generation based on AwsDevice calibration data.  (TODO: Complete unit tests for 100% coverage).
Merge Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your pull request.
General

[x] I have read the CONTRIBUTING doc
[x] I used the PR title format described in CONTRIBUTING
[ ] I have updated any necessary documentation, including READMEs and API docs (if appropriate)

Tests

[x] I have added tests that prove my fix is effective or that my feature works (if appropriate)
[x] I have checked that my tests are not configured for a specific region or account (if appropriate)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Looking good to me, let's see if @krneta has any feedback!


Notification indicators for Electron app

The Electron apps' dock icon should display a notification indicator when new messages or highlights appear and the app is unfocused.
These can be dig out from the UI's internal highlight and mentions system and passed via Electron's IPC to the app's main process. Electron itself has a built-in support and functionality to display the icon in the dock.

On this note, native notifications for new messages would also be nice. I've used https://www.npmjs.com/package/node-notifier for this with great success


[spirv][vulkan] Enable integer dot prod on desktop GPUs

This is to exercise efficient i8 matmul codegen.
Enable e2e i8 matmul tests on Nvidia GPU in CI.
Fixes: https://github.com/openxla/iree/issues/13123

Hmm, the test is labeled requires-gpu-nvidia but it still runs on swiftshader

@GMNGeoffrey @pzread @ScottTodd How can I make the CI respect the 'requires-nvidia-gpu' test label? I want these new test to only execute on nvidia; swiftshared does not implement the extensions used in those tests.
I looked at the scripts used by the CI and I think we would have decide when to exclude this label, similar to existing Vulkan/CUDA tests:
if [[ "${IREE_VULKAN_DISABLE}" == 1 ]]; then
  label_exclude_args+=("^driver=vulkan$")
fi
if [[ "${IREE_CUDA_DISABLE}" == 1 ]]; then
  label_exclude_args+=("^driver=cuda$")
fi
if [[ "${IREE_VULKAN_F16_DISABLE}" == 1 ]]; then
  label_exclude_args+=("^vulkan_uses_vk_khr_shader_float16_int8$")
fi

I wonder if we could deduce that these tests should run when both vulkan and cuda are enabled?

OK, since this is a bit more complicated than I expected, let's separate the matmul test changes from the Vulkan/SPIR-V extensions/capabilities.


systemc: Fix gcc13 systemC compilation error

issue: https://github.com/gem5/gem5/issues/472
Change-Id: Ie06bf87b4df3b100d456540ac66b910e1c6b752b

Thanks you for the review, I will make the PR ready once the github action issues fixed.

It seem the github action work again, open the PR


preview_src refactor and readability improvements

Inside the Vizabi repo, the only place where a developer can see how a tool is embedded inside an HTML is inside preview_src folder. The handlebars file need improvement and more documentation to help developers see that bit of the code they need.

Follow-up:
Added warning here: https://github.com/Gapminder/vizabi/tree/develop/preview_src
Added standalone previews:
http://static.gapminderdev.org/vizabi/develop/preview/fullscreen/bubblechart.html
http://static.gapminderdev.org/vizabi/develop/preview/fullscreen/linechart.html
http://static.gapminderdev.org/vizabi/develop/preview/fullscreen/barchart.html
Apart from codepen examples, bl.ocks.org examples, people can also use the source code of these pages to understand how Vizabi is initialized.


docs - dendogram margin

Would it be possible to remove margin (on the left side of the plot), because it makes the plots in the online docs function badly.
When you open the plot in the browser you can see the dendogram plots are shifted to the right, with big white gap on the left. This causes the plot to be shifted right when embedded, and the plot controls disappear.
link: https://github.com/plotly/plotly.matlab-docs/blob/main/matlab/2021-08-04-dendrogram.md

This issue was fixed by PR #469
To fix this I have proposed a new optional parameter called 'DomainFactor'. This parameter scales each of the domain components of the plotly chart.
The domain or position of a chart box is defined by a 4-element vector, namely:
domain = [xo, yo, w, h]
where:

xo: the initial x-coordinate of the chart (referred to the left-bottom)
yo: the initial y-coordinate of the chart (referred to the left-bottom)
w: is the width of the chart
h: is the height of the chart

Then the 'DomainFactor' parameter must be a vector of 4-elements at most, in which each of its elements will scale to each of the elements of the chart's domain.
Example: Without scaling
rng('default')
X = rand(10,3);

tree = linkage(X,'average');

dendrogram(tree)

fig2plotly(gcf);

In this example we have not set the optional DomainFactor parameter, therefore, the domain of the chart will not be scaled, which will result in:

Example: set DomianFactor to scaling
rng('default')
X = rand(10,3);

tree = linkage(X,'average');

dendrogram(tree)

domainFactor = [0.2, 1, 0.9, 0.9];
fig2plotly(gcf, 'offline', offline, 'DomainFactor', domainFactor);

In this case we have set the 'DomainFactor' parameter as [0.2, 1, 0.9, 0.9] and like this:

xo will be scaled by a factor of 0.2
yo will scale by a factor of 1 (it will stay the same)
w: the width of the chart will be scaled by a factor of 0.9
h: the height of the chart will be scaled by a factor of 0.9

Here I share the result:


Distinct Document support

#202

I also fixed a typo on Attachments

Pushed a partial fix.  It fixes the two new unit tests, and keeps almost everything else working.
Please sanity check these changes before I go much further down the rabbit hole.

I am ok to merge it, unless you want to add something else


Migrate some features to neurom.fst module

section_areas
section_volumes
segment_taper_rates
number_of_bifurcations:

analogous to "bifurcation_number", but for populations it is estimated per neuon, and not as a total over all neurons.

total_length_per_neurite
segment_midpoints

returns an array of (x, y, z) positions representing the segment midpoints and replaces segment_x_coordinates,  segment_y_coordinates, and segment_z_coordinates.

Replace some lambda expressions for functools.partial calls.

This implements most of #376. For the segment x, y, z coordinates, use the segment_midpoints:
pts = fst.get('segment_midpoints', fst_pop)
pts_x = ezy.get('segment_x_coordinates', ezy_pop)
numpy.all(pts[:, 0] == pts_x)


Question

The demo images look amazing, but how to download this app on android?

Not yet released.


2024-12-04_01-35-54_master-next_aws-crt-python

Automatically created.

Successfully created backport PR for kirkstone-next:

#10621

Successfully created backport PR for scarthgap-next:

#10622

Successfully created backport PR for styhead-next:

#10623


circling back on review feedback

Documentation

[X] I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

[X] I thought about adding a changelog entry, and added one if I deemed necessary.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Paul Harris seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Test suite subsys.pm.device_runtime_api fail on qemu_x86_64

Describe the bug
"pm->state" is accessed by multiple functions, only in runtime_suspend_work() it is protected by "pm->lock", for architectures with multiple CPU, the value of "pm->state" is unexpectable.
To Reproduce
twister -T tests/subsys/pm/device_runtime_api/ -p qemu_x86_64
Expected behavior
test cases pass.
Impact
Test coverage report
Logs and console output
Running test suite device_runtime_api
===================================================================
START - test_api
W: Unbalanced suspend
W: Unbalanced suspend
W: Unbalanced suspend
Assertion failed at ZEPHYR_BASE/tests/subsys/pm/device_runtime_api/src/main.c:151: test_api: state not equal to PM_DEVICE_STATE_SUSPENDED
FAIL - test_api in 0.5 seconds
===================================================================
Test suite device_runtime_api failed.
===================================================================
Environment (please complete the following information):

OS: (e.g. Linux, MacOS, Windows)
Toolchain (e.g Zephyr SDK, ...)
Commit SHA or Version used

Additional context
Add any other context about the problem here.

not sure if this is also related but the same failure is seen for qemu_cortex_a53_smp

Could you please provide more details, test is passing on my setup:
DEBUG   - QEMU (1359901): SeaBIOS (version zephyr-v1.0.0-0-g31d4e0e-dirty-20200714_234759-fv-az50-zephyr)
DEBUG   - QEMU (1359901): Booting from ROM..*** Booting Zephyr OS build v2.7.99-1182-g0ab1bf42b30e  ***
DEBUG   - QEMU (1359901): Running test suite device_runtime_api
DEBUG   - QEMU (1359901): ===================================================================
DEBUG   - QEMU (1359901): START - test_api
DEBUG   - QEMU (1359901): W: Unbalanced suspend
DEBUG   - QEMU (1359901): W: Unbalanced suspend
DEBUG   - QEMU (1359901): W: Unbalanced suspend
DEBUG   - QEMU (1359901): PASS - test_api in 0.3 seconds
DEBUG   - QEMU (1359901): ===================================================================
DEBUG   - QEMU (1359901): Test suite device_runtime_api succeeded
DEBUG   - QEMU (1359901): ===================================================================
DEBUG   - QEMU (1359901): PROJECT EXECUTION SUCCESSFUL
DEBUG   - QEMU (1359901) complete (passed) after 2.1003847122192383 seconds
DEBUG   - No timeout, return code from QEMU (None): 0
DEBUG   - return code from QEMU (None): 0
DEBUG   - run status: qemu_x86_64/tests/subsys/pm/device_runtime_api/subsys.pm.device_runtime_api passed
INFO    - 1/1 qemu_x86_64               tests/subsys/pm/device_runtime_api/subsys.pm.device_runtime_api PASSED (qemu 2.100s)

DEBUG   - QEMU (1358717): *** Booting Zephyr OS build v2.7.99-1182-g0ab1bf42b30e  ***
DEBUG   - QEMU (1358717): Secondary CPU core 1 (MPID:0x1) is up
DEBUG   - QEMU (1358717): Running test suite device_runtime_api
DEBUG   - QEMU (1358717): ===================================================================
DEBUG   - QEMU (1358717): START - test_api
DEBUG   - QEMU (1358717): W: Unbalanced suspend
DEBUG   - QEMU (1358717): W: Unbalanced suspend
DEBUG   - QEMU (1358717): W: Unbalanced suspend
DEBUG   - QEMU (1358717): PASS - test_api in 0.6 seconds
DEBUG   - QEMU (1358717): ===================================================================
DEBUG   - QEMU (1358717): Test suite device_runtime_api succeeded
DEBUG   - QEMU (1358717): ===================================================================
DEBUG   - QEMU (1358717): PROJECT EXECUTION SUCCESSFUL
DEBUG   - QEMU (1358717) complete (passed) after 2.0300774574279785 seconds
DEBUG   - No timeout, return code from QEMU (None): 0
DEBUG   - return code from QEMU (None): 0
DEBUG   - run status: qemu_cortex_a53_smp/tests/subsys/pm/device_runtime_api/subsys.pm.device_runtime_api passed
INFO    - 1/1 qemu_cortex_a53_smp       tests/subsys/pm/device_runtime_api/subsys.pm.device_runtime_api PASSED (qemu 2.030s)

DEBUG   - QEMU (66881): SeaBIOS (version zephyr-v1.0.0-0-g31d4e0e-dirty-20200714_234759-fv-az50-zephyr)                                                                                DEBUG   - QEMU (66881): Booting from ROM..*** Booting Zephyr OS build zephyr-v2.4.0-13068-g5a218decfad8  ***
DEBUG   - QEMU (66881): Running test suite device_runtime_api
DEBUG   - QEMU (66881): ===================================================================
DEBUG   - QEMU (66881): START - test_api
DEBUG   - QEMU (66881): W: Unbalanced suspend
DEBUG   - QEMU (66881): W: Unbalanced suspend
DEBUG   - QEMU (66881): W: Unbalanced suspend
DEBUG   - QEMU (66881):
DEBUG   - QEMU (66881): Assertion failed at ZEPHYR_BASE/tests/subsys/pm/device_runtime_api/src/main.c:151: test_api: state not equal to PM_DEVICE_STATE_SUSPENDED
DEBUG   - QEMU (66881):
DEBUG   - QEMU (66881): FAIL - test_api in 0.6 seconds
DEBUG   - QEMU (66881): ===================================================================
DEBUG   - QEMU (66881): Test suite device_runtime_api failed.
DEBUG   - QEMU (66881): ===================================================================
DEBUG   - QEMU (66881): PROJECT EXECUTION FAILED
DEBUG   - QEMU (66881) complete (failed) after 2.1199686527252197 seconds
DEBUG   - No timeout, return code from QEMU (None): 0
DEBUG   - return code from QEMU (None): 0
DEBUG   - run status: qemu_x86_64/tests/subsys/pm/device_runtime_api/subsys.pm.device_runtime_api failed
INFO    - 1/1 qemu_x86_64               tests/subsys/pm/device_runtime_api/subsys.pm.device_runtime_api FAILED Failed (qemu 2.120s)

DEBUG   - QEMU (70346): *** Booting Zephyr OS build zephyr-v2.4.0-13068-g5a218decfad8  ***
DEBUG   - QEMU (70346): Secondary CPU core 1 (MPID:0x1) is up
DEBUG   - QEMU (70346): Running test suite device_runtime_api
DEBUG   - QEMU (70346): ===================================================================
DEBUG   - QEMU (70346): START - test_api
DEBUG   - QEMU (70346): W: Unbalanced suspend
DEBUG   - QEMU (70346): W: Unbalanced suspend
DEBUG   - QEMU (70346): W: Unbalanced suspend
DEBUG   - QEMU (70346):
DEBUG   - QEMU (70346): Assertion failed at ZEPHYR_BASE/tests/subsys/pm/device_runtime_api/src/main.c:151: test_api: state not equal to PM_DEVICE_STATE_SUSPENDED
DEBUG   - QEMU (70346):
DEBUG   - QEMU (70346): FAIL - test_api in 0.9 seconds
DEBUG   - QEMU (70346): ===================================================================
DEBUG   - QEMU (70346): Test suite device_runtime_api failed.
DEBUG   - QEMU (70346): ===================================================================
DEBUG   - QEMU (70346): PROJECT EXECUTION FAILED
DEBUG   - QEMU (70346) complete (failed) after 2.0601963996887207 seconds
DEBUG   - No timeout, return code from QEMU (None): 0
DEBUG   - return code from QEMU (None): 0
DEBUG   - run status: qemu_cortex_a53_smp/tests/subsys/pm/device_runtime_api/subsys.pm.device_runtime_api failed
INFO    - 1/1 qemu_cortex_a53_smp       tests/subsys/pm/device_runtime_api/subsys.pm.device_runtime_api FAILED Failed (qemu 2.060s)

There is a race condition in SMP environment. It is possible that,  with 2 concurrent threads, the workqueue runs before the get_runner thread. The test is doing assumptions that there is only one core (get_runner priority would make it run before the workqueue), as the test is not testing smp nor require it, just changed the test to use only one core.


Generator rewrite

If the generator is rewritten the following features should be thought of:

Prefixing of interfaces (requires loading of other libraries while one library is generated, to detect if a type is an interface)
Generation of properties which are defined in an interface (requires loading of a different XML than the one which is currently generated)

I have a few ideas for this. I think the main point is to give us access to richer information about GObject types by processing the data beforehand (which is necessary for e.g. prefixing interfaces).
Preferably, we'd split the generator up into a few passes:

Load: Read in XML file for library and all dependencies
Preprocess: Resolve aliases, Obtain rich type information->for SignalArgs, GVariant, GValue, interface prefix, etc. By loading the entire tree and preprocessing, we also get dependencies' type information, which we'll need for renaming interfaces.
Validation: (Optional) Make sure gir data is complete/correct; more for third party libraries
Writing/Generation: Async generation of all source files (since we have all the data we need in Preprocess, we can simply write in any order. Should speed things up a lot I imagine). We also get the benefit of decoupling Scriban and templates from our logic.

The first three steps would be done synchronously, while the last step could use async/await so we're not waiting on File I/O.
I think you mentioned wanting to make this a dotnet tool, and I like this idea a lot. If we rewrite the generator, we should implement this at the same time. Would we also merge the build tool into the generator in that case?

I think you mentioned wanting to make this a dotnet tool, and I like this idea a lot. If we rewrite the generator, we should implement this at the same time. Would we also merge the build tool into the generator in that case?

I think we would not merge the build project. The dotnet tool is just able to generate one binding. As we are supporting several libraries we need to call the dotnet tool several times. This is probably the job of the Build project. Other 3rd party library authors perhaps want to build their project in a different way, so we just generate source files with the generator and don't force someone that we build their projects, too.

Generator wishlist/Adding for future reference:

We need to properly implement in/out/ref based on the direction annotation from gir
PascalCase for struct fields
Fix inconsistency where null becomes @null instead of Null.

From #127:

GstMessage and many other structs depends on support for custom Value types in the generator. This will allow us to use ref struct rather than the complicated and unsustainable (maintenance-wise) marshalling I'm using at the moment. This can reduce method bodies from >20 lines to sub-5, as we won't need to explicitly marshal anymore. It's probably much safer this way as well, as there is little chance of memory corruption from forgetting to free or update something.

The generator would need to care about reference handling see #78. We can probably have some helper methods which just take in the information on how to handle the ownership transfer as a bool parameter and generate the bool value directly from the gir. into the call of the helper method.

The generator would need to care about reference handling see #78. We can probably have some helper methods which just take in the information on how to handle the ownership transfer as a bool parameter and generate the bool value directly from the gir. into the call of the helper method.

I just tried to hide the class structs from GObjects (e.g. ButtonClass struct) and move them into the corresponding class (e.g. Button). This results in the problem that the references inside the GIR file are not matching anymore. As in the GIR the class structs are a top level element in the corresponding namespace (e.g. Gtk) and are referenced like Gtk.ButtonClass and not Gtk.Button.ButtonClass.
I wonder if we want to move the elements inside the gir into other locations. This would make probably a lot of things more complicated, similarly to renaming things as the integrity of the gir files referencing each other is not given anymore.
The benefit could be a cleaner API. But I wonder if it is worth the effort as we would diverge from the original API just to hide the class structs. Currently I would probably not change the location in the first public version. Perhaps this is even more of a feature than a flaw.

I just tried to hide the class structs from GObjects (e.g. ButtonClass struct) and move them into the corresponding class (e.g. Button). This results in the problem that the references inside the GIR file are not matching anymore. As in the GIR the class structs are a top level element in the corresponding namespace (e.g. Gtk) and are referenced like Gtk.ButtonClass and not Gtk.Button.ButtonClass.
I wonder if we want to move the elements inside the gir into other locations. This would make probably a lot of things more complicated, similarly to renaming things as the integrity of the gir files referencing each other is not given anymore.
The benefit could be a cleaner API. But I wonder if it is worth the effort as we would diverge from the original API just to hide the class structs. Currently I would probably not change the location in the first public version. Perhaps this is even more of a feature than a flaw.

I've hit a dead end with delegates (#119) under the current generator. Since we don't have rich type information, marshalling from an arbitrary type to managed and vice-versa isn't really possible.
I've started prototyping a staged generator (complete rewrite) on branch feature/generator-v2. Early results seem quite promising, as I've already got interface prefixing implemented. I'm having a look at how reparenting could work (probably just a simple rename from ButtonClass to Button.ButtonClass).
I still need to settle on a pattern for how data processing should work, since introspection data uses strings for references. I'm thinking we either:

resolve hard references database-style (but this would require "duplicate" classes which use resolved references)
write a custom serialiser (but this would make it very hard to deal with changes to gir data)
stick with string references, make introspection data immutable (so references are always valid), and allow user-added metadata.

I've implemented the third approach, as it's the most flexible. It essentially has a namespaced type dictionary which can take in either a qualified ('Gtk.Application') or unqualified name ('Application'), resolve it based on the active namespace, and make it accessible to services which implement the generation logic. It works well enough, but I'm not sure how scalable it is (and string-based APIs aren't nice to use).
I'm thinking it might be worth combining the first and third approach to get something like libgirepository (but written in C#). It means data will effectively be duplicated, but one of them will be raw serialised data, and the other will be processed resolved data, so perhaps it makes sense. The string references would be resolved by the type dict during processing rather than generation, so we can fully decouple generation from earlier stages.
I'll keep investigating into this a bit more, but I think the staged generator is the right way to go, given how easy it makes things like renaming and reparenting.

I've hit a dead end with delegates (#119) under the current generator. Since we don't have rich type information, marshalling from an arbitrary type to managed and vice-versa isn't really possible.
I've started prototyping a staged generator (complete rewrite) on branch feature/generator-v2. Early results seem quite promising, as I've already got interface prefixing implemented. I'm having a look at how reparenting could work (probably just a simple rename from ButtonClass to Button.ButtonClass).
I still need to settle on a pattern for how data processing should work, since introspection data uses strings for references. I'm thinking we either:

resolve hard references database-style (but this would require "duplicate" classes which use resolved references)
write a custom serialiser (but this would make it very hard to deal with changes to gir data)
stick with string references, make introspection data immutable (so references are always valid), and allow user-added metadata.

I've implemented the third approach, as it's the most flexible. It essentially has a namespaced type dictionary which can take in either a qualified ('Gtk.Application') or unqualified name ('Application'), resolve it based on the active namespace, and make it accessible to services which implement the generation logic. It works well enough, but I'm not sure how scalable it is (and string-based APIs aren't nice to use).
I'm thinking it might be worth combining the first and third approach to get something like libgirepository (but written in C#). It means data will effectively be duplicated, but one of them will be raw serialised data, and the other will be processed resolved data, so perhaps it makes sense. The string references would be resolved by the type dict during processing rather than generation, so we can fully decouple generation from earlier stages.
I'll keep investigating into this a bit more, but I think the staged generator is the right way to go, given how easy it makes things like renaming and reparenting.

This looks very good! I did not take a super deep look into the code, but I like what I see and the general direction of your code looks very promising.
I have 2 remakrs:

I don't like the ServiceManager as it is some kind of Anti-Pattern. For now this is not relevant as it can be changed / refactored later. I think even if we are done with the generator there will be quite a bit of refactoring, so I would not bother with it. We can fix it then.
The 2nd thing is the logger. I think there are enough logging frameworks available. We should probably use a given framework and not maintain those 500 lines of code. I'm quite sure we will find something good. It must not be one of those very well known "beasts" perhaps there is some neat nuget which fullfills our needs. I don't have some special framework in mind or even an idea. But let's keep to our basic mission: Create a Generator. Here applies the same like for the first point. Let's fix it at the end, as it is a minor point and should be not very hard to do.

Regarding "how data processing should work" I agree to you that we should start with the string based references. If we see the need we can use more advanced things. But I think this simplistic approach will be very well suited for this and if done right will be very well maintainable. Everything else would probably blow up the netto lines of code as I see no easy way to parse the gir files in some predefined structure in a simple and easy way.

This looks very good! I did not take a super deep look into the code, but I like what I see and the general direction of your code looks very promising.
I have 2 remakrs:

I don't like the ServiceManager as it is some kind of Anti-Pattern. For now this is not relevant as it can be changed / refactored later. I think even if we are done with the generator there will be quite a bit of refactoring, so I would not bother with it. We can fix it then.
The 2nd thing is the logger. I think there are enough logging frameworks available. We should probably use a given framework and not maintain those 500 lines of code. I'm quite sure we will find something good. It must not be one of those very well known "beasts" perhaps there is some neat nuget which fullfills our needs. I don't have some special framework in mind or even an idea. But let's keep to our basic mission: Create a Generator. Here applies the same like for the first point. Let's fix it at the end, as it is a minor point and should be not very hard to do.

Regarding "how data processing should work" I agree to you that we should start with the string based references. If we see the need we can use more advanced things. But I think this simplistic approach will be very well suited for this and if done right will be very well maintainable. Everything else would probably blow up the netto lines of code as I see no easy way to parse the gir files in some predefined structure in a simple and easy way.

I don't like the ServiceManager as it is some kind of Anti-Pattern. For now this is not relevant as it can be changed / refactored later. I think even if we are done with the generator there will be quite a bit of refactoring, so I would not bother with it. We can fix it then.

Yeah, this is temporary. I want the services to be stateless (static) in the long term. This is an easy way of keeping track of state while I iterate over various ideas.

The 2nd thing is the logger. I think there are enough logging frameworks available. We should probably use a given framework and not maintain those 500 lines of code. I'm quite sure we will find something good. It must not be one of those very well known "beasts" perhaps there is some neat nuget which fullfills our needs. I don't have some special framework in mind or even an idea. But let's keep to our basic mission: Create a Generator. Here applies the same like for the first point. Let's fix it at the end, as it is a minor point and should be not very hard to do.

I looked for a logging library at first but everything I found was unnecessarily complex when all I wanted was Console.WriteLine with colours. If we find something nice, it should be a simple find + replace to switch libraries, so no big deal.

I've been having a look at gtk-rs's gir tool (specifically library.rs and parser.rs) and they also have a separation between serialised and processed data. Based on this, I'm experimenting with separating the Generator into two projects:

Repository -> Loading/Parsing/Resolving introspection data
Generator -> Data driven generator. Consumes Repository. No dependency on file format

It's not that much larger in lines of code, and greatly improves the readability of the Generator. It lets us effectively make a data-driven generator and not have to worry about the GIR file format. I'm a bit worried that by using the serialised classes directly (as we do now), any change in GIR will break the entire generator.

I don't like the ServiceManager as it is some kind of Anti-Pattern. For now this is not relevant as it can be changed / refactored later. I think even if we are done with the generator there will be quite a bit of refactoring, so I would not bother with it. We can fix it then.

Yeah, this is temporary. I want the services to be stateless (static) in the long term. This is an easy way of keeping track of state while I iterate over various ideas.

The 2nd thing is the logger. I think there are enough logging frameworks available. We should probably use a given framework and not maintain those 500 lines of code. I'm quite sure we will find something good. It must not be one of those very well known "beasts" perhaps there is some neat nuget which fullfills our needs. I don't have some special framework in mind or even an idea. But let's keep to our basic mission: Create a Generator. Here applies the same like for the first point. Let's fix it at the end, as it is a minor point and should be not very hard to do.

I looked for a logging library at first but everything I found was unnecessarily complex when all I wanted was Console.WriteLine with colours. If we find something nice, it should be a simple find + replace to switch libraries, so no big deal.

I've been having a look at gtk-rs's gir tool (specifically library.rs and parser.rs) and they also have a separation between serialised and processed data. Based on this, I'm experimenting with separating the Generator into two projects:

Repository -> Loading/Parsing/Resolving introspection data
Generator -> Data driven generator. Consumes Repository. No dependency on file format

It's not that much larger in lines of code, and greatly improves the readability of the Generator. It lets us effectively make a data-driven generator and not have to worry about the GIR file format. I'm a bit worried that by using the serialised classes directly (as we do now), any change in GIR will break the entire generator.

I'm a bit worried that by using the serialised classes directly (as we do now), any change in GIR will break the entire generator.

I'm not strictly against of abstracting away the GIR file. I think from an architectural point of view it makes sense. But it involes some kind of structure in between which needs to be maintained. I believe that the GIR format is well maintained and stable (there are deprecated annotations and possible future annotations). So I assume that the GIR will not change in genral but perhaps add some new features. I'm going to verify this in #introspection.

It's not that much larger in lines of code, and greatly improves the readability of the Generator. It lets us effectively make a data-driven generator and not have to worry about the GIR file format.

This is always a killer feature for me. If we can improve readability it is a must have. But then I would wonder why is the same quality of readability not possible while using the GIR classes? If you have some examplary code which abstracts away the GIR classes available please ping me for a quick check perhaps we can work something out.

I'm a bit worried that by using the serialised classes directly (as we do now), any change in GIR will break the entire generator.

I'm not strictly against of abstracting away the GIR file. I think from an architectural point of view it makes sense. But it involes some kind of structure in between which needs to be maintained. I believe that the GIR format is well maintained and stable (there are deprecated annotations and possible future annotations). So I assume that the GIR will not change in genral but perhaps add some new features. I'm going to verify this in #introspection.

It's not that much larger in lines of code, and greatly improves the readability of the Generator. It lets us effectively make a data-driven generator and not have to worry about the GIR file format.

This is always a killer feature for me. If we can improve readability it is a must have. But then I would wonder why is the same quality of readability not possible while using the GIR classes? If you have some examplary code which abstracts away the GIR classes available please ping me for a quick check perhaps we can work something out.

Before reimplementing the services as static let's discuss / review this as static services could potentially be as problematic as a static service manager.
Sorry for my interference I just want to make sure that there is as less doubled work as possible.

Before reimplementing the services as static let's discuss / review this as static services could potentially be as problematic as a static service manager.
Sorry for my interference I just want to make sure that there is as less doubled work as possible.

The new PR for this is #274


[BUG] marlin_cuda_kernel.cuh and others missing from pypi

Describe the bug
pypi json data about AutoGPTQ gives a source download file auto_gptq-0.7.1.tar.gz which is missing some required files. Specifically, the .cuh files are missing and marlin only contains:
auto_gptq-0.7.1/autogptq_extension/marlin/
auto_gptq-0.7.1/autogptq_extension/marlin/marlin_cuda.cpp
auto_gptq-0.7.1/autogptq_extension/marlin/marlin_cuda_kernel.cu
auto_gptq-0.7.1/autogptq_extension/marlin/marlin_repack.cu

This in turns cause compilation to fail:
  /build/auto-gptq-0.7.1/work/auto_gptq-0.7.1/autogptq_extension/marlin/marlin_cuda_kernel.cu:27:10: fatal error: marlin_cuda_kernel.cuh: No such file or directory
     27 | #include "marlin_cuda_kernel.cuh"
        |          ^~~~~~~~~~~~~~~~~~~~~~~~
  compilation terminated.

Note that downloading the github generated archive for the 0.7.1 tag contains the .cuh files:
AutoGPTQ-0.7.1/autogptq_extension/marlin/
AutoGPTQ-0.7.1/autogptq_extension/marlin/marlin_cuda.cpp
AutoGPTQ-0.7.1/autogptq_extension/marlin/marlin_cuda_kernel.cu
AutoGPTQ-0.7.1/autogptq_extension/marlin/marlin_cuda_kernel.cuh
AutoGPTQ-0.7.1/autogptq_extension/marlin/marlin_repack.cu
AutoGPTQ-0.7.1/autogptq_extension/marlin/marlin_repack.cuh

Software version

AzusaOS
Python 3.12.2
pytorch 2.2.1

To Reproduce
Steps to reproduce the behavior:

Download source from pypi
Attempt to build. It will fail because some files are missing.

Expected behavior
Packaged version on pypi should include all files needed to build auto-gptq.
I am guessing the method used to package the data for pypi excludes .cuh files.

Hi Mark, thank you for the report! https://github.com/AutoGPTQ/AutoGPTQ/pull/600 fixed the issue, this will be fixed on PyPI in the next release.


Eliminate global state: wallet_handle

https://github.com/hyperledger/aries-vcx/pull/517
https://github.com/hyperledger/aries-vcx/pull/519


Would be nice if lilBox closed when you click off

It would be great if, when users click off the box, it closes.  The X and close buttons work fine, but having the option would also be nice, too.
Right now I don't think this works for lilBox.basic or lilBox.ok 😸

I think for lilBox.basic, this makes sense. Fixed in Master.


Difference between "with()" validation of args vs. block validation of args when mixing expect+allow

Subject of the issue
Its a bit complicated, but what I'm really trying to do is get something that behaves a bit like a custom MessageExpectation matcher to modify the matching behavior of with().   See https://stackoverflow.com/questions/50807345/how-to-write-a-custom-messageexpectation-in-rspec/50807536#50807536 for some backstory.  The answer in that is something that I've implemented, but I'm having difficulties mixing allow+expect on the same object with the same method call, but different args, after I've converted the arg matching over to using blocks instead of with.
Your environment

Ruby version: 2.5.1
rspec-mocks version: 3.7.0

Steps to reproduce
require 'spec_helper'

describe "whatever" do
  it "works" do
    obj = Object.new
    allow(obj).to receive(:shell_out!).with("foo")
    expect(obj).to receive(:shell_out!).with("bar")
    obj.shell_out!("foo")
    obj.shell_out!("bar")
  end

  it "does not work" do
    obj = Object.new
    allow(obj).to receive(:shell_out!) do |args|
      expect(args).to eql("foo")
    end
    expect(obj).to receive(:shell_out!) do |args|
      expect(args).to eql("bar")
    end
    obj.shell_out!("foo")
    obj.shell_out!("bar")
  end
end

Expected behavior
I suspect there's good reasons why blocks can't be made magical like I'd want, because its not clear if the blocks "match" or not the same way that can be done to the arguments to with()?  If so, I guess this boils down into a request for being able to write a custom MessageExpectation.  Or maybe a request for a way to "preprocess" the actual arguments that were passed before handing off to the with() matcher?
I'm trying to get to something like:
describe "whatever" do
  it "works" do
    obj = Object.new
    allow(obj).to receive(:shell_out!).flatten_compact_args.with("foo", "bar")
    obj.shell_out!("foo", nil, [ "bar" ])
  end

  it "works" do
    obj = Object.new
    allow(obj).to receive(:shell_out!).flatten_compact_args.with("foo", "bar")
    expect(obj).to receive(:shell_out!).flatten_compact_args.with("baz", "quux")
    obj.shell_out!("foo", nil, [ "bar" ])
    obj.shell_out!([ "baz", nil ], "quux")
  end
end

When you pass a block, the block defines the new implementation of the method.  So when you do this:
    allow(obj).to receive(:shell_out!) do |args|
      expect(args).to eql("foo")
    end
    expect(obj).to receive(:shell_out!) do |args|
      expect(args).to eql("bar")
    end

...you are first replacing the existing obj.shell_out! implementation with expect(args).to eql("foo"), and then replacing that implementation with expect(args).to eql("bar").  That's why it's not working how you'd like.
In general, defining a custom matcher and passing it to with is the normal way to go, but as you've noticed you can't write a custom matcher that is given the entire list of arguments -- each arg passed to with operates on a single positional arg.
The simplest way to do what you'd like is to do a single allow with an implementation that tracks the passed args, and then make expectations about the args at the end.  Like so:
  it "works" do
    flattened_arg_lists = []

    obj = Object.new
    allow(obj).to receive(:shell_out!) { |*args| flattened_arg_lists << args.flatten.compact }

    obj.shell_out!("foo", nil, [ "bar" ])
    obj.shell_out!([ "baz", nil ], "quux")

    expect(flattened_arg_lists).to include(["baz", "quux"])
  end

thanks!


Does not load

I've already updated to the latest version, however the app doesn't seem to load anything, i don't know if the problem is on my end or the server end

@danialol94 can you access to the nhentai.net or nhent.ai in your browser?

I got this error when trying to accesa nhent.ai

Try nhentai.net nhent.ai can be tricky sometimes. Go to Settings and turn off "Use nhent.ai" option

Also its normal for the app to unable to load anything since the website is down

I initially thought it was server issue since I've been using VPN, anyway thank you bro

@danialol94 You can close this issue if you want. Im glad I could help ya!


Table is not shown properly in GH

An extra line break is required before the table header.
GH needs it but some markdown viewers don't.

Thanks, Alex.


Allow use of date_string in service call

Description:
In the original implementation of the Todoist calendar component it was not possible to allow Todoist natural language for due dates. This PR adds this capability.
Also fixes the services.yaml for the service call
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#4923
Checklist:

[x] The code change is tested and works locally.
[x] Local tests pass with tox. Your PR cannot be merged unless tests pass

If user exposed functionality or configuration variables are added/changed:

[x] Documentation added/updated in home-assistant.github.io

@tinloaf Thanks for the feedback, think I've processed it all in the latest commit 👍

Doh... Missed that one indeed. Fixed now, thanks 👍

Do I need to do anything else to have this PR (and the accompanying docs PR) merged?


Add Surface Pro 9 models

Closed due to the OSDCloud repo being updated and maintainer updated from there.


c8d/export: Fix temporary image being deleted too early

The image was scheduled for deletion before the actual export was started.
For bigger images this resulted in the output archive being incomplete, because the content is usually deleted faster than the whole image is exported to an archive.
Also made the temporary image name unique by adding an uuid, just to avoid breaking the export if concurrent exports are taking place.

- What I did
- How I did it
- How to verify it
- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

It was the defer i.client.ImageService().Delete(ctx, newImg.Name, containerdimages.SynchronousDelete()) that was called inside a helper function. This caused the image to be scheduled for deletion just after the helper function exited and not the whole ExportImage function.
That was probably because at first I had all of this in ExportImage and as a last-touch refactoring I extracted it to a helper function and forgot about the defer 😄

Lease won't change anything here as images are not GCed by c8d automatically. They need to be deleted explicitly.


Resolve Menu Size Issue with Scrollbar Solution

Description
This pull request addresses the open issue regarding the "Menu size issue with some monitor resolutions". Collaborating with @foivospro, we've proposed a solution to accommodate the varying sizes of languages in the navbar without hiding any options. Our solution involves implementing a scrollbar within the navbar to ensure all language options remain accessible.
Key Points of the Solution:

Dynamic Sizing: Adjusted the navbar layout to dynamically accommodate languages of varying lengths, preventing any options from being hidden.

Scrollbar Integration: Introduced a scrollbar within the navbar to enable users to navigate through the language options seamlessly, even on screens with limited space.

Please provide a summary of the changes, including relevant motivation and context.
Closes #929
Checklist:

[x ] I have read the Contribution Guidelines
[x ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[x ] My changes generate no new warnings

Contributor License Agreement
By submitting this pull request, I acknowledge and agree that my contributions will be included in Stirling-PDF and that they can be relicensed in the future under the MPL 2.0 (Mozilla Public License Version 2.0) license.
(This does not change the general open-source nature of Stirling-PDF, simply moving from one license to another license)

Sorry will not be merging this, we have a whole redesign UI PR open which will render this unused


How to print log from tools called via mise exec?

Hi,
I'm using Mise in my development workflow, especially with the Tuist (tuist.io) CLI tool. Unfortunately, when I call tuist generate via Mise (mise x -- tuist generate), the output from Tuist never prints. Is there a way to capture the stdout of the tool being called?
Thanks

mise already does this, it's probably something to do with tuist
Cc @pepicrft

@malcommac that's odd, we output the logs through the standard pipelines, which Mise forwards. I double-checked with the github.com/tuist/tuist repository, where we also use Tuist against Tuist, and it works as expected. What do you get if you try there:
mise x -- tuist generate


⚠ Bofrost.lu has degraded performance

In 5095d04, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1246 ms

Resolved: Bofrost.lu performance has improved in 1c4c196 after 6 minutes.


Atome

Breaking Change:

Description:
The atome sensor platform is retrieving the consumption of your home from the Direct Energy Atome electric meter.
This special little device is connected to a Linky Electric Meter, and sends live data to a cloud platform.
Related issue (if applicable): fixes #
Pull request with documentation for home-assistant.io (if applicable): home-assistant/home-assistant.io#<home-assistant.io PR number goes here>
10172: https://github.com/home-assistant/home-assistant.io/pull/10172
Example entry for configuration.yaml (if applicable):
sensor:
  - platform: atome
    username: YOUR_ATOME_USERNAME
    password: YOUR_ATOME_PASSWORD

Checklist:

[x] The code change is tested and works locally.
[x] Local tests pass with tox. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.
[x] I have followed the development checklist

If user exposed functionality or configuration variables are added/changed:

[x] Documentation added/updated in home-assistant.io

If the code communicates with devices, web services, or third-party tools:

[x] The manifest file has all fields filled out correctly. Update and include derived files by running python3 -m script.hassfest.
[x] New or updated dependencies have been added to requirements_all.txt by running python3 -m script.gen_requirements_all.
[x] Untested files have been added to .coveragerc.

If the code does not interact with devices:

[ ] Tests have been added to verify that the new code works.

Hello @BaQs,
When attempting to inspect the commits of your pull request for CLA signature status among all authors we encountered commit(s) which were not linked to a GitHub account, thus not allowing us to determine their status(es).
The commits that are missing a linked GitHub account are the following:

1cc886affb6101aac04209c5313119df2d79c2d8 - This commit has something that looks like an email address (baqs@users.github.com). Maybe try linking that to GitHub?.
747ba8ff73a87b99af6e68e957c351003d190dcb - This commit has something that looks like an email address (baqs@users.github.com). Maybe try linking that to GitHub?.
aa48a72aa846a9c962fdd1262f4fd9fcf2ecb1f4 - This commit has something that looks like an email address (baqs@users.github.com). Maybe try linking that to GitHub?.
1b610e3e1a153ba958c0cd5774977fd4780ed0ab - This commit has something that looks like an email address (baqs@users.github.com). Maybe try linking that to GitHub?.
54cbd69dd2a6f07e8f91eea4989081d4b6a60fa7 - This commit has something that looks like an email address (baqs@users.github.com). Maybe try linking that to GitHub?.
ef1a4447c2750db07971225f3a6bb3a410a0f80c - This commit has something that looks like an email address (baqs@users.github.com). Maybe try linking that to GitHub?.
12aedb74bdbc1ecb3c24ab018075ca24ae821e9c - This commit has something that looks like an email address (baqs@users.github.com). Maybe try linking that to GitHub?.
92301a78a2ad18a68be957a3f473522f9888fbcb - This commit has something that looks like an email address (baqs@users.github.com). Maybe try linking that to GitHub?.
6e326f56728bd7c9763f62eb16c49fa8320e1017 - This commit has something that looks like an email address (baqs@users.github.com). Maybe try linking that to GitHub?.
3a96ac40a1ac0b97c7ba08c140226f14ea25807f - This commit has something that looks like an email address (baqs@users.github.com). Maybe try linking that to GitHub?.

Unfortunately, we are unable to accept this pull request until this situation is corrected.
Here are your options:

If you had an email address set for the commit that simply wasn't linked to your GitHub account you can link that email now and it will retroactively apply to your commits. The simplest way to do this is to click the link to one of the above commits and look for a blue question mark in a blue circle in the top left. Hovering over that bubble will show you what email address you used. Clicking on that button will take you to your email address settings on GitHub. Just add the email address on that page and you're all set. GitHub has more information about this option in their help center.

If you didn't use an email address at all, it was an invalid email, or it's one you can't link to your GitHub, you will need to change the authorship information of the commit and your global Git settings so this doesn't happen again going forward. GitHub provides some great instructions on how to change your authorship information in their help center.

If you only made a single commit you should be able to rungit commit --amend --author="Author Name<EMAIL_ADDRESS>
(substituting Author Name and<EMAIL_ADDRESS>for your actual information) to set the authorship information.
If you made more than one commit and the commit with the missing authorship information is not the most recent one you have two options:

You can re-create all commits missing authorship information. This is going to be the easiest solution for developers that aren't extremely confident in their Git and command line skills.
You can use this script that GitHub provides to rewrite history. Please note: this should be used only if you are very confident in your abilities and understand its impacts.

Whichever method you choose, I will come by to re-check the pull request once you push the fixes to this branch.

We apologize for this inconvenience, especially since it usually bites new contributors to Home Assistant. We hope you understand the need for us to protect ourselves and the great community we all have built legally. The best thing to come out of this is that you only need to fix this once and it benefits the entire Home Assistant and GitHub community.
Thanks, I look forward to checking this PR again soon! :heart:


Add option to parse comments

https://github.com/Microsoft/vscode-go/pull/1116#discussion_r133992917 was closed due to inactivity, this PR is an attempt to follow up to where the discussion has left off.

For performance reasons, this functionality will be implemented in gocode instead (see thread in https://github.com/Microsoft/vscode-go/issues/1072)


Performance regression in stats.mode due to _axis_nan_policy decorator

Copying relevant part of https://github.com/scipy/scipy/issues/18254#issuecomment-1502973890:
I wanted to do some quick tests of  _axis_nan_policy_factory from within IPython, and it failed with a hard to understand inspect.signature traceback:
>>> def f(x):
...     x
...
>>> _axis_nan_policy_factory(f)([1])
Traceback (most recent call last):
  Cell In[16], line 1
    _axis_nan_policy_factory(f)([1])
  File ~/code/scipy/build-install/lib/python3.10/site-packages/scipy/stats/_axis_nan_policy.py:612 in axis_nan_policy_decorator
    sig = inspect.signature(axis_nan_policy_wrapper)
...
ValueError: callable [1] is not supported by signature

That led me to look at that factory function closer, and it's using inspect quite a bit - which tends to be not a good idea at runtime. Aside from robustness, some benchmarking shows large performance regressions:
>>> import numpy as np
>>> from scipy import stats
>>> z = np.random.randint(10000)
>>> scipy.__version__
'1.10.1'
>>> %timeit stats.mode(z, keepdims=True)
47.9 µs ± 235 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each)

compared to main:
>>> %timeit stats.mode(z, keepdims=True)
229 µs ± 2.45 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)

I have not been involved in review of that machinery - I assume some of this was discussed already? My first impression is that the ~250 line implementation of _axis_nan_policy_factory looks a bit scary.

Aside from robustness, some benchmarking shows large performance regressions:

Basing this assessment on input of size 1 input seems somewhat unfair to me : /
The regression on 1D input is a constant overhead that disappears once the total execution time is on the order of a few ms.

import numpy as np
from scipy import stats
import matplotlib.pyplot as plt
rng = np.random.default_rng(1638083107694713882823079058616272161)
from time import perf_counter_ns

np.logspace(0, 7, 17, dtype=int)

times_main = []
times_110 = []
sizes = np.logspace(0, 7, 17, dtype=int)
for size in sizes:
    z = np.random.randint(10000, size=size)

    tic = perf_counter_ns()
    res = stats.mode(z)
    toc = perf_counter_ns()
    times_main.append((toc-tic)/1e9)

    tic = perf_counter_ns()
    res = stats.mode(z, _no_deco=True)
    toc = perf_counter_ns()
    times_110.append((toc-tic)/1e9)

plt.loglog(sizes, times_main, sizes, times_110)
plt.legend(("With Decorator", "Without Decorator"))
plt.xlabel("input size")
plt.ylabel("execution time (s)")
plt.show()

Reducing this overhead is important to me, but I think it's important to keep it in context.

I have not been involved in review of that machinery - I assume some of this was discussed already?

Yes, I believe a few active stats maintainers discussed that this was a fair, temporary price to pay for fixing lots of bugs. Note that there are many ways to reduce that overhead, all in good time. But there haven't been issues filed about the overhead (except this), so I haven't prioritized it.

I wanted to do some quick tests of _axis_nan_policy_factory from within IPython, and it failed with a hard to understand inspect.signature traceback:

It is a private tool, so it does not give great error messages when configured incorrectly. For instance, the decorator is primarily for reduction operations, and f is an elementwise operation.
The factory also needs a few arguments to produce a decorator for this function. (It was originally designed for hypothesis tests that produce namedtuples, so the defaults are not configured to handle this simple case.)

from scipy import stats
import numpy as np
from scipy.stats._axis_nan_policy import _axis_nan_policy_factory
rng = np.random.default_rng(94713882823079058616272161)

@_axis_nan_policy_factory(tuple_to_result=lambda x: x,
                          n_outputs=1,
                          result_to_tuple=lambda x: (x,))
def my_mean(x):
    return sum(x)/len(x)

x = rng.random(size=(3, 5))
my_mean(x, axis=None)  # 0.5260813343900258
my_mean(x, axis=0)  # array([0.66651292, 0.61757697, 0.28485519, 0.40367072, 0.65779087])
my_mean(x, axis=-1, keepdims=True)
# array([[0.4448106 ],
#        [0.76953225],
#        [0.36390116]])

x[x > 0.5] = np.nan
my_mean(x, axis=1)  # array([nan, nan, nan])
my_mean(x, axis=1, nan_policy='omit')  # array([0.12083134, 0.46403535, 0.19273502])
# my_mean(x, nan_policy='raise')  # ValueError: The input contains nan values

x = rng.random(size=(2, 3, 4, 5))
my_mean(x, axis=(1, 2)).shape  # (2, 5)

x = rng.random(size=(0, 5))
assert my_mean(x, axis=0).shape  # (5,), like NumPy
assert my_mean(x, axis=1).shape  # (0,), like NumPy

Yes, I believe a few active stats maintainers discussed that this was a fair, temporary price to pay for easily fixing bugs, addressing enhancement requests, and paving a way toward unifying stats and mstats. Note that there are many ways to reduce that overhead, all in good time. But I don't recall issues filed about the overhead (except this), so I haven't prioritized it.

Thanks for the detailed reply, and fair enough - correctness and maintainability should come first, and performance optimization afterwards.
The inspect usage does look a bit too fragile to me (e.g., I suspect it may not be happy with PYTHONOPTIMIZE=2, which strips docstrings, in all circumstances), but I did a cursory bit of testing and could not make it break - so should be good enough, and bugs will get addressed if/when they show up.

@mdhaber I wanted to flag this as a concern, but please feel free to close this issue if it's not helpful to you.


temporal alignment for raster stacker

[ ] I added an entry to CHANGELOG.md if knowledge of this change could be valuable to users.

Here is a brief summary of what I did:

 Multibands: RasterStacker soll temporal alignen

I think we need more tests:
* Source with 1 BAnd and Source with more then 2

* 3 Sources

073339d32d54bb99299fc804276379161b542671


oneOf only supports first sub-schema

Description
Only the first sub-schema of oneOf is supported. Usage of any other sub-schema results in an error.
Steps to reproduce

See unit test in pull request #586

Expected behavior
Any one of multiple sub-schemas of oneOf should be supported
System Information:

OS & version: Ubuntu
Browser & version: n/a
Specmatic version: 0.59.0
JDK version: 11

Additional context
Also blocks resolution of another bug related to a dictionary with values with oneOf schema #587

I think this is related too: https://github.com/znsio/specmatic/pull/588#issuecomment-1399256057

@westse as mentioned by @joelrosario we had to look at this failing scenario 437e242be4650519df78d1445a609b1b0e2bae6a and we have subsequently fixed the same with 24340d8ee6b55b98dc30cfbc378596616460f728


TxDatabase.Wrap() does not perform Rallback() in case of panic.

TxDatabase.Wrap() does not perform Rollback() in case of panic.
It's trivial to fix or workaround, but it either should be fixed or documented properly.

@nikolay-turpitko once the supplied function is done, it'll complete or rollback the transaction. I would recommend handling the error and only panic-ing when absolutely necessary. I may be missing something, if so, please provide an example or test-case as best I can tell, it is working like it should.
tx, err := db.Begin()
if err != nil{
     panic(err.Error()) //you could gracefully handle the error also
}
if err := tx.Wrap(func() error{
    if _, err := tx.From("test").Insert(Record{"a":1, "b": "b"}).Exec(){
        //this error will be the return error from the Wrap call
        // should rollback here
        return err
    }
    // should commit here
    return nil
}); err != nil{
     panic(err.Error()) //you could gracefully handle the error also
}

@TechnotronicOz I suggest to add a phrase to the function's description like "Notice, that this function does not rollback transaction in case of panic, handle it yourself" and close this issue. Looking on the documentation alone I thought that it'd rollback in case of panic for me.

https://godoc.org/github.com/doug-martin/goqu#TxDatabase.Wrap

@TechnotronicOz yes, this is the place where you could add this sentence. Probably, my English is not particularly well, it's not my mother tongue after all, but from the current doc it's not immediately clear for me, that in case of panic transaction neither committed or rolled back. If you think it's clear enough, then it's just my fault. Feel free to close the issue. Thanks!


Issue with date Conversion

Hi there,
I think I discovered a serious issue with date conversion here is an example:
console.log(new DateOnly(20160101).toDate())
//Mon Feb 01 2016 00:00:00 GMT+1300 (NZDT) - Correct
Now we change year to 2017
console.log(new DateOnly(20170101).toDate())
//Wed Mar 01 2017 00:00:00 GMT+1300 (NZDT) - Not correct
So I'm not sure if you aware of this but if you could shine some light on why it works this way would be much appreciated.
Thanks

Thanks, this is now fixed and published on npm @1.1.1.


dependency graph submission seems unsuccessful as cannot be found by dependency review action

Hi,
I set up the gradle-build-action so that it generates and submits the dependency graph to the github dependency submission api:
- name: 👩🏻🍳 Setup gradle
  uses: gradle/gradle-build-action@v2
  with:
    dependency-graph: generate-and-submit

There are three executions of gradle in my CI (build and test, javadoc, generate cyclonedx sbom) so gradle generates a dependency graph for each of these tree runs.
When looking at the post operation of the gradle-build-action in my builds I can see the following if the CI workflow gets triggered by a PR:
Post job cleanup.
In final post-action step, saving state and writing summary
Cache is read-only: will not save state for use in subsequent builds.
Writing job summary
Uploading dependency graph files: dependency-graph-reports/ci_pipeline-build_test_sbom_javadoc-1.json,dependency-graph-reports/ci_pipeline-build_test_sbom_javadoc-2.json,dependency-graph-reports/ci_pipeline-build_test_sbom_javadoc.json
Starting artifact upload
For more detailed logs during the artifact upload process, enable step-debugging: https://docs.github.com/actions/monitoring-and-troubleshooting-workflows/enabling-debug-logging#enabling-step-debug-logging
Artifact name is valid!
Container for artifact "dependency-graph" successfully created. Starting upload of file(s)
Total size of all the files uploaded is 23964 bytes
File upload process has finished. Finalizing the artifact upload
Artifact has been finalized. All files have been successfully uploaded!

The raw size of all the files that were specified for upload is 275964 bytes
The size of all the files that were uploaded is 23964 bytes. This takes into account any gzip compression used to reduce the upload size, time and storage

Note: The size of downloaded zips can differ significantly from the reported size. For more information see: https://github.com/actions/upload-artifact#zipped-artifact-downloads

Notice: Submitted dependency-graph-reports/ci_pipeline-build_test_sbom_javadoc-1.json: The snapshot was accepted, but it is not for the default branch. It will not update dependency results for the repository.
Notice: Submitted dependency-graph-reports/ci_pipeline-build_test_sbom_javadoc-2.json: The snapshot was accepted, but it is not for the default branch. It will not update dependency results for the repository.
Notice: Submitted dependency-graph-reports/ci_pipeline-build_test_sbom_javadoc.json: The snapshot was accepted, but it is not for the default branch. It will not update dependency results for the repository.

Looking at the last three lines of that output it seems that the dependency results have not been updated.
The dependency review action is set up in a different yml file following your example in the README.md:
name: "Dependency review"

on:
  pull_request:
    branches: [ main ]
# remove default permissions from the token
permissions: {}

jobs:
  dependency_review:
    name: Dependency review
    runs-on: ubuntu-latest
    permissions:
      actions: read
      contents: read
      pull-requests: write

    steps:
      - name: 🥽 PR dependency review
        uses: actions/dependency-review-action@v3
        with:
          comment-summary-in-pr: 'always'
          # Enable retrying the action every 10 seconds while waiting for dependency submission actions to complete.
          retry-on-snapshot-warnings: true
          # Maximum amount of seconds to retry the action while waiting for dependency submission actions to complete.
          retry-on-snapshot-warnings-timeout: 300

However, the dependency review action cannot find the snapshot though even minutes after the CI workflow finished:
Run actions/dependency-review-action@v3
  with:
    comment-summary-in-pr: always
    retry-on-snapshot-warnings: true
    retry-on-snapshot-warnings-timeout: 300
    repo-token: ***
No snapshots were found for the head SHA 82ef38589abd4553abfcb95d6dc120fbdf166567.
Retrying in 10 seconds...
No snapshots were found for the head SHA 82ef38589abd4553abfcb95d6dc120fbdf166567.
Retrying in 10 seconds...

I'd appreciate any help to get the dependency graph successfully submitted for PRs so that it can be picked up by the dependency review action.

Thank you @DuncanCasteleyn for taking the time to comment, much appreciated.
Just to clarify: The workflow to execute actions/dependency-review-action@v3 has two parameters that configure it to check every 10 seconds if the snapshots are available for up to 5 minutes:
 # Enable retrying the action every 10 seconds while waiting for dependency submission actions to complete.
retry-on-snapshot-warnings: true
# Maximum amount of seconds to retry the action while waiting for dependency submission actions to complete.
retry-on-snapshot-warnings-timeout: 300

This follows the example given in the dependency action documenation.

Oh, that's good to know. Strange that they told us something different during the meeting and it was just 1 week ago they should know how their own actions work.
In any case did you try a checkout on your actual head of the branch instead of the pull requests merged state? to clarify what i mean is this https://github.com/actions/checkout?tab=readme-ov-file#checkout-pull-request-head-commit-instead-of-merge-commit it might make no difference but worth a try to figure out what might be happening, if this resolves it this might be a bug with the action or dependency graph API.

@DuncanCasteleyn Thanks again for your comment. I submitted a ticket to github support but haven't received a reply yet. I'll update here if I am able to get this resolved...

Hi @uli-f
Have you tried to use  generate value in the dependency-graph parameter and then at the end of those 3 jobs running the action with download-and-submit prior to running the dependency review action?
See

@uli-f Update, I've misread your issue (I assume there were 3 different jobs doing the build. So this might be even simpler
name: Run Gradle Build

on:
  push:
    branches: [ "main", "development" ]
  pull_request:
    branches: [ "main", "development" ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Set up JDK 11
        uses: actions/setup-java@v3
        with:
          java-version: '11'
          distribution: 'temurin'

      - name: Set up Gradle Build Action
        uses: gradle/gradle-build-action@v2
        with:
          dependency-graph: generate-and-submit
          cache-disabled: true

      - name: Build and test with Gradle
        run: ./gradlew build

  dependency-review:
      runs-on: ubuntu
      if: github.event_name == 'pull_request'

      steps:

      - name: Set up Gradle Build Action
        uses: gradle/gradle-build-action@v2
        with:
          dependency-graph: download-and-submit
          cache-disabled: true

      - name: 'Dependency Review'
        uses: actions/dependency-review-action@v3

I have not tried it with more than submission, I will if I can find an example with more than one submission

Thank you for your comments @tspascoal.
Yes, I have a single job calling gradle three times for different reasons (build and test, javadoc, generate sbom).
My scenario isn't running PRs from forks, but having a workflow that can run
on:
  pull request

which includes PRs opened by dependabot. My understanding is that PRs opened by dependabot run with limited permissions comparable to PRs from forks.
Looking at the dependency-review job of your example above:
dependency-review:
      runs-on: ubuntu
      if: github.event_name == 'pull_request'

      steps:

      - name: Set up Gradle Build Action
        uses: gradle/gradle-build-action@v2
        with:
          dependency-graph: download-and-submit
          cache-disabled: true

      - name: 'Dependency Review'
        uses: actions/dependency-review-action@v3

my understanding is that the dependency-review action diffs the dependency-graph of two revisions of my repo. The dependency-review job above is only run if the workflow was triggered by a PR. So what revision would the dependency graph of the PR be compared to? In other words, I don't see the dependency-review action being run for main to generate a baseline dependency graph.

Thank you for your comments @tspascoal.
Yes, I have a single job calling gradle three times for different reasons (build and test, javadoc, generate sbom).
My scenario isn't running PRs from forks, but having a workflow that can run
on:
  pull request

which includes PRs opened by dependabot. My understanding is that PRs opened by dependabot run with limited permissions comparable to PRs from forks.

Both dependabot and PR from forks will run with limited permissions (read only), but I also don't think it makes sense to run dependency review on dependabot alerts, since dependabot is going to fix potential vulnerabilities and not add them. :)
So if it's about dependabot, just put a condition to avoid dependency review to run if it's a dependabot PR
something like this
       - name: 'Dependency Review'
         if: github.event_name == 'pull_request && github.actor != 'dependabot[bot]'
         uses: actions/dependency-review-action@v3

See About Dependabot and GitHub Actions

Looking at the dependency-review job of your example above:
dependency-review:
      runs-on: ubuntu
      if: github.event_name == 'pull_request'

      steps:

      - name: Set up Gradle Build Action
        uses: gradle/gradle-build-action@v2
        with:
          dependency-graph: download-and-submit
          cache-disabled: true

      - name: 'Dependency Review'
        uses: actions/dependency-review-action@v3

my understanding is that the dependency-review action diffs the dependency-graph of two revisions of my repo. The dependency-review job above is only run if the workflow was triggered by a PR. So what revision would the dependency graph of the PR be compared to? In other words, I don't see the dependency-review action being run for main to generate a baseline dependency graph.

There are 2 steps. One is submitting the dependencies and that is done by the gradle action. That needs to be done both on default branch and on PRs.
And then on PRs the dependency review will run run, based on those two "diffs"
So the dependency submission is used to feed information to the dependency graph (, this will allow you to see both the graph, generate the SBOM (from the UI or using GH api) or for dependabot to generate alerts. (the alerts are generated from the default branch).
The dependency review, is used on the PR process to prevent (or warn) the introduction of version that have know vulnerabilities.
They are orthogonal. BUT dependency review might need the submission process for some package managers (like graddle) to be aware of the graph.
If the dependencies from running  javadoc and generate sbom don't really matter you can also disable it's generation by using the environment variable GITHUB_DEPENDENCY_GRAPH_ENABLED: false to the gradle step that is doing javadoc and generate sbom (I assume you have 3 separate steps)
So it seems (based on my limited view of your requirements)  this is what you want I believe
name: Run Gradle Build

on:
  push:
    branches: [ "main", "development" ]
  pull_request:
    branches: [ "main", "development" ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Set up JDK 11
        uses: actions/setup-java@v3
        with:
          java-version: '11'
          distribution: 'temurin'

      - name: Set up Gradle Build Action
        uses: gradle/gradle-build-action@v2
        with:
          dependency-graph: generate-and-submit
          cache-disabled: true

      - name: Build and test with Gradle
        run: ./gradlew build

      - name: javadoc
        run: ./gradlew WHATEVER
        env:
          GITHUB_DEPENDENCY_GRAPH_ENABLED: false

      - name: javadoc
        run: ./gradlew WHATEVER
        env:
          GITHUB_DEPENDENCY_GRAPH_ENABLED: false

  submit-and-review:
      runs-on: ubuntu-latest
      if: github.event_name == 'pull_request && github.actor != 'dependabot[bot]'
      needs: build

      steps:

      - name: 'Dependency Review'
        if: github.event_name == 'pull_request'
        uses: actions/dependency-review-action@v3

Hi everyone,
I have some questions regarding the final outcome of the workflow file that you discussed and reached a consensus on. According to the documentation on integrating dependency-submission and dependency-review-action with pull requests from public forked repositories, it seems that dependency-submission cannot submit the dependency graph in a workflow triggered by a pull request. This means that the dependency-review-action cannot access the changes made to the dependencies in the pull request.
I'm currently working on this issue mentioned in this PR, and I wanted to ask if the reason the workflow file discussed in this issue is able to run successfully is because it is running in a private repository?
Thank you for your help and clarification.


UI Frontend scaffolding

neuroscan

Top bar
Menu in the top-left side corner
left sidebar
right sidebar
core part of the UI where the flexlayout components will be spawned.

promoterDB

top bar
Menu in the top-left side corner
left sidebar
? right sidebar
? core part of the UI where the flexlayout components will be spawned.

canvas + layout manager (afonso)
all the rest (vidhya)

duplicate of https://app.zenhub.com/workspaces/yale-neuroscan--db-promoter-60749ce5c09a74000fe7ef74/issues/metacell/geppetto-neuroscan/27


Add LensRendererExtension.isEnabledForCluster

Fixes #1489

MacOS failure seems to be an issue with Azure. Going to hit merge.


containerd support

Multus service currently can be configured with docker and crio, is it possible to support containerd runtime ?

Any updates on this request?

Thank you for the report, @obiTrinobiIntel and @davecremins .
As far as I know of, multus-service should work with containerd because containerd supports cri. You may need to change deployment yaml to adopt the cri socket path, but it does not require any go code change.
Could you please try that and let me know the feedback for that? Thanks!

Thanks Tomo, we will modify the yaml spec and deploy. I will post updates
here once we run the test.
On Tue, Aug 2, 2022 at 7:49 PM Tomofumi Hayashi @.***>
wrote:

Thank you for the report, @obiTrinobiIntel
https://github.com/obiTrinobiIntel and @davecremins
https://github.com/davecremins .
As far as I know of, multus-service should work with containerd because
containerd supports cri. You may need to change deployment yaml to adopt
the cri socket path, but it does not require any go code change.
Could you please try that and let me know the feedback for that? Thanks!
—
Reply to this email directly, view it on GitHub
https://github.com/k8snetworkplumbingwg/multus-service/issues/9#issuecomment-1203091053,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABJTM3X3TOIZR3SOJK3UBYTVXFUTFANCNFSM54SYSXIQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

@davecremins It is 3month+ since you replied. Did you check that? If you don't mind it, I will close this issue.

@davecremins followup. Does it works? If you don't test it yet, I will test it and close this if it works.


[Question] How easy would it be to have this work with Sublime Text

This is an awesome idea, having autocomplete for crafttweaker. Would it be possible for this to also be made compatible with sublime text?

zenscript-mode is written entirely in Emacs Lisp. Sublime Text, to my knowledge, does not support extension in Emacs Lisp, so unfortunately that would not be possible.


os-tor: Add the FreeBSD nyx port to the OPNSense ports collection or provide a better tor management tool

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[X] I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
[X] I have searched the existing issues, open and closed, and I'm convinced that mine is new.
[X] When the request is meant for an existing plugin, I've added its name to the title.

Is your feature request related to a problem? Please describe.
You added a tor plugin with out any useful information about the gateway's state. There is a terminal UI tool that would provide at least basic monitoring/troubleshooting abilities (nyx) and there are several GUI options you might consider
Describe the solution you'd like
Minimum: Just add nyx to the subset of FreeBSD ports provided in the OPNSense collection.
Better: Add one of the tor Web frontends.
Describe alternatives you've considered
Removing tor proxy functions from the OPNSense gateway and run a separat system just for tor.

FWIW, nyx is easy to install:
python3 -m ensurepip --upgrade
pip3 install nyx

Then you just need to get the ControlPort password out of your OPNsense config file and store it in .nyx/config.

As soon as I'm not using "vendor included package sources" and have to use "third-party sources" (i. e. pip) I have to write an essay on the topic, prepare a ISO-level presentation and still fear that someone wants to discuss it for days.


Allow the 'nonce' (and/or arbitrary) attributes in the Requirements backend

Affected Version
^4
Description
The requirements backend doesn't allow certain attributes that are documented in https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script - a good example is "nonce" but others are  listed at that URL
While there might be reasons for restricting attributes in the Requirements_Backend it would be helpful to allow a developer to specify arbitrary per-request attributes via an injected requirements backend, such as "nonce".
In the context of a Content Security Policy, allowing the "nonce" attribute on an inline script/style would alleviate the need to create an SRI hash for each inline element and store that hash in a CSP.
A good example is @ https://content-security-policy.com/examples/allow-inline-style/ (Allow Inline Styles using a Nonce)
Currently, the only sensible way to do this is by replacing the entire includeInHTML() method in an injected Requirements backend.
References:

Attribute restrictions in includeInHTML @ https://github.com/silverstripe/silverstripe-framework/blob/4/src/View/Requirements_Backend.php#L797

Steps to Reproduce
For Requirements::javascript/css

Add a nonce attribute to a script/style/link via an injected Requirements backend (e.g by overriding the getCSS() method)
Expect to see nonce="$nonce" for the element in the returned HTML document
There is no nonce attribute

Help us with step-by-step instructions.

Create a custom Requirements backend that extends SilverStripe\View\Requirements_Backend and add the following methods:

namespace MyNamespace;

use SilverStripe\View\Requirements_Backend;

class NonceRequirements_Backend extends Requirements_Backend {

    /**
     * @inheritdoc
     */
    public function getJavascript()
    {
        $items = parent::getJavascript();
        foreach($items as $file => $attributes) {
            $items[$file]['nonce'] = 'the_request_nonce';
        }
        return $items;
    }

    /**
     * @inheritdoc
     */
    public function getCSS()
    {
        $items = parent::getCSS();
        foreach($items as $file => $attributes) {
            $items[$file]['nonce'] = 'the_request_nonce';
        }
        return $items;
    }

}

Add the requirements backend configuration via Injector:

SilverStripe\Core\Injector\Injector:
  SilverStripe\View\Requirements_Backend:
    class: MyNamespace\NonceRequirements_Backend

nonce="the_request_nonce" should be added to the attributes for the elements.

Inline scripts and styles would benefit from nonce inclusion via getCustomCSS /  getCustomScripts but these requirements do not support attributes beyond "type".

Just adding my two cents here since i've been working quite a lot with the requirements backend on my module https://github.com/lekoala/silverstripe-defer-backend
it is indeed annoying that customScripts have not the same structure as regular stricts. For instance, in my module, i had to resort to conventions in the ID attribute to pass custom values for the cookie-consent attribute. Not ideal at all. I feel that the customScript property would benefit from being a flat array that looks like ["id"=> null, "content"=> "console.log('my script');"], ["id" => "unique script", "content" => "console.log('my unique script')", "some-attribute" => "some-value"]. It wouldn't affect the external api which would be extended to accept an array after $uniquenessID. The current api is just too restrictive.
i recently added js modules support to my module. And I discovered that by default you cannot set the type of custom scripts as well. Again, this is not ideal and could be easily dealt with an array structure as explained above where you could just set the type attribute. Something like Requirements::customScript('mymodule.js',null,['type' => 'module']);

I like what @lekoala suggests. Issues with type to pass W3C validator without warning for JS & CSS or for json+ld schema data etc. could be addressed with this as well?
https://github.com/silverstripe/silverstripe-framework/issues/8710


Add once more dropdown for login page (Hm/ms, Teachers, Students, Admin and Psychiatrist) to login

just add 1 more field in the login page which has options (Hm/ms, Teachers, Students, Admin and Psychiatrist) and send to backend for login

@Coderlearner41 kindly take over!

thanks @Coderlearner41. Respective pull request has been merged to the main


Royal Render: Maya support

Changelog Description
Basic working implementation of Royal Render support in Maya.
It expects New publisher implemented in Maya.
Known issues
renders folder is duplicated path something like work\modeling\renders\maya\maya\test_project

In that case this is only waiting for merge of New publisher in Maya and the general RR support PR.


Support for other models like gpt-4-turbo-preview

Feature details
Please allow the option to enter free text in the GPT Model settings so that we can use other GPT models.

Thank you for the feature request. Something like that may come, but probably not in the form of a free form text box. While you may know exactly which models to insert, most users won’t and that will make configuration hard for them.
There are so many different knobs and dials that an early explicit goal of this workflow remains to avoid configuration fatigue. Right this moment the operative word is focus and carefully choosing what makes the biggest impact for the largest number of users.


[core] Fix some mouse issues on SDL

Fixes

Fixes the mouse wheel getting stucked scrolling up or down by adding the missing reset (R534-R536).

Fixes the mouse sensitivity being really high on 3D by adding the missing previous mouse position registry (R538-R539).

Fixes the mouse button presses not working properly by adding the missing previous mouse button registry (R561-R562) and by adding handling for SDL_MOUSEBUTTONUP (R619-R622).
.
VERY IMPORTANT NOTE: @raysan5
The SDL2 mouse button order is LEFT, MIDDLE, RIGHT, ... (doc), but we currently use LEFT, RIGHT, MIDDLE, ... (L674-L676), so, when the migration to SDL2 is complete, that MouseButton enum on raylib.h needs to be adjusted. Until then, the middle and right mouse binds will be inverted.

Reference
Items 1, 2, 6 of https://github.com/raysan5/raylib/issues/3313#issuecomment-1763623854.
Environment
Tested this changes successfully on Linux (Ubuntu 22.04 64-bit, gcc 11.2.0) with SDL2 (2.28.4).
Edits
1: added line marks.
2: added another fix, environment, formatting.
3: added another fix.

@ubkp thank you very much for the review! Good catch the mouse button order! Yes, it should be reviewed, not sure if it follows glfw order...

@raysan5 Checked it here and GLFW does indeed use LEFT, RIGHT, MIDDLE, ... (doc). I'd suggest not flipping them yet on MouseButton enum to not cause issues for anyone using current master branch. I can keep track here to remind this when the times comes, if you want.

@ubkp I see, probably the remap should be done on input polling then. Feel free to add a TODO in the code to remember it!


Add NOOP message and bind it to CTRL + Z + LMB

Big thanks to @0HyperCube
This is a fix that is presented in the issue as 1) i.e. prevent it by sending a NOOP instead of UNDO when CTRL + Z + LMB is pressed.
Closes #1674

!build


Multiple vs Single Endpoint Description Is Unclear

Section Number Identify the most specific section number the issue occurs (e.g. 4.1.2)
1:<IP_ADDRESS>.1
Issue Describe your issue. Don't write a book, but do include enough to indicate what you see as a problem.
The following text implies that an organization can have a single endpoint for FHIR or multiple endpoints for XD* types of transactions. I think what it is trying to say is that some communication channels can be expressed by a single endpoint (FHIR) while others might require multiple endpoints (XCA, XCPD, etc.)
"Organizations may have a single endpoint for a technical mechanism like FHIR (e.g., a single Service Base URL), or multiple endpoints (e.g., IHE XCPD, IHE XCA Query Responding Gateway, IHE XCA Retrieve Responding Gateway, etc.)."
Proposed Change Propose a resolution to your issue (e.g., suggested new wording or description of a way to address the issue). The committee might simply accept your suggested text. Even if they don't, it gives a good sense of what you are looking for. Leaving this blank means you can't imagine how to resolve the issue, which makes it easier for the committee to admit they can't imagine how to resolve it either and leave it unresolved.
"Organizations may have one or more endpoints depending on the communication channels they support. For example, a server that only supports FHIR communication might have only a single endpoint, while a server that supports, for example, the IHE XCPD or XCA integration profiles would need to have multiple endpoints to support each transaction. Servers can support many communication channels, each of which might have one or more endpoints.
"Organizations might support one or many communication channels, each of which might have one or more distinct endpoints. For example, a FHIR communication channel might require only a single endpoint, while an IHE XCA communication channel might require separate endpoints for each transaction"
Priority:

Low: Typo or other minor classification that an editor can manage. Requires no group discussion.

Going with the second rec.

Keep the e.g.


Issues-104 dynamicRoutes

@gaoluona hey thanks for the PR -- do you know when/why the routes are accessible via nextServer.router sometimes instead of directly on nextServer? I think it would be valuable to include that as a comment in the code for posterity

http://www.yvk2x1.cn泪 ，这个是咱班棉花告诉我的，郧我试了试，挺好玩的，你也来吧，等你

Do you have useFilesystemPublicRoutes set to true or false?

yes，I set useFilesystemPublicRoutes to false

Hello you all,
I am facing a similar problem. I have an app with no dynamic routes at all, so neither the old or new code works for me (cannot read properties of undefined error). This is my debug on that line:

In order to not duplicate pull requests, I propose to @gaoluona to set nextDynamicRoutes as a default {} if neither nextServer.dynamicRoutes nor nextServer.router.dynamicRoutes are set. The code will be:
const nextDynamicRoutes = nextServer.dynamicRoutes || nextServer.router.dynamicRoutes || {}
What do you guys think?
Regards


Can't ping mtproto proxies

Hello! Can't ping mtproto proxies. I have sended log file to @tdlib_bot
SOCKS5 works fine. Tried different internet connections

Country blocking issue, closing.