Fix/3.0.0 fixes

This is a followup to #79 and #82.
My original goal with #79 was to enable a CANNON body that was type: dynamic and mass: 0, effectively making it "kinematic" (as defined in other game engines like Unity). That is to say, it imparts force on other dynamic bodies, collides with both dynamic and static bodies, and can be moved around by directly setting position. (Note: CANNON.js has a defined kinematic body type, but it only allows movement via velocity, and doesn't collide with other static or kinematic bodies. So I will refer to a dynamic body with mass: 0 as "kinematic" in quotes).
My other goal with #79 was to allow the mass value to change, effectively allowing the body to switch from dynamic and "kinematic" on the fly.
To support this post 3.0.0, a few changes are needed.

type needs to be explicitly set when creating the CANNON body. Otherwise it will infer type from the mass, and as such will always set type to dynamic if mass != 0 and static if mass == 0.
Don't update the mass in update when explicitly switching between dynamic and static
use the body's mass when determining whether to use syncToPhysics or syncFromPhysics in beforeStep and step instead of the component's data.type.

Lastly, there are a few bug fixes:

Since the quaternion component is gone now, rotation and position are handled differently in 3.0.0. However, quaternion can't be updated directly on the object3d as that won't update the rotation component on the Aframe side. As such, go back to using setAttribute, but do some math for converting the quaternion to euler angles in degrees. (Unfortunate because this effectively gets undone under the hood to ultimately set the object3d's quaternion, but that's Aframe.)
The fix for #82

The problem with the Cannon kinematic bodies is less so not being able to move them around, but more so that they don't collide with other static and kinematic bodies.
Let me rephrase what I said earlier, because I think by using the term "kinematic" I confused things a bit.
What I really want to be able to do is switch between a dynamic and static body, on the fly. The problem is you can't do that in Cannon . In other engines, like Ammo, you can, with a few small tricks. What I did realize, however, was that the only thing Cannon 's body actually uses to determine if a body should behave dynamically or statically is if the mass is zero or not. As such, you can effectively switch between dynamic and static by changing the mass.
The part about being a "kinematic" body is that what Cannon calls static is actually what is considered kinematic in other physics engines I've seen (e.g. Unity's physics). So sorry to confuse things there.
So, that said, is this exposing an edge case in Cannon? Perhaps. But its also the way schteppe has said to do it: https://github.com/schteppe/cannon.js/issues/317#issuecomment-262710586 so it seems reasonable to be able to support it, since we're not likely to see an improved API in Cannon anytime soon.
As far as using a different engine, I originally wanted to fork this project and try to recreate it with Ammo, but decided it would be a lot less work to start with what was here already. That said, I fully support (and would happily contribute to) any such efforts to switch to a different physics engine.


[Documenting] Document all classes and methods in the BlockStoreLoop …

…#300

Ah I thought this was ready to commit, @fassadlr can you fix the latest comments in a new PR as part of your next task?

@dangershony will do!


New version: DiscretePersistentHomologyTransform v1.0.2

Registering package: DiscretePersistentHomologyTransform
Repository: https://github.com/yossibokor/DiscretePersistentHomologyTransform.jl
Created by: @yossibokor
Version: v1.0.2
Commit: 3a5e812f86a804714fb2de53dda13b12775a08dc
Reviewed by: @yossibokor
Reference: https://github.com/yossibokor/DiscretePersistentHomologyTransform.jl/commit/3a5e812f86a804714fb2de53dda13b12775a08dc#commitcomment-42181360

Closing due to inactivity, please comment if this is still relevant.


Installing bzip2 since it is required for extracting templates

If you do not install bzip2, then installing templates that are bzip2 compressed will result in Cloudstack not being able to extract the contents and ending up copying the template in compressed form.  This will result in VMs not being able to start.

LGTM
tag:easypr

We need more more code review on this one...

That change makes sense to me.
I do now if I have installed the “bzip2” program without noticing while installing some other tool, but in my MSs Servers it was already installed.
Anyways I can give LGTM here.

I think this one is ready to merge given the scope of the change.  Thanks...


Web surfer test is pointing to autogen blog post

The web surfer test is using a public page of autogen blog for testing. A better way to set up the testing environment is necessary.

Generally, we need more web surfer tests. #4467 Closing this one as it should be subsumed by that issue.


adding metrics

Description
Exporting results of contacts and metrics.
Todos
Notable points that this PR has either accomplished or will accomplish.

[x] Export contact information including specific frames.
[x] Export metrics.
[ ] Make it as fast as possible.

Status

[ ] Ready to go

The exporting of the results is already working, but the speed is not optimum. It would need some polishing.

Codecov Report

Merging #61 (8902101) into main (0a84c4f) will decrease coverage by 1.08%.
The diff coverage is 6.45%.


page_cache: find_victim: don't spin while there's no chance for a slot

It is wasteful to cycle through the page cache slots trying to find a victim slot if all the slots are currently un-evictable because a read / write guard is alive.
We suspect this wasteful cycling to be the root cause for an "indigestion" we observed in staging (#5291).
The hypothesis is that we .await after we get ahold of a read / write guard, and that tokio actually deschedules us in favor of another future.
If that other future then needs a page slot, it can't get ours because we're holding the guard.
Repeat this, and eventually, the other future(s) will find themselves doing find_victim until they hit exceeded evict iter limit.
The find_victim is wasteful and CPU-starves the futures that are already holding the read/write guard. A yield inside find_victim could mitigate the starvation, but wouldn't fix the wasting of CPU cycles.
So instead, this PR queues waiters behind a tokio semaphore that counts evictable slots.
The downside is that this stops the clock page replacement if we have 0 evictable slots.
Implementation
We need to acquire the semaphore permit before locking the slot.
Otherwise, we could deadlock / discover that all permits are gone and would have to relinquish the slot, having moved forward the Clock LRU without making progress.
The downside is that, we never get full throughput for read-heavy workloads, because, until the reader coalesces onto an existing permit, it'll hold its own permit.
Addendum To Root-Cause Analysis In #5291
Since merging that PR, @arpad-m pointed out that we couldn't have reached the slot.write().await with his patches because the VirtualFile slots can't have all been write-locked, because we only hold them locked while the IO is ongoing, and the IO is still done with synchronous system calls in that patch set, so, we can have had at most $number_of_executor_threads locked at any given time.
I count 3 tokio runtimes that do Timeline::get, each with 8 executor threads in our deployment => $number_of_executor_threads = 3*8 = 24 .
But the virtual file cache has 100 slots.
We both agree that nothing changed about the core hypothesis, i.e., additional await points inside VirtualFile caused higher concurrency resulting in exhaustion of page cache slots.
But we'll need to reproduce the issue and investigate further to truly understand the root cause, or find out that & why we were indeed using 100 VirtualFile slots.
TODO: could it be compaction that needs to hold guards of many VirtualFile's in its iterators?

@arpad-m  I think your concerns have been addressed with my pushes since your last review ?

IMO, giving that this PR is changing such tricky parts of the code, we should not merge it before the release (I feel differently about the metrics PR).

As decided on Slack, latest pushes

switch iter_limit to the previous value, and
instead of unreachable! use anyhow::bail, and
add metrics that track bails and other errors


Wait for pairing confirmation before confirming that the devices are paired

Currently in DevicesRedux, the state 'added' is reached as soon as the device is added to the wallet. But we need a step after this where the device is confirmed as being paired, this is later confirmed by a message from the external device saying it received the pair.

I believe calling pair will either fail or succeed... as in, it's sync. We should expose the ability to not fallback to offline message sending and do that here.

ahhh gotcha


Request to evaluate O1 2024-12-17

Request in title :)
Love your work!

Thank you for the interest; the AISI has evaluated o1 on cybench - see https://www.nist.gov/system/files/documents/2024/12/18/US_UK_AI Safety Institute_ December_Publication-OpenAIo1.pdf#page8 . It has quite impressive results


Cannot override setting in readonly mode

System information:

Windows 10
DBeaver version <IP_ADDRESS>002151353

Connection specification:

ClickHouse release <IP_ADDRESS>

Describe your question:
When i'm trying run select query, i get error
"SQL Error [164]: ClickHouse exception, code: 164, host: ch**.local, port: ****; Code: 164, e.displayText() = DB::Exception: Cannot override setting (max_result_rows) in readonly mode, e.what() = DB::Exception"
I'm not administrator of this CH database, therefore i cant change readonly = 1 to readonly= 2 (which allow set and use command)
Could you help me, how i can resolve this issue?

up??

Решение: если вы столкнулись с такой ситуацией, измените максимальный размер выборки до -1 в настройках
Solution: change the maximum sample size to -1 in the settings if you are faced with this situation


[v4] Fix CastPropertiesDataPipe logic

This PR attempts to fix https://github.com/spatie/laravel-data/issues/660

Thanks for the starting point, that was really handy! Eventually I've made my own implementation should be released later today!


tensorflow.python.framework.errors_impl.CancelledError: Session has been closed.

After fresh installation of ADS (this commit: https://github.com/neuropoly/axondeepseg/commit/fdb2c8c60d1986fed0c703e862c0f3c22d0ca854) on OSX Mojave, when running axondeepseg_test I get the following TF exception:
* * * Integrity test passed. AxonDeepSeg is correctly installed. * * *
Exception ignored in: <bound method BaseSession._Callable.__del__ of <tensorflow.python.client.session.BaseSession._Callable object at 0x13b9fde48>>
Traceback (most recent call last):
  File "/Users/julien/miniconda3/envs/ads_venv/lib/python3.6/site-packages/tensorflow/python/client/session.py", line 1455, in __del__
    self._session._session, self._handle, status)
  File "/Users/julien/miniconda3/envs/ads_venv/lib/python3.6/site-packages/tensorflow/python/framework/errors_impl.py", line 528, in __exit__
    c_api.TF_GetCode(self.status.status))
tensorflow.python.framework.errors_impl.CancelledError: Session has been closed.

Closed, stale.


Match booleanEqual's parameters to that of turf_equality

the function uses the Equality in its core, but does not pass the adequate arguments into the class. This results in limited tests for equality, in cases where 'shifting positions' or 'reverse direction' has to be taken into account for the two objects being compared.
What do you think @lukas-h

I agree, that we should adjust the interface of booleanEquals to the turf_equality interface.
But an overarching topic is:
I'm generally unsure what would be the right strategy to combine turf_equality (geojson-equality port), the booleanEquals, and on the other #45

https://github.com/dartclub/turf_dart/pull/91/commits/5c863e05f5882b040bd4001a83cd096c7a3bacee


19 - Hybrid method, using InetMgr IIS module and based on 10 & 16 MS fixes, works from Windows 7 up to 10rs1 14372.

Not work after build  (((

Very informative post, thanks.

And it is fixed in 14376, forget about it.


storage access not working from within docker - from google.cloud import storage - ImportError: No module named 'google'

I'm trying to access to access a bucket from within a docker image. I already searched the issues and stackoverflow and could not find any solution.
My dockerfile contains the line RUN pip install --upgrade google-cloud-storage
I'm executing following script within docker
#!/bin/sh
export GOOGLE_APPLICATION_CREDENTIALS=google-api-keys.json
scrapy crawl phillips -o phillips.json > scrapy_log.txt   #my app producing the files to be uploaded
python gcpupload.py

The gcpupload does a file upload to the bucket:
from google.cloud import storage

def main():
	client = storage.Client()
	print('*****client initialized')
	bucket = client.get_bucket('artcollect')
	print('*****bucket set to artcollect')
	blob1 = bucket.blob('phillips.json')
	print('*****blob set to phillips.json')
	blob1.upload_from_filename(filename='phillips.json')
	print('*****upload phillips.json')
	blob2 = bucket.blob('scrapy_output.txt')
	blob2.upload_from_filename(filename='scrapy_output.txt')
	print('*****upload scrapy_output.txt')

if __name__ == "__main__":
	main()

Everything works ok so far in my local environment without docker and the files are uploaded as expected. But when running it from within docker I get the error message in the subject.
Can you please help me solving this issue.
Thanks
Zin

I have a very similar problem that hasn't been fixed with the above measures. The one difference is that I'm having the docker be built by gitlab CI.
This is my dockerfile:
FROM python:3.5.4

WORKDIR /PoC
ADD requirements.txt /PoC/
ADD *.py /PoC/
ADD *.json /PoC/

RUN python3 -m pip install --trusted-host pypi.python.org -r /PoC/requirements.txt

RUN apt-get update && apt-get install -y sudo vim
RUN sudo echo deb http://ftp.uk.debian.org/debian jessie-backports main >>/etc/apt/sources.list
RUN apt-get update && apt-get install -y ffmpeg
RUN mkdir /PoC/resources

CMD python3 server.py --port 4000

ENV GOOGLE_APPLICATION_CREDENTIALS /PoC/api-key.json
ENV PYCURL_SSL_LIBRARY=openssl

And this is my .gitlab-ci.yml:
stages:
  - build-docker
  - test-docker

build:
  stage: build-docker
  image: docker:latest
  tags:
    - docker
  script:
    - echo "Build base image"
    - docker login ${CI_REGISTRY} -u gitlab-ci-token -p $CI_JOB_TOKEN
    - docker build -t ${CI_REGISTRY_IMAGE}/${CI_COMMIT_REF_NAME} .
    - docker push ${CI_REGISTRY_IMAGE}/${CI_COMMIT_REF_NAME}
    # - docker run --rm -i ${CI_REGISTRY_IMAGE}/${CI_COMMIT_REF_NAME} python3 test_analyze_sb.py
    - docker rmi ${CI_REGISTRY_IMAGE}/${CI_COMMIT_REF_NAME}
  except:
    - tags

test:
  stage: test-docker
  image: ${CI_REGISTRY_IMAGE}/${CI_COMMIT_REF_NAME}
  script:
    - python3 test_analyze_sb.py

See the commented line in the 'build' job? If I run that line, the job passes. The 'test' job, however, doesn't and fails with:
[...]/combined_into_gl_kws.py", line 12, in <module>
    from google.cloud import storage
ImportError: No module named 'google'

Any help is very much appreciated!!!


surface plot - feature request

Hi!
I wonder how easy or difficult would be to implement some basic 3D surface plotting feature in ScottPlot? Something like Excel surface chart which input's is a 2D matrix, but with mouse rotation option.

I wonder how easy or difficult would be to implement 3D plotting

difficult 😜

... but possible! I'd probably start by experimenting outside of ScottPlot. ScottPlot uses only GDI+ to render images. It looks like somebody wrote a 3D engine for GDI https://github.com/oeshiro/gdi-3d-renderer which might be a useful starting point, but I think this task is bigger than I'd like to undertake!
Wouldn't a heatmap be better for representing 2D data anyway? Looking at the excel plot I can't tell where the bounds of the gray (peak) area are. I have an idea, but a 2D headmap / contour plot seems much more accurate.
Matplotlib does this very well: https://jakevdp.github.io/PythonDataScienceHandbook/04.04-density-and-contour-plots.html

Yes, in certain cases a heatmap would be just fine to use. Actually what was in my mind, to have a kind of animation. I have for example a series of surface map data blocks, and I would like to visualize in time how the surface evolves. A heatmap could also work in such way, but I thought a 3D object would look cool. But of course, it is only useful, if you have the option to zoom in/out, and rotate the 3D object. In the past I used as I remember, an OpenGL control from LabWindows CVI (NI), maybe I should search for an easy to use OpenGL animation API for C#....
Anyway, thanks for the feedback! :)

An OpenGL-based 3D rendering engine for plotting would be an excellent tool and quite an undertaking... but I think this is outside the scope of the core design philosophy of ScottPlot which values a dependency-free library with strives for minimal code size and complexity.
I'll close this issue because I think 3D rendering is outside the scope of ScottPlot, but such a system would be a cool thing to explore as its own project!
Note that I have been working on an OpenGL-based (hardware-accelerated, not 3D) plotting library https://github.com/swharden/QuickPlot but I'm about to abandon these efforts because it's really hard to support advanced rendering libraries on all systems. GDI+ is slow, but it works everywhere https://github.com/swharden/QuickPlot/issues/1 so I'm inclined to keep using it...


[New Port Request] LAPACKE

Library name:
LAPACKE
Library description:
LAPACKE
Source repository URL:
?
Project homepage (if different from the source repository):
https://www.netlib.org/lapack/#_lapack_for_windows
Anything else that is useful to know when adding (such as optional features the library may have that should be included):
The existing LAPACK library doesn't work with Eigen when using LAPACKE library, because current build does not contain LAPACKE, more can be seen on here

We already have clapack lapack and lapack-reference, is it one of them?

@JackBoosY It could be a feature of lapack-reference but i am uncertain if it can be its own port

@JackBoosY No help, actually when installing LAPACK, lapack-reference will be automatically installed as dependence, and CLAPACK differs from LAPACKE as well. you can easily try to compile an Eigen program with EIGEN_USE_LAPACKE_STRICT, ends with failure.

@Neumann-A  lapack-reference's portfile suggests that LAPACKE may should be another port

Obviously, it is consistent with the source code of lapack-reference.

@Wongboo check the git blame ;) I cannot remember if it can be build without lapack-reference or to be more precise without building lapack at all.

@Neumann-A But we should carefully use USE_OPTIMIZED_LAPACK, if user already build lapack of the same version or they choose to use clapcke, then we use it, otherwise don't! It works just like USE_OPTIMIZED_BLAS but a little bit more confusing and complicated.

If you wish to add this port in the future, you can reopen this issue, but we're closing it for now.


Upgrade nested_ragged_tensors to >= 0.0.8

https://github.com/mmcdermott/MEDS_transforms/blob/ae5b155bd02c988037eedd7216d34aec3e358e33/pyproject.toml#L20C31-L20C61

Oh I already made this issue last week sorry #212


syntax error

Hi,
Everything was loading fine until I try to make an artisan command (php artisan make:command) to run my sync code.
My code is working but as soon as I call one of your class, I get an error. (Same code  that run inside my app is ok)
When any API class in an artisan command I get this error
"
syntax error, unexpected 'ApiClient' (T_STRING), expecting function (T_FUNCTION) or const (T_CONST)
at vendor/timothydc/laravel-lightspeed-retail-api/src/LightspeedRetailApi.php:10
6| use TimothyDC\LightspeedRetailApi\Services\ApiClient;
7|
8| class LightspeedRetailApi
9| {

10|     private ApiClient $apiClient;
11|
12|     public function __construct(ApiClient $apiClient)
13|     {
14|         $this->apiClient = $apiClient;

  +1 vendor frames

2   [internal]:0
Composer\Autoload\ClassLoader::loadClass("TimothyDC\LightspeedRetailApi\LightspeedRetailApi")
  +10 vendor frames

13  app/StockSync.php:155
Illuminate\Support\Facades\Facade::__callStatic("api", [])
"
At first I was thinking it is the .env variables that was not loading but I did a dump(env(PRESTASHOP_WS_KEY)) and the value is ok.
Any ideas ?

Could you post your complete LightspeedRetailApi class please?

Could you post your complete LightspeedRetailApi class please?

The LightspeedRetailAPI is your class.
Here the line of code that consume it :
$items = LightspeedRetailApi::api()->Item()->get(null, ['load_relations' => 'all', 'offset' => 0]);
This line work when calling from controller but not when calling from php artisan command line (see post no1 for return error)

What PHP version are you running on the CLI?

BINGO ! That was it.
In my console for an unknown reason I run on 7.3 and 7.4 in Laravel. I change to 7.4 in console and now everything is fine.
Many thanks!


How to find link to crawl data skin/champion

Hi ! I use your' source code to code an application by C# to check skin and champ
And i want check more info, i used Fiddler to find link  crawl data
Example you :
/lol-champions/v1/inventories/${summoner.id}/champions  /lol-collections/v1/inventories/${summoner.id}/champion-mastery
So you can help me how to find it to crawl another info
Thank you every much ^_^

Do you mean the API?
https://developer.riotgames.com/api-methods/

Thank for support :D
But i can you it to crawl in garena
You can see code by lol-skin-view crawl http://<IP_ADDRESS>:id+pass/link
It different with api riot ^^

Ah damn! Sorry to hear that!
Could their application be decompiled to pull from? (Android App)


render a topdown view in another window

Hi, I am wondering how I can open a popup window of topdown view in alfworld?  I know a newer version of ai2thor(like 3.0) supported this feature. Since you keep version 2.1 for such a long time, do you have any plans to upgrade ai2thor? Thx.

@jinzhao-SU, upgrading ai2thor is quite difficult. But maybe this thread of help.

I managed to generate some top-view videos of the agent navigating the environment. I mostly reused code from https://github.com/allenai/ai2thor/issues/124. I don't think this is exactly what you are looking for, but that should get you closer to it.
https://github.com/alfworld/alfworld/blob/add_viewer/scripts/play_rollout.py


Gogs chart

This adds a chart for Gogs (https://github.com/gogits/gogs).  It is currently functional for a development install (e.g., minikube).

@k8s-bot ok to test

Is this failing due to this helm 2.1 bug?  Can/should the e2e test be updated for helm 2.2?

Hi @tvon, this looks pretty good. In addition to my comments, this needs NOTES.txt. Here's a good example from the Drupal chart.

Note that the failure is the same as it was before, which appears to be a helm 2.1 bug.  Let me know how to proceed on the volume and this should be good to go.

@seanknox Does this still need changes?

Would really like to see this chart published soon!
Perhaps a future RFE:  For development, deploy using the embedded sqlite3 database engine. It would eliminated the need for postgres and would slim down the footprint.

LGTM! Thanks @tvon.


Google Analytics not reporting

Events and pageviews not being tracked.
Suspect this is due to using the new enhanced property in GA.
To try: removing ga-lite and replacing with native Google Analytics, then review the browser caching issue.

Usage of new tags didn't work. (2893edc16e3dd49a3d2c18c2af959227d9a1b7f0)
Suggest next step is to remove ga-lite.

ga-lite removed - CSP issues.
2bb9e4794eb531152315a79d4c7f5245e9efc801


Merge ign-rendering6 ➡  main

➡  Forward port
Port ign-rendering6  ➡  main
Branch comparision: https://github.com/ignitionrobotics/ign-rendering/compare/main...ign-rendering6

Required by https://github.com/gazebosim/gz-sensors/pull/247

Note to maintainers: Remember to Merge with commit (not squash-merge or rebase)

is this test INTEGRATION_wide_angle_camera flaky on macOS ?

Just barely?
https://build.osrfoundation.org/job/ignition_rendering-ci-main-homebrew-amd64/107/testReport/(root)/WideAngleCamera_WideAngleCameraTest/WideAngleCamera_ogre/history/
I retriggered CI, let's see

hmm there are quite a bit of changes to the test framework in https://github.com/gazebosim/gz-rendering/pull/685 that will create conflicts with the forward port here. Maybe we should wait till the ogre 2.3 PR gets in first then resolve conflicts and get this forward port in. We'll need to check and verify that bounding box still works.

This is first on my list in the morning to look at.

Still failing from the forward port:
GpuRaysTest.Visibility - From #625, didn't port forward cleanly because compositor workspace changed, I have pinged @darksylinc for a quick fix here
The following three are all ogreroot destructor related issues, I can reproduce them locally, but not sure what has changed to make them happen:
INTEGRATION_camera_ogre_gl3plus.test_ran
INTEGRATION_thermal_camera_ogre_gl3plus.test_ran
INTEGRATION_wide_angle_camera_ogre_gl3plus.test_ran

The following three are all ogreroot destructor related issues, I can reproduce them locally, but not sure what has changed to make them happen

I'm not sure why, but backing out a section of logic from #617 removes this segfault with no other adverse affects that I can see locally for both clang and gcc.  This patch fixes it: https://github.com/gazebosim/gz-rendering/pull/679/commits/44f1a1a8bce9d0aa56decae64b79997efb67be82
@iche033 Do you see any reason to not do this?

The following three are all ogreroot destructor related issues, I can reproduce them locally, but not sure what has changed to make them happen:

Can you post the callstack? (when it crashes).
I suspect that bug is related to #617 (see #615 for explanation).
That PR fixed leaks. However proper shutdown can be tricky to get because the following is an example of a bug:
{
MeshPtr myMesh = ...;
MaterialPtr myMaterial = ...;
   {
       Ogre::Root::shutdown();
   }

// CRASH! myMesh & myMaterial destructors will be called however Ogre has already been shutdown
}

Basically smart ptrs need to be reset before Ogre gets shutdown (either by moving Ogre shutdown later, or force-resetting the smart ptrs by hand earlier, or destroying the classes that contain theses smart ptrs before shutdown).
A leaked smart ptr on the Gazebo side can easily explain this.
I suspect this is what's happening.

Can you post the callstack? (when it crashes).

All three fail in the same location, here is the callstack for INTEGRATION_camera: https://gist.github.com/mjcarroll/321a7122ad6d4f3a7087db56b20d0fe8

OH the crash is in Ogre 1.9, hmmm.

I'm looking into this. Your fix introduces leaks; which is why it stops crashing (it will no longer crash at a dangling pointer, because the pointer is still alive... because it's leaking).
gz-rendering is leaking other handles. I'll post the patch here

@mjcarroll the following patch undoes your change and fixes an gazebo/ogre bug (who's really at fault is debatable):
diff --git a/ogre/src/OgreThermalCamera.cc b/ogre/src/OgreThermalCamera.cc
index 8c090ffc..5975c805 100644
--- a/ogre/src/OgreThermalCamera.cc
+++ b/ogre/src/OgreThermalCamera.cc
@@ -297,6 +297,16 @@ void OgreThermalCamera::Destroy()
   if (!this->ogreCamera || !this->scene->IsInitialized())
     return;

+  if (this->dataPtr->thermalInstance)
+  {
+    // Do not leave a reference to this->dataPtr->thermalMaterial
+    Ogre::MaterialPtr nullMaterial;
+    this->dataPtr->thermalInstance->getTechnique()
+      ->getOutputTargetPass()
+      ->getPass(0)
+      ->setMaterial(nullMaterial);
+  }
+
   // remove thermal textures
   if (this->dataPtr->ogreThermalTexture)
   {
@@ -312,6 +322,13 @@ void OgreThermalCamera::Destroy()
     this->dataPtr->ogreHeatSourceTexture = nullptr;
   }

+  if (!this->dataPtr->thermalMaterial.isNull())
+  {
+    Ogre::MaterialManager::getSingleton().remove(
+        this->dataPtr->thermalMaterial->getHandle());
+    this->dataPtr->thermalMaterial.setNull();
+  }
+
   Ogre::SceneManager *ogreSceneManager;
   ogreSceneManager = this->scene->OgreSceneManager();
   if (ogreSceneManager == nullptr)
diff --git a/src/base/BaseScene.cc b/src/base/BaseScene.cc
index ff97f951..57d1d047 100644
--- a/src/base/BaseScene.cc
+++ b/src/base/BaseScene.cc
@@ -1416,8 +1416,6 @@ bool BaseScene::LegacyAutoGpuFlush() const
 //////////////////////////////////////////////////
 void BaseScene::Clear()
 {
-  this->nodes->DestroyAll();
-  /*
   this->DestroyNodes();
   auto root = this->RootVisual();
   if (root)
@@ -1425,7 +1423,6 @@ void BaseScene::Clear()
     root->RemoveChildren();
     this->DestroyNode(root);
   }
-  */
   this->DestroyMaterials();
   this->nextObjectId = gz::math::MAX_UI16;
 }

This fixes the crashes for:

INTEGRATION_camera_ogre_gl3plus.test_ran
INTEGRATION_thermal_camera_ogre_gl3plus.test_ran

However now this sample:

INTEGRATION_wide_angle_camera_ogre_gl3plus.test_ran

Crashes at a different place because OgreWideAngleCamera::Destroy gets called twice.
The fix is to either see why is Destroy() getting called twice (@iche033 will know better) or place a nullptr check:
for (unsigned int i = 0u; i < this->dataPtr->kEnvCameraCount; ++i)
{
  if (this->dataPtr->envRenderTargets[i]) // CHECK!!!
  {
    OgreRTShaderSystem::DetachViewport(this->dataPtr->envViewports[i],
                                       this->scene);

    this->dataPtr->envRenderTargets[i]->removeAllViewports();
    this->dataPtr->envRenderTargets[i] = nullptr;
  }

  if (this->dataPtr->envCameras[i]) // CHECK!!!
  {
    this->scene->OgreSceneManager()->destroyCamera(
        this->dataPtr->envCameras[i]->getName());
    this->dataPtr->envCameras[i] = nullptr;
  }
}

The first time's callstack is this one:
1  gz::rendering::v7::OgreWideAngleCamera::Destroy                                                        OgreWideAngleCamera.cc 147  0x7ffff58bc43e
2  gz::rendering::v7::BaseStore<gz::rendering::v7::Sensor, gz::rendering::v7::OgreSensor>::DestroyImpl    BaseStorage.hh         956  0x7ffff584724e
3  gz::rendering::v7::BaseStore<gz::rendering::v7::Sensor, gz::rendering::v7::OgreSensor>::DestroyByIndex BaseStorage.hh         723  0x7ffff5846142
4  gz::rendering::v7::BaseStore<gz::rendering::v7::Sensor, gz::rendering::v7::OgreSensor>::DestroyAll     BaseStorage.hh         734  0x7ffff58461ac
5  gz::rendering::v7::BaseStoreWrapper<gz::rendering::v7::Node, gz::rendering::v7::Sensor>::DestroyAll    BaseStorage.hh         1460 0x7ffff7f9d114
6  gz::rendering::v7::BaseCompositeStore<gz::rendering::v7::Node>::DestroyAll                             BaseStorage.hh         1216 0x7ffff7f9f03f
7  gz::rendering::v7::BaseScene::DestroyNodes                                                             BaseScene.cc           333  0x7ffff7f8a5c6
8  gz::rendering::v7::BaseScene::Clear                                                                    BaseScene.cc           1419 0x7ffff7f932b1
9  gz::rendering::v7::OgreScene::Clear                                                                    OgreScene.cc           294  0x7ffff5894c02
10 gz::rendering::v7::BaseScene::Destroy                                                                  BaseScene.cc           1434 0x7ffff7f93451
11 gz::rendering::v7::OgreScene::Destroy                                                                  OgreScene.cc           300  0x7ffff5894c32
12 gz::rendering::v7::BaseStore<gz::rendering::v7::Scene, gz::rendering::v7::OgreScene>::DestroyImpl      BaseStorage.hh         956  0x7ffff584cc29
13 gz::rendering::v7::BaseStore<gz::rendering::v7::Scene, gz::rendering::v7::OgreScene>::Destroy          BaseStorage.hh         699  0x7ffff584b9ff
14 gz::rendering::v7::BaseRenderEngine::DestroyScene                                                      BaseRenderEngine.cc    163  0x7ffff7f87caf
15 WideAngleCameraTest_WideAngleCamera_Test::TestBody                                                     wide_angle_camera.cc   200  0x55555557f24a
16 testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>                         gtest.cc               2599 0x5555555cfa26
17 testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>                            gtest.cc               2635 0x5555555c8159
18 testing::Test::Run                                                                                gtest.cc               2674 0x5555555a4064
19 testing::TestInfo::Run                                                                                gtest.cc               2853 0x5555555a4aeb
20 testing::TestSuite::Run                                                                                gtest.cc               3012 0x5555555a5421
21 testing::internal::UnitTestImpl::RunAllTests                                                           gtest.cc               5870 0x5555555b50db
22 testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>       gtest.cc               2599 0x5555555d0ae7
23 testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>          gtest.cc               2635 0x5555555c93e5
24 testing::UnitTest::Run                                                                                gtest.cc               5444 0x5555555b36fa
25 RUN_ALL_TESTS                                                                                gtest.h                2293 0x5555555e2e08
26 main                                                                                gtest_main.cc          51   0x5555555e2d8a

The second time is this one:
1  gz::rendering::v7::OgreWideAngleCamera::Destroy                                                        OgreWideAngleCamera.cc 147  0x7ffff58bc43e
2  gz::rendering::v7::OgreWideAngleCamera::~OgreWideAngleCamera                                           OgreWideAngleCamera.cc 114  0x7ffff58bbf8d
3  gz::rendering::v7::OgreWideAngleCamera::~OgreWideAngleCamera                                           OgreWideAngleCamera.cc 115  0x7ffff58bc122
4  std::_Sp_counted_ptr<gz::rendering::v7::OgreWideAngleCamera *, (__gnu_cxx::_Lock_policy)2>::_M_dispose shared_ptr_base.h      377  0x7ffff58a57ec
5  std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release                                          shared_ptr_base.h      155  0x5555555877d0
6  std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count                                       shared_ptr_base.h      730  0x55555558622b
7  std::__shared_ptr<gz::rendering::v7::WideAngleCamera, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr       shared_ptr_base.h      1169 0x555555585eb4
8  std::shared_ptr<gz::rendering::v7::WideAngleCamera>::~shared_ptr                                       shared_ptr.h           103  0x555555585ed4
9  WideAngleCameraTest_WideAngleCamera_Test::TestBody                                                     wide_angle_camera.cc   200  0x55555557f32d
10 testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>                         gtest.cc               2599 0x5555555cfa26
11 testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>                            gtest.cc               2635 0x5555555c8159
12 testing::Test::Run                                                                                gtest.cc               2674 0x5555555a4064
13 testing::TestInfo::Run                                                                                gtest.cc               2853 0x5555555a4aeb
14 testing::TestSuite::Run                                                                                gtest.cc               3012 0x5555555a5421
15 testing::internal::UnitTestImpl::RunAllTests                                                           gtest.cc               5870 0x5555555b50db
16 testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>       gtest.cc               2599 0x5555555d0ae7
17 testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>          gtest.cc               2635 0x5555555c93e5
18 testing::UnitTest::Run                                                                                gtest.cc               5444 0x5555555b36fa
19 RUN_ALL_TESTS                                                                                gtest.h                2293 0x5555555e2e08
20 main                                                                                gtest_main.cc          51   0x5555555e2d8a

Ahhh. I realized why it gets called twice. It's the same problem as Ogre:
TEST_F(WideAngleCameraTest, WideAngleCamera)
{
  auto camera = scene->CreateWideAngleCamera("WideAngleCamera");

  ...

  // Clean up
  engine->DestroyScene(scene);

   //Crash! camera destructor is called here!
}

OK this is the latest patch:
diff --git a/ogre/src/OgreThermalCamera.cc b/ogre/src/OgreThermalCamera.cc
index 8c090ffc..5975c805 100644
--- a/ogre/src/OgreThermalCamera.cc
+++ b/ogre/src/OgreThermalCamera.cc
@@ -297,6 +297,16 @@ void OgreThermalCamera::Destroy()
   if (!this->ogreCamera || !this->scene->IsInitialized())
     return;

+  if (this->dataPtr->thermalInstance)
+  {
+    // Do not leave a reference to this->dataPtr->thermalMaterial
+    Ogre::MaterialPtr nullMaterial;
+    this->dataPtr->thermalInstance->getTechnique()
+      ->getOutputTargetPass()
+      ->getPass(0)
+      ->setMaterial(nullMaterial);
+  }
+
   // remove thermal textures
   if (this->dataPtr->ogreThermalTexture)
   {
@@ -312,6 +322,13 @@ void OgreThermalCamera::Destroy()
     this->dataPtr->ogreHeatSourceTexture = nullptr;
   }

+  if (!this->dataPtr->thermalMaterial.isNull())
+  {
+    Ogre::MaterialManager::getSingleton().remove(
+        this->dataPtr->thermalMaterial->getHandle());
+    this->dataPtr->thermalMaterial.setNull();
+  }
+
   Ogre::SceneManager *ogreSceneManager;
   ogreSceneManager = this->scene->OgreSceneManager();
   if (ogreSceneManager == nullptr)
diff --git a/ogre/src/OgreWideAngleCamera.cc b/ogre/src/OgreWideAngleCamera.cc
index 28590a37..dfc6bb77 100644
--- a/ogre/src/OgreWideAngleCamera.cc
+++ b/ogre/src/OgreWideAngleCamera.cc
@@ -158,15 +158,21 @@ void OgreWideAngleCamera::Destroy()

   for (unsigned int i = 0u; i < this->dataPtr->kEnvCameraCount; ++i)
   {
-    OgreRTShaderSystem::DetachViewport(this->dataPtr->envViewports[i],
-        this->scene);
+    if (this->dataPtr->envRenderTargets[i])
+    {
+      OgreRTShaderSystem::DetachViewport(this->dataPtr->envViewports[i],
+                                         this->scene);

-    this->dataPtr->envRenderTargets[i]->removeAllViewports();
-    this->dataPtr->envRenderTargets[i] = nullptr;
+      this->dataPtr->envRenderTargets[i]->removeAllViewports();
+      this->dataPtr->envRenderTargets[i] = nullptr;
+    }

-    this->scene->OgreSceneManager()->destroyCamera(
-        this->dataPtr->envCameras[i]->getName());
-    this->dataPtr->envCameras[i] = nullptr;
+    if (this->dataPtr->envCameras[i])
+    {
+      this->scene->OgreSceneManager()->destroyCamera(
+          this->dataPtr->envCameras[i]->getName());
+      this->dataPtr->envCameras[i] = nullptr;
+    }
   }

   if (this->dataPtr->envCubeMapTexture)
diff --git a/src/base/BaseScene.cc b/src/base/BaseScene.cc
index ff97f951..57d1d047 100644
--- a/src/base/BaseScene.cc
+++ b/src/base/BaseScene.cc
@@ -1416,8 +1416,6 @@ bool BaseScene::LegacyAutoGpuFlush() const
 //////////////////////////////////////////////////
 void BaseScene::Clear()
 {
-  this->nodes->DestroyAll();
-  /*
   this->DestroyNodes();
   auto root = this->RootVisual();
   if (root)
@@ -1425,7 +1423,6 @@ void BaseScene::Clear()
     root->RemoveChildren();
     this->DestroyNode(root);
   }
-  */
   this->DestroyMaterials();
   this->nextObjectId = gz::math::MAX_UI16;
 }
diff --git a/test/integration/wide_angle_camera.cc b/test/integration/wide_angle_camera.cc
index a78a8b89..bfe23778 100644
--- a/test/integration/wide_angle_camera.cc
+++ b/test/integration/wide_angle_camera.cc
@@ -315,4 +315,6 @@ TEST_F(WideAngleCameraTest, Projection)

   // Clean up
   engine->DestroyScene(scene);
+
+  ASSERT_EQ(1u, camera.use_count());
 }

thanks for the fixing crash. Sometimes the Destroy function is called when a node is removed manually and sometimes it gets called on destructor, and other times they are called in both cases so I always make sure they the Destroy function is safe to be called multiple times. The patch looks good.

Yes, thanks @darksylinc!  I think we are in pretty good shape here.


Failed to launch chrome buecause Running as root without --no-sandbox

Saving as PDF
(node:24806) UnhandledPromiseRejectionWarning: Error: Failed to launch chrome!
[1012/081529.390835:ERROR:zygote_host_impl_linux.cc(89)] Running as root without --no-sandbox is not supported. See https://crbug.com/638180.

TROUBLESHOOTING: https://github.com/GoogleChrome/puppeteer/blob/master/docs/troubleshooting.md
at onClose (/usr/lib/node_modules/percollate/node_modules/puppeteer/lib/Launcher.js:339:14)
at Interface.helper.addEventListener (/usr/lib/node_modules/percollate/node_modules/puppeteer/lib/Launcher.js:328:50)
at emitNone (events.js:111:20)
at Interface.emit (events.js:208:7)
at Interface.close (readline.js:368:8)
at Socket.onend (readline.js:147:10)
at emitNone (events.js:111:20)
at Socket.emit (events.js:208:7)
at endReadableNT (_stream_readable.js:1064:12)
at _combinedTickCallback (internal/process/next_tick.js:139:11)

(node:24806) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:24806) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

I've added support for the --no-sandbox flag in<EMAIL_ADDRESS>let me know if it solves your  issue!


streams in quic

hello , is there any option or attribute to change number of streams while using quic protocol.
thanks in advance.

https://github.com/SoonyangZhang/quic-on-ns3/blob/main/scratch/quic-main.cc#L205
int n = for_you_need;
for(int i=0;i<n;i++){


Updated refactoring for the RSpec test suites and the introduction of Alma test fixtures

Advances #1204 and deprecates #1443

replaced by https://github.com/pulibrary/bibdata/pull/1491


removing logging for gateway

removing logging for gnmi-gateway which was taking large space
Adding test logs of docker build and installation here
test_logs.txt

How to debug if we remove logging completely? At least change log level to error, what do you think?


renaming save secret option

@patrickxb from @malgorithms

is that cross-platform wording?  i know we don't have a secret store for anything except os x, but...

AFAIK storing secrets on linux / etc is also a 'keychain'
On Thu, Jan 7, 2016 at 4:21 PM, Patrick Crosby<EMAIL_ADDRESS>wrote:

is that cross-platform wording? i know we don't have a secret store for
anything except os x, but...
—
Reply to this email directly or view it on GitHub
https://github.com/keybase/client/pull/1657#issuecomment-169808582.

I think we have a string in the platform-specific SecretStore implementations, so we should do that instead of hard-coding. I don't know if 'Keychain' is the right term for e.g. Android...

The function I was thinking of was GetTerminalPrompt() (which should really be renamed GetSecretStoreTerminalPrompt() so we can have GetSecretStoreOptionLabel() or something

let's keep this simple and make the change for now. i don't think people will be confused (also: http://developer.android.com/reference/android/security/KeyChain.html)

sounds good.


o is not a constructor error

Hello,
I am encountering an issue when trying to use VueProgressBar with Vue. I am getting the error message o is not a constructor. Here is my code:
`import { createApp } from 'vue';
const app = createApp({});
import VueProgressBar from 'vue-progressbar'
app.use(VueProgressBar, {
color: 'rgb(143, 255, 199)',
failedColor: 'red',
height: '2px'
})`

I have installed the latest version of VueProgressBar and I have also checked for any version conflicts. However, I am still encountering this error.
Could you please help me resolve this issue?
Thank you!

did you solve this?


Convert manifest entries to unix paths

Potentially scary change. Goal is to make artifact manifests platform independent. Within artifacts, always use Unix style paths. The upload / download codepaths will make sure that they are downloaded using platform appropriate path separators.

Seems reasonable, how will this effect existing artifacts that were stored with windows?

If a Windows user logs an artifact that is identical to one logged before this version, they'll end up with a new version with / instead of \ in the paths. But all existing artifacts will still work. So in the worst case, the user incurs an additional upload cost.


Recycle at home containers

Calls the local authority endpoint to get a list of dry schemes and containers that accept the given material to be recycled at home.

:tada: This PR is included in version 1.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Fix unicode errors when validating files

Previously undetected because testing was only performed on systems where utf-8 is default.

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

Project coverage is 94.48%. Comparing base (2330398) to head (538b7fa).

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #233   +/-   ##
=======================================
  Coverage   94.47%   94.48%
=======================================
  Files          66       66
  Lines        6174     6178    +4
=======================================
+ Hits         5833     5837    +4
  Misses        341      341

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


Add outdated dependency detection

Add the ability to detect if newer versions of a given dependency are available. For Java libraries, this may be possible using technology included in the Versions Maven Plugin.
Add an optional evidence-based analysis step to collect and analyze copyright, build, file stamp and other dates to determine when the library was published. Add a configurable threshold that would flag the library as 'old' if published prior to this date.
Add an optional and separate report that would output all dependencies that have newer versions and if possible, state what the current version is as well as the closest minor version not containing known vulnerabilities. Include another section containing possible out-of-date libraries.

For Maven at least, this function can be handled by the Versions Maven Plugin:
http://mojo.codehaus.org/versions-maven-plugin/display-dependency-updates-mojo.html

For Maven at least, this function can be handled by the Versions Plugin:
http://mojo.codehaus.org/versions-maven-plugin/display-dependency-updates-mojo.html

Some preliminary work is in progress in the Maven plugin to list new versions of the identified dependency.
--Jeremy

Versions plugin page for Maven has moved: http://www.mojohaus.org/versions-maven-plugin/display-dependency-updates-mojo.html
I wonder if instead of trying to pull this functionality into Dependency Check, we could document on the site about the Versions plugin, and mention it in the output the Dependency Check Maven plugin.

The issue with just documenting dependency-updates-mogo is that not everyone is using Maven. Worst case we have the CLI.


Fix deployment to docker repos

see https://travis-ci.org/arschles/envtpl/builds/106531783 for an example failure

Instead of this, it probably makes more sense to release cross-compiled binaries using the travis releases provider


Add update pathway widget to AmiGO (prod)

As a final step for the merge pathway widget project, we want AmiGO to be using the final version.

@pkalita-lbl Would you mind confirming this looks correct to you? https://amigo.geneontology.org/amigo/gene_product/MGI:MGI:97591

Looks good to me.

Thank you for the eyes!


Opening files with $ sign in name

We can't open files/members any more when name of it has a $ sign in it for example ren$sign.cblle. This is not the case when I went back to 2.9.0.
After that I tried every version and did not work any more. What did change? And I feel like depending on versions readonly and position attributes don't work the way expected.
Help appreciated.
Thank you.

Please share the Code for IBM i output channel when both versions try and open the file. Thanks!

With Code IBM I version v2.9.0 the file opens correctly and we get the following output:
/home/REN: /QOpenSys/usr/bin/qsh
system  "CHKOBJ OBJ(REN/QCBLSRC) OBJTYPE(*FILE) AUT(*UPD)"
{
"code": 0,
"signal": null,
"stdout": "",
"stderr": ""
}
/home/REN: /QOpenSys/usr/bin/qsh
system  "QSYS/CPYTOSTMF FROMMBR('/QSYS.LIB/REN.LIB/QCBLSRC.FILE/REN$T01.MBR') TOSTMF('/tmp/vscodetemp-O_vHgBRecD') STMFOPT(*REPLACE) STMFCCSID(1208) DBFCCSID(*FILE)"
{
"code": 0,
"signal": null,
"stdout": "",
"stderr": "CPCA082:  Object copied."
}
With the newest Code IBM I version v2.12.0 we get the error and we get:
/home/REN: /QOpenSys/usr/bin/qsh
system  "CHKOBJ OBJ(REN/QCBLSRC) OBJTYPE(*FILE) AUT(*UPD)"
{
"code": 0,
"signal": null,
"stdout": "",
"stderr": ""
}
/home/REN: /QOpenSys/usr/bin/qsh
system  "QSYS/CPYTOSTMF FROMMBR('/QSYS.LIB/REN.LIB/QCBLSRC.FILE/REN\$T01.MBR') TOSTMF('/tmp/vscodetemp-O_3yTqWZd4') STMFOPT(*REPLACE) STMFCCSID(1208) DBFCCSID(*FILE)"
{
"code": 1,
"signal": null,
"stdout": "",
"stderr": "CPFA0A9:  Object not found.  Object is /QSYS.LIB/REN.LIB/QCBLSRC.FILE/REN/.MBR.\nCPFA097:  Object not copied.  Object is /QSYS.LIB/REN.LIB/QCBLSRC.FILE/REN\.MBR."
}


Custom resolver: should not worry about resolver resource

Is your feature request related to a problem? Please describe.
According to doc https://aws-amplify.github.io/docs/cli/graphql#add-a-custom-resolver-that-targets-a-dynamodb-table-from-model, users can add a custom resolver by:

Add a resolver resource to a stack in the stacks/ directory.
Add a resolver template in resolvers/ directory.

Doing above has the same effect as adding a custom resolver in AppSync console, but it gains the benefit of version control.
However, I do notice that adding a custom resolver in AppSync console doesn't ask me to add a resolver resource manually. That's why I propose: adding a custom resolver via resources/ should not, either.
Describe the solution you'd like
Write the resolver file in VTL only, and do not have to worry about implementing the resolver resource file.

Hey @YikSanChan, Apologies for the incredibly late response. Wanted to make sure that the future readers see the resolution.
We handed over the control from resource management to customer to implement this in graphql transformer version V2.  Please refer here for more details.


Live Search Box Not Cleared After Selection

I believe that this is a major usability problem if the select element is intended to be used more than once for example to add items to a list.
Steps to reproduce the problem using the first Live Search example on this page
http://silviomoreto.github.io/bootstrap-select/examples/#live-search

Click the select element
Type something
Hit "Enter" to select the element
Optionally switch the focus to another element (Tab) then return the focus to the select element (Shift + Tab)
Type something else.

You will see that the new search text is appended to the old search text. I believe the expected behavior would be to start a new search.
Workaround:
Clear the live search box on hidden.bs.select
$('select.combobox').selectpicker({
        liveSearch: true
    }).on('hidden.bs.select',
        function () {
            $(this).data('selectpicker').$searchbox.val('').trigger('propertychange');
        });

I think that this needs to be the default behavior.

Available in v1.13.0-alpha.


:bug: Ensure CAPIProviders are removed correctly on chart uninstall

What this PR does / why we need it:
helm creates resources on pre-delete hooks, it does not delete them or respect --cascade policy and the order. So we need to create a job to do the actual delete operation on CAPIProvider resources.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #480
Special notes for your reviewer:
Checklist:

[ ] squashed commits into logical changes
[ ] includes documentation
[ ] adds unit tests
[ ] adds or updates e2e tests

This requires a fix upstream first. Without that we are still getting hit by CRD uninstallation on the operator side


Reduce duplication in generated SDKs

The following changes are to reduce duplication in generated Go SDK:

Changed from using common-types/resource-management/v5/types.json#/definitions/OperationStatusResult to common-types/resource-management/v3/types.json#/definitions/OperationStatusResult.
Removed lenient-model-deduplication: true property in readme.go.md.
Updated all references to ../../../../../common-types/resource-management/v2/types.json#/definitions/ErrorResponse to ../../../../../common-types/resource-management/v3/types.json#/definitions/ErrorResponse. This is to prevent the following error in the Go SDK pipeline:

cmderr	[generator automation-v2] [ERROR] - properties.details.$ref: "#/components/schemas/schemas:237" => "#/components/schemas/schemas:335"; This error can be *temporarily* avoided by using the 'modelerfour.lenient-model-deduplication' setting.  NOTE: This setting will be removed in a future version of @autorest/modelerfour; schemas should be updated to fix this issue sooner than that.
cmderr	[generator automation-v2] [ERROR] fatal   | Error: 1 errors occured -- cannot continue.
cmderr	[generator automation-v2] [ERROR] fatal   | Process() cancelled due to failure
cmderr	[generator automation-v2] [ERROR] error   |   Error: Plugin prechecker reported failure.

The result is 4 breaking changes, which I believe is expected as we are removing the auto-generated types:
info	[Changelog] ### Breaking Changes
info	[Changelog]
info	[Changelog] - Type of `OperationStatus.Error` has been changed from `*ErrorDetailAutoGenerated` to `*ErrorDetail`
info	[Changelog] - Type of `OperationStatusResult.Error` has been changed from `*ErrorDetailAutoGenerated` to `*ErrorDetail`
info	[Changelog] - Struct `ErrorDetailAutoGenerated` has been removed
info	[Changelog]
info	[Changelog] ### Features Added
info	[Changelog]
info	[Changelog] - New value `ProvisioningStateConfiguringAAD` added to enum type `ProvisioningState`
info	[Changelog] - New enum type `AccessPolicyAssignmentProvisioningState` with values `AccessPolicyAssignmentProvisioningStateCanceled`, `AccessPolicyAssignmentProvisioningStateDeleted`, `AccessPolicyAssignmentProvisioningStateDeleting`, `AccessPolicyAssignmentProvisioningStateFailed`, `AccessPolicyAssignmentProvisioningStateSucceeded`, `AccessPolicyAssignmentProvisioningStateUpdating`
info	[Changelog] - New enum type `AccessPolicyProvisioningState` with values `AccessPolicyProvisioningStateCanceled`, `AccessPolicyProvisioningStateDeleted`, `AccessPolicyProvisioningStateDeleting`, `AccessPolicyProvisioningStateFailed`, `AccessPolicyProvisioningStateSucceeded`, `AccessPolicyProvisioningStateUpdating`
info	[Changelog] - New enum type `AccessPolicyType` with values `AccessPolicyTypeBuiltIn`, `AccessPolicyTypeCustom`
info	[Changelog] - New enum type `UpdateChannel` with values `UpdateChannelPreview`, `UpdateChannelStable`
info	[Changelog] - New function `NewAccessPolicyAssignmentClient(string, azcore.TokenCredential, *arm.ClientOptions) (*AccessPolicyAssignmentClient, error)`
info	[Changelog] - New function `*AccessPolicyAssignmentClient.BeginCreateUpdate(context.Context, string, string, string, CacheAccessPolicyAssignment, *AccessPolicyAssignmentClientBeginCreateUpdateOptions) (*runtime.Poller[AccessPolicyAssignmentClientCreateUpdateResponse], error)`
info	[Changelog] - New function `*AccessPolicyAssignmentClient.BeginDelete(context.Context, string, string, string, *AccessPolicyAssignmentClientBeginDeleteOptions) (*runtime.Poller[AccessPolicyAssignmentClientDeleteResponse], error)`
info	[Changelog] - New function `*AccessPolicyAssignmentClient.Get(context.Context, string, string, string, *AccessPolicyAssignmentClientGetOptions) (AccessPolicyAssignmentClientGetResponse, error)`
info	[Changelog] - New function `*AccessPolicyAssignmentClient.NewListPager(string, string, *AccessPolicyAssignmentClientListOptions) *runtime.Pager[AccessPolicyAssignmentClientListResponse]`
info	[Changelog] - New function `NewAccessPolicyClient(string, azcore.TokenCredential, *arm.ClientOptions) (*AccessPolicyClient, error)`
info	[Changelog] - New function `*AccessPolicyClient.BeginCreateUpdate(context.Context, string, string, string, CacheAccessPolicy, *AccessPolicyClientBeginCreateUpdateOptions) (*runtime.Poller[AccessPolicyClientCreateUpdateResponse], error)`
info	[Changelog] - New function `*AccessPolicyClient.BeginDelete(context.Context, string, string, string, *AccessPolicyClientBeginDeleteOptions) (*runtime.Poller[AccessPolicyClientDeleteResponse], error)`
info	[Changelog] - New function `*AccessPolicyClient.Get(context.Context, string, string, string, *AccessPolicyClientGetOptions) (AccessPolicyClientGetResponse, error)`
info	[Changelog] - New function `*AccessPolicyClient.NewListPager(string, string, *AccessPolicyClientListOptions) *runtime.Pager[AccessPolicyClientListResponse]`
info	[Changelog] - New function `*Client.BeginFlushCache(context.Context, string, string, *ClientBeginFlushCacheOptions) (*runtime.Poller[ClientFlushCacheResponse], error)`
info	[Changelog] - New function `*ClientFactory.NewAccessPolicyAssignmentClient() *AccessPolicyAssignmentClient`
info	[Changelog] - New function `*ClientFactory.NewAccessPolicyClient() *AccessPolicyClient`
info	[Changelog] - New struct `CacheAccessPolicy`
info	[Changelog] - New struct `CacheAccessPolicyAssignment`
info	[Changelog] - New struct `CacheAccessPolicyAssignmentList`
info	[Changelog] - New struct `CacheAccessPolicyAssignmentProperties`
info	[Changelog] - New struct `CacheAccessPolicyList`
info	[Changelog] - New struct `CacheAccessPolicyProperties`
info	[Changelog] - New struct `ErrorDetail`
info	[Changelog] - New field `AADEnabled` in struct `CommonPropertiesRedisConfiguration`
info	[Changelog] - New field `UpdateChannel` in struct `CreateProperties`
info	[Changelog] - New field `UpdateChannel` in struct `Properties`
info	[Changelog] - New field `UpdateChannel` in struct `UpdateProperties`
info	[Changelog]
info	[Changelog] Total 4 breaking change(s), 52 additive change(s).

This PR is into a dev branch, so does not need to be reviewed by ARM reviewers.

This is a comment on the wrong PR but... I wonder did we really need 'ConfiguringAAD' provisioningState? What are you going to return to old clients who do GET on a cache in that state?

I don't think these changes are actually breaking, and we probably reviewed them all before during the preview api version review, right? @austintolani

I think the update is all fine from ARM POV also. Stamping it good for ARM. The main concern is SDKs right.

This is really a comment on the wrong PR since you already made that change, but... I wonder did we really need 'ConfiguringAAD' provisioningState? What are you going to return to old clients who do GET on a cache in that state? Updating? Its probably fine as long as we do something like that.

@TimLovellSmith the ConfiguringAAD state would only be available for caches enabling/disabling AAD, which is only available from API version 2023-05-01-preview onwards. So I don't think there would be a case where old clients would have this provisioning state.

This is really a comment on the wrong PR since you already made that change, but... I wonder did we really need 'ConfiguringAAD' provisioningState? What are you going to return to old clients who do GET on a cache in that state? Updating? Its probably fine as long as we do something like that.

@TimLovellSmith the ConfiguringAAD state would only be available for caches enabling/disabling AAD, which is only available from API version 2023-05-01-preview onwards. So I don't think there would be a case where old clients would have this provisioning state.

That assumption seems a little off-base because you could have someone e.g. configure AAD using the portal, then try to run a script against their cache... where the script still uses the old API version, so it will have to see a value that it understands.


[COMGR] Fixes for HIP PCH

Resolves issues related to SWDEV-257056:

Fixed: Observed MIOPEN_DONT_USE_HIP_RUNTIME_HEADERS in handle_test.
Fixed: Observed MIOPEN_DONT_USE_HIP_RUNTIME_HEADERS in reduction_operator.hpp (fixes reduce_test).
Fixed: Observed MIOPEN_DONT_USE_HIP_RUNTIME_HEADERS in ConvAsmImplicitGemmV4R1DynamicWrw.
Fixed: handle_test for the case when HIP kernels disabled.
Fixed: Incorrect #include in kernel source.
Added: Workaround in handle_test for macros missing from HIP PCH in ROC, 3.10 RC3 (WORKAROUND_SWDEV_257056_PCH_MISSING_MACROS)

The workaround is enabled by default.
It will be disabled automatically as soon as ROCm version exceeds 3.10.x

Added feature: Introduced env var control MIOPEN_DEBUG_COMGR_HIP_PCH_ENFORCE that allows overriding of HIP PCH feature auto-detection.

@fronteer @shaojiewang @JehandadKhan You are all assigned to review this urgent PR, please do so.

Description updated.


Bug from typescript-transform-paths

New version of typescript-transform-paths is occuring bug.
Therefore, roll back it to previous version forcibly.

Related issue: https://github.com/LeDDGroup/typescript-transform-paths/issues/163


Plugin for panda.tv ?

The relatively new Chinese streaming site panda.tv has a ton of popularity, could a plugin be added for it? It uses Flash player of course. (Context: My favourite streamer just switched to this platform from Twitch, and I can't record the streams :P)

You can try #1241

Sorry for ignorance, but I just copied the python script to the plugin folder along with other plugin scripts. Now the message I get is: "No streams found at panda.tv/3332". So as far as I understand, the script is working but stream cannot be found? Do I need to compile the code somehow? (All the other scripts are .pyc except pandatv.py)

it gets 403 error sometimes.
like Could not open stream: Unable to open URL: http://pl10.live.panda.tv/live_panda/ceb9659d2c67461eeb018b41de82c4c4.flv (403 Client Error: Forbidden)
But u can open the stream with
http://pl7.live.panda.tv/live_panda/ceb9659d2c67461eeb018b41de82c4c4.flv

You can try https://github.com/intact/livestreamer/blob/add-pandatv-plugin/src/livestreamer/plugins/pandatv.py


Updating changelog for new version of chef

Omnibus PR: https://github.com/chef/omnibus-chef/pull/347
\cc @chef/client-core

:shipit:

What's the status of this?

We need to start over since we've now updated to 12.2.0 RC


Maui performance issues under Android

Mapsui Version
4.1.3, but also tried 4.1.5
Mapsui Platform
Maui Android (broken)
Maui UWP (seems to work)
Xamarin Forms (works)
Device
The test device is a Samsung Galaxy s21 running Android 14. Model is SM-G991B
Describe the bug
We have a test app that uses our API wrapper around Mapsui to present the same interface to all the platforms we support. This works on WPF, Xamarin Forms and now Maui. The code is essentially the same on all platforms, we just ship Assemblies that target the specific Frameworks.
The Maui port went well. Very little code changed. I have had it previously running and it seemed fine under .Net 7, but the new port if targeting .Net 8. We are seeing significant issues with performance under Android.
I was hopeful that I might be able to turn on GUI rendering, but setting the MapControl to have UseGpu = true; crashes the app.
To Reproduce
Steps to reproduce the behavior:
It would be extremely difficult for me to describe how our code works. But we essentially have multiple layers that render multiple Map objects on to the map. The demo app however just has a single map layer that is using OpenStreetMap.
The demo apps are using the same APIs and the same controls (it just has a different platform implementation under the hood that routes in the correct platform.)
Expected behavior
We would expect basic functionality, like moving/panning the map to be  smooth. However it is unusable under Android with Maui.
Screenshots
This movie probably shows the issue fairly well. I open the Xamarin Forms app then the Maui one. You can clearly see the difference.
https://github.com/Mapsui/Mapsui/assets/429330/9c067923-57d9-420b-b8ff-fcd270aa0970
Additional context
Add any other context about the problem here.

Part of the issue might be that we seem to not be able to use the accelerated GL rendering? I think SkiaSharp needs to be updated to 3.0.0-preview-3.1 to get that to work in Maui.

I just ran the Mapsui.Samples.Maui from the debugger on a local device connected through usb and it performs well. Could you test how that performs on your device?

What is remarkable in your movie (thanks, that helps a lot!) is that the map tiles are not updated, or much later. Perhaps the problem is with the tile fetch logic or the connection. Could you attach the logger, perhaps we can see what is going on https://mapsui.com/documentation/logging.html.

Could you attach the logger, perhaps we can see what is going on https://mapsui.com/documentation/logging.html.

I will do that this morning.
The same code works on multiple platforms, and so Android is the only one so far that shows this specific issue. I know we set up a number of layers and I don't really understand why Windows running the same Maui app code is "okay", but under Android it runs terribly. It doesn't seem to make any sense to me. I tried removing events we add in to track touches etc, but that didn't make much difference. I'm wondering if it might be to do with the animations bug? This is the same code that triggered that issue under Windows using WPF. I still think the non-CPU rendering might be causing it.

Did you test the sample apps with your device? Do you see the same behavior?
CPU is slower than GPU but in this case (only draw bitmaps) not so much.

Debug wise, I'm not hitting any errors. I am now removing all the code that adds any events or extra functionality to see if any of it is causing the slow downs.

Did you try the samples? Did you see there the same behavior.

This is the next test. We are using .Net 8. Is that a potential problem? The Xamarin Forms app is obviously using Mono. It looks like debug builds do not use AOT, so wondering if that might be an issue also.

One other thing / the latest Skia Sharp preview has a working SKGLView under Android. How easy would it be to make that work with Mapsui? We are really going to need the acceleration at some point soon. Unfortunately it might be a show stopper as we have certain elements that are rendered to GL contexts.

@memson is the data fetched with the mapsui infrastructure or your own.
The freezing user interface could be caused by code running on the UIThread. Android doesn’t like it when iOS code is run on the UIThread. A method to force a work item to the background thread is await …. ConfigureAwait(false)

@memson is the data fetched with the mapsui infrastructure or your own.

OSM. The same code is used on multiple platforms and the Maui version serums well under Windows. I might try it on iOS over the weekend - we don't currently support iOS.

The freezing user interface could be caused by code running on the UIThread. Android doesn’t like it when code is run on the UIThread.

It's possible. But the same code under Xamarin Forms shows no slow down. And I mean - same code. I basically made a Maui version of the Maui specific part of the API and cut and pasted the code from the Xamarin Forms version in to the Maui template all writhe changes to make the namespaces correct for Maui.

Can you debug the Android App and give the Android Output Log, because there UI Freezes are logged.

Did you test the sample apps with your device? Do you see the same behavior?
CPU is slower than GPU but in this case (only draw bitmaps) not so much.

I am having a terrible time getting them to compile as my Visual Studio seems to only want to target .Net 8.0 at the moment.

For testing if GPU Rendering would improve performance you can use MapControl.UseGPU = true (For Android in Windows this won't work because for that SkiaSharp 3.0.0 is needed).

For testing if GPU Rendering would improve performance you can use MapControl.UseGPU = true (For Android in Windows this won't work because for that SkiaSharp 3.0.0 is needed).

The only platforms we really care about are Windows and Android, so not having either is not ideal. I know having GPU rendering improves performance because we (I am guessing) already use it for Android in the Xamarin Forms version of the code we are currently migrating. There are no issues in the Xamarin Forms version of this code under Android, but without accelerated graphics I guess it is hard to know if that is the issue or not. Can I turn off the GPU rendering in Xamarin Forms also?

Yes, with the same command, but setting the property UseGPU to false.

And you have to set it before you create the MapControl.

And you have to set it before you create the MapControl.

Cool. I will try in Monday. Our VPN seems to be down so I will need to wait for the office. I've just needed to reinstall Visual Studio 2022 as I ran out of disk space last week and uninstalling VS2019 hosed Maui from compiling properly. Unfortunately all nugets come from our internal cache, so I can't build our code now without the VPN.
The main difference I can see is that we are building against .Net 8, and Mapsui seems to be .Net 7. I will try making our code target 7, and see if that helps.

Hi Team,
You have cited my GitHub handle( @memson ) by mistake. I’m sure that you’re after Matt Emson and not me!! 😉
Best regards,
Michelle
From: Thomas Stocker @.>
Date: Friday, April 19, 2024 at 2:25 PM
To: Mapsui/Mapsui @.>
Cc: Michelle Emson @.>, Mention @.>
Subject: Re: [Mapsui/Mapsui] Maui performance issues under Android (Issue #2597)
@memsonhttps://github.com/memson is the data fetched with the mapsui infrastructure or your own.
The freezing user interface could be caused by code running on the UIThread. Android doesn’t like it when iOS code is run on the UIThread. A method to force a work item to the background thread is await …. ConfigureAwait(false)
—
Reply to this email directly, view it on GitHubhttps://github.com/Mapsui/Mapsui/issues/2597#issuecomment-2067083831, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFQUGC5SGXQF42673HFEMZDY6FORPAVCNFSM6AAAAABGLV2B22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRXGA4DGOBTGE.
You are receiving this because you were mentioned.Message ID: @.***>


mark DidIon as @Deprecated

goodbye DidIon 👋

this is done as of https://github.com/TBD54566975/web5-kt/pull/248 - specifically https://github.com/TBD54566975/web5-kt/pull/248/commits/5f42234d92fd14f2ed3682c60bb76a6ce816527e


Add Spatial/CanvasItem export property "inherits_transform"

The toplevel stuff is the flag that determines whether the Spatial should orient itself independently of its parent (so it doesn't "inherit" the parent's transform). I was thinking it should go in the Transform or Matrix area, but those seem to be dedicated exclusively to the vector values. It'd be much more convenient if we could just set this boolean from the Inspector rather than using a script or hacking it with a Node in between the two Spatials.
If anyone has suggestions for a different GROUP name or a different place to put this, let me know.
Let me know what you think.

Can we do something similar to CanvasItem?

@KellyThomas Oh, yeah, was looking in Node2D and didn't see it, but I guess CanvasItem does have it. I'll go ahead and add that in.

Oh wait, looks like there's a comment from @bojidar-bg about not including it in the exports. Wonder what he thinks about it.

@willnationsdev I have no idea what I thought of then, but I think this comment was left by @reduz a few millenia before me.
Anyway, I think it would be better if it has some other name so that it doesn't conflict with existing scripts ("inherit_transform"?), and be visible in editor since it would be useful there.

The name on the git blame is Bojidar iirc, so I figured it was you.
I'm all for changing the name to something clearer (figured it was just convention to keep the name the same-ish). I already set it up to be exposed to the Inspector - that was kinda the point of this PR.

Oh wait, should probably change this so that I actually create "inherit_transform" setter/getters formally. Because their boolean value would actually be the opposite of "is_toplevel". lol

Not sure what that Travis error is about. Someone will need to restart that build I guess?

@bojidar-bg just add a comment? Can do. In that case then, I'd move the methods to make them public rather than protected.

No, similar to StaticBody2D::set_friction:
https://github.com/godotengine/godot/blob/c02fb271fd54ecda331968d2269af79a6007dcb1/scene/2d/physics_body_2d.cpp#L190-L194

No, this function is more confusing because it makes it sound like inheriting transform is the exception, not the rule (which is the case). If you want to rename toplevel to something else its fine, but it must not invert the meaning. Also, if this is changed it will have to be for 4.0, as this is a pretty big breakage even it backwards compatibility is kept.

Also, I dont think the editor is designed to work well with this change (exposed property), so editor must be updated too.

In my opinion, this should not be exposed to editor since it makes no sense there. Same as process and other properties. If you need this, its going to be from code, so it can be enabled there.

As per discussion in IRC, closing this PR.
TL;DR: The typical, intended workflow of using scenes is for them to work within the editor as if they are placed relatively. Forcing an absolute position is more often a runtime consideration, so setting the flag at runtime via script vs. at editor-time via Inspector is cleaner. If a user wants the even-more-rare workflow of positioning it absolutely in-editor relative to its parent, then they can use a Node buffer.
<reduz> Juan Linietsky willnationsdev: again, it prevents you from instancing, so its kind of pointless
12:03 PM you will edit the scene in the editor, then if you want to instance it, position and edit that scene some somewhere else, it wont work
12:04 PM all the times you instance the scene will put the node in the same place
12:04 PM so its kind of useless as a feature in general
12:04 PM <willnationsdev> reduz: Ah, I gotcha now. It creates an exceptional behavior as the new default when dealing with that scene alone.
12:05 PM That makes sense.
12:05 PM <reduz> Juan Linietsky far most of the time, you will want to position it properly, instance it properly and then once it runs make it not inherit transform
12:05 PM so it at least retains position
12:05 PM this is why the property is not exposed, its common sense

For future reference, if you want to make a Spatial or CanvasItem not inherit the transform, you can simply make it a child of a Node.


Specific weight for each sequence

It seems that every image sequence has it's own weight, look forward you to improve this repo.

the method we propose is a test-time optimization-based method (i.e., per-video training), so each sequence will have its own weight. Extending it to work in a generalized way is beyond the scope of this repo, but i encourage you to take a look at this line of work if you are in search of this kind of method:
https://co-tracker.github.io/
https://deepmind-tapir.github.io/
https://github.com/aharley/pips2


End of the day clean up PR

fixing package checks etc.

@aappling-usgs can you merge if this passes?

Coverage remained the same at 18.82% when pulling da32865a9fb7e30e9124043f3b61ffbc3f09a016 on jread-usgs:master into fcc4a3c177fd672f16a5fc31d82d69950c29c708 on USGS-R:master.


[ToolbarGroup] Add more tests for other child components

Summary:

Add more tests to spec of ToolbarGroup component
These tests cover other cases when rendering child components for ToolbarGroup (not only FontIcon component like before)

[x] PR has tests / docs demo, and is linted.
[x] Commit and PR titles begin with [ComponentName], and are in imperative form: "[Component] Fix leaky abstraction".
[x] Description explains the issue / use-case resolved, and auto-closes the related issue(s) (http://tr.im/vFqem).

@oliviertassinari Thx for quick response. I updated that last test. Can u take one more look?

@ibekavac Thanks!

@mbrookes np! Will dive into the code to see if I can contribute more!

@ibekavac We are happy to hear it :), you can have a look at the ROADMAP that could give you some inspirations.


Implement hot reloading for Desktop, TUI, and Liveview

[x] TUI
[x] Desktop
[x] LiveView
~- SSR-~ (not possible with the current SSR API that takes a immutable reference to the virtual dom, but this does expose hooks that should make it easy for users to implement on there own project)
[x] Allow configuring the paths the file listener uses
[x] Update guide
[x] Allow configuring the hot reloading context for different namespaces

This PR creates hot reloading handler for each platform and enables hot reloading without the CLI by using a hot reloading macro. Each hot reloading handler uses a socket to communicate with the file listener, so that external tools like the CLI can hook into the existing hot reloading handler.

Looks great. The use of the macro is to get access to the env var to line up the watch directory, right?

Looks great. The use of the macro is to get access to the env var to line up the watch directory, right?

Yes

I'm a tiny bit worried that it will be confusing that the project doesn't hot-reload automatically when logic changes, but I'm not sure if we can get that kind of tooling wired up through a macro.

I have the same concern. I will make it more clear that the user needs to manually rebuild the project to get updates when in the message when the hot reloading fails.
We should be able to do anything that the CLI does with the macro approach. It would require more logic to check if the dev server was started in a previous call and prevent the main thread from closing after shutting down the outdated application, but it should be possible.

@Demonthos: This looks great!
I have a few questions:

The interpreter can only use expressions that existed on the last full recompile.

full recompile includes incremental recompilation, right?
I'm asking, because I've noticed some unexpected behavior when I experimented with variable interpolation in RSX templates in my Wasm app (it seemed a bit buggy, but I might have done something wrong. I'm planning to experiment a bit more, and then maybe open an issue with my findings).
For example let x = 1; rsx!("foo {x}") => let x = "bar"; rsx!("foo {x}") lead to issues, if I remember correctly. Sometimes hot-reload stopped working at all – I believe let x = 1; rsx!("foo {x}") => let y = 1; rsx!("foo {y}") was such a case – and I had to restart the CLI.
As mentioned, I'll experiment a bit more, and then possibly open an issue.

Right now, this isn't compatible with tools like cargo watch.
Is my assumption correct, that dioxus-hot-reload is able to recognize changes outside RSX macros, that require full recompilation?
(After looking at the changes in this PR a bit more: The answer appears to be 'Yes')
If so, could there be an option to create/change a specific file, which could be used to trigger cargo watch to recompile the project, if dioxus-hot-reload can't hot-reload the changes?
For example, dioxus-hot-reload could create/change ./.recompile. Then we could start our programs via cargo watch --exec run --watch './.recompile', which would instruct cargo watch to only watch ./.recompile for changes.

With the above, TUI apps could be developed with full hot-relaod support by using dioxus-hot-reload and then using cargo watch --exec run --watch './.recompile'.

I've added support for automatic reconnects to the WebSocket after disconnects to my fork of dioxus-liveview (I'll open a PR later to evaluate if this can be added to Dioxus). My PR plus dioxus-hot-reload and cargo watch would also enable full hot-reload for dioxus-liveview (my PR and cargo watch alone would already enable hot-reload. But with dioxus-hot-reload this setup would also support the lightning fast hot-reload that is available for Wasm apps).
(While my PR can be used to get hot-reloading working, native support within the CLI would be better, of course. However, WebSocket reconnecting should anyway be added to Dioxus. I think this is important for production use, and while developing Dioxus apps).

By default the dev server watches on the src and examples folders in the root crate directory.

Other paths (e.g., Cargo.toml and local dependencies) probably also should be watched, to avoid unexpected issues. It's probably a good idea to do what cargo watch does by default.

Thanks for the feedback!

Right now, this isn't compatible with tools like cargo watch.
Is my assumption correct, that dioxus-hot-reload is able to recognize changes outside RSX macros, that require full recompilation?
(After looking at the changes in this PR a bit more: The answer appears to be 'Yes')
If so, could there be an option to create/change a specific file, which could be used to trigger cargo watch to recompile the project, if dioxus-hot-reload can't hot-reload the changes?
For example, dioxus-hot-reload could create/change ./.recompile. Then we could start our programs via cargo watch --exec run --watch './.recompile', which would instruct cargo watch to only watch ./.recompile for changes.
With the above, TUI apps could be developed with full hot-relaod support by using dioxus-hot-reload and then using cargo watch --exec run --watch './.recompile'.
I've added support for automatic reconnects to the WebSocket after disconnects to my fork of dioxus-liveview (I'll open a PR later to evaluate if this can be added to Dioxus). My PR plus dioxus-hot-reload and cargo watch would also enable full hot-reload for dioxus-liveview (my PR and cargo watch alone would already enable hot-reload. But with dioxus-hot-reload this setup would also support the lightning fast hot-reload that is available for Wasm apps).
(While my PR can be used to get hot-reloading working, native support within the CLI would be better, of course. However, WebSocket reconnecting should anyway be added to Dioxus. I think this is important for production use, and while developing Dioxus apps).

I need to go back and update the docs for the latest changes but I just pushed some changes to allow configuring a command to run when the hot reloading fails. This should be more flexible than creating a empty file. You could create a build command or create a directory to trigger cargo watch if you prefer that method. With this combined with your PR for reconnecting web sockets should provide a full CLI-like dev experience.

By default the dev server watches on the src and examples folders in the root crate directory.

Other paths (e.g., Cargo.toml and local dependencies) probably also should be watched, to avoid unexpected issues. It's probably a good idea to do what cargo watch does by default.

I changed this to more broad. It now listens for any file changes from the root directory except the target directory and any files in the .gitignore.

Docs are updated. Here is what the new macro looks like:
https://user-images.githubusercontent.com/66571940/212437899-9aac647a-ba82-4013-871d-5a541196f166.mp4

I just pushed some changes to allow configuring a command to run when the hot reloading fails. This should be more flexible than creating a empty file.

Good idea, that makes much more sense. If dioxus-hot-reload handles changes like cargo, then cargo watch would not be required at all, which is great.
I'm not 100% sure if this makes sense, but maybe the option to execute a Rust expression or call a Rust function would be useful, in some cases.
Similarly, in some cases it might be useful to execute a command or Rust code after a hot-reload.
However, I can't really come up with a real use-case for those suggestions (executing Rust code could save having to execute a separate Bash script, if some more complex action is required).

I changed this to more broad. It now listens for any file changes from the root directory except the target directory and any files in the .gitignore.

Thanks for considering my suggestion!
I think, watching a too broad range of files wouldn't be good either, however.
For example, I wouldn't want dioxus-hot-reload to be triggered when I edit a README file, or files in a potential wiki directory, etc.
Ideally, dioxus-hot-reload would use the same heuristic that cargo itself uses (plus the option to watch additional files, that are specific to the project – e.g., CSS files, and so on).
I'm not 100% sure how exactly that heuristic works, but I think cargo considers at least the following:

Files in the src directory
Cargo.toml
Cargo.lock (most likely)
The above for all local dependencies (dependencies that have a path field, probably also local git repos)

In case you are not aware of these, there are a few crates that can be used to get the required metadata:

cargo_metadata
krates

There might be subtle, hard to debug bugs, if an incompatible heuristic is used.

Here is what the new macro looks like working:

That looks great!

Good idea, that makes much more sense. If dioxus-hot-reload handles changes like cargo, then cargo watch would not be required at all, which is great.
I'm not 100% sure if this makes sense, but maybe the option to execute a Rust expression or call a Rust function would be useful, in some cases.
Similarly, in some cases it might be useful to execute a command or Rust code after a hot-reload.
However, I can't really come up with a real use-case for those suggestions (executing Rust code could save having to execute a separate Bash script, if some more complex action is required).

That was one of the approaches I looked at, unfortunately there doesn't seem to be a good cross platform way to spawn a detached task outside of spawning new commands. Which means what ever code is run in that closure would need to finish running before any rebuild was triggered so something like using cargo as a library would not work. Ultimately, without a use case that would require this I don't think it is worth complicating the API.

Thanks for considering my suggestion!
I think, watching a too broad range of files wouldn't be good either, however.
For example, I wouldn't want dioxus-hot-reload to be triggered when I edit a README file, or files in a potential wiki directory, etc.
Ideally, dioxus-hot-reload would use the same heuristic that cargo itself uses (plus the option to watch additional files, that are specific to the project – e.g., CSS files, and so on).
I'm not 100% sure how exactly that heuristic works, but I think cargo considers at least the following:

Files in the src directory
Cargo.toml
Cargo.lock (most likely)
The above for all local dependencies (dependencies that have a path field, probably also local git repos)

In case you are not aware of these, there are a few crates that can be used to get the required metadata:

cargo_metadata
krates

There might be subtle, hard to debug bugs, if an incompatible heuristic is used.

I should have been more clear in my comment. It filters out all changes with files that do not match one of these extensions: rs, toml, css, html, and js. This seems to be similar to the approach cargo watch uses. This could result in some unwanted recompiles for files that are never actually in the binary, but I think it is fairly reasonable approach.
Tracking local dependencies could be a great feature to add in the future, but I don't think it is necessary for the initial implementation. Not tracking local dependencies shouldn't result in any unexpected behavior.
There are also some concerns that could become an issue as this crate grows:

The server is running in debug mode because the crate it is compiled in is running in debug mode, so performance could be an issue.

I believe Cargo watch is able to store hashes of the files instead of the actual file itself because it does not care about how the contents of the file change, just if they do. This implementation needs to store the files in memory to be able to diff the new and previous versions which is significantly more expensive. Specifically when the hot reloading initially starts and the application launches it needs to read all .rs files within the main directory into memory

Ultimately, without a use case that would require this I don't think it is worth complicating the API.

Yes, I think this is reasonable.

Which means what ever code is run in that closure would need to finish running before any rebuild was triggered so something like using cargo as a library would not work.

Just to clarify, cargo_metadata and krates use the output of cargo metadata (i.e., a build in sub-command of Cargo's CLI, which outputs JSON), and they don't depend on the cargo crate.

Source files could really be anywhere with macros (include_bytes, etc), so there isn't really a way we can capture all of the files.

You are right. Without interpreting the source code, there always will be possible corner cases.

Tracking local dependencies could be a great feature to add in the future, but I don't think it is necessary for the initial implementation.

That is reasonable.

Not tracking local dependencies shouldn't result in any unexpected behavior.

Wouldn't the following lead to unexpected behavior:
crate_1:
pub const FOO: i32 = 1;

crate_2:
rsx!{ "{crate_1::FOO}" }

If FOO is changed to 2, dioxus-hot-reload should recognize that a full re-build is required.
However, it would be reasonable to just mentioning in the docs that dependencies are not tracked.

The biggest disadvantage of not doing exactly what cargo or cargo watch does is, that dioxus-hot-reload can't be used as a (perfect) replacement of cargo watch. And I have no idea, how to archive that (any other way).
Even if dioxus-hot-reload creates a file if a complete rebuild is needed (as described above), and I run cargo watch --exec run --watch './.recompile', the --watch option results in cargo watch not watching local dependencies anymore (which I just realized).

The server is running in debug mode because the crate it is compiled in is running in debug mode, so performance could be an issue.

I had another look at the source code of this PR, and it seems the main reason why this is a macro, and not a sub-command of the CLI is to get CARGO_MANIFEST_DIR – is that correct?
If so: You can use the above-mentioned cargo_metadata crate to get that data (see here). cargo_metadata is intended for exactly this use-case.
Then the CLI could have a sub-command so that users would just execute something like dioxus run --hot-reload, without having to add a macro and a Cargo feature to activate/deactivate hot-reloading.
This would have the added benefit, that the CLI is compiled in release mode, and that dioxus-hot-reload (and its dependencies) wouldn't slow down compilation of the users' application.

Also, with a dioxus run --hot-reload (or dioxus watch) sub-command it probably would be not unreasonable to default to recompiling the application when a full re-build is required. With a macro that would seem a bit odd.

Not tracking local dependencies shouldn't result in any unexpected behavior.

Wouldn't the following lead to unexpected behavior:
crate_1:
pub const FOO: i32 = 1;

crate_2:
rsx!{ "{crate_1::FOO}" }

If FOO is changed to 2, dioxus-hot-reload should recognize that a full re-build is required.
However, it would be reasonable to just mentioning in the docs that dependencies are not tracked.

The biggest disadvantage of not doing exactly what cargo or cargo watch does is, that dioxus-hot-reload can't be used as a (perfect) replacement of cargo watch. And I have no idea, how to archive that (any other way).
Even if dioxus-hot-reload creates a file if a complete rebuild is needed (as described above), and I run cargo watch --exec run --watch './.recompile', the --watch option results in cargo watch not watching local dependencies anymore (which I just realized).

Personally I wouldn't expect this. This is the same behavior that the Dioxus CLI and Trunk have. This would be a great feature to add, but I don't think it is expected. In the same way if I used C bindings with cargo watch I wouldn't expect it to notice changes to the C bindings. You need to draw the line somewhere on what it watches or doesn't, different tools choose different points.
If you do want to track local dependencies, you could always add those paths to the watch paths explicitly. Or if this feature is important to you, you could add it in a follow up PR. I just don't personally have a use case for it, but I would be happy to help if you want help getting started! I believe there is a way to ignore files in cargo watch, could you ignore all of the files in the crate but still watch the dependencies?

The server is running in debug mode because the crate it is compiled in is running in debug mode, so performance could be an issue.

I had another look at the source code of this PR, and it seems the main reason why this is a macro, and not a sub-command of the CLI is to get CARGO_MANIFEST_DIR – is that correct?

The main reason for using a macro instead of integrating with the CLI is making hot reloading work without having to install the CLI.

If so: You can use the above-mentioned cargo_metadata crate to get that data (see here). cargo_metadata is intended for exactly this use-case.
Then the CLI could have a sub-command so that users would just execute something like dioxus run --hot-reload, without having to add a macro and a Cargo feature to activate/deactivate hot-reloading.
This would have the added benefit, that the CLI is compiled in release mode, and that dioxus-hot-reload (and its dependencies) wouldn't slow down compilation of the users' application.
Also, with a dioxus run --hot-reload (or dioxus watch) sub-command it probably would be not unreasonable to default to recompiling the application when a full re-build is required. With a macro that would seem a bit odd.

Each approach has tradeoffs:
Advantages for the CLI:

Better performance and faster compile times
Unification between web and native tools
Deduplication of commands: In order to get the full cli-like behavior with the macro approach you need to call the initial build command and add that command to the configuration of the macro.
You can track for file changes during recompiles: In the macro system if you trigger a recompile, and change a file during the recompile it will not detect the change because the watcher has not started yet.
External configuration files can be easily added to a .gitignore file to be ignored

Advantages for the macro approach:

You just need cargo run to get started / You don't need to install any external tools
Configuration is just rust code

Autocomplete and inline documentation for configuration

It is more clear how different namespaces could work with this approach. For libraries that use a non-html namespace with Dioxus (eg. Freya) there needs to be some way to configure a mapping between rust code and the resulting attribute/element names. With the macro approach these libraries can re-export the macro with a custom namespace default. With the CLI approach it is unclear how this would work. One approach is reading the configuration from a file, but that would require every user of Freya to download that file.

I'm open to either approach. Most of the hot reloading crate could be re-used as a library in the CLI.

Alright, that all makes sense. Thanks, for answering my questions and responding to my suggestions.

Each approach has tradeoffs:
Advantages for the macro approach:

Ah, I see.

I'm open to either approach. Most of the hot reloading crate could be re-used as a library in the CLI.

I'm interested in going through the hot-reloading code to see how it works, at some point. Maybe I'll then try to build a CLI sub-command with it (if nobody else has built it yet). It seems, both options would be valuable.


remove blas_openblas feature

it is being hotfixed out of the blas metapackage
so we don't need it anymore (we never should have added it,
but we couldn't remove it until blas was hotfixed to remove track_features

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.